Re: [PATCH] drm/amdgpu: Fix NULL pointer dereference
Christian König, Simon Ser In fact, the code looks strange, we return the return code, but for some reason we also write false and 0. In my opinion, the caller should do this. Of course, you are right, but I look from the position that nothing should fall in the user system. There may be strange errors that occur periodically under certain conditions and do not affect developers. Also, the user will not always be able to correctly write a bug report. Regards, Grigory. пт, 8 апр. 2022 г. в 17:30, Christian König : > > Am 08.04.22 um 15:21 schrieb Grigory Vasilyev: > > Simon Ser and Bas Nieuwenhuizen, do you understand that you are > > proposing to make the code less safe in the future? In the future, > > someone might rewrite the code and we'll get an error. > > Which is perfectly fine. > > See error handling is to handle userspace or hardware errors and *not* > coding errors. > > Testing all pointers for NULL without any reason is not defensive, but > rather the exactly opposite since it helps hiding real bugs. > > Regards, > Christian. > > > > > пт, 8 апр. 2022 г. в 14:48, Simon Ser : > >> On Friday, April 8th, 2022 at 13:28, Bas Nieuwenhuizen > >> wrote: > >> > >>> On Fri, Apr 8, 2022 at 12:01 PM Simon Ser cont...@emersion.fr wrote: > >>> > Is amdgpu_display_get_fb_info ever called with NULL > tiling_flags/tmz_surface? > If not, there's no point in adding NULL checks. > >>> It isn't called with NULL anywhere, the NULL checks that already exist > >>> seem redundant. > >> Grigory, would be be willing to submit a v2 which removes the unnecessary > >> NULL checks? >
Re: [PATCH] drm/amdgpu: Senseless code and unnecessary memset
Christian König in fact the compiler will very often replace {0} with
a memset call. I don't see a problem using {0} for local arrays with
primitive types.
There should also be no problem with memory alignment. Because the
compiler understands it. Using sizeof is also not a good idea.
More often everyone also makes mistakes with sizeof. It's best to
leave it as is, and there's no errors.
Indeed, when using structures and {0}, errors may occur, but I am not
aware of errors when using primitive types. I also looked at the
amdgpu code and {0} is used in many places.
Also from experience malloc+memset is the most dangerous chain, can
silently damage memory, causing a bunch of subtle problems, and it is
better to replace them with more safe calloc.
Such a problem, for example, was recently found by me in fontconfig
and it crashed intel quartus. Therefore, where possible, I try to
avoid memset.
Regards, Grigory.
ср, 6 апр. 2022 г. в 17:43, Christian König :
>
> Am 06.04.22 um 16:26 schrieb Jani Nikula:
> > On Tue, 05 Apr 2022, Christian König wrote:
> >> Am 05.04.22 um 19:36 schrieb Grigory Vasilyev:
> >>> Using memset on local arrays before exiting the function is pointless.
> >>> Compilator will remove this code. Also for local arrays is preferable to
> >>> use {0} instead of memset. Mistakes are often made when working with
> >>> memset.
> >> Well actually memset is preferred when working with structures which are
> >> given to the hardware parser because {0} won't initialize paddings.
> > Not that I'd know anything that's going on here... but it sure seems
> > strange to me to be passing unpacked structures where the padding might
> > matter to a "hardware parser".
>
> Well to me it is an absolute miracle why the heck compilers don't
> initialize paddings.
>
> We had so many ups moments over the years and I really don't see why it
> should be more optimal to do this.
>
> Anyway, the memset() is used intentionally here and I don't really want
> to change it. What we could do is removing the second superfluous memset
> and use sizeof() instead of hard coding the size.
>
> Regards,
> Christian.
>
> >
> > *shrug*
> >
> >
> > BR,
> > Jani.
> >
> >
> >> So please don't use {0} in any of the atom bios code.
> >>
> >> Regards,
> >> Christian.
> >>
> >>> Signed-off-by: Grigory Vasilyev
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/atom.c | 8 +---
> >>>1 file changed, 1 insertion(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> b/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> index be9d61bcb8ae..537e48fbbe6b 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> >>> @@ -1538,11 +1538,9 @@ struct atom_context *amdgpu_atom_parse(struct
> >>> card_info *card, void *bios)
> >>>int amdgpu_atom_asic_init(struct atom_context *ctx)
> >>>{
> >>> int hwi = CU16(ctx->data_table + ATOM_DATA_FWI_PTR);
> >>> - uint32_t ps[16];
> >>> + uint32_t ps[16] = {0};
> >>> int ret;
> >>>
> >>> - memset(ps, 0, 64);
> >>> -
> >>> ps[0] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFSCLK_PTR));
> >>> ps[1] = cpu_to_le32(CU32(hwi + ATOM_FWI_DEFMCLK_PTR));
> >>> if (!ps[0] || !ps[1])
> >>> @@ -1551,10 +1549,6 @@ int amdgpu_atom_asic_init(struct atom_context *ctx)
> >>> if (!CU16(ctx->cmd_table + 4 + 2 * ATOM_CMD_INIT))
> >>> return 1;
> >>> ret = amdgpu_atom_execute_table(ctx, ATOM_CMD_INIT, ps);
> >>> - if (ret)
> >>> - return ret;
> >>> -
> >>> - memset(ps, 0, 64);
> >>>
> >>> return ret;
> >>>}
>
Re: vc4: Couldn't stop firmware display driver during boot
Am 09.04.22 um 21:25 schrieb Stefan Wahren: Hi, today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected to my HDMI display (multi_v7_defconfig + CONFIG_ARM_LPAE, firmware: 2021-01-08T14:31:16) and i'm getting these strange errors from raspberrypi-firmware driver / vc4 during boot: [ 13.094733] fb0: switching to vc4 from simple [ 13.110759] Console: switching to colour dummy device 80x30 [ 13.120691] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.120715] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 This is a new error which was introduced with Linux 5.18-rc1 (c406ad5e4a85 "drm/vc4: Notify the firmware when DRM is in charge"). 0x00030066 stands for the new firmware property RPI_FIRMWARE_NOTIFY_DISPLAY_DONE. And i guess the firmware from January 2021 doesn't support it? [ 13.120839] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) [ 13.121213] Bluetooth: Core ver 2.22 [ 13.121266] NET: Registered PF_BLUETOOTH protocol family [ 13.121270] Bluetooth: HCI device and connection manager initialized [ 13.121281] Bluetooth: HCI socket layer initialized [ 13.121286] Bluetooth: L2CAP socket layer initialized [ 13.121297] Bluetooth: SCO socket layer initialized [ 13.132879] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 13.164278] Bluetooth: HCI UART driver ver 2.3 [ 13.164293] Bluetooth: HCI UART protocol H4 registered [ 13.166608] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.166633] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.166717] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.176173] Bluetooth: HCI UART protocol Broadcom registered [ 13.182365] hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator [ 13.182505] hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator [ 13.300636] uart-pl011 fe201000.serial: no DMA platform data [ 13.422683] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.422700] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.422788] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.458620] bcmgenet fd58.ethernet: GENET 5.0 EPHY: 0x [ 13.461925] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.461941] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.462006] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.469287] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 13.507497] vc4-drm gpu: bound fef00700.hdmi (ops vc4_drm_unregister [vc4]) [ 13.521840] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9 [ 13.522128] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.raspberrypi,400.bin failed with error -2 [ 13.535444] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.raspberrypi,400.txt failed with error -2 [ 13.564153] Bluetooth: hci0: BCM: chip id 130 [ 13.564675] Bluetooth: hci0: BCM: features 0x0f [ 13.566157] Bluetooth: hci0: BCM4345C5 [ 13.566164] Bluetooth: hci0: BCM4345C5 (003.006.006) build [ 13.568434] Bluetooth: hci0: BCM4345C5 'brcm/BCM4345C5.hcd' Patch [ 13.570485] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus [ 13.576820] vc4-drm gpu: bound fef05700.hdmi (ops vc4_drm_unregister [vc4]) [ 13.576967] vc4-drm gpu: bound fe004000.txp (ops vc4_drm_unregister [vc4]) [ 13.577044] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577118] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577185] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577237] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.613504] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 Best regards
[PATCH] drm: mxsfb: Implement LCDIF scanout CRC32 support
The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has
CRC_STAT register, which contains CRC32 of the frame as it was clocked
out of the DPI interface of the LCDIF. This is most likely meant as a
functional safety feature.
Unfortunately, there is zero documentation on how the CRC32 is calculated,
there is no documentation of the polynomial, the init value, nor on which
data is the checksum applied.
By applying brute-force on 8 pixel / 2 line frame, which is the minimum
size LCDIF would work with, it turns out the polynomial is CRC32_POLY_LE
0xedb88320 , init value is 0x , the input data are bitrev32()
of the entire frame and the resulting CRC has to be also bitrev32()ed.
Doing this calculation in kernel for each frame is unrealistic due to the
CPU demand, so attach the CRC collected from hardware to a frame instead.
The DRM subsystem already has an interface for this purpose and the CRC
can be accessed e.g. via debugfs:
"
$ echo auto > /sys/kernel/debug/dri/1/crtc-0/crc/control
$ cat /sys/kernel/debug/dri/1/crtc-0/crc/data
0x408c 0xa4e5cdd8
0x408d 0x72f537b4
"
The per-frame CRC can be used by userspace e.g. during automated testing,
to verify that whatever buffer was sent to be scanned out was actually
scanned out of the LCDIF correctly.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +++-
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 3 ++
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 59 --
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 1 +
4 files changed, 73 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 94cafff7f68d5..ccf4107476ecc 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#include
#include
@@ -52,6 +53,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.hs_wdth_shift = 24,
.has_overlay= false,
.has_ctrl2 = false,
+ .has_crc32 = false,
},
[MXSFB_V4] = {
.transfer_count = LCDC_V4_TRANSFER_COUNT,
@@ -61,6 +63,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.hs_wdth_shift = 18,
.has_overlay= false,
.has_ctrl2 = true,
+ .has_crc32 = true,
},
[MXSFB_V6] = {
.transfer_count = LCDC_V4_TRANSFER_COUNT,
@@ -70,6 +73,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.hs_wdth_shift = 18,
.has_overlay= true,
.has_ctrl2 = true,
+ .has_crc32 = true,
},
};
@@ -145,12 +149,19 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
{
struct drm_device *drm = data;
struct mxsfb_drm_private *mxsfb = drm->dev_private;
- u32 reg;
+ u32 reg, crc;
+ u64 vbc;
reg = readl(mxsfb->base + LCDC_CTRL1);
- if (reg & CTRL1_CUR_FRAME_DONE_IRQ)
+ if (reg & CTRL1_CUR_FRAME_DONE_IRQ) {
drm_crtc_handle_vblank(>crtc);
+ if (mxsfb->crc_active) {
+ crc = readl(mxsfb->base + LCDC_V4_CRC_STAT);
+ vbc = drm_crtc_accurate_vblank_count(>crtc);
+ drm_crtc_add_crc_entry(>crtc, true, vbc, );
+ }
+ }
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index ddb5b0417a82c..d160d921b25fc 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -23,6 +23,7 @@ struct mxsfb_devdata {
unsigned inths_wdth_shift;
boolhas_overlay;
boolhas_ctrl2;
+ boolhas_crc32;
};
struct mxsfb_drm_private {
@@ -44,6 +45,8 @@ struct mxsfb_drm_private {
struct drm_encoder encoder;
struct drm_connector*connector;
struct drm_bridge *bridge;
+
+ boolcrc_active;
};
static inline struct mxsfb_drm_private *
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index c7f14ef1edc25..85ba17fbbe35c 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -454,6 +454,39 @@ static void mxsfb_crtc_disable_vblank(struct drm_crtc
*crtc)
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
}
+static int mxsfb_crtc_set_crc_source(struct drm_crtc *crtc, const char *source)
+{
+ struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(crtc->dev);
+
+ if (!crtc)
+ return -ENODEV;
+
+ if
Re: vc4: Couldn't stop firmware display driver during boot
Hi Phil, Am 09.04.22 um 22:03 schrieb Phil Elwell: You know the drill, Stefan - what's in your config.txt? sure. Everything commented out. Regards Phil On Sat, 9 Apr 2022, 20:26 Stefan Wahren, wrote: Hi, today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected to my HDMI display (multi_v7_defconfig + CONFIG_ARM_LPAE, firmware: 2021-01-08T14:31:16) and i'm getting these strange errors from raspberrypi-firmware driver / vc4 during boot: [ 13.094733] fb0: switching to vc4 from simple [ 13.110759] Console: switching to colour dummy device 80x30 [ 13.120691] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.120715] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.120839] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) [ 13.121213] Bluetooth: Core ver 2.22 [ 13.121266] NET: Registered PF_BLUETOOTH protocol family [ 13.121270] Bluetooth: HCI device and connection manager initialized [ 13.121281] Bluetooth: HCI socket layer initialized [ 13.121286] Bluetooth: L2CAP socket layer initialized [ 13.121297] Bluetooth: SCO socket layer initialized [ 13.132879] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 13.164278] Bluetooth: HCI UART driver ver 2.3 [ 13.164293] Bluetooth: HCI UART protocol H4 registered [ 13.166608] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.166633] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.166717] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.176173] Bluetooth: HCI UART protocol Broadcom registered [ 13.182365] hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator [ 13.182505] hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator [ 13.300636] uart-pl011 fe201000.serial: no DMA platform data [ 13.422683] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.422700] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.422788] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.458620] bcmgenet fd58.ethernet: GENET 5.0 EPHY: 0x [ 13.461925] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.461941] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.462006] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.469287] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 13.507497] vc4-drm gpu: bound fef00700.hdmi (ops vc4_drm_unregister [vc4]) [ 13.521840] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9 [ 13.522128] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.raspberrypi,400.bin failed with error -2 [ 13.535444] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.raspberrypi,400.txt failed with error -2 [ 13.564153] Bluetooth: hci0: BCM: chip id 130 [ 13.564675] Bluetooth: hci0: BCM: features 0x0f [ 13.566157] Bluetooth: hci0: BCM4345C5 [ 13.566164] Bluetooth: hci0: BCM4345C5 (003.006.006) build [ 13.568434] Bluetooth: hci0: BCM4345C5 'brcm/BCM4345C5.hcd' Patch [ 13.570485] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus [ 13.576820] vc4-drm gpu: bound fef05700.hdmi (ops vc4_drm_unregister [vc4]) [ 13.576967] vc4-drm gpu: bound fe004000.txp (ops vc4_drm_unregister [vc4]) [ 13.577044] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577118] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577185] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577237] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.613504] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 Best regards
vc4: Couldn't stop firmware display driver during boot
Hi, today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected to my HDMI display (multi_v7_defconfig + CONFIG_ARM_LPAE, firmware: 2021-01-08T14:31:16) and i'm getting these strange errors from raspberrypi-firmware driver / vc4 during boot: [ 13.094733] fb0: switching to vc4 from simple [ 13.110759] Console: switching to colour dummy device 80x30 [ 13.120691] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.120715] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.120839] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) [ 13.121213] Bluetooth: Core ver 2.22 [ 13.121266] NET: Registered PF_BLUETOOTH protocol family [ 13.121270] Bluetooth: HCI device and connection manager initialized [ 13.121281] Bluetooth: HCI socket layer initialized [ 13.121286] Bluetooth: L2CAP socket layer initialized [ 13.121297] Bluetooth: SCO socket layer initialized [ 13.132879] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 13.164278] Bluetooth: HCI UART driver ver 2.3 [ 13.164293] Bluetooth: HCI UART protocol H4 registered [ 13.166608] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.166633] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.166717] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.176173] Bluetooth: HCI UART protocol Broadcom registered [ 13.182365] hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator [ 13.182505] hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator [ 13.300636] uart-pl011 fe201000.serial: no DMA platform data [ 13.422683] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.422700] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.422788] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.458620] bcmgenet fd58.ethernet: GENET 5.0 EPHY: 0x [ 13.461925] raspberrypi-firmware soc:firmware: Request 0x00030066 returned status 0x8001 [ 13.461941] vc4-drm gpu: [drm] Couldn't stop firmware display driver: -22 [ 13.462006] vc4-drm gpu: bound fe40.hvs (ops vc4_drm_unregister [vc4]) [ 13.469287] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 13.507497] vc4-drm gpu: bound fef00700.hdmi (ops vc4_drm_unregister [vc4]) [ 13.521840] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9 [ 13.522128] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.raspberrypi,400.bin failed with error -2 [ 13.535444] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.raspberrypi,400.txt failed with error -2 [ 13.564153] Bluetooth: hci0: BCM: chip id 130 [ 13.564675] Bluetooth: hci0: BCM: features 0x0f [ 13.566157] Bluetooth: hci0: BCM4345C5 [ 13.566164] Bluetooth: hci0: BCM4345C5 (003.006.006) build [ 13.568434] Bluetooth: hci0: BCM4345C5 'brcm/BCM4345C5.hcd' Patch [ 13.570485] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus [ 13.576820] vc4-drm gpu: bound fef05700.hdmi (ops vc4_drm_unregister [vc4]) [ 13.576967] vc4-drm gpu: bound fe004000.txp (ops vc4_drm_unregister [vc4]) [ 13.577044] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577118] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577185] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.577237] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_drm_unregister [vc4]) [ 13.613504] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 Best regards
[PATCH] drm: rcar-du: Extend CMM HDSE documentation
When the CMM is enabled, the HDSE offset is further adjusted to compensate for consumed pixels. Explain this further, with an extra comment at the point the offset is adjusted. Suggested-by: Laurent Pinchart Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index f361a604337f..23e1aedf8dc0 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -300,6 +300,11 @@ static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc) | DSMR_DIPM_DISP | DSMR_CSPM; rcar_du_crtc_write(rcrtc, DSMR, dsmr); + /* +* When the CMM is enabled, an additional offset of 25 pixels must be +* subtracted from the HDS (horizontal display start) and HDE +* (horizontal display end) registers. +*/ hdse_offset = 19; if (rcrtc->group->cmms_mask & BIT(rcrtc->index % 2)) hdse_offset += 25; -- 2.32.0
Re: [PATCH] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
On Sat, Apr 9, 2022 at 7:33 AM Christian König wrote:
>
> Am 08.04.22 um 23:12 schrieb Chia-I Wu:
> > In practice, trace_dma_fence_init is good enough and almost no driver
> > calls trace_dma_fence_emit. But this is still more correct in theory.
>
> Well, the reason why basically no driver is calling this is because it
> is pretty much deprecated.
Why is it considered deprecated? trace_dma_fence_{emit,signaled} are
useful to visualize fence timelines. I am actually less sure about
how trace_dma_fence_{init,destroy} are used.
Is it because trace_dma_fence_init is called automatically, and is
good enough most of the time?
>
> We do have a case in the GPU scheduler where it makes sense to distinct
> between init and emit, but it doesn't really matter for drivers.
virtio also has a case where init and emit can be far apart, when the
host cannot process commands fast enough and there is no space in
virtqueue.
>
> So I'm not sure if it's a good idea to add that here.
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: Chia-I Wu
> > Cc: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_gpu.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > index faf0c242874e..a82193f41ea2 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /*
> >* Power Management:
> > @@ -769,6 +770,7 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> > msm_gem_submit *submit)
> > gpu->active_submits++;
> > mutex_unlock(>active_lock);
> >
> > + trace_dma_fence_emit(submit->hw_fence);
> > gpu->funcs->submit(gpu, submit);
> > gpu->cur_ctx_seqno = submit->queue->ctx->seqno;
> >
>
Re: AMDGPU: regression on 5.17.1 #forregzbot
TWIMC: this mail is primarily send for documentation purposes and for regzbot, my Linux kernel regression tracking bot. These mails usually contain '#forregzbot' in the subject, to make them easy to spot and filter. On 09.04.22 18:28, Michele Ballabio wrote: > On Tue, 5 Apr 2022 10:23:16 -0400 > Alex Deucher wrote: > >> On Mon, Apr 4, 2022 at 3:39 PM Michele Ballabio >> wrote: >>> >>> On Mon, 4 Apr 2022 13:03:41 -0400 >>> Alex Deucher wrote: >>> On Sun, Apr 3, 2022 at 10:19 AM Michele Ballabio wrote: > > Hi, > I've hit a regression on 5.17.1 (haven't tested 5.17.0, > but 5.16-stable didn't have this problem). > > The machine is a Ryzen 5 1600 with AMD graphics (RX 560). > > The regression I hit seems to trigger when the machine is left > idle at boot (I don't boot straight to X, I boot to a tty, login > and then start X). The machine after a while blanks the screen. > Usually, the screen unblanks as the keyboard is hit or the mouse > moves, but with kernel 5.17.1 the screen does not wake up. The > machine seems to run mostly fine: I can login from ssh, but I > cannot reboot or halt it: a sysrq sequence is needed for that. > Note that if the screen goes blank under X, it wakes up fine. > > Below a dmesg and two traces from syslog (they're quite > similar). Can you bisect? Does setting amdgpu.runpm=0 help? >>> >>> I can try to bisect, should I narrow the search to drivers/gpu/drm/ >>> ? >> >> I would just do a full bisect if possible in case the change happens >> to be outside of drm. >> >>> >>> Setting amdgpu.runpm=0 works, the display now unblanks without >>> problems. >> > > Hi, > I bisected this, and the first bad commit is > [087451f372bf76d971184caa258807b7c35aac8f] drm/amdgpu: use generic fb > helpers instead of setting up AMD own's. #regzbot introduced: 087451f372bf76d971184caa258807b7c35aac8f
[PATCH] drm/radeon: remove r600_blit_shaders.[c|h]
The only use of the global variables in r600_blit_shaders.c
were in the old drivers/gpu/drm/radeon/r600_blit.c
This file was removed in
commit 8333f607a631 ("drm/radeon: remove UMS support")
So remove the r600_blit_shaders.[c|h] files
Signed-off-by: Tom Rix
---
drivers/gpu/drm/radeon/Makefile| 2 +-
drivers/gpu/drm/radeon/r600_blit_shaders.c | 719 -
drivers/gpu/drm/radeon/r600_blit_shaders.h | 38 --
3 files changed, 1 insertion(+), 758 deletions(-)
delete mode 100644 drivers/gpu/drm/radeon/r600_blit_shaders.c
delete mode 100644 drivers/gpu/drm/radeon/r600_blit_shaders.h
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 2425a3612d6c..4deedaacd655 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -39,7 +39,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
radeon_clocks.o radeon_fb.o radeon_gem.o radeon_ring.o radeon_irq_kms.o
\
radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
- r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \
+ r200.o radeon_legacy_tv.o r600_cs.o \
radeon_pm.o atombios_dp.o r600_hdmi.o dce3_1_afmt.o \
evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
evergreen_hdmi.o radeon_trace_points.o ni.o \
diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c
b/drivers/gpu/drm/radeon/r600_blit_shaders.c
deleted file mode 100644
index 443cbe59b274..
--- a/drivers/gpu/drm/radeon/r600_blit_shaders.c
+++ /dev/null
@@ -1,719 +0,0 @@
-/*
- * Copyright 2009 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- * Alex Deucher
- */
-
-#include
-#include
-#include
-
-/*
- * R6xx+ cards need to use the 3D engine to blit data which requires
- * quite a bit of hw state setup. Rather than pull the whole 3D driver
- * (which normally generates the 3D state) into the DRM, we opt to use
- * statically generated state tables. The register state and shaders
- * were hand generated to support blitting functionality. See the 3D
- * driver or documentation for descriptions of the registers and
- * shader instructions.
- */
-
-const u32 r6xx_default_state[] =
-{
- 0xc0002400, /* START_3D_CMDBUF */
- 0x,
-
- 0xc0012800, /* CONTEXT_CONTROL */
- 0x8000,
- 0x8000,
-
- 0xc0016800,
- 0x0010,
- 0x8000, /* WAIT_UNTIL */
-
- 0xc0016800,
- 0x0542,
- 0x0703, /* TA_CNTL_AUX */
-
- 0xc0016800,
- 0x05c5,
- 0x, /* VC_ENHANCE */
-
- 0xc0016800,
- 0x0363,
- 0x, /* SQ_DYN_GPR_CNTL_PS_FLUSH_REQ */
-
- 0xc0016800,
- 0x060c,
- 0x8200, /* DB_DEBUG */
-
- 0xc0016800,
- 0x060e,
- 0x01020204, /* DB_WATERMARKS */
-
- 0xc0026f00,
- 0x,
- 0x, /* SQ_VTX_BASE_VTX_LOC */
- 0x, /* SQ_VTX_START_INST_LOC */
-
- 0xc0096900,
- 0x022a,
- 0x, /* SQ_ESGS_RING_ITEMSIZE */
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
-
- 0xc0016900,
- 0x0004,
- 0x, /* DB_DEPTH_INFO */
-
- 0xc0026900,
- 0x000a,
- 0x, /* DB_STENCIL_CLEAR */
- 0x, /* DB_DEPTH_CLEAR */
-
- 0xc0016900,
- 0x0200,
- 0x, /* DB_DEPTH_CONTROL */
-
- 0xc0026900,
- 0x0343,
- 0x0060, /* DB_RENDER_CONTROL */
- 0x0040, /* DB_RENDER_OVERRIDE */
-
- 0xc0016900,
- 0x0351,
- 0xaa00, /* DB_ALPHA_TO_MASK */
-
- 0xc00f6900,
-
Re: [PATCH v3 1/2] dt-bindings: display: msm: Add optional resets
On 08/04/2022 23:08, Bjorn Andersson wrote: > Add an optional reference to the MDSS_CORE reset, which when specified > can be used by the implementation to reset the hardware blocks. > > Signed-off-by: Bjorn Andersson > --- > > Resending these two patches again as I put "v2" in the subject, even though I > meant v3. Sorry about that. > I reviewed v2, so one here as well: Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v2 1/2] dt-bindings: display: msm: Add optional resets
On 08/04/2022 23:02, Bjorn Andersson wrote: > Add an optional reference to the MDSS_CORE reset, which when specified > can be used by the implementation to reset the hardware blocks. > > Signed-off-by: Bjorn Andersson > --- > > Changes since v2: > - None > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: AMDGPU: regression on 5.17.1
On Tue, 5 Apr 2022 10:23:16 -0400 Alex Deucher wrote: > On Mon, Apr 4, 2022 at 3:39 PM Michele Ballabio > wrote: > > > > On Mon, 4 Apr 2022 13:03:41 -0400 > > Alex Deucher wrote: > > > > > On Sun, Apr 3, 2022 at 10:19 AM Michele Ballabio > > > wrote: > > > > > > > > Hi, > > > > I've hit a regression on 5.17.1 (haven't tested 5.17.0, > > > > but 5.16-stable didn't have this problem). > > > > > > > > The machine is a Ryzen 5 1600 with AMD graphics (RX 560). > > > > > > > > The regression I hit seems to trigger when the machine is left > > > > idle at boot (I don't boot straight to X, I boot to a tty, login > > > > and then start X). The machine after a while blanks the screen. > > > > Usually, the screen unblanks as the keyboard is hit or the mouse > > > > moves, but with kernel 5.17.1 the screen does not wake up. The > > > > machine seems to run mostly fine: I can login from ssh, but I > > > > cannot reboot or halt it: a sysrq sequence is needed for that. > > > > Note that if the screen goes blank under X, it wakes up fine. > > > > > > > > Below a dmesg and two traces from syslog (they're quite > > > > similar). > > > > > > Can you bisect? Does setting amdgpu.runpm=0 help? > > > > I can try to bisect, should I narrow the search to drivers/gpu/drm/ > > ? > > I would just do a full bisect if possible in case the change happens > to be outside of drm. > > > > > Setting amdgpu.runpm=0 works, the display now unblanks without > > problems. > Hi, I bisected this, and the first bad commit is [087451f372bf76d971184caa258807b7c35aac8f] drm/amdgpu: use generic fb helpers instead of setting up AMD own's. Let me know if you need some more testing. Thanks, Michele Ballabio
Re: [PATCH] drm/msm: add trace_dma_fence_emit to msm_gpu_submit
Am 08.04.22 um 23:12 schrieb Chia-I Wu: In practice, trace_dma_fence_init is good enough and almost no driver calls trace_dma_fence_emit. But this is still more correct in theory. Well, the reason why basically no driver is calling this is because it is pretty much deprecated. We do have a case in the GPU scheduler where it makes sense to distinct between init and emit, but it doesn't really matter for drivers. So I'm not sure if it's a good idea to add that here. Regards, Christian. Signed-off-by: Chia-I Wu Cc: Rob Clark --- drivers/gpu/drm/msm/msm_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index faf0c242874e..a82193f41ea2 100644 --- a/drivers/gpu/drm/msm/msm_gpu.c +++ b/drivers/gpu/drm/msm/msm_gpu.c @@ -15,6 +15,7 @@ #include #include #include +#include /* * Power Management: @@ -769,6 +770,7 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit) gpu->active_submits++; mutex_unlock(>active_lock); + trace_dma_fence_emit(submit->hw_fence); gpu->funcs->submit(gpu, submit); gpu->cur_ctx_seqno = submit->queue->ctx->seqno;
Re: ttm_bo_move_sync_cleanup() issue
Am 08.04.22 um 18:01 schrieb Matthew Auld: Hi Christian, We seem to be hitting a new issue in ttm_bo_move_sync_cleanup(), due to passing a NULL fence, and I guess with some recent changes this is now blowing up in at least dma_resv_add_fence(). Question is how should we handle this? Should we add a special case in ttm_bo_move_accel_cleanup() in case of NULL fence, and then maybe just always call ttm_bo_wait_free_node() and also skip the add_fence? Or maybe this case should rather be moved into the driver, and handled with something along the lines of ttm_bo_move_null()? Any thoughts here? Ah, crap I though I've catched all cases where somebody wants to insert a NULL fence into the dma_resv object. For the short term we should probably do as you suggested, e.g. always use ttm_bo_wait_free_node(). In the long term we should just completely nuke ttm_bo_wait_free_node() and directly cleanup properly here. Regards, Christian.
Re: [PATCH v9, 16/17] media: mediatek: vcodec: support stateless VP9 decoding
Hi Yunfei, Thank you for the patch! Yet something to improve: [auto build test ERROR on media-tree/master] [also build test ERROR on v5.18-rc1 next-20220408] [cannot apply to remoteproc/rproc-next drm-tip/drm-tip] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/intel-lab-lkp/linux/commits/Yunfei-Dong/media-mediatek-vcodec-Add-vdec-enable-disable-hardware-helpers/20220408-210244 base: git://linuxtv.org/media_tree.git master config: arm64-randconfig-r015-20220408 (https://download.01.org/0day-ci/archive/20220409/202204092137.3rrpn4hr-...@intel.com/config) compiler: aarch64-linux-gcc (GCC) 11.2.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/251c7c77f6690881357df39867a32a03eb7db3b7 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Yunfei-Dong/media-mediatek-vcodec-Add-vdec-enable-disable-hardware-helpers/20220408-210244 git checkout 251c7c77f6690881357df39867a32a03eb7db3b7 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm64 SHELL=/bin/bash If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): aarch64-linux-ld: drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.o: in function `vdec_vp9_slice_update_prob.isra.0': >> vdec_vp9_req_lat_if.c:(.text+0x2654): undefined reference to >> `v4l2_vp9_adapt_noncoef_probs' vdec_vp9_req_lat_if.c:(.text+0x2654): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `v4l2_vp9_adapt_noncoef_probs' >> aarch64-linux-ld: vdec_vp9_req_lat_if.c:(.text+0x26c0): undefined reference >> to `v4l2_vp9_adapt_coef_probs' vdec_vp9_req_lat_if.c:(.text+0x26c0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `v4l2_vp9_adapt_coef_probs' aarch64-linux-ld: vdec_vp9_req_lat_if.c:(.text+0x26d8): undefined reference to `v4l2_vp9_adapt_coef_probs' vdec_vp9_req_lat_if.c:(.text+0x26d8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `v4l2_vp9_adapt_coef_probs' aarch64-linux-ld: vdec_vp9_req_lat_if.c:(.text+0x26f0): undefined reference to `v4l2_vp9_adapt_coef_probs' vdec_vp9_req_lat_if.c:(.text+0x26f0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `v4l2_vp9_adapt_coef_probs' -- 0-DAY CI Kernel Test Service https://01.org/lkp
[PATCH] drm/panel: newvision-nv3052c: Fix build
The driver was compile-tested then rebased on drm-misc-next, and not
compile-tested after the rebase; unfortunately the driver didn't compile
anymore when it hit drm-misc-next.
Fixes: 49956b505c53 ("drm/panel: Add panel driver for NewVision NV3052C based
LCDs")
Cc: Christophe Branchereau
Cc: kbuild-all
Cc: Stephen Rothwell
Reported-by: kernel test robot
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/panel-newvision-nv3052c.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
index 127bcfdb59df..cf078f0d3cd3 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3052c.c
@@ -416,15 +416,13 @@ static int nv3052c_probe(struct spi_device *spi)
return 0;
}
-static int nv3052c_remove(struct spi_device *spi)
+static void nv3052c_remove(struct spi_device *spi)
{
struct nv3052c *priv = spi_get_drvdata(spi);
drm_panel_remove(>panel);
drm_panel_disable(>panel);
drm_panel_unprepare(>panel);
-
- return 0;
}
static const struct drm_display_mode ltk035c5444t_modes[] = {
--
2.35.1
