[PATCH] drm/msm/hdm: Fix the error handling path of msm_hdmi_dev_probe()
If an error occurs after a successful msm_hdmi_get_phy() call, it must be
undone by a corresponding msm_hdmi_put_phy(), as already done in the
remove function.
Fixes: 437365464043 ("drm/msm/hdmi: move msm_hdmi_get_phy() to
msm_hdmi_dev_probe()")
Signed-off-by: Christophe JAILLET
---
Not sure if the Fixes tag is correct. At least it is when the probe needs
to be fixed but the issue was maybe there elsewhere before.
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 4d3fdc806bef..97372bb241d8 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -532,11 +532,19 @@ static int msm_hdmi_dev_probe(struct platform_device
*pdev)
ret = devm_pm_runtime_enable(>dev);
if (ret)
- return ret;
+ goto err_put_phy;
platform_set_drvdata(pdev, hdmi);
- return component_add(>dev, _hdmi_ops);
+ ret = component_add(>dev, _hdmi_ops);
+ if (ret)
+ goto err_put_phy;
+
+ return 0;
+
+err_put_phy:
+ msm_hdmi_put_phy(hdmi);
+ return ret;
}
static int msm_hdmi_dev_remove(struct platform_device *pdev)
--
2.34.1
Re: Screen corruption using radeon kernel driver
On 2022-12-10 10:32, Mikhail Krylov wrote: > On Wed, Nov 30, 2022 at 11:07:32AM -0500, Alex Deucher wrote: >> On Wed, Nov 30, 2022 at 10:42 AM Robin Murphy wrote: >>> >>> On 2022-11-30 14:28, Alex Deucher wrote: On Wed, Nov 30, 2022 at 7:54 AM Robin Murphy wrote: > > On 2022-11-29 17:11, Mikhail Krylov wrote: >> On Tue, Nov 29, 2022 at 11:05:28AM -0500, Alex Deucher wrote: >>> On Tue, Nov 29, 2022 at 10:59 AM Mikhail Krylov >>> wrote: On Tue, Nov 29, 2022 at 09:44:19AM -0500, Alex Deucher wrote: > On Mon, Nov 28, 2022 at 3:48 PM Mikhail Krylov > wrote: >> >> On Mon, Nov 28, 2022 at 09:50:50AM -0500, Alex Deucher wrote: >> > [excessive quoting removed] >> So, is there any progress on this issue? I do understand it's not a high priority one, and today I've checked it on 6.0 kernel, and unfortunately, it still persists... I'm considering writing a patch that will allow user to override need_dma32/dma_bits setting with a module parameter. I'll have some time after the New Year for that. Is it at all possible that such a patch will be merged into kernel? >>> On Mon, Nov 28, 2022 at 9:31 AM Mikhail Krylov >>> wrote: >>> Unless someone familiar with HIMEM can figure out what is going >>> wrong >>> we should just revert the patch. >>> >>> Alex >> >> >> Okay, I was suggesting that mostly because >> >> a) it works for me with dma_bits = 40 (I understand that's what it is >> without the original patch applied); >> >> b) there's a hint of uncertainity on this line >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/radeon_device.c#n1359 >> saying that for AGP dma_bits = 32 is the safest option, so >> apparently there are >> setups, unlike mine, where dma_bits = 32 is better than 40. >> >> But I'm in no position to argue, just wanted to make myself clear. >> I'm okay with rebuilding the kernel for my machine until the original >> patch is reverted or any other fix is applied. > > What GPU do you have and is it AGP? If it is AGP, does setting > radeon.agpmode=-1 also fix it? > > Alex That is ATI Radeon X1950, and, unfortunately, radeon.agpmode=-1 doesn't help, it just makes 3D acceleration in games such as OpenArena stop working. >>> >>> Just to confirm, is the board AGP or PCIe? >>> >>> Alex >> >> It is AGP. That's an old machine. > > Can you check whether dma_addressing_limited() is actually returning the > expected result at the point of radeon_ttm_init()? Disabling highmem is > presumably just hiding whatever problem exists, by throwing away all > >32-bit RAM such that use_dma32 doesn't matter. The device in question only supports a 32 bit DMA mask so dma_addressing_limited() should return true. Bounce buffers are not really usable on GPUs because they map so much memory. If dma_addressing_limited() returns false, that would explain it. >>> >>> Right, it appears to be the only part of the offending commit that >>> *could* reasonably make any difference, so I'm primarily wondering if >>> dma_get_required_mask() somehow gets confused. >> >> Mikhail, >> >> Can you see that dma_addressing_limited() and dma_get_required_mask() >> return in this case? >> >> Alex >> >> >>> >>> Thanks, >>> Robin. > > Hello again, I was able to confirm by adding printk() to the functions > and recompiling the kernel that dma_addressing_limited() returns > *false* on the kernel with the bug. > > And dma_get_required_mask() returns 0x7fff, as I said before. Yes, dma_addressing_limited() evaluates to "false" in your case, and this is the correct answer according to the function's comment: "Return %true if the devices DMA mask is too small to address all memory in the system, else %false." In this case the device's DMA mask is 0x and the mask for the 1.5 GiB memory is 0x7FFF, so the static inline returns "false". (dma_direct_get_required_mask() returns this for your memory size.) It would appear that dma_addressing_limited() isn't answering the question which the last parameter to ttm_device_init(), "use GFP_DMA32", wants answered. Perhaps we should use another method to make sure that that parameter is set in the scenario in question. Regards, Luben
Re: [PATCH v9 00/18] drm: bridge: Add Samsung MIPI DSIM bridge
On Sun, Dec 11, 2022 at 7:58 AM Marek Vasut wrote: > > On 12/9/22 16:23, Jagan Teki wrote: > > This series supports common bridge support for Samsung MIPI DSIM > > which is used in Exynos and i.MX8MM SoC's. > > > > The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. > > I wonder if it would rather make sense to split the series up and submit > all the various partial fixes and additions separately, instead of > piling them up in this series and ever growing the series. > > It seems to me 3..5 and 7..14 can just go in before the rest. Only 4 and 5 come under fixes and the rest of them seem dependent on the series. However, 4, and 5 are reproduced in i.MX8M platform hence I have added it as part of this series. Jagan,
Re: [PATCH v9 07/18] drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices
On Sun, Dec 11, 2022 at 7:58 AM Marek Vasut wrote:
>
> On 12/9/22 16:23, Jagan Teki wrote:
> > The child devices in MIPI DSI can be binding with OF-graph
> > and also via child nodes.
> >
> > The OF-graph interface represents the child devices via
> > remote and associated endpoint numbers like
> >
> > dsi {
> > compatible = "fsl,imx8mm-mipi-dsim";
> >
> > ports {
> > port@0 {
> >reg = <0>;
> >
> >dsi_in_lcdif: endpoint@0 {
> > reg = <0>;
> > remote-endpoint = <_out_dsi>;
> >};
> > };
> >
> > port@1 {
> >reg = <1>;
> >
> >dsi_out_bridge: endpoint {
> > remote-endpoint = <_in_dsi>;
> >};
> > };
> > };
> >
> > The child node interface represents the child devices via
> > conventional child nodes on given DSI parent like
> >
> > dsi {
> > compatible = "samsung,exynos5433-mipi-dsi";
> >
> > ports {
> > port@0 {
> > reg = <0>;
> >
> > dsi_to_mic: endpoint {
> >remote-endpoint = <_to_dsi>;
> > };
> > };
> > };
> >
> > panel@0 {
> > reg = <0>;
> > };
> > };
> >
> > As Samsung DSIM bridge is common DSI IP across all Exynos DSI
> > and NXP i.MX8M host controllers, this patch adds support to
> > lookup the child devices whether its bindings on the associated
> > host represent OF-graph or child node interfaces.
> >
> > v9, v8, v7, v6, v5, v4, v3:
> > * none
> >
> > v2:
> > * new patch
>
> This looks like a good candidate for common/helper code which can be
> reused by other similar drivers.
Yes, I have responded to the same comment of yours in v7 [1]. It is
hard to make this code work in a generic way.
[1]
https://lore.kernel.org/all/camty3zbtrz-vdpqyx+m8uwmsd+vmbfoncgvba8swq8gwtwa...@mail.gmail.com/
[PATCH] Documentation: gpu: vc4: add blank line separator before KUnit code block
kernel test robot reports htmldocs warning:
Documentation/gpu/vc4.rst:65: WARNING: Unexpected indentation.
The warning is due to missing blank line separator between KUnit mock
driver sentence and its code block.
Add the separator to fix the warning.
Link: https://lore.kernel.org/linux-doc/202212102116.a10vg3jg-...@intel.com/
Fixes: 5304c8e6010012 ("Documentation: gpu: vc4: Add KUnit Tests Section")
Reported-by: kernel test robot
Signed-off-by: Bagas Sanjaya
---
Documentation/gpu/vc4.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/gpu/vc4.rst b/Documentation/gpu/vc4.rst
index a2375f1584e6d9..ec920c4f5bb322 100644
--- a/Documentation/gpu/vc4.rst
+++ b/Documentation/gpu/vc4.rst
@@ -62,6 +62,7 @@ integration tests.
These tests are using a mock driver and can be ran using the
command::
+
./tools/testing/kunit/kunit.py run \
--kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \
--cross_compile aarch64-linux-gnu- --arch arm64
base-commit: 612e241fb4bcd98d8ff9da7a795abb86b8ccfe38
--
An old man doll... just what I always wanted! - Clara
Re: [PATCH v9 08/18] drm: bridge: samsung-dsim: Mark PHY as optional
On 12/9/22 16:23, Jagan Teki wrote: In i.MX8M Mini/Nano SoC the DSI Phy requires a MIPI DPHY bit 8M Plus too. to reset in order to activate the PHY and that can be done via upstream i.MX8M blk-ctrl driver. So, mark the phy get as optional. v9, v8, v7, v6, v5, v4, v3, v2: * none v1: * new patch Signed-off-by: Jagan Teki Reviewed-by: Marek Vasut H ... It seems like my comments on v7 of the series, and RBs were dropped ? Please double-check that and reinstate the RBs.
Re: [PATCH v9 00/18] drm: bridge: Add Samsung MIPI DSIM bridge
On 12/9/22 16:23, Jagan Teki wrote: This series supports common bridge support for Samsung MIPI DSIM which is used in Exynos and i.MX8MM SoC's. The final bridge supports both the Exynos and i.MX8M Mini/Nano/Plus. I wonder if it would rather make sense to split the series up and submit all the various partial fixes and additions separately, instead of piling them up in this series and ever growing the series. It seems to me 3..5 and 7..14 can just go in before the rest.
Re: [PATCH v9 05/18] drm: exynos: dsi: Properly name HSA/HBP/HFP/HSE bits
On 12/9/22 16:23, Jagan Teki wrote: HSA/HBP/HFP/HSE mode bits in Processor Reference Manuals specify a naming conversion as 'disable mode bit' due to its bit definition, 0 = Enable and 1 = Disable. For HSE bit, the i.MX 8M Mini/Nano/Plus Applications Processor Reference Manual named this bit as 'HseDisableMode' but the bit definition is quite opposite like 0 = Disables transfer 1 = Enables transfer which clearly states that HSE is not a disable bit. HSE is named as per the manual even though it is not a disable bit however the driver logic for handling HSE is based on the MIPI_DSI_MODE_VIDEO_HSE flag itself. Cc: Nicolas Boichat Signed-off-by: Jagan Teki Reviewed-by: Marek Vasut
Re: [PATCH v9 07/18] drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices
On 12/9/22 16:23, Jagan Teki wrote:
The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.
The OF-graph interface represents the child devices via
remote and associated endpoint numbers like
dsi {
compatible = "fsl,imx8mm-mipi-dsim";
ports {
port@0 {
reg = <0>;
dsi_in_lcdif: endpoint@0 {
reg = <0>;
remote-endpoint = <_out_dsi>;
};
};
port@1 {
reg = <1>;
dsi_out_bridge: endpoint {
remote-endpoint = <_in_dsi>;
};
};
};
The child node interface represents the child devices via
conventional child nodes on given DSI parent like
dsi {
compatible = "samsung,exynos5433-mipi-dsi";
ports {
port@0 {
reg = <0>;
dsi_to_mic: endpoint {
remote-endpoint = <_to_dsi>;
};
};
};
panel@0 {
reg = <0>;
};
};
As Samsung DSIM bridge is common DSI IP across all Exynos DSI
and NXP i.MX8M host controllers, this patch adds support to
lookup the child devices whether its bindings on the associated
host represent OF-graph or child node interfaces.
v9, v8, v7, v6, v5, v4, v3:
* none
v2:
* new patch
This looks like a good candidate for common/helper code which can be
reused by other similar drivers.
Re: [PATCH v9 04/18] drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags
On 12/9/22 16:23, Jagan Teki wrote:
HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies
0 = Enable and 1 = Disable.
The logic for checking these mode flags was correct before
the MIPI_DSI*_NO_* mode flag conversion.
Fix the MIPI_DSI*_NO_* mode flags handling.
Fixes: <0f3b68b66a6d> ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling
features")
Reviewed-by: Nicolas Boichat
Reported-by: Sébastien Szymanski
Signed-off-by: Jagan Teki
Reviewed-by: Marek Vasut
Re: [PATCH v9 03/18] drm: exynos: dsi: Restore proper bridge chain order
On 12/9/22 16:23, Jagan Teki wrote: From: Marek Szyprowski Restore the proper bridge chain by finding the previous bridge in the chain instead of passing NULL. This establishes a proper bridge chain while attaching downstream bridges. v9, v4: * none v3: * new patch Signed-off-by: Marek Szyprowski Signed-off-by: Jagan Teki Reviewed-by: Marek Vasut
Re: [PATCH 1/9] drm/amdgpu: generally allow over-commit during BO allocation
Am 2022-12-10 um 09:12 schrieb Christian König:
Am 10.12.22 um 07:15 schrieb Felix Kuehling:
On 2022-11-25 05:21, Christian König wrote:
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those workarounds and generalize this for GTT as well. This
fixes ENOMEM issues with runaway applications which try to
allocate/free
GTT in a loop and are otherwise only limited by the CPU speed.
The CS will wait for the cleanup of freed up BOs to satisfy the
various domain specific limits and so effectively throttle those
buggy applications down to a sane allocation behavior again.
Signed-off-by: Christian König
This patch causes some regressions in KFDTest. KFDMemoryTest.MMBench
sees a huge VRAM allocation slow-down. And
KFDMemoryTest.LargestVramBufferTest can only allocate half the
available memory.
Mhm, I wasn't expecting that we use this for the KFD as well.
Yeah, we use amdgpu_gem_object_create. I guess we could duplicate its
functionality or add a "no_overcommit" or "greedy" parameter for our needs.
This seems to be caused by initially validating VRAM BOs in the CPU
domain, which allocates a ttm_tt. A subsequent validation in the VRAM
domain involves a copy from GTT to VRAM.
The idea was to initially create the BOs without any backing store.
I thought about it a bit more. I believe the BO creation without backing
store is working as expected. But amdgpu_bo_move can't move the
uninitialized BO directly from system to VRAM. It returns -EMULTIHOP. So
the BO gets moved to GTT first (allocating system memory) before it can
be migrated to VRAM. That adds a bunch of overhead with unnecessary
system memory allocation and forces all VRAM to be zero-initialized on
the CPU and copied through PCIe. I think your idea would work with
almost no overhead if amdgpu_bo_move could directly move a BO without
backing store to VRAM with ttm_bo_move_null.
Regards,
Felix
After that, freeing of BOs can get delayed by the ghost object of a
previous migration, which delays calling release notifiers and causes
problems for KFDs available memory accounting.
I experimented with a workaround that validates BOs immediately after
allocation, but that only moves around the delays and doesn't solve
the problem. During those experiments I may also have stumbled over a
bug in ttm_buffer_object_transfer: It calls ttm_bo_set_bulk_move
before initializing and locking fbo->base.base._resv. This results in
a flood of warnings because ttm_bo_set_bulk_move expects the
reservation to be locked.
Right now I'd like to remove the bp.domain = initial_domain |
AMDGPU_GEM_DOMAIN_CPU change in amdgpu_gem_object_create to fix this.
Yeah, let's revert and investigate this first.
Thanks,
Christian.
Regards,
Felix
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 16 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index a0780a4e3e61..62e98f1ad770 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -113,7 +113,7 @@ int amdgpu_gem_object_create(struct
amdgpu_device *adev, unsigned long size,
bp.resv = resv;
bp.preferred_domain = initial_domain;
bp.flags = flags;
- bp.domain = initial_domain;
+ bp.domain = initial_domain | AMDGPU_GEM_DOMAIN_CPU;
bp.bo_ptr_size = sizeof(struct amdgpu_bo);
r = amdgpu_bo_create_user(adev, , );
@@ -332,20 +332,10 @@ int amdgpu_gem_create_ioctl(struct drm_device
*dev, void *data,
}
initial_domain = (u32)(0x & args->in.domains);
-retry:
r = amdgpu_gem_object_create(adev, size, args->in.alignment,
- initial_domain,
- flags, ttm_bo_type_device, resv, );
+ initial_domain, flags, ttm_bo_type_device,
+ resv, );
if (r && r != -ERESTARTSYS) {
- if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
- flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
- goto retry;
- }
-
- if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
- initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
- goto retry;
- }
DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu,
%d)\n",
size, initial_domain, args->in.alignment, r);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 974e85d8b6cc..919bbea2e3ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -581,11 +581,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;
bo->tbo.bdev = >mman.bdev;
- if (bp->domain &
Re: [PATCH v2 00/11] pwm: Allow .get_state to fail
Hello Andy, On Sat, Dec 10, 2022 at 10:57:16PM +0200, Andy Shevchenko wrote: > On Sat, Dec 10, 2022 at 10:18:33AM +0100, Uwe Kleine-König wrote: > > On Fri, Dec 09, 2022 at 11:47:54PM +0200, Andy Shevchenko wrote: > > > On Wed, Nov 30, 2022 at 04:21:37PM +0100, Uwe Kleine-König wrote: > > ... > > > > I'm wondering why we didn't see a compiler warning about mistyped function > > > prototypes in some drivers. > > > > I don't understand where you expected a warning. Care to elaborate? > > intel-lpss.c has the prototype that returns an int. IIRC it was like this Do you mean drivers/mfd/intel-lpss.c? That one doesn't implement a PWM?! And drivers/pwm/pwm-lpss.c is adapted by this series. One of us is confused ... Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH v2 00/11] pwm: Allow .get_state to fail
On Sat, Dec 10, 2022 at 10:18:33AM +0100, Uwe Kleine-König wrote: > On Fri, Dec 09, 2022 at 11:47:54PM +0200, Andy Shevchenko wrote: > > On Wed, Nov 30, 2022 at 04:21:37PM +0100, Uwe Kleine-König wrote: ... > > I'm wondering why we didn't see a compiler warning about mistyped function > > prototypes in some drivers. > > I don't understand where you expected a warning. Care to elaborate? intel-lpss.c has the prototype that returns an int. IIRC it was like this before your patches. Now the above wondering passage... -- With Best Regards, Andy Shevchenko
Re: [PATCH] fbdev: make offb driver tristate
On 11/26/22 14:40, Thomas Zimmermann wrote: Am 26.11.22 um 01:04 schrieb Randy Dunlap: Make the offb (Open Firmware frame buffer) driver tristate, i.e., so that it can be built as a loadable module. However, it still depends on the setting of DRM_OFDRM so that both of these drivers cannot be builtin at the same time nor can one be builtin and the other one a loadable module. Build-tested successfully with all combination of DRM_OFDRM and FB_OF. This fixes a build issue that Michal reported when FB_OF=y and DRM_OFDRM=m: powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x58): undefined reference to `cfb_fillrect' powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x60): undefined reference to `cfb_copyarea' powerpc64-linux-ld: drivers/video/fbdev/offb.o:(.data.rel.ro+0x68): undefined reference to `cfb_imageblit' Signed-off-by: Randy Dunlap Suggested-by: Arnd Bergmann Cc: Masahiro Yamada Cc: Thomas Zimmermann Cc: Michal Suchánek Cc: linuxppc-...@lists.ozlabs.org Cc: Daniel Vetter Cc: Helge Deller Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Acked-by: Thomas Zimmermann applied. Thanks! Helge --- drivers/video/fbdev/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -456,8 +456,8 @@ config FB_ATARI chipset found in Ataris. config FB_OF - bool "Open Firmware frame buffer device support" - depends on (FB = y) && PPC && (!PPC_PSERIES || PCI) + tristate "Open Firmware frame buffer device support" + depends on FB && PPC && (!PPC_PSERIES || PCI) depends on !DRM_OFDRM select APERTURE_HELPERS select FB_CFB_FILLRECT
Re: [PATCH] fbdev: fbcon: release buffer when fbcon_do_set_font() failed
On 12/5/22 23:10, Tetsuo Handa wrote:
syzbot is reporting memory leak at fbcon_do_set_font() [1], for
commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when
vc_resize() failed") missed that the buffer might be newly allocated
by fbcon_set_font().
Link: https://syzkaller.appspot.com/bug?extid=25bdb7b1703639abd498 [1]
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize()
failed")
applied.
Thanks!
Helge
---
drivers/video/fbdev/core/fbcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 098b62f7b701..8363f3b2b452 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2450,7 +2450,8 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
if (userfont) {
p->userfont = old_userfont;
- REFCOUNT(data)--;
+ if (--REFCOUNT(data) == 0)
+ kfree(data - FONT_EXTRA_WORDS * sizeof(int));
}
vc->vc_font.width = old_width;
Re: [PATCH linux-next v3] fbdev: use sysfs_emit() to instead of scnprintf()
On 12/5/22 09:31, ye.xingc...@zte.com.cn wrote: From: ye xingchen Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by: ye xingchen I've applied this patch, but split it up into two (one for each driver). Please, send seperate patches per driver next time (and add proper changelog if you do a v2/v3 version). Thanks! Helge --- v2 -> v3 Fix the mistakes in v2. drivers/video/fbdev/sh_mobile_lcdcfb.c | 8 drivers/video/fbdev/uvesafb.c | 10 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c index 6d00893d41f4..ad9323ed8e2e 100644 --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c @@ -1188,7 +1188,7 @@ overlay_alpha_show(struct device *dev, struct device_attribute *attr, char *buf) struct fb_info *info = dev_get_drvdata(dev); struct sh_mobile_lcdc_overlay *ovl = info->par; - return scnprintf(buf, PAGE_SIZE, "%u\n", ovl->alpha); + return sysfs_emit(buf, "%u\n", ovl->alpha); } static ssize_t @@ -1226,7 +1226,7 @@ overlay_mode_show(struct device *dev, struct device_attribute *attr, char *buf) struct fb_info *info = dev_get_drvdata(dev); struct sh_mobile_lcdc_overlay *ovl = info->par; - return scnprintf(buf, PAGE_SIZE, "%u\n", ovl->mode); + return sysfs_emit(buf, "%u\n", ovl->mode); } static ssize_t @@ -1265,7 +1265,7 @@ overlay_position_show(struct device *dev, struct device_attribute *attr, struct fb_info *info = dev_get_drvdata(dev); struct sh_mobile_lcdc_overlay *ovl = info->par; - return scnprintf(buf, PAGE_SIZE, "%d,%d\n", ovl->pos_x, ovl->pos_y); + return sysfs_emit(buf, "%d,%d\n", ovl->pos_x, ovl->pos_y); } static ssize_t @@ -1306,7 +1306,7 @@ overlay_rop3_show(struct device *dev, struct device_attribute *attr, char *buf) struct fb_info *info = dev_get_drvdata(dev); struct sh_mobile_lcdc_overlay *ovl = info->par; - return scnprintf(buf, PAGE_SIZE, "%u\n", ovl->rop3); + return sysfs_emit(buf, "%u\n", ovl->rop3); } static ssize_t diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c index 00d789b6c0fa..ba8028a0cc7a 100644 --- a/drivers/video/fbdev/uvesafb.c +++ b/drivers/video/fbdev/uvesafb.c @@ -1580,7 +1580,7 @@ static ssize_t uvesafb_show_vendor(struct device *dev, struct uvesafb_par *par = info->par; if (par->vbe_ib.oem_vendor_name_ptr) - return scnprintf(buf, PAGE_SIZE, "%s\n", (char *) + return sysfs_emit(buf, "%s\n", (char *) (>vbe_ib) + par->vbe_ib.oem_vendor_name_ptr); else return 0; @@ -1595,7 +1595,7 @@ static ssize_t uvesafb_show_product_name(struct device *dev, struct uvesafb_par *par = info->par; if (par->vbe_ib.oem_product_name_ptr) - return scnprintf(buf, PAGE_SIZE, "%s\n", (char *) + return sysfs_emit(buf, "%s\n", (char *) (>vbe_ib) + par->vbe_ib.oem_product_name_ptr); else return 0; @@ -1610,7 +1610,7 @@ static ssize_t uvesafb_show_product_rev(struct device *dev, struct uvesafb_par *par = info->par; if (par->vbe_ib.oem_product_rev_ptr) - return scnprintf(buf, PAGE_SIZE, "%s\n", (char *) + return sysfs_emit(buf, "%s\n", (char *) (>vbe_ib) + par->vbe_ib.oem_product_rev_ptr); else return 0; @@ -1625,7 +1625,7 @@ static ssize_t uvesafb_show_oem_string(struct device *dev, struct uvesafb_par *par = info->par; if (par->vbe_ib.oem_string_ptr) - return scnprintf(buf, PAGE_SIZE, "%s\n", + return sysfs_emit(buf, "%s\n", (char *)(>vbe_ib) + par->vbe_ib.oem_string_ptr); else return 0; @@ -1639,7 +1639,7 @@ static ssize_t uvesafb_show_nocrtc(struct device *dev, struct fb_info *info = dev_get_drvdata(dev); struct uvesafb_par *par = info->par; - return scnprintf(buf, PAGE_SIZE, "%d\n", par->nocrtc); + return sysfs_emit(buf, "%d\n", par->nocrtc); } static ssize_t uvesafb_store_nocrtc(struct device *dev,
Re: [PATCH v2 1/2] video: fbdev: uvesafb: Fixes an error handling path in uvesafb_probe()
On 12/10/22 12:35, Christophe JAILLET wrote:
If an error occurs after a successful uvesafb_init_mtrr() call, it must be
undone by a corresponding arch_phys_wc_del() call, as already done in the
remove function.
This has been added in the remove function in commit 63e28a7a5ffc
("uvesafb: Clean up MTRR code")
Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core")
Signed-off-by: Christophe JAILLET
Both patches applied.
Thanks!
Helge
---
Unsure about the Fixes tag, maybe it is 63e28a7a5ffc
Change in v2:
- add arch_phys_wc_del() at the right place in the error handling path
v1 (a long time ago!):
https://lore.kernel.org/all/dd2a4806d3a570ab84947806f38a494454fd0245.1622994310.git.christophe.jail...@wanadoo.fr/
---
drivers/video/fbdev/uvesafb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 00d789b6c0fa..0e3cabbec4b4 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1758,6 +1758,7 @@ static int uvesafb_probe(struct platform_device *dev)
out_unmap:
iounmap(info->screen_base);
out_mem:
+ arch_phys_wc_del(par->mtrr_handle);
release_mem_region(info->fix.smem_start, info->fix.smem_len);
out_reg:
release_region(0x3c0, 32);
Re: [PATCH 1/9] drm/amdgpu: generally allow over-commit during BO allocation
Am 10.12.22 um 07:15 schrieb Felix Kuehling:
On 2022-11-25 05:21, Christian König wrote:
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those workarounds and generalize this for GTT as well. This
fixes ENOMEM issues with runaway applications which try to allocate/free
GTT in a loop and are otherwise only limited by the CPU speed.
The CS will wait for the cleanup of freed up BOs to satisfy the
various domain specific limits and so effectively throttle those
buggy applications down to a sane allocation behavior again.
Signed-off-by: Christian König
This patch causes some regressions in KFDTest. KFDMemoryTest.MMBench
sees a huge VRAM allocation slow-down. And
KFDMemoryTest.LargestVramBufferTest can only allocate half the
available memory.
Mhm, I wasn't expecting that we use this for the KFD as well.
This seems to be caused by initially validating VRAM BOs in the CPU
domain, which allocates a ttm_tt. A subsequent validation in the VRAM
domain involves a copy from GTT to VRAM.
The idea was to initially create the BOs without any backing store.
After that, freeing of BOs can get delayed by the ghost object of a
previous migration, which delays calling release notifiers and causes
problems for KFDs available memory accounting.
I experimented with a workaround that validates BOs immediately after
allocation, but that only moves around the delays and doesn't solve
the problem. During those experiments I may also have stumbled over a
bug in ttm_buffer_object_transfer: It calls ttm_bo_set_bulk_move
before initializing and locking fbo->base.base._resv. This results in
a flood of warnings because ttm_bo_set_bulk_move expects the
reservation to be locked.
Right now I'd like to remove the bp.domain = initial_domain |
AMDGPU_GEM_DOMAIN_CPU change in amdgpu_gem_object_create to fix this.
Yeah, let's revert and investigate this first.
Thanks,
Christian.
Regards,
Felix
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 16 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index a0780a4e3e61..62e98f1ad770 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -113,7 +113,7 @@ int amdgpu_gem_object_create(struct amdgpu_device
*adev, unsigned long size,
bp.resv = resv;
bp.preferred_domain = initial_domain;
bp.flags = flags;
- bp.domain = initial_domain;
+ bp.domain = initial_domain | AMDGPU_GEM_DOMAIN_CPU;
bp.bo_ptr_size = sizeof(struct amdgpu_bo);
r = amdgpu_bo_create_user(adev, , );
@@ -332,20 +332,10 @@ int amdgpu_gem_create_ioctl(struct drm_device
*dev, void *data,
}
initial_domain = (u32)(0x & args->in.domains);
-retry:
r = amdgpu_gem_object_create(adev, size, args->in.alignment,
- initial_domain,
- flags, ttm_bo_type_device, resv, );
+ initial_domain, flags, ttm_bo_type_device,
+ resv, );
if (r && r != -ERESTARTSYS) {
- if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
- flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
- goto retry;
- }
-
- if (initial_domain == AMDGPU_GEM_DOMAIN_VRAM) {
- initial_domain |= AMDGPU_GEM_DOMAIN_GTT;
- goto retry;
- }
DRM_DEBUG("Failed to allocate GEM object (%llu, %d, %llu,
%d)\n",
size, initial_domain, args->in.alignment, r);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 974e85d8b6cc..919bbea2e3ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -581,11 +581,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE;
bo->tbo.bdev = >mman.bdev;
- if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA |
- AMDGPU_GEM_DOMAIN_GDS))
- amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
- else
- amdgpu_bo_placement_from_domain(bo, bp->domain);
+ amdgpu_bo_placement_from_domain(bo, bp->domain);
if (bp->type == ttm_bo_type_kernel)
bo->tbo.priority = 1;
[drm-misc:drm-misc-next 20/26] htmldocs: Documentation/gpu/vc4.rst:65: WARNING: Unexpected indentation.
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next head: 612e241fb4bcd98d8ff9da7a795abb86b8ccfe38 commit: 5304c8e60100120c25557037edcc85791cb33a9a [20/26] Documentation: gpu: vc4: Add KUnit Tests Section reproduce: git remote add drm-misc git://anongit.freedesktop.org/drm/drm-misc git fetch --no-tags drm-misc drm-misc-next git checkout 5304c8e60100120c25557037edcc85791cb33a9a make menuconfig # enable CONFIG_COMPILE_TEST, CONFIG_WARN_MISSING_DOCUMENTS, CONFIG_WARN_ABI_ERRORS make htmldocs If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot All warnings (new ones prefixed by >>): >> Documentation/gpu/vc4.rst:65: WARNING: Unexpected indentation. vim +65 Documentation/gpu/vc4.rst 62 63 These tests are using a mock driver and can be ran using the 64 command:: > 65 ./tools/testing/kunit/kunit.py run \ 66 --kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \ 67 --cross_compile aarch64-linux-gnu- --arch arm64 68 -- 0-DAY CI Kernel Test Service https://01.org/lkp # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 6.1.0-rc6 Kernel Configuration # CONFIG_CC_VERSION_TEXT="gcc-11 (Debian 11.3.0-8) 11.3.0" CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=110300 CONFIG_CLANG_VERSION=0 CONFIG_AS_IS_GNU=y CONFIG_AS_VERSION=23900 CONFIG_LD_IS_BFD=y CONFIG_LD_VERSION=23900 CONFIG_LLD_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_CAN_LINK_STATIC=y CONFIG_CC_HAS_ASM_GOTO_OUTPUT=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_CC_HAS_NO_PROFILE_FN_ATTR=y CONFIG_PAHOLE_VERSION=123 CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_TABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_COMPILE_TEST=y # CONFIG_WERROR is not set CONFIG_LOCALVERSION="" CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_HAVE_KERNEL_ZSTD=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set # CONFIG_KERNEL_ZSTD is not set CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set # CONFIG_WATCH_QUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_HAVE_POSIX_CPU_TIMERS_TASK_WORK=y CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_CLOCKSOURCE_WATCHDOG_MAX_SKEW_US=100 # end of Timers subsystem CONFIG_HAVE_EBPF_JIT=y CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y # # BPF subsystem # # CONFIG_BPF_SYSCALL is not set # end of BPF subsystem CONFIG_PREEMPT_NONE_BUILD=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_DYNAMIC is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_PSI is not set # end of CPU/Task time and stats accounting CONFIG_CPU_ISOLATION=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TINY_SRCU=y # end of RCU Subsystem # CONFIG_IKCONFIG is not set # CONFIG_IKHEADERS is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_CC_HAS_INT128=y CONFIG_CC_IMPLICIT_FALLTHROUGH="-Wimplicit-fallthrough=5" CONFIG_GCC12_NO_ARRAY_BOUNDS=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_CGROUPS is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_TIME_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_BOOT_CONFIG is not set # CONFIG_INITRAMFS_PRESERVE_MTIME is not set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
[PATCH v2 2/2] video: fbdev: uvesafb: Simplify uvesafb_remove()
When the remove() function is called, we know that the probe() function has
successfully been executed. So 'info' is known to be not NULL.
Simplify the code accordingly.
Signed-off-by: Christophe JAILLET
---
Change in v2:
- new patch
---
drivers/video/fbdev/uvesafb.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 0e3cabbec4b4..2bb95c35ab2a 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1777,25 +1777,23 @@ static int uvesafb_probe(struct platform_device *dev)
static int uvesafb_remove(struct platform_device *dev)
{
struct fb_info *info = platform_get_drvdata(dev);
+ struct uvesafb_par *par = info->par;
- if (info) {
- struct uvesafb_par *par = info->par;
+ sysfs_remove_group(>dev.kobj, _dev_attgrp);
+ unregister_framebuffer(info);
+ release_region(0x3c0, 32);
+ iounmap(info->screen_base);
+ arch_phys_wc_del(par->mtrr_handle);
+ release_mem_region(info->fix.smem_start, info->fix.smem_len);
+ fb_destroy_modedb(info->monspecs.modedb);
+ fb_dealloc_cmap(>cmap);
- sysfs_remove_group(>dev.kobj, _dev_attgrp);
- unregister_framebuffer(info);
- release_region(0x3c0, 32);
- iounmap(info->screen_base);
- arch_phys_wc_del(par->mtrr_handle);
- release_mem_region(info->fix.smem_start, info->fix.smem_len);
- fb_destroy_modedb(info->monspecs.modedb);
- fb_dealloc_cmap(>cmap);
+ kfree(par->vbe_modes);
+ kfree(par->vbe_state_orig);
+ kfree(par->vbe_state_saved);
- kfree(par->vbe_modes);
- kfree(par->vbe_state_orig);
- kfree(par->vbe_state_saved);
+ framebuffer_release(info);
- framebuffer_release(info);
- }
return 0;
}
--
2.34.1
[PATCH v2 1/2] video: fbdev: uvesafb: Fixes an error handling path in uvesafb_probe()
If an error occurs after a successful uvesafb_init_mtrr() call, it must be
undone by a corresponding arch_phys_wc_del() call, as already done in the
remove function.
This has been added in the remove function in commit 63e28a7a5ffc
("uvesafb: Clean up MTRR code")
Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core")
Signed-off-by: Christophe JAILLET
---
Unsure about the Fixes tag, maybe it is 63e28a7a5ffc
Change in v2:
- add arch_phys_wc_del() at the right place in the error handling path
v1 (a long time ago!):
https://lore.kernel.org/all/dd2a4806d3a570ab84947806f38a494454fd0245.1622994310.git.christophe.jail...@wanadoo.fr/
---
drivers/video/fbdev/uvesafb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 00d789b6c0fa..0e3cabbec4b4 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1758,6 +1758,7 @@ static int uvesafb_probe(struct platform_device *dev)
out_unmap:
iounmap(info->screen_base);
out_mem:
+ arch_phys_wc_del(par->mtrr_handle);
release_mem_region(info->fix.smem_start, info->fix.smem_len);
out_reg:
release_region(0x3c0, 32);
--
2.34.1
Re: [PATCH] drm: Drop ARCH_MULTIPLATFORM from dependencies
Hello Arnd,
On Fri, Dec 09, 2022 at 11:53:49PM +0100, Arnd Bergmann wrote:
> On Fri, Dec 9, 2022, at 23:05, Uwe Kleine-König wrote:
> > Some of these dependencies used to be sensible when only a small part of
> > the platforms supported by ARCH=arm could be compiled together in a
> > single kernel image. Nowadays ARCH_MULTIPLATFORM is only used as a guard
> > for kernel options incompatible with a multiplatform image. See commit
> > 84fc86360623 ("ARM: make ARCH_MULTIPLATFORM user-visible") for some more
> > details.
> >
> > Signed-off-by: Uwe Kleine-König
>
> Makes sense,
>
> Acked-by: Arnd Bergmann
Thanks. (But honestly I'm not surprised you agree to this patch after
our conversation on irc :-)
> > diff --git a/drivers/gpu/drm/omapdrm/Kconfig
> > b/drivers/gpu/drm/omapdrm/Kconfig
> > index 455e1a91f0e5..76ded1568bd0 100644
> > --- a/drivers/gpu/drm/omapdrm/Kconfig
> > +++ b/drivers/gpu/drm/omapdrm/Kconfig
> > @@ -2,7 +2,7 @@
> > config DRM_OMAP
> > tristate "OMAP DRM"
> > depends on DRM && OF
> > - depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
> > + depends on ARCH_OMAP2PLUS
> > select DRM_KMS_HELPER
> > select VIDEOMODE_HELPERS
> > select HDMI
>
> Since the original purpose of the ||ARCH_MULTIPLATFORM was to allow
> building the driver on more targets, I wonder if we should instead
> make that ||COMPILE_TEST, which would also allow building it on
> x86 and others.
I wondered about that, too, but thought that would be a new patch.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [syzbot] WARNING in drm_wait_one_vblank
On Fri, 09 Dec 2022 17:41:23 +0530, syzbot wrote > syzbot has tested the proposed patch but the reproducer is still triggering > an issue: I keep getting "ERROR: Out of memory at tomoyo_realpath_from_path." and cannot reproduce the crash...
Re: [syzbot] WARNING in drm_wait_one_vblank
Test the reproducer on latest. #syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
Re: [PATCH v2 00/11] pwm: Allow .get_state to fail
Hello Andy, On Fri, Dec 09, 2022 at 11:47:54PM +0200, Andy Shevchenko wrote: > On Wed, Nov 30, 2022 at 04:21:37PM +0100, Uwe Kleine-König wrote: > > In v1 Thierry had the concern: > > > > | That raises the question about what to do in these cases. If we return > > | an error, that could potentially throw off consumers. So perhaps the > > | closest would be to return a disabled PWM? Or perhaps it'd be up to the > > | consumer to provide some fallback configuration for invalidly configured > > | or unconfigured PWMs. > > > > .get_state() is only called in pwm_device_request on a pwm_state that a > > consumer might see. Before my series a consumer might have seen a > > partial modified pwm_state (because .get_state() might have modified > > .period, then stumbled and returned silently). The last patch ensures > > that this partial modification isn't given out to the consumer. Instead > > they now see the same as if .get_state wasn't implemented at all. > > I'm wondering why we didn't see a compiler warning about mistyped function > prototypes in some drivers. I don't understand where you expected a warning. Care to elaborate? > P.S. The series is good thing to do, thank you. It's already too late for an ack, the series is already in Thierry's tree. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
