[Bug 111784] Hang when using glWaitSync with multithreaded shared GL contexts
https://bugs.freedesktop.org/show_bug.cgi?id=111784 --- Comment #2 from Emmanuel Durand --- Created attachment 145474 --> https://bugs.freedesktop.org/attachment.cgi?id=145474=edit Source code exhibiting the issue -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111785] Registration not working
https://bugs.freedesktop.org/show_bug.cgi?id=111785 Bug ID: 111785 Summary: Registration not working Product: DRI Version: DRI git Hardware: Other URL: http://localhost:4000 OS: Windows (All) Status: NEW Severity: major Priority: not set Component: General Assignee: dri-devel@lists.freedesktop.org Reporter: venkatasaichowda...@gmail.com In general Dri issues Registration not working -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111785] Registration not working
https://bugs.freedesktop.org/show_bug.cgi?id=111785 Andre Klapper changed: What|Removed |Added Component|General |Two Group||spam Version|DRI git |unspecified Status|NEW |RESOLVED Product|DRI |Spam Resolution|--- |INVALID --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: Add xylon logicvc bindings documentation
Hi, On Fri 13 Sep 19, 20:16, Rob Herring wrote: > On Fri, Sep 13, 2019 at 4:58 PM Paul Kocialkowski > wrote: > > > > Hi Rob and thanks for the review! > > > > On Fri 13 Sep 19, 15:35, Rob Herring wrote: > > > On Tue, Sep 10, 2019 at 05:34:08PM +0200, Paul Kocialkowski wrote: > > > > The Xylon LogiCVC is a display controller implemented as programmable > > > > logic in Xilinx FPGAs. > > > > > > > > Signed-off-by: Paul Kocialkowski > > > > --- > > > > .../bindings/display/xylon,logicvc.txt| 188 ++ > > > > 1 file changed, 188 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/xylon,logicvc.txt > > > > > > Consider converting this to DT schema format. See > > > Documentation/devicetree/writing-schema.rst (.md in 5.3). > > > > Oh right, that would certainly be much more future-proof! > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > > > b/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > > > new file mode 100644 > > > > index ..eb4b1553888a > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/xylon,logicvc.txt > > > > @@ -0,0 +1,188 @@ > > > > +Xylon LogiCVC display controller > > > > + > > > > +The Xylon LogiCVC is a display controller that supports multiple > > > > layers. > > > > +It is usually implemented as programmable logic and was optimized for > > > > use > > > > +with Xilinx Zynq-7000 SoCs and Xilinx FPGAs. > > > > + > > > > +Because the controller is intended for use in a FPGA, most of the > > > > configuration > > > > +of the controller takes place at logic configuration bitstream > > > > synthesis time. > > > > +As a result, many of the device-tree bindings are meant to reflect the > > > > +synthesis configuration. These do not allow configuring the controller > > > > +differently than synthesis configuration. > > > > + > > > > +Layers are declared in the "layers" sub-node and have dedicated > > > > configuration. > > > > +In version 3 of the controller, each layer has fixed memory offset and > > > > address > > > > +starting from the video memory base address for its framebuffer. With > > > > version 4, > > > > +framebuffers are configured with a direct memory address instead. > > > > + > > > > +Matching synthesis parameters are provided when applicable. > > > > + > > > > +Required properties: > > > > +- compatible: Should be one of: > > > > + "xylon,logicvc-3.02.a-display" > > > > + "xylon,logicvc-4.01.a-display" > > > > +- reg: Physical base address and size for the controller registers. > > > > +- clocks: List of phandle and clock-specifier pairs, one for each entry > > > > + in 'clock-names' > > > > +- clock-names: List of clock names that should at least contain: > > > > + - "vclk": The VCLK video clock input. > > > > +- interrupts: The interrupt to use for VBLANK signaling. > > > > +- xylon,display-interface: Display interface in use, should be one of: > > > > + - "lvds-4bits": 4-bit LVDS interface (C_DISPLAY_INTERFACE == 4). > > > > +- xylon,display-colorspace: Display output colorspace in use, should > > > > be one of: > > > > + - "rgb": RGB colorspace (C_DISPLAY_COLOR_SPACE == 0). > > > > +- xylon,display-depth: Display output depth in use > > > > (C_PIXEL_DATA_WIDTH). > > > > +- xylon,row-stride: Fixed number of pixels in a framebuffer row > > > > (C_ROW_STRIDE). > > > > +- xylon,layers-count: The number of available layers (C_NUM_OF_LAYERS). > > > > > > Presumably some of this is determined by the display attached. Isn't it > > > safe to assume the IP was configured correctly for the intended display > > > and you can just get this from the panel? > > > > Layers are what corresponds to DRM planes, which are not actually indicated > > by the panel but are a charasteristic of the display controller. In our > > case, > > this is directly selected at bitstream synthesis time for the controller. > > > > So I'm afraid there is no way we can auto-detect this from the driver. > > Sorry, I referring to the set of properties above. In particular, > xylon,display-interface and xylon,display-colorspace, though I don't > know if the latter is talking in memory format or on the wire format. Both of these are about the wire format, which is also "hardcoded" at synthesis time with no way to be detected afterwards, as far as I know. Memory format is described in the layer sub-nodes. > Actually for xylon,layers-count, You should just count the child nodes > of 'layers'. Oh that's a good point, thanks! > > > > +Optional properties: > > > > +- memory-region: phandle to a node describing memory, as specified in: > > > > + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > > +- clock-names: List of clock names that can optionally contain: > > > > + - "vclk2": The VCLK2 doubled-rate video clock input. > > > > + - "lvdsclk": The LVDS clock. > > > > + - "lvdsclkn": The LVDS clock inverted. >
Re: [PATCH v18 15/19] Documentation: kunit: add documentation for KUnit
On 9/23/19 2:02 AM, Brendan Higgins wrote: > Add documentation for KUnit, the Linux kernel unit testing framework. > - Add intro and usage guide for KUnit > - Add API reference > > Signed-off-by: Felix Guo > Signed-off-by: Brendan Higgins > Cc: Jonathan Corbet > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Logan Gunthorpe > Reviewed-by: Stephen Boyd > --- > Documentation/dev-tools/index.rst | 1 + > Documentation/dev-tools/kunit/api/index.rst | 16 + > Documentation/dev-tools/kunit/api/test.rst | 11 + > Documentation/dev-tools/kunit/faq.rst | 62 +++ > Documentation/dev-tools/kunit/index.rst | 79 +++ > Documentation/dev-tools/kunit/start.rst | 180 ++ > Documentation/dev-tools/kunit/usage.rst | 576 > 7 files changed, 925 insertions(+) > create mode 100644 Documentation/dev-tools/kunit/api/index.rst > create mode 100644 Documentation/dev-tools/kunit/api/test.rst > create mode 100644 Documentation/dev-tools/kunit/faq.rst > create mode 100644 Documentation/dev-tools/kunit/index.rst > create mode 100644 Documentation/dev-tools/kunit/start.rst > create mode 100644 Documentation/dev-tools/kunit/usage.rst > diff --git a/Documentation/dev-tools/kunit/start.rst > b/Documentation/dev-tools/kunit/start.rst > new file mode 100644 > index ..6dc229e46bb3 > --- /dev/null > +++ b/Documentation/dev-tools/kunit/start.rst > @@ -0,0 +1,180 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +=== > +Getting Started > +=== > + > +Installing dependencies > +=== > +KUnit has the same dependencies as the Linux kernel. As long as you can build > +the kernel, you can run KUnit. > + > +KUnit Wrapper > += > +Included with KUnit is a simple Python wrapper that helps format the output > to > +easily use and read KUnit output. It handles building and running the > kernel, as > +well as formatting the output. > + > +The wrapper can be run with: > + > +.. code-block:: bash > + > + ./tools/testing/kunit/kunit.py run > + > +Creating a kunitconfig > +== > +The Python script is a thin wrapper around Kbuild as such, it needs to be around Kbuild. As such, > +configured with a ``kunitconfig`` file. This file essentially contains the > +regular Kernel config, with the specific test targets as well. > + > +.. code-block:: bash > + > + git clone -b master https://kunit.googlesource.com/kunitconfig > $PATH_TO_KUNITCONFIG_REPO > + cd $PATH_TO_LINUX_REPO > + ln -s $PATH_TO_KUNIT_CONFIG_REPO/kunitconfig kunitconfig > + > +You may want to add kunitconfig to your local gitignore. > + > +Verifying KUnit Works > +- > + > +To make sure that everything is set up correctly, simply invoke the Python > +wrapper from your kernel repo: > + > +.. code-block:: bash > + > + ./tools/testing/kunit/kunit.py > + > +.. note:: > + You may want to run ``make mrproper`` first. I normally use O=builddir when building kernels. Does this support using O=builddir ? > + > +If everything worked correctly, you should see the following: > + > +.. code-block:: bash > + > + Generating .config ... > + Building KUnit Kernel ... > + Starting KUnit Kernel ... > + > +followed by a list of tests that are run. All of them should be passing. > + > +.. note:: > + Because it is building a lot of sources for the first time, the ``Building > + kunit kernel`` step may take a while. > + > +Writing your first test > +=== [snip] > diff --git a/Documentation/dev-tools/kunit/usage.rst > b/Documentation/dev-tools/kunit/usage.rst > new file mode 100644 > index ..c6e69634e274 > --- /dev/null > +++ b/Documentation/dev-tools/kunit/usage.rst TBD... -- ~Randy
[PATCH trivial 3/3] treewide: arch: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- arch/Kconfig | 4 ++-- arch/alpha/Kconfig | 2 +- arch/arm/Kconfig.debug | 4 ++-- arch/arm/mach-ep93xx/Kconfig | 8 arch/arm/mach-hisi/Kconfig | 2 +- arch/arm/mach-ixp4xx/Kconfig | 16 arch/arm/mach-mmp/Kconfig | 2 +- arch/arm/mach-omap1/Kconfig| 14 +++--- arch/arm/mach-prima2/Kconfig | 6 +++--- arch/arm/mach-s3c24xx/Kconfig | 4 ++-- arch/arm/mach-s3c64xx/Kconfig | 6 +++--- arch/arm/plat-samsung/Kconfig | 2 +- arch/arm64/Kconfig | 6 +++--- arch/arm64/Kconfig.debug | 2 +- arch/h8300/Kconfig | 4 ++-- arch/h8300/Kconfig.cpu | 4 ++-- arch/m68k/Kconfig.bus | 2 +- arch/m68k/Kconfig.debug| 16 arch/m68k/Kconfig.machine | 8 arch/nds32/Kconfig.cpu | 18 +- arch/openrisc/Kconfig | 26 +- arch/powerpc/Kconfig.debug | 18 +- arch/powerpc/platforms/Kconfig.cputype | 2 +- arch/riscv/Kconfig.socs| 2 +- arch/sh/boards/Kconfig | 2 +- arch/sh/mm/Kconfig | 2 +- arch/um/Kconfig| 2 +- arch/x86/Kconfig | 18 +- 28 files changed, 101 insertions(+), 101 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 5f8a5d84dbbe..8d4f77bbed29 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -76,7 +76,7 @@ config JUMP_LABEL depends on HAVE_ARCH_JUMP_LABEL depends on CC_HAS_ASM_GOTO help - This option enables a transparent branch optimization that +This option enables a transparent branch optimization that makes certain almost-always-true or almost-always-false branch conditions even cheaper to execute within the kernel. @@ -84,7 +84,7 @@ config JUMP_LABEL scheduler functionality, networking code and KVM have such branches and include support for this optimization technique. - If it is detected that the compiler has support for "asm goto", +If it is detected that the compiler has support for "asm goto", the kernel will compile such branches with just a nop instruction. When the condition flag is toggled to true, the nop will be converted to a jump instruction to execute the diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index ef179033a7c2..30a6291355cb 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -545,7 +545,7 @@ config NR_CPUS default "4" if !ALPHA_GENERIC && !ALPHA_MARVEL help MARVEL support can handle a maximum of 32 CPUs, all the others - with working support have a maximum of 4 CPUs. + with working support have a maximum of 4 CPUs. config ARCH_DISCONTIGMEM_ENABLE bool "Discontiguous Memory Support" diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 8bcbd0cd739b..0e5d52fbddbd 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -274,7 +274,7 @@ choice select DEBUG_UART_8250 help Say Y here if you want the debug print routines to direct - their output to the CNS3xxx UART0. + their output to the CNS3xxx UART0. config DEBUG_DAVINCI_DA8XX_UART1 bool "Kernel low-level debugging on DaVinci DA8XX using UART1" @@ -828,7 +828,7 @@ choice select DEBUG_UART_8250 help Say Y here if you want kernel low-level debugging support - on Rockchip RV1108 based platforms. + on Rockchip RV1108 based platforms. config DEBUG_RV1108_UART1 bool "Kernel low-level debugging messages via Rockchip RV1108 UART1" diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig index f2db5fd38145..bf81dfab7f1b 100644 --- a/arch/arm/mach-ep93xx/Kconfig +++ b/arch/arm/mach-ep93xx/Kconfig @@ -126,10 +126,10 @@ config MACH_MICRO9S Contec Micro9-Slim board. config MACH_SIM_ONE -bool "Support Simplemachines Sim.One board" -help - Say 'Y' here if you want your kernel to support the - Simplemachines Sim.One board. + bool "Support Simplemachines Sim.One board" + help + Say 'Y' here if you want your kernel to support the + Simplemachines Sim.One board. config MACH_SNAPPER_CL15 bool "Support Bluewater Systems Snapper CL15 Module" diff --git a/arch/arm/mach-hisi/Kconfig
[PATCH trivial 2/3] treewide: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- certs/Kconfig | 14 ++--- init/Kconfig | 28 +- kernel/trace/Kconfig | 8 lib/Kconfig| 2 +- lib/Kconfig.debug | 36 +- lib/Kconfig.kgdb | 8 mm/Kconfig | 28 +- samples/Kconfig| 2 +- security/apparmor/Kconfig | 2 +- security/integrity/Kconfig | 24 +++ security/integrity/ima/Kconfig | 12 ++-- security/safesetid/Kconfig | 24 +++ 12 files changed, 94 insertions(+), 94 deletions(-) diff --git a/certs/Kconfig b/certs/Kconfig index c94e93d8bccf..0358c66d3d7c 100644 --- a/certs/Kconfig +++ b/certs/Kconfig @@ -6,14 +6,14 @@ config MODULE_SIG_KEY default "certs/signing_key.pem" depends on MODULE_SIG help - Provide the file name of a private key/certificate in PEM format, - or a PKCS#11 URI according to RFC7512. The file should contain, or - the URI should identify, both the certificate and its corresponding - private key. +Provide the file name of a private key/certificate in PEM format, +or a PKCS#11 URI according to RFC7512. The file should contain, or +the URI should identify, both the certificate and its corresponding +private key. - If this option is unchanged from its default "certs/signing_key.pem", - then the kernel will automatically generate the private key and - certificate as described in Documentation/admin-guide/module-signing.rst +If this option is unchanged from its default "certs/signing_key.pem", +then the kernel will automatically generate the private key and +certificate as described in Documentation/admin-guide/module-signing.rst config SYSTEM_TRUSTED_KEYRING bool "Provide system-wide ring of trusted keys" diff --git a/init/Kconfig b/init/Kconfig index 6d4db887f696..f59c854839d2 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -169,10 +169,10 @@ config BUILD_SALT string "Build ID Salt" default "" help - The build ID is used to link binaries and their debug info. Setting - this option will use the value in the calculation of the build id. - This is mostly useful for distributions which want to ensure the - build is unique between builds. It's safe to leave the default. + The build ID is used to link binaries and their debug info. Setting + this option will use the value in the calculation of the build id. + This is mostly useful for distributions which want to ensure the + build is unique between builds. It's safe to leave the default. config HAVE_KERNEL_GZIP bool @@ -1327,9 +1327,9 @@ menuconfig EXPERT select DEBUG_KERNEL help This option allows certain base kernel options and settings - to be disabled or tweaked. This is for specialized - environments which can tolerate a "non-standard" kernel. - Only use this if you really know what you are doing. + to be disabled or tweaked. This is for specialized + environments which can tolerate a "non-standard" kernel. + Only use this if you really know what you are doing. config UID16 bool "Enable 16-bit UID system calls" if EXPERT @@ -1439,11 +1439,11 @@ config BUG bool "BUG() support" if EXPERT default y help - Disabling this option eliminates support for BUG and WARN, reducing - the size of your kernel image and potentially quietly ignoring - numerous fatal conditions. You should only consider disabling this - option for embedded systems with no facilities for reporting errors. - Just say Y. + Disabling this option eliminates support for BUG and WARN, reducing + the size of your kernel image and potentially quietly ignoring + numerous fatal conditions. You should only consider disabling this + option for embedded systems with no facilities for reporting errors. + Just say Y. config ELF_CORE depends on COREDUMP @@ -1459,8 +1459,8 @@ config PCSPKR_PLATFORM select I8253_LOCK default y help - This option allows to disable the internal PC-Speaker - support, saving some memory. + This option allows to disable the internal PC-Speaker + support, saving some memory. config BASE_FULL default y diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index e08527f50d2a..0393003f102f 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -76,7 +76,7
Re: [PATCH 5/6] vringh: fix copy direction of vringh_iov_push_kern()
On Mon, Sep 23, 2019 at 09:45:59AM -0600, Alex Williamson wrote:
> On Mon, 23 Sep 2019 21:03:30 +0800
> Jason Wang wrote:
>
> > We want to copy from iov to buf, so the direction was wrong.
> >
> > Signed-off-by: Jason Wang
> > ---
> > drivers/vhost/vringh.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
>
>
> Why is this included in the series? Seems like an unrelated fix being
> held up within a proposal for a new feature. Thanks,
>
> Alex
It's better to have it as patch 1/6, but it's a dependency of the
example driver in the series. I can reorder when I apply.
> > diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
> > index 08ad0d1f0476..a0a2d74967ef 100644
> > --- a/drivers/vhost/vringh.c
> > +++ b/drivers/vhost/vringh.c
> > @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst,
> > size_t len)
> > return 0;
> > }
> >
> > +static inline int kern_xfer(void *dst, void *src, size_t len)
> > +{
> > + memcpy(dst, src, len);
> > + return 0;
> > +}
> > +
> > /**
> > * vringh_init_kern - initialize a vringh for a kernelspace vring.
> > * @vrh: the vringh to initialize.
> > @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern);
> > ssize_t vringh_iov_push_kern(struct vringh_kiov *wiov,
> > const void *src, size_t len)
> > {
> > - return vringh_iov_xfer(wiov, (void *)src, len, xfer_kern);
> > + return vringh_iov_xfer(wiov, (void *)src, len, kern_xfer);
> > }
> > EXPORT_SYMBOL(vringh_iov_push_kern);
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/11] drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index()
Hi Heikki, On Mon, Sep 23, 2019 at 06:03:33PM +0300, Heikki Krogerus wrote: > On Sat, Sep 21, 2019 at 02:12:28AM +0300, Laurent Pinchart wrote: > > Hi Dmitry, > > > > (CC'ing Heikki as the original author of software nodes support) > > > > Thank you for the patch. > > > > On Wed, Sep 11, 2019 at 12:52:10AM -0700, Dmitry Torokhov wrote: > > > Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use > > > the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit > > > > s/bit/but/ > > > > > works with arbitrary firmware node. > > > > > > Signed-off-by: Dmitry Torokhov > > > > Reviewed-by: Laurent Pinchart > > > > On a side note, as I'm not very familiar with software nodes, I tried to > > see how they are to be used, and it seems they are completely > > undocumented :-( Heikki, is this something that could be fixed ? > > OK. I'll start writing API documentation for it. That's great, thanks ! I'll do my best to review it if you CC me. -- Regards, Laurent Pinchart
[Bug 111784] Hang when using glWaitSync with multithreaded shared GL contexts
https://bugs.freedesktop.org/show_bug.cgi?id=111784 Bug ID: 111784 Summary: Hang when using glWaitSync with multithreaded shared GL contexts Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: emmanueldur...@protonmail.com Created attachment 145472 --> https://bugs.freedesktop.org/attachment.cgi?id=145472=edit Output of dmesg I develop a tool which uses a separate thread for uploading textures to the GPU, in parallel to the rendering thread. These two threads are synchronized using OpenGL fences, which prevents the rendering to happen while a texture is being copied from a PBO. On recent AMD hardware (tested on a Vega 56 and a Radeon VII) this setup hangs almost instantaneously. From my tests it seems that it waits for a glWaitSync to finish. The exact same code runs flawlessly on Intel (Mesa driver) and Nvidia (proprietary driver). I managed to somewhat reproduce the issue in a simpler code, which merely creates two shared OpenGL contexts and does nothing except creating fences and waiting for the other thread. This example hangs with AMDGPU driver, but once again runs fine on Intel (Mesa driver) and Nvidia (proprietary driver). I'll attach the code to this thread, and it can be found here too: https://gitlab.com/sat-metalab/splash/blob/fix/radeon_test/tests/sandbox/radeon_mesa_shared_context_freeze.cpp. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #141 from Alex Deucher --- (In reply to sehellion from comment #140) > Created attachment 145463 [details] > 5.3.1 with Alex's patches and dual monitors, crash That's not a crash, it's just a warning. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] MAINTAINERS: Add Jernej Škrabec as a reviewer for DE2
On Thu, Sep 19, 2019 at 08:24:18PM +0200, Jernej Škrabec wrote: > Dne četrtek, 19. september 2019 ob 19:30:20 CEST je Maxime Ripard napisal(a): > > The newer Allwinner SoCs have a different layers controller than the older > > ones. Jernej wrote that support and has been reviewing patches for a while > > now, so let's make him a formal reviewer. > > > > Signed-off-by: Maxime Ripard > > --- > > MAINTAINERS | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 54e222e1d0d6..fae328f06c17 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5361,6 +5361,15 @@ F: drivers/gpu/drm/sun4i/ > > F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > T: git git://anongit.freedesktop.org/drm/drm-misc > > > > +DRM DRIVER FOR ALLWINNER DE2 ENGINE > > Please make that DE2 and DE3 engine, they share almost all code. > > > +M: Maxime Ripard > > +M: Chen-Yu Tsai > > +R: Jernej Škrabec > > Please make that "S" for consistency with other entry. > > With that: > Reviewed-by: Jernej Skrabec Applied both patches, with your suggestions. Thanks, and welcome to the team :) Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111784] Hang when using glWaitSync with multithreaded shared GL contexts
https://bugs.freedesktop.org/show_bug.cgi?id=111784 Emmanuel Durand changed: What|Removed |Added Version|XOrg git|DRI git -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] MAINTAINERS: Add Jernej Škrabec as a reviewer for DE2
On Fri, Sep 20, 2019 at 10:12:30PM +0200, Jernej Škrabec wrote: > Dne petek, 20. september 2019 ob 08:08:20 CEST je Maxime Ripard napisal(a): > > Hi > > > > On Thu, Sep 19, 2019 at 09:39:19PM +0200, Daniel Vetter wrote: > > > On Thu, Sep 19, 2019 at 7:30 PM Maxime Ripard wrote: > > > > The newer Allwinner SoCs have a different layers controller than the > > > > older > > > > ones. Jernej wrote that support and has been reviewing patches for a > > > > while > > > > now, so let's make him a formal reviewer. > > > > > > > > Signed-off-by: Maxime Ripard > > > > > > Haz commit rights already, or do we need to fix that? > > > > He doesn't, as far as I'm remember. > > No, I don't. > > > > > Jernej, do you want to have drm-misc committers rights as well? > > I would be nice, yes. Thanks! You have everything needed (hopefully) there: https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html Once you have requested the account, please let us know so that we can ack it and move forward in the process. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] vringh: fix copy direction of vringh_iov_push_kern()
On Mon, 23 Sep 2019 21:03:30 +0800
Jason Wang wrote:
> We want to copy from iov to buf, so the direction was wrong.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/vringh.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Why is this included in the series? Seems like an unrelated fix being
held up within a proposal for a new feature. Thanks,
Alex
> diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c
> index 08ad0d1f0476..a0a2d74967ef 100644
> --- a/drivers/vhost/vringh.c
> +++ b/drivers/vhost/vringh.c
> @@ -852,6 +852,12 @@ static inline int xfer_kern(void *src, void *dst, size_t
> len)
> return 0;
> }
>
> +static inline int kern_xfer(void *dst, void *src, size_t len)
> +{
> + memcpy(dst, src, len);
> + return 0;
> +}
> +
> /**
> * vringh_init_kern - initialize a vringh for a kernelspace vring.
> * @vrh: the vringh to initialize.
> @@ -958,7 +964,7 @@ EXPORT_SYMBOL(vringh_iov_pull_kern);
> ssize_t vringh_iov_push_kern(struct vringh_kiov *wiov,
>const void *src, size_t len)
> {
> - return vringh_iov_xfer(wiov, (void *)src, len, xfer_kern);
> + return vringh_iov_xfer(wiov, (void *)src, len, kern_xfer);
> }
> EXPORT_SYMBOL(vringh_iov_push_kern);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #143 from Tom B --- I'm not sure how KDE handles monitor power behind the scenes but I have an uptime of 2 days now since applying the patches and with KDE I've let it turn off the monitors at least 6 or 7 times and suspend/resume 3 times without issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/msm/adreno: Add support for Adreno 510 GPU
On Sat, Sep 21, 2019 at 3:04 AM wrote:
>
> From: "Angelo G. Del Regno"
>
> The Adreno 510 GPU is a stripped version of the Adreno 5xx,
> found in low-end SoCs like 8x56 and 8x76, which has 256K of
> GMEM, with no GPMU nor ZAP.
> Also, since the Adreno 5xx part of this driver seems to be
> developed with high-end Adreno GPUs in mind, and since this
> is a lower end one, add a comment making clear which GPUs
> which support is not implemented yet is not using the GPMU
> related hw init code, so that future developers will not go
> crazy with that.
>
> By the way, the lower end Adreno GPUs with no GPMU are:
> A505/A506/A510 (no ZAP firmware)
> A508/A509/A512 (with ZAP firmware)
>
Hi, thanks for the patch.. one comment below about zap firmware...
which is not completely to do with this patch, but is my thoughts on
how we should clean up zap handling
> Signed-off-by: Angelo G. Del Regno
[snip]
> @@ -679,7 +716,8 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
>
> a5xx_preempt_hw_init(gpu);
>
> - a5xx_gpmu_ucode_init(gpu);
> + if (!adreno_is_a510(adreno_gpu))
> + a5xx_gpmu_ucode_init(gpu);
>
> ret = a5xx_ucode_init(gpu);
> if (ret)
> @@ -712,12 +750,18 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
> }
>
> /*
> -* Try to load a zap shader into the secure world. If successful
> +* If the chip that we are using does support loading one, then
> +* try to load a zap shader into the secure world. If successful
> * we can use the CP to switch out of secure mode. If not then we
> * have no resource but to try to switch ourselves out manually. If we
> * guessed wrong then access to the RBBM_SECVID_TRUST_CNTL register
> will
> * be blocked and a permissions violation will soon follow.
> */
> + if (adreno_is_a510(adreno_gpu)) {
> + gpu_write(gpu, REG_A5XX_RBBM_SECVID_TRUST_CNTL, 0x0);
> + goto skip_zap;
> + }
This is something we need to cleanup on a6xx as well. But it is
actually possible to have the same GPU with and without zap. We have
this situation today with sdm845, for example.
What I'd like to do is rather than guess whether we can write
RBBM_SECVID_TRUST_CNTL or not (since that goes spectacularly wrong
when we guess incorrectly), is choose based on the presence of the
zap-shader child node in dtb. (Currently a6xx tries to choose based
on whether zap firmware is present.. which we need to fix.)
Originally I was thinking we could keep the zap-shader node in the
SoC's "core" dtsi (ie. msm8996.dtsi, sdm845.dtsi, etc) and using
/delete-node/ in per-device dts files for devices without zap.. but
(AFAIU) the zap shader ends up being signed with a vendor key in most
cases, meaning that to have a "generic" (not device-specific) distro
image need to have different zap file names/paths for devices from
different vendors. Given this, I think it makes more sense to move
the zap-shader node into a per-device (or at least, per-vendor) dts
file, ie. something like:
/* sdm850-lenovo-yoga-c630.dts: */
gpu {
zap-shader {
memory-region = <_mem>;
zap-prefix = "LENOVO";
};
};
which would trigger the driver to try to load
/lib/firmware/qcom/LENOVO/a630_zap.mbn
(I'd like to, at least for devices that have ACPI/SMBIOS tables,
standardize on using the vendor name from SMBIOS tables as this
prefix.. so we have a way to construct the firmware path if we
eventually have ACPI boot support on the aarch64 laptops.)
BR,
-R
> +
> ret = a5xx_zap_shader_init(gpu);
> if (!ret) {
> OUT_PKT7(gpu->rb[0], CP_SET_SECURE_MODE, 1);
> @@ -733,6 +777,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
> gpu_write(gpu, REG_A5XX_RBBM_SECVID_TRUST_CNTL, 0x0);
> }
>
> +skip_zap:
> /* Last step - yield the ringbuffer */
> a5xx_preempt_start(gpu);
>
> @@ -1066,6 +,7 @@ static void a5xx_dump(struct msm_gpu *gpu)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111761] Latest Git Kernel doesn’t boot with Radeon NI with the drm-next-2019-09-18 updates
https://bugs.freedesktop.org/show_bug.cgi?id=111761 --- Comment #1 from Alex Deucher --- Can you bisect? Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/11] drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index()
On Sat, Sep 21, 2019 at 02:12:28AM +0300, Laurent Pinchart wrote: > Hi Dmitry, > > (CC'ing Heikki as the original author of software nodes support) > > Thank you for the patch. > > On Wed, Sep 11, 2019 at 12:52:10AM -0700, Dmitry Torokhov wrote: > > Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use > > the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit > > s/bit/but/ > > > works with arbitrary firmware node. > > > > Signed-off-by: Dmitry Torokhov > > Reviewed-by: Laurent Pinchart > > On a side note, as I'm not very familiar with software nodes, I tried to > see how they are to be used, and it seems they are completely > undocumented :-( Heikki, is this something that could be fixed ? OK. I'll start writing API documentation for it. thanks, -- heikki
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On 7/12/19 1:06 PM, Ville Syrjälä wrote: On Fri, Jul 12, 2019 at 12:07:46PM -0400, Tony Camuso wrote: On 7/10/19 9:56 AM, Ville Syrjälä wrote: On Wed, Jul 10, 2019 at 09:47:11AM -0400, Tony Camuso wrote: On 5/24/19 4:36 AM, Jani Nikula wrote: On Thu, 23 May 2019, tcamuso wrote: From Daniel Kwon The system was crashed due to invalid memory access while trying to access auxiliary device. crash> bt PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool" #0 [89cedd7f3868] machine_kexec at b0663674 #1 [89cedd7f38c8] __crash_kexec at b071cf62 #2 [89cedd7f3998] crash_kexec at b071d050 #3 [89cedd7f39b0] oops_end at b0d6d758 #4 [89cedd7f39d8] no_context at b0d5bcde #5 [89cedd7f3a28] __bad_area_nosemaphore at b0d5bd75 #6 [89cedd7f3a78] bad_area at b0d5c085 #7 [89cedd7f3aa0] __do_page_fault at b0d7080c #8 [89cedd7f3b10] do_page_fault at b0d70905 #9 [89cedd7f3b40] page_fault at b0d6c758 [exception RIP: drm_dp_aux_dev_get_by_minor+0x3d] RIP: c0a589bd RSP: 89cedd7f3bf0 RFLAGS: 00010246 RAX: RBX: RCX: 89cedd7f3fd8 RDX: RSI: RDI: c0a613e0 RBP: 89cedd7f3bf8 R8: 89f1bcbabbd0 R9: R10: 89f1be7a1cc0 R11: R12: R13: 89f1b32a2830 R14: 89d18fadfa00 R15: ORIG_RAX: CS: 0010 SS: 0018 RIP: 2b45f0d80d30 RSP: 7ffc416066a0 RFLAGS: 00010246 RAX: 0002 RBX: 56062e212d80 RCX: 7ffc41606810 RDX: RSI: 0002 RDI: 7ffc41606ec0 RBP: R8: 56062dfed229 R9: 2b45f0cdf14d R10: 0002 R11: 0246 R12: 7ffc41606ec0 R13: 7ffc41606ed0 R14: 7ffc41606ee0 R15: ORIG_RAX: 0002 CS: 0033 SS: 002b It was trying to open '/dev/ipmi0', but as no entry in aux_dir, it returned NULL from 'idr_find()'. This drm_dp_aux_dev_get_by_minor() should have done a check on this, but had failed to do it. I think the better question is, *why* does the idr_find() return NULL? I don't think it should, under any circumstances. I fear adding the check here papers over some other problem, taking us further away from the root cause. Also, can you reproduce this on a recent upstream kernel? The aux device nodes were introduced in kernel v4.6. Whatever you reproduced on v3.10 is pretty much irrelevant for upstream. BR, Jani. I have not been able to reproduce this problem. mknod /dev/foo c 255 cat /dev/foo should do it. How do I determine ? ls,file,stat. Take your pick. Problem here is I can't ls,file,stat /dev/foo until after it's created, but I need to know the drm_dp_aux major number befroe I can use mknod. What am I missing here?
Re: [PATCH 2/6] mdev: introduce device specific ops
On Mon, Sep 23, 2019 at 11:20:12PM +0800, kbuild test robot wrote: > Hi Jason, > > I love your patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [cannot apply to v5.3 next-20190920] > [if your patch is applied to the wrong git tree, please drop us a note to help > improve the system. BTW, we also suggest to use '--base' option to specify the > base tree in git format-patch, please see > https://stackoverflow.com/a/37406982] > > url: > https://github.com/0day-ci/linux/commits/Jason-Wang/mdev-based-hardware-virtio-offloading-support/20190923-210738 > config: ia64-allmodconfig (attached as .config) > compiler: ia64-linux-gcc (GCC) 7.4.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > GCC_VERSION=7.4.0 make.cross ARCH=ia64 > > If you fix the issue, kindly add following tag > Reported-by: kbuild test robot > > All error/warnings (new ones prefixed by >>): Looks like a bunch of includes missing. I guess they happen to be pulled in on some platforms but not others - ideally headers should be self contained though, pulling in all their dependencies. >In file included from include/linux/vfio_mdev.h:10:0, > from :0: > >> include/linux/mdev.h:25:34: warning: 'struct device' declared inside > >> parameter list will not be visible outside of this definition or > >> declaration > int mdev_set_iommu_device(struct device *dev, struct device > *iommu_device); > ^~ > >> include/linux/mdev.h:62:27: warning: 'struct kobject' declared inside > >> parameter list will not be visible outside of this definition or > >> declaration > int (*create)(struct kobject *kobj, struct mdev_device *mdev); > ^~~ > >> include/linux/mdev.h:69:19: error: field 'attr' has incomplete type > struct attribute attr; > ^~~~ >include/linux/mdev.h:70:25: warning: 'struct kobject' declared inside > parameter list will not be visible outside of this definition or declaration > ssize_t (*show)(struct kobject *kobj, struct device *dev, char *buf); > ^~~ >include/linux/mdev.h:71:26: warning: 'struct kobject' declared inside > parameter list will not be visible outside of this definition or declaration > ssize_t (*store)(struct kobject *kobj, struct device *dev, > ^~~ > >> include/linux/mdev.h:98:23: error: field 'driver' has incomplete type > struct device_driver driver; > ^~ > >> include/linux/mdev.h:106:7: error: unknown type name 'guid_t' > const guid_t *mdev_uuid(struct mdev_device *mdev); > ^~ >In file included from :0:0: > >> include/linux/vfio_mdev.h:50:47: warning: 'struct vm_area_struct' declared > >> inside parameter list will not be visible outside of this definition or > >> declaration > int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma); > ^~ > > vim +/attr +69 include/linux/mdev.h > > 7b96953bc640b6 Kirti Wankhede 2016-11-17 14 > 8ac13175cbe985 Lu Baolu2019-04-12 15 /* > 8ac13175cbe985 Lu Baolu2019-04-12 16 * Called by the parent > device driver to set the device which represents > 8ac13175cbe985 Lu Baolu2019-04-12 17 * this mdev in iommu > protection scope. By default, the iommu device is > 8ac13175cbe985 Lu Baolu2019-04-12 18 * NULL, that indicates using > vendor defined isolation. > 8ac13175cbe985 Lu Baolu2019-04-12 19 * > 8ac13175cbe985 Lu Baolu2019-04-12 20 * @dev: the mediated device > that iommu will isolate. > 8ac13175cbe985 Lu Baolu2019-04-12 21 * @iommu_device: a pci > device which represents the iommu for @dev. > 8ac13175cbe985 Lu Baolu2019-04-12 22 * > 8ac13175cbe985 Lu Baolu2019-04-12 23 * Return 0 for success, > otherwise negative error value. > 8ac13175cbe985 Lu Baolu2019-04-12 24 */ > 8ac13175cbe985 Lu Baolu2019-04-12 @25 int > mdev_set_iommu_device(struct device *dev, struct device *iommu_device); > 8ac13175cbe985 Lu Baolu2019-04-12 26 > 8ac13175cbe985 Lu Baolu2019-04-12 27 struct device > *mdev_get_iommu_device(struct device *dev); > 8ac13175cbe985 Lu Baolu2019-04-12 28 > 7b96953bc640b6 Kirti Wankhede 2016-11-17
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #144 from sehell...@gmail.com --- I also think this is strange. Since yesterday, they turned off and on many times successfully without any problems. Most likely, it's connected with something else, but I don’t know where to find. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/imx: Add initial support for DCSS on iMX8MQ
Hi Laurentiu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Laurentiu-Palcu/Add-support-for-iMX8MQ-Display-Controller-Subsystem/20190923-230115
config: c6x-allyesconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=c6x
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/imx/dcss/dcss-blkctl.c: In function 'dcss_blkctl_init':
>> drivers/gpu/drm/imx/dcss/dcss-blkctl.c:50:58: error: 'SZ_4K' undeclared
>> (first use in this function)
blkctl->base_reg = devm_ioremap(dcss->dev, blkctl_base, SZ_4K);
^
drivers/gpu/drm/imx/dcss/dcss-blkctl.c:50:58: note: each undeclared
identifier is reported only once for each function it appears in
--
drivers/gpu/drm/imx/dcss/dcss-dtg.c: In function 'dcss_dtg_init':
>> drivers/gpu/drm/imx/dcss/dcss-dtg.c:174:52: error: 'SZ_4K' undeclared (first
>> use in this function)
dtg->base_reg = devm_ioremap(dcss->dev, dtg_base, SZ_4K);
^
drivers/gpu/drm/imx/dcss/dcss-dtg.c:174:52: note: each undeclared identifier
is reported only once for each function it appears in
--
drivers/gpu/drm/imx/dcss/dcss-ss.c: In function 'dcss_ss_init':
>> drivers/gpu/drm/imx/dcss/dcss-ss.c:93:50: error: 'SZ_4K' undeclared (first
>> use in this function)
ss->base_reg = devm_ioremap(dcss->dev, ss_base, SZ_4K);
^
drivers/gpu/drm/imx/dcss/dcss-ss.c:93:50: note: each undeclared identifier
is reported only once for each function it appears in
--
drivers/gpu/drm/imx/dcss/dcss-dpr.c: In function 'dcss_dpr_ch_init_all':
>> drivers/gpu/drm/imx/dcss/dcss-dpr.c:125:55: error: 'SZ_4K' undeclared (first
>> use in this function)
ch->base_reg = devm_ioremap(dpr->dev, ch->base_ofs, SZ_4K);
^
drivers/gpu/drm/imx/dcss/dcss-dpr.c:125:55: note: each undeclared identifier
is reported only once for each function it appears in
--
drivers/gpu/drm/imx/dcss/dcss-scaler.c: In function
'dcss_scaler_ch_init_all':
>> drivers/gpu/drm/imx/dcss/dcss-scaler.c:287:55: error: 'SZ_4K' undeclared
>> (first use in this function)
ch->base_reg = devm_ioremap(scl->dev, ch->base_ofs, SZ_4K);
^
drivers/gpu/drm/imx/dcss/dcss-scaler.c:287:55: note: each undeclared
identifier is reported only once for each function it appears in
vim +/SZ_4K +50 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
41
42 int dcss_blkctl_init(struct dcss_dev *dcss, unsigned long blkctl_base)
43 {
44 struct dcss_blkctl *blkctl;
45
46 blkctl = devm_kzalloc(dcss->dev, sizeof(*blkctl), GFP_KERNEL);
47 if (!blkctl)
48 return -ENOMEM;
49
> 50 blkctl->base_reg = devm_ioremap(dcss->dev, blkctl_base, SZ_4K);
51 if (!blkctl->base_reg) {
52 dev_err(dcss->dev, "unable to remap BLK CTRL base\n");
53 devm_kfree(dcss->dev, blkctl);
54 return -ENOMEM;
55 }
56
57 dcss->blkctl = blkctl;
58 blkctl->dev = dcss->dev;
59 blkctl->hdmi_output = dcss->hdmi_output;
60
61 dcss_blkctl_cfg(blkctl);
62
63 return 0;
64 }
65
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111784] Hang when using glWaitSync with multithreaded shared GL contexts
https://bugs.freedesktop.org/show_bug.cgi?id=111784 --- Comment #1 from Emmanuel Durand --- Created attachment 145473 --> https://bugs.freedesktop.org/attachment.cgi?id=145473=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111784] Hang when using glWaitSync with multithreaded shared GL contexts
https://bugs.freedesktop.org/show_bug.cgi?id=111784 Emmanuel Durand changed: What|Removed |Added Priority|not set |high -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/21] drm/dp: Various helper improvements and cleanups
On Mon, Sep 23, 2019 at 04:52:50PM +0300, Jani Nikula wrote: > On Fri, 20 Sep 2019, Thierry Reding wrote: > > On Mon, Sep 02, 2019 at 01:31:00PM +0200, Thierry Reding wrote: > >> From: Thierry Reding > >> > >> Hi, > >> > >> this series of patches improves the DP helpers a bit and cleans up some > >> inconsistencies along the way. > >> > >> v2 incorporates all review comments add collects Reviewed-bys from v1. > >> > >> Thierry > >> > >> Thierry Reding (21): > >> drm/dp: Sort includes alphabetically > >> drm/dp: Add missing kerneldoc for struct drm_dp_link > >> drm/dp: Add drm_dp_link_reset() implementation > >> drm/dp: Track link capabilities alongside settings > >> drm/dp: Turn link capabilities into booleans > >> drm/dp: Probe link using existing parsing helpers > >> drm/dp: Read fast training capability from link > >> drm/dp: Read TPS3 capability from sink > >> drm/dp: Read channel coding capability from sink > >> drm/dp: Read alternate scrambler reset capability from sink > >> drm/dp: Read eDP version from DPCD > >> drm/dp: Read AUX read interval from DPCD > >> drm/dp: Do not busy-loop during link training > >> drm/dp: Use drm_dp_aux_rd_interval() > >> drm/dp: Add helper to get post-cursor adjustments > >> drm/dp: Set channel coding on link configuration > >> drm/dp: Enable alternate scrambler reset when supported > >> drm/dp: Add drm_dp_link_choose() helper > >> drm/dp: Add support for eDP link rates > >> drm/dp: Remove a gratuituous blank line > >> drm/bridge: tc358767: Use DP nomenclature > > > > Anyone interested in reviewing these? > > Thierry, I don't quite know how to put this nicely, but I also don't > think it's nice to not reply at all. So I'll try to be fair but it'll be > blunt. Fair enough? Fair enough. > I've glanced over the series, already before you pinged for reviews. It > looks like you've put effort into it, and it all looks nice. However, it > does not look like we could use this in i915, without significant effort > both on top of this work and in i915. It does not feel like there's any > incentive for us to review this in detail. > > It also feels like there's an increasing disconnect between "small" and > "big" drivers (*) when it comes to handling DP link and training. It > scares me a bit that this work is being done on the terms of the "small" > drivers, and that later in time this might be considered the One True > Way of handling DP. I'm not sure I understand your concern here. The goal of the series is primarily to extend the existing support for DP. It follows the pattern established by existing helpers and then goes one step further and provides some common way of actually storing the values that are being read from the sink so that they can be used. These are meant to be helpers and in no way should anyone feel obliged to use them. If you've got this all figured out already, great! If you do this already much better in i915, by all means stay away from this. At the same time it seems counter-productive to write all of this code as part of the Tegra DRM driver. In my opinion subsystems should provide generic helpers that can help multiple drivers share code. This is especially true for things that are defined in a specification because there's not a lot of room for interpretation. The helpers in these patches are meant to be that kind of helpers. > One of the technical observations is that you fill the struct > drm_dp_link and struct drm_dp_link_caps from the sink. It's not clear > that the link caps really are an intersection of the source and sink > caps. The eDP 1.4 link rates are the prime example. I think you should > have sets of source and sink rates, and you should intersect those to > find out the available link rates. The max rate is the highest number in > that set. Similarly for many things, like training pattern support. I > think it's only going to get more complicated with DP 2.0. The idea here was to provide only helpers to collect the DPCD data defined by the specification. Anything specific to the source is meant to be handled by display driver. In case of eDP 1.4 link rates the code will only add the rates read from DPCD. It's up to the driver to filter out rates that it doesn't support from that list. I think the fact that things will keep getting more complicated is an argument in favour of sharing code rather than keep doing the same (complicated) thing over and over again in every driver. > Another pain point is the caching of the caps as bits in > drm_dp_link_caps. How far are you going to take it? There's an insane > and growing amount of things in the DPCD that describe the link in one > way or another. Should they all be added to caps? Where do you draw the > line? Do we add both the bit and the helper for getting that bit from > the DPCD? And are you then going to add support for intersecting all > those cap bits between the source and the sink? Like I said the primary goal here is
Re: [PATCH 13/36] drm/nouveau: use bpp instead of cpp for drm_format_info
On Mon, Sep 23, 2019 at 8:56 AM Sandy Huang wrote:
>
> cpp[BytePerPlane] can't describe the 10bit data format correctly,
> So we use bpp[BitPerPlane] to instead cpp.
>
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 7 ---
> drivers/gpu/drm/nouveau/dispnv50/base507c.c | 4 ++--
> drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
> 3 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index f22f010..59d2f07 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -874,11 +874,12 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
>
> /* Update the framebuffer location. */
> regp->fb_start = nv_crtc->fb.offset & ~3;
> - regp->fb_start += (y * drm_fb->pitches[0]) + (x *
> drm_fb->format->cpp[0]);
> + regp->fb_start += (y * drm_fb->pitches[0]) +
> + (x * drm_fb->format->bpp[0] / 8);
> nv_set_crtc_base(dev, nv_crtc->index, regp->fb_start);
>
> /* Update the arbitration parameters. */
> - nouveau_calc_arb(dev, crtc->mode.clock, drm_fb->format->cpp[0] * 8,
> + nouveau_calc_arb(dev, crtc->mode.clock, drm_fb->format->bpp[0],
> _burst, _lwm);
>
> regp->CRTC[NV_CIO_CRE_FF_INDEX] = arb_burst;
> @@ -1238,7 +1239,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
> drm_framebuffer *fb,
>
> /* Initialize a page flip struct */
> *s = (struct nv04_page_flip_state)
> - { { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
> + { { }, event, crtc, fb->format->bpp[0], fb->pitches[0],
> new_bo->bo.offset };
>
> /* Keep vblanks on during flip, for the target crtc of this flip */
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/base507c.c
> b/drivers/gpu/drm/nouveau/dispnv50/base507c.c
> index d5e295c..59883bd0 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/base507c.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/base507c.c
> @@ -190,12 +190,12 @@ base507c_acquire(struct nv50_wndw *wndw, struct
> nv50_wndw_atom *asyw,
> return ret;
>
> if (!wndw->func->ilut) {
> - if ((asyh->base.cpp != 1) ^ (fb->format->cpp[0] != 1))
> + if (asyh->base.cpp != 1 ^ fb->format->bpp[0] != 8)
Please leave the parens in. Even if it works out to the same thing
(don't know), ^ vs != ordering isn't fresh in many people's minds
(mine included).
> asyh->state.color_mgmt_changed = true;
> }
>
> asyh->base.depth = fb->format->depth;
> - asyh->base.cpp = fb->format->cpp[0];
> + asyh->base.cpp = fb->format->bpp[0] / 8;
> asyh->base.x = asyw->state.src.x1 >> 16;
> asyh->base.y = asyw->state.src.y1 >> 16;
> asyh->base.w = asyw->state.fb->width;
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c
> b/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c
> index cc41766..c6c2e0b 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c
> @@ -135,7 +135,7 @@ ovly507e_acquire(struct nv50_wndw *wndw, struct
> nv50_wndw_atom *asyw,
> if (ret)
> return ret;
>
> - asyh->ovly.cpp = fb->format->cpp[0];
> + asyh->ovly.cpp = fb->format->bpp[0] / 8;
> return 0;
> }
>
> --
> 2.7.4
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] mdev: introduce device specific ops
Hi Jason, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3 next-20190920] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Jason-Wang/mdev-based-hardware-virtio-offloading-support/20190923-210738 config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=ia64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All error/warnings (new ones prefixed by >>): In file included from include/linux/vfio_mdev.h:10:0, from :0: >> include/linux/mdev.h:25:34: warning: 'struct device' declared inside >> parameter list will not be visible outside of this definition or declaration int mdev_set_iommu_device(struct device *dev, struct device *iommu_device); ^~ >> include/linux/mdev.h:62:27: warning: 'struct kobject' declared inside >> parameter list will not be visible outside of this definition or declaration int (*create)(struct kobject *kobj, struct mdev_device *mdev); ^~~ >> include/linux/mdev.h:69:19: error: field 'attr' has incomplete type struct attribute attr; ^~~~ include/linux/mdev.h:70:25: warning: 'struct kobject' declared inside parameter list will not be visible outside of this definition or declaration ssize_t (*show)(struct kobject *kobj, struct device *dev, char *buf); ^~~ include/linux/mdev.h:71:26: warning: 'struct kobject' declared inside parameter list will not be visible outside of this definition or declaration ssize_t (*store)(struct kobject *kobj, struct device *dev, ^~~ >> include/linux/mdev.h:98:23: error: field 'driver' has incomplete type struct device_driver driver; ^~ >> include/linux/mdev.h:106:7: error: unknown type name 'guid_t' const guid_t *mdev_uuid(struct mdev_device *mdev); ^~ In file included from :0:0: >> include/linux/vfio_mdev.h:50:47: warning: 'struct vm_area_struct' declared >> inside parameter list will not be visible outside of this definition or >> declaration int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma); ^~ vim +/attr +69 include/linux/mdev.h 7b96953bc640b6 Kirti Wankhede 2016-11-17 14 8ac13175cbe985 Lu Baolu2019-04-12 15 /* 8ac13175cbe985 Lu Baolu2019-04-12 16 * Called by the parent device driver to set the device which represents 8ac13175cbe985 Lu Baolu2019-04-12 17 * this mdev in iommu protection scope. By default, the iommu device is 8ac13175cbe985 Lu Baolu2019-04-12 18 * NULL, that indicates using vendor defined isolation. 8ac13175cbe985 Lu Baolu2019-04-12 19 * 8ac13175cbe985 Lu Baolu2019-04-12 20 * @dev: the mediated device that iommu will isolate. 8ac13175cbe985 Lu Baolu2019-04-12 21 * @iommu_device: a pci device which represents the iommu for @dev. 8ac13175cbe985 Lu Baolu2019-04-12 22 * 8ac13175cbe985 Lu Baolu2019-04-12 23 * Return 0 for success, otherwise negative error value. 8ac13175cbe985 Lu Baolu2019-04-12 24 */ 8ac13175cbe985 Lu Baolu2019-04-12 @25 int mdev_set_iommu_device(struct device *dev, struct device *iommu_device); 8ac13175cbe985 Lu Baolu2019-04-12 26 8ac13175cbe985 Lu Baolu2019-04-12 27 struct device *mdev_get_iommu_device(struct device *dev); 8ac13175cbe985 Lu Baolu2019-04-12 28 7b96953bc640b6 Kirti Wankhede 2016-11-17 29 /** 42930553a7c11f Alex Williamson 2016-12-30 30 * struct mdev_parent_ops - Structure to be registered for each parent device to 7b96953bc640b6 Kirti Wankhede 2016-11-17 31 * register the device to mdev module. 7b96953bc640b6 Kirti Wankhede 2016-11-17 32 * 7b96953bc640b6 Kirti Wankhede 2016-11-17 33 * @owner: The module owner. 7b96953bc640b6 Kirti Wankhede 2016-11-17 34 * @dev_attr_groups: Attributes of the parent device. 7b96953bc640b6 Kirti Wankhede 2016-11-17 35 * @mdev_attr_groups: Attributes of the mediated device. 7b96953bc640b6 Kirti Wankhede 2016-11-17 36 * @supported_type_groups: Attributes to define supported types. It is mandatory 7b96953bc640b6 Kirti Wankhe
Re: [PATCH] drm/rockchip: Add AFBC support
Dear All,
As a result of my mistake I've sent this patch with an incorrect SOB chain.
Please kindly disregard this patch.
@Neil: thank you for your time you spent reviewing it and answering and I'm
sorry it's to no effect.
@Ezequiel, @Tomeu: I apologize to you. My mistake.
Regards,
Andrzej Pietrasiewicz
W dniu 23.09.2019 o 15:53, Neil Armstrong pisze:
On 23/09/2019 14:20, Andrzej Pietrasiewicz wrote:
From: Ezequiel Garcia
AFBC is a proprietary lossless image compression protocol and format.
It helps reduce memory bandwidth of the graphics pipeline operations.
This, in turn, improves power efficiency.
Signed-off-by: Ezequiel Garcia
[locking improvements]
Signed-off-by: Tomeu Vizoso
[squashing the above, commit message and Rockchip AFBC modifier]
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 27 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 -
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 18
include/uapi/drm/drm_fourcc.h | 3 +
5 files changed, 151 insertions(+), 3 deletions(-)
[...]
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..ba6caf06c824 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -742,6 +742,9 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+#define AFBC_FORMAT_MOD_ROCKCHIP \
+ (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)
This define looks useless, what's Rockchip specific here ?
Neil
+
/*
* Allwinner tiled modifier
*
Re: [PATCH v18 06/19] lib: enable building KUnit in lib/
Quoting Brendan Higgins (2019-09-23 02:02:36) > KUnit is a new unit testing framework for the kernel and when used is > built into the kernel as a part of it. Add KUnit to the lib Kconfig and > Makefile to allow it to be actually built. > > Signed-off-by: Brendan Higgins > Cc: Randy Dunlap > Cc: Andrew Morton > Cc: Masahiro Yamada > Cc: Kees Cook > --- Reviewed-by: Stephen Boyd
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 --- Comment #142 from sehell...@gmail.com --- (In reply to Alex Deucher from comment #141) > (In reply to sehellion from comment #140) > > Created attachment 145463 [details] > > 5.3.1 with Alex's patches and dual monitors, crash > > That's not a crash, it's just a warning. But system hangs after. Today it happened twice. When I try to resume work, monitors turn on, then the secondary shows that there is no signal, and the primary shows a black screen. But perhaps this is not related to this bug. I can connect via ssh and see logs when this happens, if necessary. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] mdev: class id support
On Mon, 23 Sep 2019 21:03:26 +0800
Jason Wang wrote:
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> one example is virtio-mdev[1] driver. This means we need to add device
> class id support in bus match method to pair the mdev device and mdev
> driver correctly.
>
> So this patch adds id_table to mdev_driver and class_id for mdev
> parent with the match method for mdev bus.
>
> Signed-off-by: Jason Wang
> ---
> Documentation/driver-api/vfio-mediated-device.rst | 7 +--
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
> drivers/s390/cio/vfio_ccw_ops.c | 2 +-
> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
> drivers/vfio/mdev/mdev_core.c | 14 --
> drivers/vfio/mdev/mdev_driver.c | 14 ++
> drivers/vfio/mdev/mdev_private.h | 1 +
> drivers/vfio/mdev/vfio_mdev.c | 6 ++
> include/linux/mdev.h | 7 ++-
> include/linux/mod_devicetable.h | 8
> samples/vfio-mdev/mbochs.c| 2 +-
> samples/vfio-mdev/mdpy.c | 2 +-
> samples/vfio-mdev/mtty.c | 2 +-
> 13 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 25eb7d5b834b..0e052072e1d8 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
>* @probe: called when new device created
>* @remove: called when device removed
>* @driver: device driver structure
> + * @id_table: the ids serviced by this driver.
>*/
> struct mdev_driver {
>const char *name;
>int (*probe) (struct device *dev);
>void (*remove) (struct device *dev);
>struct device_driverdriver;
> + const struct mdev_class_id *id_table;
> };
>
> A mediated bus driver for mdev should use this structure in the function
> calls
> @@ -116,7 +118,7 @@ to register and unregister itself with the core driver:
> * Register::
>
> extern int mdev_register_driver(struct mdev_driver *drv,
> -struct module *owner);
> + struct module *owner);
>
> * Unregister::
>
> @@ -163,7 +165,8 @@ A driver should use the mdev_parent_ops structure in the
> function call to
> register itself with the mdev core driver::
>
> extern int mdev_register_device(struct device *dev,
> - const struct mdev_parent_ops *ops);
> + const struct mdev_parent_ops *ops,
> + u8 class_id);
>
> However, the mdev_parent_ops structure is not required in the function call
> that a driver should use to unregister itself with the mdev core driver::
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 23aa3e50cbf8..19d51a35f019 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1625,7 +1625,7 @@ static int kvmgt_host_init(struct device *dev, void
> *gvt, const void *ops)
> return -EFAULT;
> intel_vgpu_ops.supported_type_groups = kvm_vgpu_type_groups;
>
> - return mdev_register_device(dev, _vgpu_ops);
> + return mdev_register_vfio_device(dev, _vgpu_ops);
> }
>
> static void kvmgt_host_exit(struct device *dev)
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index f0d71ab77c50..246ff0f80944 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -588,7 +588,7 @@ static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
>
> int vfio_ccw_mdev_reg(struct subchannel *sch)
> {
> - return mdev_register_device(>dev, _ccw_mdev_ops);
> + return mdev_register_vfio_device(>dev, _ccw_mdev_ops);
> }
>
> void vfio_ccw_mdev_unreg(struct subchannel *sch)
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index 5c0f53c6dde7..7487fc39d2c5 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -1295,7 +1295,8 @@ int vfio_ap_mdev_register(void)
> {
> atomic_set(_dev->available_instances, MAX_ZDEV_ENTRIES_EXT);
>
> - return mdev_register_device(_dev->device, _ap_matrix_ops);
> + return mdev_register_vfio_device(_dev->device,
> + _ap_matrix_ops);
> }
>
> void vfio_ap_mdev_unregister(void)
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index
[PULL] drm-misc-next-fixes
Hi Daniel, Dave, Here is a new round of drm-misc-next fixes Maxime drm-misc-next-fixes-2019-09-23: - Multiple panfrost fixes for regulator support and page fault handling - Some cleanups and fixes in the self-refresh helpers - Some cleanups and fixes in the atomic helpers The following changes since commit 88537ddbbe4c755e193aa220a306395edf08a4cf: drm/mcde: Fix DSI transfers (2019-09-04 22:05:34 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2019-09-23 for you to fetch changes up to 65e51e30d8625c82ddfe405da46124e9bbffaa71: drm/panfrost: Prevent race when handling page fault (2019-09-19 11:48:57 -0500) - Multiple panfrost fixes for regulator support and page fault handling - Some cleanups and fixes in the self-refresh helpers - Some cleanups and fixes in the atomic helpers Daniel Vetter (4): drm/kms: Duct-tape for mode object lifetime checks drm/atomic: Take the atomic toys away from X drm/atomic: Reject FLIP_ASYNC unconditionally drm/atomic: Rename crtc_state->pageflip_flags to async_flip Mark Brown (1): drm/panfrost: Fix regulator_get_optional() misuse Rob Clark (1): Revert "drm/bridge: adv7511: Attach to DSI host at probe time" Sean Paul (2): drm: Fix kerneldoc and remove unused struct member in self_refresh helper drm: Measure Self Refresh Entry/Exit times to avoid thrashing Steven Price (2): drm/panfrost: Remove NULL checks for regulator drm/panfrost: Prevent race when handling page fault drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 +--- drivers/gpu/drm/drm_atomic_helper.c | 22 ++- drivers/gpu/drm/drm_atomic_state_helper.c | 2 +- drivers/gpu/drm/drm_atomic_uapi.c | 3 +- drivers/gpu/drm/drm_drv.c | 4 +- drivers/gpu/drm/drm_ioctl.c | 7 ++- drivers/gpu/drm/drm_mode_object.c | 4 +- drivers/gpu/drm/drm_self_refresh_helper.c | 73 --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4 +- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 ++-- drivers/gpu/drm/panfrost/panfrost_device.c| 8 +-- drivers/gpu/drm/panfrost/panfrost_mmu.c | 55 +++-- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +- include/drm/drm_crtc.h| 10 ++-- include/drm/drm_self_refresh_helper.h | 6 +- 16 files changed, 157 insertions(+), 73 deletions(-) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/panfrost: Reduce the amount of logs on deferred probe
There is no point to print deferred probe (and its failures to get
resources) as an error. Also there is no need to print regulator errors
twice.
In case of multiple probe tries this would pollute the dmesg.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Remove second error message from calling panfrost_regulator_init().
---
drivers/gpu/drm/panfrost/panfrost_device.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 46b0b02e4289..287c6ba314d9 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -95,7 +95,9 @@ static int panfrost_regulator_init(struct panfrost_device
*pfdev)
pfdev->regulator = NULL;
if (ret == -ENODEV)
return 0;
- dev_err(pfdev->dev, "failed to get regulator: %d\n", ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(pfdev->dev, "failed to get regulator: %d\n",
+ ret);
return ret;
}
@@ -133,10 +135,8 @@ int panfrost_device_init(struct panfrost_device *pfdev)
}
err = panfrost_regulator_init(pfdev);
- if (err) {
- dev_err(pfdev->dev, "regulator init failed %d\n", err);
+ if (err)
goto err_out0;
- }
err = panfrost_reset_init(pfdev);
if (err) {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII
https://bugs.freedesktop.org/show_bug.cgi?id=110674 Alex Deucher changed: What|Removed |Added Attachment #145463|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: assure aux_dev is nonzero before using it
On Mon, Sep 23, 2019 at 11:03:35AM -0400, Tony Camuso wrote: > On 7/12/19 1:06 PM, Ville Syrjälä wrote: > > On Fri, Jul 12, 2019 at 12:07:46PM -0400, Tony Camuso wrote: > >> On 7/10/19 9:56 AM, Ville Syrjälä wrote: > >>> On Wed, Jul 10, 2019 at 09:47:11AM -0400, Tony Camuso wrote: > On 5/24/19 4:36 AM, Jani Nikula wrote: > > On Thu, 23 May 2019, tcamuso wrote: > >>From Daniel Kwon > >> > >> The system was crashed due to invalid memory access while trying to > >> access > >> auxiliary device. > >> > >> crash> bt > >> PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool" > >> #0 [89cedd7f3868] machine_kexec at b0663674 > >> #1 [89cedd7f38c8] __crash_kexec at b071cf62 > >> #2 [89cedd7f3998] crash_kexec at b071d050 > >> #3 [89cedd7f39b0] oops_end at b0d6d758 > >> #4 [89cedd7f39d8] no_context at b0d5bcde > >> #5 [89cedd7f3a28] __bad_area_nosemaphore at b0d5bd75 > >> #6 [89cedd7f3a78] bad_area at b0d5c085 > >> #7 [89cedd7f3aa0] __do_page_fault at b0d7080c > >> #8 [89cedd7f3b10] do_page_fault at b0d70905 > >> #9 [89cedd7f3b40] page_fault at b0d6c758 > >>[exception RIP: drm_dp_aux_dev_get_by_minor+0x3d] > >>RIP: c0a589bd RSP: 89cedd7f3bf0 RFLAGS: 00010246 > >>RAX: RBX: RCX: > >> 89cedd7f3fd8 > >>RDX: RSI: RDI: > >> c0a613e0 > >>RBP: 89cedd7f3bf8 R8: 89f1bcbabbd0 R9: > >> > >>R10: 89f1be7a1cc0 R11: R12: > >> > >>R13: 89f1b32a2830 R14: 89d18fadfa00 R15: > >> > >>ORIG_RAX: CS: 0010 SS: 0018 > >>RIP: 2b45f0d80d30 RSP: 7ffc416066a0 RFLAGS: 00010246 > >>RAX: 0002 RBX: 56062e212d80 RCX: > >> 7ffc41606810 > >>RDX: RSI: 0002 RDI: > >> 7ffc41606ec0 > >>RBP: R8: 56062dfed229 R9: > >> 2b45f0cdf14d > >>R10: 0002 R11: 0246 R12: > >> 7ffc41606ec0 > >>R13: 7ffc41606ed0 R14: 7ffc41606ee0 R15: > >> > >>ORIG_RAX: 0002 CS: 0033 SS: 002b > >> > >> > >> > >> It was trying to open '/dev/ipmi0', but as no entry in aux_dir, it > >> returned > >> NULL from 'idr_find()'. This drm_dp_aux_dev_get_by_minor() should have > >> done a > >> check on this, but had failed to do it. > > > > I think the better question is, *why* does the idr_find() return NULL? I > > don't think it should, under any circumstances. I fear adding the check > > here papers over some other problem, taking us further away from the > > root cause. > > > > Also, can you reproduce this on a recent upstream kernel? The aux device > > nodes were introduced in kernel v4.6. Whatever you reproduced on v3.10 > > is pretty much irrelevant for upstream. > > > > > > BR, > > Jani. > > I have not been able to reproduce this problem. > >>> > >>> mknod /dev/foo c 255 > >>> cat /dev/foo > >>> > >>> should do it. > >> > >> How do I determine ? > > > > ls,file,stat. Take your pick. > > > > Problem here is I can't ls,file,stat /dev/foo until after it's created, > but I need to know the drm_dp_aux major number befroe I can use mknod. > > What am I missing here? udev/whatever should create a bunch of these for you so you can check from them. If not, then dig around in /sys/class/drm_dp_aux_dev. -- Ville Syrjälä Intel
[PATCH trivial] gpu: Fix Kconfig indentation
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^/\t/' -i */Kconfig Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/Kconfig | 10 +- drivers/gpu/drm/amd/display/Kconfig | 20 ++-- drivers/gpu/drm/bridge/Kconfig | 8 +- drivers/gpu/drm/i915/Kconfig | 12 +- drivers/gpu/drm/i915/Kconfig.debug | 144 +++ drivers/gpu/drm/lima/Kconfig | 2 +- drivers/gpu/drm/mgag200/Kconfig | 8 +- drivers/gpu/drm/nouveau/Kconfig | 2 +- drivers/gpu/drm/omapdrm/displays/Kconfig | 6 +- drivers/gpu/drm/omapdrm/dss/Kconfig | 12 +- drivers/gpu/drm/rockchip/Kconfig | 8 +- drivers/gpu/drm/udl/Kconfig | 2 +- drivers/gpu/vga/Kconfig | 2 +- 13 files changed, 118 insertions(+), 118 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index e67c194c2aca..7cb6e4eb99e8 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -207,8 +207,8 @@ config DRM_RADEON tristate "ATI Radeon" depends on DRM && PCI && MMU select FW_LOADER -select DRM_KMS_HELPER -select DRM_TTM + select DRM_KMS_HELPER + select DRM_TTM select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE @@ -226,9 +226,9 @@ config DRM_AMDGPU tristate "AMD GPU" depends on DRM && PCI && MMU select FW_LOADER -select DRM_KMS_HELPER + select DRM_KMS_HELPER select DRM_SCHED -select DRM_TTM + select DRM_TTM select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE @@ -266,7 +266,7 @@ config DRM_VKMS If M is selected the module will be called vkms. config DRM_ATI_PCIGART -bool + bool source "drivers/gpu/drm/exynos/Kconfig" diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 71991a28a775..0a35cb8e803a 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -23,16 +23,16 @@ config DRM_AMD_DC_DCN2_0 depends on DRM_AMD_DC && X86 depends on DRM_AMD_DC_DCN1_0 help - Choose this option if you want to have - Navi support for display engine + Choose this option if you want to have + Navi support for display engine config DRM_AMD_DC_DCN2_1 -bool "DCN 2.1 family" -depends on DRM_AMD_DC && X86 -depends on DRM_AMD_DC_DCN2_0 -help -Choose this option if you want to have -Renoir support for display engine + bool "DCN 2.1 family" + depends on DRM_AMD_DC && X86 + depends on DRM_AMD_DC_DCN2_0 + help + Choose this option if you want to have + Renoir support for display engine config DRM_AMD_DC_DSC_SUPPORT bool "DSC support" @@ -41,8 +41,8 @@ config DRM_AMD_DC_DSC_SUPPORT depends on DRM_AMD_DC_DCN1_0 depends on DRM_AMD_DC_DCN2_0 help - Choose this option if you want to have - Dynamic Stream Compression support + Choose this option if you want to have + Dynamic Stream Compression support config DEBUG_KERNEL_DC bool "Enable kgdb break in DC" diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 1cc9f502c1f2..a5aa7ec16000 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -60,10 +60,10 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW select DRM_KMS_HELPER select DRM_PANEL ---help--- - This is a driver for the display bridges of - GE B850v3 that convert dual channel LVDS - to DP++. This is used with the i.MX6 imx-ldb - driver. You are likely to say N here. + This is a driver for the display bridges of + GE B850v3 that convert dual channel LVDS + to DP++. This is used with the i.MX6 imx-ldb + driver. You are likely to say N here. config DRM_NXP_PTN3460 tristate "NXP PTN3460 DP/LVDS bridge" diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 0d21402945ab..3c6d57df262d 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -76,7 +76,7 @@ config DRM_I915_CAPTURE_ERROR This option enables capturing the GPU state when a hang is detected. This information is vital for triaging hangs and assists in debugging. Please report any hang to -https://bugs.freedesktop.org/enter_bug.cgi?product=DRI + https://bugs.freedesktop.org/enter_bug.cgi?product=DRI for triaging. If in doubt, say "Y". @@ -105,11 +105,11 @@ config DRM_I915_USERPTR If in doubt, say "Y". config DRM_I915_GVT -bool "Enable Intel GVT-g graphics virtualization host
Re: [PATCH 5/5] drm/msm/adreno: Add support for Adreno 510 GPU
On Sat, Sep 21, 2019 at 12:04:39PM +0200, khol...@gmail.com wrote:
> From: "Angelo G. Del Regno"
>
> The Adreno 510 GPU is a stripped version of the Adreno 5xx,
> found in low-end SoCs like 8x56 and 8x76, which has 256K of
> GMEM, with no GPMU nor ZAP.
> Also, since the Adreno 5xx part of this driver seems to be
> developed with high-end Adreno GPUs in mind, and since this
> is a lower end one, add a comment making clear which GPUs
> which support is not implemented yet is not using the GPMU
> related hw init code, so that future developers will not go
> crazy with that.
>
> By the way, the lower end Adreno GPUs with no GPMU are:
> A505/A506/A510 (no ZAP firmware)
> A508/A509/A512 (with ZAP firmware)
Thanks, just a few comments. It is good to see some of these lower tier
parts start to make their way upstream.
> Signed-off-by: Angelo G. Del Regno
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 87 +++---
> drivers/gpu/drm/msm/adreno/a5xx_power.c| 7 ++
> drivers/gpu/drm/msm/adreno/adreno_device.c | 15
> drivers/gpu/drm/msm/adreno/adreno_gpu.h| 5 ++
> 4 files changed, 102 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index e9c55d1d6c04..c3814a65ba2d 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -353,6 +353,9 @@ static int a5xx_me_init(struct msm_gpu *gpu)
>* 2D mode 3 draw
>*/
> OUT_RING(ring, 0x000B);
> + } else if (adreno_is_a510(adreno_gpu)) {
> + /* Workaround for token and syncs */
> + OUT_RING(ring, 0x0001);
> } else {
> /* No workarounds enabled */
> OUT_RING(ring, 0x);
> @@ -502,6 +505,8 @@ static int a5xx_zap_shader_init(struct msm_gpu *gpu)
> static int a5xx_hw_init(struct msm_gpu *gpu)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> + u32 meq_thresh, merciu_sz, roq_thresh_1, roq_thresh_2, eco_cntl;
> + u32 cur_eco_cnt;
> int ret;
>
> gpu_write(gpu, REG_A5XX_VBIF_ROUND_ROBIN_QOS_ARB, 0x0003);
> @@ -568,15 +573,31 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
> 0x0010 + adreno_gpu->gmem - 1);
> gpu_write(gpu, REG_A5XX_UCHE_GMEM_RANGE_MAX_HI, 0x);
>
> - gpu_write(gpu, REG_A5XX_CP_MEQ_THRESHOLDS, 0x40);
> - if (adreno_is_a530(adreno_gpu))
> - gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x40);
> + /* Values for the majority of the models */
> + meq_thresh = 0x40;
> + merciu_sz = 0x40;
> + roq_thresh_2 = 0x8060;
> + roq_thresh_1 = 0x40201B16;
> + eco_cntl = (0x400 << 11 | 0x300 << 22);
> +
> + /* model specific overrides */
> + if (adreno_is_a510(adreno_gpu)) {
> + meq_thresh = 0x20;
> + merciu_sz = 0x20;
> + roq_thresh_2 = 0x4030;
> + roq_thresh_1 = 0x20100D0A;
> + eco_cntl = (0x200 << 11 | 0x200 << 22);
> + }
> +
> if (adreno_is_a540(adreno_gpu))
> - gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, 0x400);
> - gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_2, 0x8060);
> - gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_1, 0x40201B16);
> + merciu_sz = 0x400;
> +
> + gpu_write(gpu, REG_A5XX_CP_MEQ_THRESHOLDS, meq_thresh);
> + gpu_write(gpu, REG_A5XX_CP_MERCIU_SIZE, merciu_sz);
> + gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_2, roq_thresh_2);
> + gpu_write(gpu, REG_A5XX_CP_ROQ_THRESHOLDS_1, roq_thresh_1);
>
> - gpu_write(gpu, REG_A5XX_PC_DBG_ECO_CNTL, (0x400 << 11 | 0x300 << 22));
> + gpu_write(gpu, REG_A5XX_PC_DBG_ECO_CNTL, eco_cntl);
Personally, I am just fine with doing the direct register writes inside of
target specific if/else blocks instead of declaring variables and trying to
support "common" code.
>
> if (adreno_gpu->info->quirks & ADRENO_QUIRK_TWO_PASS_USE_WFI)
> gpu_rmw(gpu, REG_A5XX_PC_DBG_ECO_CNTL, 0, (1 << 8));
> @@ -589,6 +610,22 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
> /* Enable ME/PFP split notification */
> gpu_write(gpu, REG_A5XX_RBBM_AHB_CNTL1, 0xA6FF);
>
> + /*
> + * In A5x, CCU can send context_done event of a particular context to
> + * UCHE which ultimately reaches CP even when there is valid
> + * transaction of that context inside CCU. This can let CP to program
> + * config registers, which will make the "valid transaction" inside
> + * CCU to be interpreted differently. This can cause gpu fault. This
> + * bug is fixed in latest A510 revision. To enable this bug fix -
> + * bit[11] of RB_DBG_ECO_CNTL need to be set to 0, default is 1
> + * (disable). For older A510 version this bit is unused.
> + */
> + if (adreno_is_a510(adreno_gpu)) {
> + cur_eco_cnt = gpu_read(gpu, REG_A5XX_RB_DBG_ECO_CNTL);
> +
Re: [RESEND PATCH] drm/panfrost: Reduce the amount of logs on deferred probe
On Thu, Sep 12, 2019 at 10:36:25AM +0100, Steven Price wrote:
> On 09/09/2019 16:51, Krzysztof Kozlowski wrote:
> > There is no point to print deferred probe (and its failures to get
> > resources) as an error.
> >
> > In case of multiple probe tries this would pollute the dmesg.
> >
> > Signed-off-by: Krzysztof Kozlowski
>
> Looks like a good idea, however from what I can tell you haven't
> completely silenced the 'error' as the return from
> panfrost_regulator_init() will be -EPROBE_DEFER causing another
> dev_err() output:
>
> err = panfrost_regulator_init(pfdev);
> if (err) {
> dev_err(pfdev->dev, "regulator init failed %d\n", err);
> goto err_out0;
> }
>
> Can you fix that up as well? Or indeed drop it altogether since
> panfrost_regulator_init() already outputs an appropriate message.
I'll drop this error message then. Thanks for feedback!
Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/36] drm/msm: use bpp instead of cpp for drm_format_info
On Mon, Sep 23, 2019 at 5:44 AM Sandy Huang wrote:
>
> cpp[BytePerPlane] can't describe the 10bit data format correctly,
> So we use bpp[BitPerPlane] to instead cpp.
>
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 4 ++--
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 2 +-
> drivers/gpu/drm/msm/msm_fb.c | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index b3417d5..c57731c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1148,8 +1148,8 @@ static int _dpu_debugfs_status_show(struct seq_file *s,
> void *data)
> fb->base.id, (char *) >format->format,
> fb->width, fb->height);
> for (i = 0; i < ARRAY_SIZE(fb->format->cpp); ++i)
> - seq_printf(s, "cpp[%d]:%u ",
> - i, fb->format->cpp[i]);
> + seq_printf(s, "bpp[%d]:%u ",
> + i, fb->format->bpp[i]);
> seq_puts(s, "\n\t");
>
> seq_printf(s, "modifier:%8llu ", fb->modifier);
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> index ff14555..61ab4dc 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> @@ -790,7 +790,7 @@ static void mdp5_crtc_restore_cursor(struct drm_crtc
> *crtc)
> width = mdp5_crtc->cursor.width;
> height = mdp5_crtc->cursor.height;
>
> - stride = width * info->cpp[0];
> + stride = width * info->bpp[0] / 8;
>
> get_roi(crtc, _w, _h);
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> index 776337f..992477d 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> @@ -147,7 +147,7 @@ uint32_t mdp5_smp_calculate(struct mdp5_smp *smp,
> for (i = 0; i < nplanes; i++) {
> int n, fetch_stride, cpp;
>
> - cpp = info->cpp[i];
> + cpp = info->bpp[i] / 8;
Unless I missed something in your first patch, I don't think this
series is bisectable, ie. replacing cpp w/ bpp would cause everything
else not to compile. Looks like there was an alternative proposal on
the first patch, but if we do end up going this route, I think you
should add bpp in the first patch, and remove cpp in the last patch.
(And also probably sprinkle around WARN_ON(info->bpp[n] % 8) in places
were it is expected to be a multiple of 8)
BR,
-R
> fetch_stride = width * cpp / (i ? hsub : 1);
>
> n = DIV_ROUND_UP(fetch_stride * nlines, smp->blk_size);
> diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
> index 5bcd5e5..4545fa1 100644
> --- a/drivers/gpu/drm/msm/msm_fb.c
> +++ b/drivers/gpu/drm/msm/msm_fb.c
> @@ -172,7 +172,7 @@ static struct drm_framebuffer
> *msm_framebuffer_init(struct drm_device *dev,
> unsigned int min_size;
>
> min_size = (height - 1) * mode_cmd->pitches[i]
> -+ width * info->cpp[i]
> ++ width * info->bpp[i] / 8
> + mode_cmd->offsets[i];
>
> if (bos[i]->size < min_size) {
> --
> 2.7.4
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v1, 2/2] drm: Clear the fence pointer when writeback job signaled
On Wed, Jul 31, 2019 at 11:04:45AM +, Lowry Li (Arm Technology China) wrote:
> During it signals the completion of a writeback job, after releasing
> the out_fence, we'd clear the pointer.
>
> Check if fence left over in drm_writeback_cleanup_job(), release it.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> Reviewed-by: Brian Starkey
Looks good to me.
Reviewed-by: James Qian Wang (Arm Technology China)
will push it to drm-misc-fixes
James
> ---
> drivers/gpu/drm/drm_writeback.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index ff138b6..43d9e3b 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job
> *job)
> if (job->fb)
> drm_framebuffer_put(job->fb);
>
> + if (job->out_fence)
> + dma_fence_put(job->out_fence);
> +
> kfree(job);
> }
> EXPORT_SYMBOL(drm_writeback_cleanup_job);
> @@ -366,25 +369,29 @@ static void cleanup_work(struct work_struct *work)
> {
> unsigned long flags;
> struct drm_writeback_job *job;
> + struct dma_fence *out_fence;
>
> spin_lock_irqsave(_connector->job_lock, flags);
> job = list_first_entry_or_null(_connector->job_queue,
> struct drm_writeback_job,
> list_entry);
> - if (job) {
> + if (job)
> list_del(>list_entry);
> - if (job->out_fence) {
> - if (status)
> - dma_fence_set_error(job->out_fence, status);
> - dma_fence_signal(job->out_fence);
> - dma_fence_put(job->out_fence);
> - }
> - }
> +
> spin_unlock_irqrestore(_connector->job_lock, flags);
>
> if (WARN_ON(!job))
> return;
>
> + out_fence = job->out_fence;
> + if (out_fence) {
> + if (status)
> + dma_fence_set_error(out_fence, status);
> + dma_fence_signal(out_fence);
> + dma_fence_put(out_fence);
> + job->out_fence = NULL;
> + }
> +
> INIT_WORK(>cleanup_work, cleanup_work);
> queue_work(system_long_wq, >cleanup_work);
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v1,1/2] drm: Free the writeback_job when it with an empty fb
On Wed, Jul 31, 2019 at 11:04:38AM +, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Adds the check if the writeback_job with an empty fb, then it should
> be freed in atomic_check phase.
>
> With this change, the driver users will not check empty fb case any more.
> So refined accordingly.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> Reviewed-by: Liviu Dudau
Looks good to me.
Reviewed-by: James Qian Wang (Arm Technology China)
And will push it to drm-misc-fixes
James
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 3 +--
> drivers/gpu/drm/arm/malidp_mw.c | 4 ++--
> drivers/gpu/drm/drm_atomic.c | 13 +
> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 4 ++--
> drivers/gpu/drm/vc4/vc4_txp.c| 5 ++---
> 5 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> index 617e1f7..d6103dd 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> @@ -43,9 +43,8 @@
> struct komeda_data_flow_cfg dflow;
> int err;
>
> - if (!writeback_job || !writeback_job->fb) {
> + if (!writeback_job)
> return 0;
> - }
>
> if (!crtc_st->active) {
> DRM_DEBUG_ATOMIC("Cannot write the composition result out on a
> inactive CRTC.\n");
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 2e81252..a59227b 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -130,7 +130,7 @@ static void malidp_mw_connector_destroy(struct
> drm_connector *connector)
> struct drm_framebuffer *fb;
> int i, n_planes;
>
> - if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> + if (!conn_state->writeback_job)
> return 0;
>
> fb = conn_state->writeback_job->fb;
> @@ -247,7 +247,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
>
> mw_state = to_mw_state(conn_state);
>
> - if (conn_state->writeback_job && conn_state->writeback_job->fb) {
> + if (conn_state->writeback_job) {
> struct drm_framebuffer *fb = conn_state->writeback_job->fb;
>
> DRM_DEV_DEBUG_DRIVER(drm->dev,
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 419381a..14aeaf7 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -430,10 +430,15 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> - if (writeback_job->out_fence && !writeback_job->fb) {
> - DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence
> without framebuffer\n",
> - connector->base.id, connector->name);
> - return -EINVAL;
> + if (!writeback_job->fb) {
> + if (writeback_job->out_fence) {
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting
> out-fence without framebuffer\n",
> + connector->base.id, connector->name);
> + return -EINVAL;
> + }
> +
> + drm_writeback_cleanup_job(writeback_job);
> + state->writeback_job = NULL;
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> index ae07290..04efa78d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> @@ -147,7 +147,7 @@ static int rcar_du_wb_enc_atomic_check(struct drm_encoder
> *encoder,
> struct drm_device *dev = encoder->dev;
> struct drm_framebuffer *fb;
>
> - if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> + if (!conn_state->writeback_job)
> return 0;
>
> fb = conn_state->writeback_job->fb;
> @@ -221,7 +221,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
> unsigned int i;
>
> state = rcrtc->writeback.base.state;
> - if (!state || !state->writeback_job || !state->writeback_job->fb)
> + if (!state || !state->writeback_job)
> return;
>
> fb = state->writeback_job->fb;
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index 96f91c1..e92fa12 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -229,7 +229,7 @@ static int vc4_txp_connector_atomic_check(struct
> drm_connector *conn,
> int i;
>
> conn_state = drm_atomic_get_new_connector_state(state, conn);
> - if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> + if (!conn_state->writeback_job)
>
[PATCH v1 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/Makefile |2 +-
drivers/gpu/drm/bridge/analogix/Kconfig |6 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 2110 +
drivers/gpu/drm/bridge/analogix/anx7625.h | 405 ++
5 files changed, 2523 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..bcd388a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e930ff9..b2f127e 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -2,3 +2,9 @@
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config ANALOGIX_ANX7625
+ tristate "Analogix MIPI to DP interface support"
+ help
+ ANX7625 is an ultra-low power 4K mobile HD transmitter designed
+ for portable devices. It converts MIPI/DPI to DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index fdbf3fd..8a52867 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ANALOGIX_ANX7625) += anx7625.o
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..2a94b85
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,2110 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "anx7625.h"
+
+/*
+ * there is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+ u8 offset;
+ struct device *dev = >dev;
+ struct i2c_client *last_client = ctx->last_client;
+ int ret = 0;
+
+ if (client != last_client) {
+ ctx->last_client = client;
+
+ if (client == ctx->i2c.tcpc_client)
+ offset = RSVD_00_ADDR;
+ else if (client == ctx->i2c.tx_p0_client)
+ offset = RSVD_D1_ADDR;
+ else if (client == ctx->i2c.tx_p1_client)
+ offset = RSVD_60_ADDR;
+ else if (client == ctx->i2c.rx_p0_client)
+ offset = RSVD_39_ADDR;
+ else if (client == ctx->i2c.rx_p1_client)
+ offset = RSVD_7F_ADDR;
+ else
+ offset = RSVD_00_ADDR;
+
+ ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev,
+ "failed to access i2c id=%x\n:%x",
+ client->addr, offset);
+ }
+
+ return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+ struct i2c_client *client, u8 reg_addr)
+{
+ int ret;
+ struct device *dev = >dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_byte_data(client, reg_addr);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c failed id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data
[PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI to DisplayPort 1.3 4K.
You can add support to your board with binding.
Example:
anx_bridge: anx7625@58 {
compatible = "analogix,anx7625";
reg = <0x58>;
low-power-mode = <1>;
enable-gpios = < 45 GPIO_ACTIVE_LOW>;
reset-gpios = < 73 GPIO_ACTIVE_LOW>;
status = "okay";
port@0 {
reg = <0>;
anx7625_1_in: endpoint {
remote-endpoint = <_dsi_bridge_1>;
};
};
};
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/anx7625.yaml | 84 ++
1 file changed, 84 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/anx7625.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
new file mode 100644
index 000..2991039
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ compatible:
+items:
+ - const: analogix,anx7625
+
+ reg:
+maxItems: 1
+
+ low-power-mode:
+description: Low power mode support feature
+maxItems: 1
+
+ hpd-gpios:
+description: used for HPD interrupt
+maxItems: 1
+
+ enable-gpios:
+description: used for power on chip control
+maxItems: 1
+
+ reset-gpios:
+description: used for reset chip control
+maxItems: 1
+
+ port@0:
+type: object
+description:
+ A port node pointing to MIPI DSI host port node.
+
+ port@1:
+type: object
+description:
+ A port node pointing to MIPI DPI host port node.
+
+ port@2:
+type: object
+description:
+ A port node pointing to external connector port node.
+
+ port@3:
+type: object
+description:
+ A port node pointing to internal panel port node.
+
+ port@4:
+type: object
+description:
+ A port node pointing to normal eDP port node.
+
+required:
+ - compatible
+ - reg
+ - port@0 | port@1
+
+example:
+ - |
+anx_bridge: anx7625@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+low-power-mode = <0>;
+status = "okay";
+port@0 {
+ reg = <0>;
+ anx7625_1_in: endpoint {
+remote-endpoint = <_dsi_bridge_1>;
+ };
+};
+};
--
2.7.4
Re: [PATCH 3/3] drm/i915: switch to drm_fb_helper_remove_conflicting_pci_framebuffers
On Fri, 23 Aug 2019, Gerd Hoffmann wrote: > On Fri, Aug 23, 2019 at 10:30:35AM +0200, Daniel Vetter wrote: >> On Fri, Aug 23, 2019 at 10:14 AM Gerd Hoffmann wrote: >> > >> > Whole series or just the i915 patch? >> >> Ok I just checked and this all landed in 5.1 already, I thought it was >> more recent. I think that's good enough, push it all without more >> waiting. > > Pushed to drm-misc-next. After-the-fact nitpick: i915 maintainers were Cc'd on the original patch, but not on the subsequent discussion on merging, or where to merge. intel-gfx@ mailing list wasn't Cc'd at all, which means this didn't get any pre-merge CI coverage we expect on every patch. I found about this having been merged through a merge conflict. If you don't see the ack from the maintainers, please ask. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 07/19] kunit: test: add initial tests
On Sun, Sep 22, 2019 at 9:28 AM Randy Dunlap wrote: > > On 9/20/19 5:18 PM, Brendan Higgins wrote: > > Add a test for string stream along with a simpler example. > > > > Signed-off-by: Brendan Higgins > > Reviewed-by: Greg Kroah-Hartman > > Reviewed-by: Logan Gunthorpe > > Reviewed-by: Stephen Boyd > > --- > > lib/kunit/Kconfig | 25 ++ > > lib/kunit/Makefile | 4 ++ > > lib/kunit/example-test.c | 88 ++ > > lib/kunit/string-stream-test.c | 52 > > 4 files changed, 169 insertions(+) > > create mode 100644 lib/kunit/example-test.c > > create mode 100644 lib/kunit/string-stream-test.c > > > > diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig > > index 666b9cb67a74..3868c226cf31 100644 > > --- a/lib/kunit/Kconfig > > +++ b/lib/kunit/Kconfig > > @@ -11,3 +11,28 @@ menuconfig KUNIT > > special hardware when using UML. Can also be used on most other > > architectures. For more information, please see > > Documentation/dev-tools/kunit/. > > + > > +if KUNIT > > The 'if' above provides the dependency clause, so the 2 'depends on KUNIT' > below are not needed. They are redundant. Thanks for catching that. I fixed it in the new revision I just sent out. > > + > > +config KUNIT_TEST > > + bool "KUnit test for KUnit" > > + depends on KUNIT > > + help > > + Enables the unit tests for the KUnit test framework. These tests > > test > > + the KUnit test framework itself; the tests are both written using > > + KUnit and test KUnit. This option should only be enabled for testing > > + purposes by developers interested in testing that KUnit works as > > + expected. > > + > > +config KUNIT_EXAMPLE_TEST > > + bool "Example test for KUnit" > > + depends on KUNIT > > + help > > + Enables an example unit test that illustrates some of the basic > > + features of KUnit. This test only exists to help new users > > understand > > + what KUnit is and how it is used. Please refer to the example test > > + itself, lib/kunit/example-test.c, for more information. This option > > + is intended for curious hackers who would like to understand how to > > + use KUnit for kernel development. > > + > > +endif # KUNIT Cheers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/komeda: Workaround for broken FLIP_COMPLETE timestamps
When initially turning a crtc on, drm_reset_vblank_timestamp will set the vblank timestamp to 0 for any driver that doesn't provide a ->get_vblank_timestamp() hook. Unfortunately, the FLIP_COMPLETE event depends on that timestamp, and the only way to regenerate a valid one is to have vblank interrupts enabled and have a valid in-ISR call to drm_crtc_handle_vblank. Additionally, if the user doesn't request vblanks but _does_ request FLIP_COMPLETE events, we still don't have a good timestamp: it'll be the same stamp as the last vblank one. Work around the issue by always enabling vblanks when the CRTC is on. Reducing the amount of time that PL0 has to be unmasked would be nice to fix at a later time. Changes since v1 [https://patchwork.freedesktop.org/patch/331727/]: - moved drm_crtc_vblank_put call to the ->atomic_disable() hook Cc: Daniel Vetter Cc: Liviu Dudau Signed-off-by: Mihail Atanassov --- drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c index 34bc73ca18bc..d06679afb228 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c @@ -489,6 +489,7 @@ komeda_crtc_atomic_enable(struct drm_crtc *crtc, pm_runtime_get_sync(crtc->dev->dev); komeda_crtc_prepare(to_kcrtc(crtc)); drm_crtc_vblank_on(crtc); + WARN_ON(drm_crtc_vblank_get(crtc)); komeda_crtc_do_flush(crtc, old); } @@ -581,6 +582,7 @@ komeda_crtc_atomic_disable(struct drm_crtc *crtc, komeda_crtc_flush_and_wait_for_flip_done(kcrtc, disable_done); } + drm_crtc_vblank_put(crtc); drm_crtc_vblank_off(crtc); komeda_crtc_unprepare(kcrtc); pm_runtime_put(crtc->dev->dev); -- 2.23.0
[PATCH v18 01/19] kunit: test: add KUnit test runner core
Add core facilities for defining unit tests; this provides a common way
to define test cases, functions that execute code which is under test
and determine whether the code under test behaves as expected; this also
provides a way to group together related test cases in test suites (here
we call them test_modules).
Just define test cases and how to execute them for now; setting
expectations on code will be defined later.
Signed-off-by: Brendan Higgins
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Logan Gunthorpe
Reviewed-by: Luis Chamberlain
Reviewed-by: Stephen Boyd
---
include/kunit/test.h | 188 ++
lib/kunit/Kconfig| 13 +++
lib/kunit/Makefile | 1 +
lib/kunit/test.c | 191 +++
4 files changed, 393 insertions(+)
create mode 100644 include/kunit/test.h
create mode 100644 lib/kunit/Kconfig
create mode 100644 lib/kunit/Makefile
create mode 100644 lib/kunit/test.c
diff --git a/include/kunit/test.h b/include/kunit/test.h
new file mode 100644
index ..e30d1bf2fb68
--- /dev/null
+++ b/include/kunit/test.h
@@ -0,0 +1,188 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Base unit test (KUnit) API.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#ifndef _KUNIT_TEST_H
+#define _KUNIT_TEST_H
+
+#include
+
+struct kunit;
+
+/**
+ * struct kunit_case - represents an individual test case.
+ *
+ * @run_case: the function representing the actual test case.
+ * @name: the name of the test case.
+ *
+ * A test case is a function with the signature,
+ * ``void (*)(struct kunit *)`` that makes expectations (see
+ * KUNIT_EXPECT_TRUE()) about code under test. Each test case is associated
+ * with a kunit_suite and will be run after the suite's init
+ * function and followed by the suite's exit function.
+ *
+ * A test case should be static and should only be created with the
+ * KUNIT_CASE() macro; additionally, every array of test cases should be
+ * terminated with an empty test case.
+ *
+ * Example:
+ *
+ * .. code-block:: c
+ *
+ * void add_test_basic(struct kunit *test)
+ * {
+ * KUNIT_EXPECT_EQ(test, 1, add(1, 0));
+ * KUNIT_EXPECT_EQ(test, 2, add(1, 1));
+ * KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
+ * KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
+ * KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
+ * }
+ *
+ * static struct kunit_case example_test_cases[] = {
+ * KUNIT_CASE(add_test_basic),
+ * {}
+ * };
+ *
+ */
+struct kunit_case {
+ void (*run_case)(struct kunit *test);
+ const char *name;
+
+ /* private: internal use only. */
+ bool success;
+};
+
+/**
+ * KUNIT_CASE - A helper for creating a kunit_case
+ *
+ * @test_name: a reference to a test case function.
+ *
+ * Takes a symbol for a function representing a test case and creates a
+ * kunit_case object from it. See the documentation for
+ * kunit_case for an example on how to use it.
+ */
+#define KUNIT_CASE(test_name) { .run_case = test_name, .name = #test_name }
+
+/**
+ * struct kunit_suite - describes a related collection of kunit_case
+ *
+ * @name: the name of the test. Purely informational.
+ * @init: called before every test case.
+ * @exit: called after every test case.
+ * @test_cases:a null terminated array of test cases.
+ *
+ * A kunit_suite is a collection of related kunit_case s, such that
+ * @init is called before every test case and @exit is called after every
+ * test case, similar to the notion of a *test fixture* or a *test class*
+ * in other unit testing frameworks like JUnit or Googletest.
+ *
+ * Every kunit_case must be associated with a kunit_suite for KUnit
+ * to run it.
+ */
+struct kunit_suite {
+ const char name[256];
+ int (*init)(struct kunit *test);
+ void (*exit)(struct kunit *test);
+ struct kunit_case *test_cases;
+};
+
+/**
+ * struct kunit - represents a running instance of a test.
+ *
+ * @priv: for user to store arbitrary data. Commonly used to pass data
+ * created in the init function (see kunit_suite).
+ *
+ * Used to store information about the current context under which the test
+ * is running. Most of this data is private and should only be accessed
+ * indirectly via public functions; the one exception is @priv which can be
+ * used by the test writer to store arbitrary data.
+ */
+struct kunit {
+ void *priv;
+
+ /* private: internal use only. */
+ const char *name; /* Read only after initialization! */
+ /*
+* success starts as true, and may only be set to false during a
+* test case; thus, it is safe to update this across multiple
+* threads using WRITE_ONCE; however, as a consequence, it may only
+* be read after the test case finishes once all threads associated
+* with the test case have terminated.
+
[PATCH v18 04/19] kunit: test: add assertion printing library
Add `struct kunit_assert` and friends which provide a structured way to
capture data from an expectation or an assertion (introduced later in
the series) so that it may be printed out in the event of a failure.
Signed-off-by: Brendan Higgins
Reviewed-by: Stephen Boyd
---
include/kunit/assert.h | 356 +
lib/kunit/Makefile | 3 +-
lib/kunit/assert.c | 141
3 files changed, 499 insertions(+), 1 deletion(-)
create mode 100644 include/kunit/assert.h
create mode 100644 lib/kunit/assert.c
diff --git a/include/kunit/assert.h b/include/kunit/assert.h
new file mode 100644
index ..db6a0fca09b4
--- /dev/null
+++ b/include/kunit/assert.h
@@ -0,0 +1,356 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Assertion and expectation serialization API.
+ *
+ * Copyright (C) 2019, Google LLC.
+ * Author: Brendan Higgins
+ */
+
+#ifndef _KUNIT_ASSERT_H
+#define _KUNIT_ASSERT_H
+
+#include
+#include
+
+struct kunit;
+
+/**
+ * enum kunit_assert_type - Type of expectation/assertion.
+ * @KUNIT_ASSERTION: Used to denote that a kunit_assert represents an
assertion.
+ * @KUNIT_EXPECTATION: Denotes that a kunit_assert represents an expectation.
+ *
+ * Used in conjunction with a kunit_assert to denote whether it
+ * represents an expectation or an assertion.
+ */
+enum kunit_assert_type {
+ KUNIT_ASSERTION,
+ KUNIT_EXPECTATION,
+};
+
+/**
+ * struct kunit_assert - Data for printing a failed assertion or expectation.
+ * @test: the test case this expectation/assertion is associated with.
+ * @type: the type (either an expectation or an assertion) of this
kunit_assert.
+ * @line: the source code line number that the expectation/assertion is at.
+ * @file: the file path of the source file that the expectation/assertion is
in.
+ * @message: an optional message to provide additional context.
+ * @format: a function which formats the data in this kunit_assert to a string.
+ *
+ * Represents a failed expectation/assertion. Contains all the data necessary
to
+ * format a string to a user reporting the failure.
+ */
+struct kunit_assert {
+ struct kunit *test;
+ enum kunit_assert_type type;
+ int line;
+ const char *file;
+ struct va_format message;
+ void (*format)(const struct kunit_assert *assert,
+ struct string_stream *stream);
+};
+
+/**
+ * KUNIT_INIT_VA_FMT_NULL - Default initializer for struct va_format.
+ *
+ * Used inside a struct initialization block to initialize struct va_format to
+ * default values where fmt and va are null.
+ */
+#define KUNIT_INIT_VA_FMT_NULL { .fmt = NULL, .va = NULL }
+
+/**
+ * KUNIT_INIT_ASSERT_STRUCT() - Initializer for a kunit_assert.
+ * @kunit: The test case that this expectation/assertion is associated with.
+ * @assert_type: The type (assertion or expectation) of this kunit_assert.
+ * @fmt: The formatting function which builds a string out of this
kunit_assert.
+ *
+ * The base initializer for a kunit_assert.
+ */
+#define KUNIT_INIT_ASSERT_STRUCT(kunit, assert_type, fmt) { \
+ .test = kunit, \
+ .type = assert_type, \
+ .file = __FILE__, \
+ .line = __LINE__, \
+ .message = KUNIT_INIT_VA_FMT_NULL, \
+ .format = fmt \
+}
+
+void kunit_base_assert_format(const struct kunit_assert *assert,
+ struct string_stream *stream);
+
+void kunit_assert_print_msg(const struct kunit_assert *assert,
+ struct string_stream *stream);
+
+/**
+ * struct kunit_fail_assert - Represents a plain fail expectation/assertion.
+ * @assert: The parent of this type.
+ *
+ * Represents a simple KUNIT_FAIL/KUNIT_ASSERT_FAILURE that always fails.
+ */
+struct kunit_fail_assert {
+ struct kunit_assert assert;
+};
+
+void kunit_fail_assert_format(const struct kunit_assert *assert,
+ struct string_stream *stream);
+
+/**
+ * KUNIT_INIT_FAIL_ASSERT_STRUCT() - Initializer for kunit_fail_assert.
+ * @test: The test case that this expectation/assertion is associated with.
+ * @type: The type (assertion or expectation) of this kunit_assert.
+ *
+ * Initializes a kunit_fail_assert. Intended to be used in
+ * KUNIT_EXPECT_* and KUNIT_ASSERT_* macros.
+ */
+#define KUNIT_INIT_FAIL_ASSERT_STRUCT(test, type) { \
+ .assert = KUNIT_INIT_ASSERT_STRUCT(test, \
+ type, \
+ kunit_fail_assert_format) \
+}
+
+/**
+ * struct kunit_unary_assert - Represents a
[PATCH v18 05/19] kunit: test: add the concept of expectations
Add support for expectations, which allow properties to be specified and
then verified in tests.
Signed-off-by: Brendan Higgins
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Logan Gunthorpe
Reviewed-by: Stephen Boyd
---
include/kunit/test.h | 836 +++
lib/kunit/test.c | 62
2 files changed, 898 insertions(+)
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 6781c756f11b..30a62de16bc9 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -9,6 +9,8 @@
#ifndef _KUNIT_TEST_H
#define _KUNIT_TEST_H
+#include
+#include
#include
#include
@@ -372,4 +374,838 @@ void __printf(3, 4) kunit_printk(const char *level,
#define kunit_err(test, fmt, ...) \
kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__)
+/**
+ * KUNIT_SUCCEED() - A no-op expectation. Only exists for code clarity.
+ * @test: The test context object.
+ *
+ * The opposite of KUNIT_FAIL(), it is an expectation that cannot fail. In
other
+ * words, it does nothing and only exists for code clarity. See
+ * KUNIT_EXPECT_TRUE() for more information.
+ */
+#define KUNIT_SUCCEED(test) do {} while (0)
+
+void kunit_do_assertion(struct kunit *test,
+ struct kunit_assert *assert,
+ bool pass,
+ const char *fmt, ...);
+
+#define KUNIT_ASSERTION(test, pass, assert_class, INITIALIZER, fmt, ...) do {
\
+ struct assert_class __assertion = INITIALIZER; \
+ kunit_do_assertion(test, \
+ &__assertion.assert,\
+ pass, \
+ fmt,\
+ ##__VA_ARGS__); \
+} while (0)
+
+
+#define KUNIT_FAIL_ASSERTION(test, assert_type, fmt, ...) \
+ KUNIT_ASSERTION(test, \
+ false, \
+ kunit_fail_assert, \
+ KUNIT_INIT_FAIL_ASSERT_STRUCT(test, assert_type), \
+ fmt, \
+ ##__VA_ARGS__)
+
+/**
+ * KUNIT_FAIL() - Always causes a test to fail when evaluated.
+ * @test: The test context object.
+ * @fmt: an informational message to be printed when the assertion is made.
+ * @...: string format arguments.
+ *
+ * The opposite of KUNIT_SUCCEED(), it is an expectation that always fails. In
+ * other words, it always results in a failed expectation, and consequently
+ * always causes the test case to fail when evaluated. See KUNIT_EXPECT_TRUE()
+ * for more information.
+ */
+#define KUNIT_FAIL(test, fmt, ...)\
+ KUNIT_FAIL_ASSERTION(test, \
+KUNIT_EXPECTATION,\
+fmt, \
+##__VA_ARGS__)
+
+#define KUNIT_UNARY_ASSERTION(test, \
+ assert_type, \
+ condition, \
+ expected_true, \
+ fmt, \
+ ...) \
+ KUNIT_ASSERTION(test, \
+ !!(condition) == !!expected_true, \
+ kunit_unary_assert,\
+ KUNIT_INIT_UNARY_ASSERT_STRUCT(test, \
+ assert_type,\
+ #condition, \
+ expected_true), \
+ fmt, \
+ ##__VA_ARGS__)
+
+#define KUNIT_TRUE_MSG_ASSERTION(test, assert_type, condition, fmt, ...)
\
+ KUNIT_UNARY_ASSERTION(test,\
+ assert_type, \
+ condition, \
+ true,\
+ fmt, \
+
[PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework
## TL;DR This revision addresses comments from Linus[1] and Randy[2], by moving top level `kunit/` directory to `lib/kunit/` and likewise moves top level Kconfig entry under lib/Kconfig.debug, so the KUnit submenu now shows up under the "Kernel Hacking" menu. As a consequence of this, I rewrote patch 06/18 (kbuild: enable building KUnit) - now 06/19 (lib: enable building KUnit in lib/), and now needs to be re-acked/reviewed. ## Background This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel. Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM (however, KUnit still allows you to run tests on test machines or in VMs if you want[3]) and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in about a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded). KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more. ### What's so special about unit testing? A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[4]. Additionally for convenience, I have applied these patches to a branch[5]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/initial/v5.3/v18 branch. ## History since v15 ### v18 - Addrssed comments on 07/19 (kunit: test: add initial tests) from Randy Dunlap by removing redundant dependencies from Kconfig entries. ### v17 - Addressed comments on 06/19 (lib: enable building KUnit in lib/) from Stephen Boyd by moving KUnit submenu ahead of Runtime Testing submenu. ### v16 - Addressed comments from Linus Torvalds by moving all kunit/ paths to lib/kunit/. - Addressed comments by Randy Dunlap by moving KUnit Kconfig under lib/Kconfig.debug so the KUnit submenu shows up under the "Kernel Hacking" menu. [1] https://www.lkml.org/lkml/2019/9/20/696 [2] https://www.lkml.org/lkml/2019/9/20/738 [3] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kunit-on-non-uml-architectures [4] https://google.github.io/kunit-docs/third_party/kernel/docs/ [5] https://kunit.googlesource.com/linux/+/kunit/initial/v5.3/v18 --- Avinash Kondareddy (1): kunit: test: add tests for KUnit managed resources Brendan Higgins (16): kunit: test: add KUnit test runner core kunit: test: add test resource management API kunit: test: add string_stream a std::stream like string builder kunit: test: add assertion printing library kunit: test: add the concept of expectations lib: enable building KUnit in lib/ kunit: test: add initial tests objtool: add kunit_try_catch_throw to the noreturn list kunit: test: add support for test abort kunit: test: add tests for kunit test abort kunit: test: add the concept of assertions kunit: defconfig: add defconfigs for building KUnit tests Documentation: kunit: add documentation for KUnit MAINTAINERS: add entry for KUnit the unit testing framework MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section kunit: fix failure to build without printk Felix Guo (1): kunit: tool: add Python wrappers for running KUnit tests Iurii Zaikin (1): kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec() Documentation/dev-tools/index.rst |1 + Documentation/dev-tools/kunit/api/index.rst | 16 + Documentation/dev-tools/kunit/api/test.rst| 11 +
Re: [PATCH] drm/panel: samsung: s6e8aa0: Add backlight control support
Hi Joonas,
On 21.09.2019 14:48, Joonas Kylmälä wrote:
> This makes the backlight brightness controllable from the
> userspace.
>
> Signed-off-by: Joonas Kylmälä
> ---
> drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 82
> ---
> 1 file changed, 60 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
> index dbced6501204..aa75934f5bed 100644
> --- a/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c
> @@ -10,8 +10,12 @@
> * Eunchul Kim
> * Tomasz Figa
> * Andrzej Hajda
> + *
> + * Derived from panel-samsung-s6e63m0.c:
> + * Copyright (C) 2019 Paweł Chmiel
> */
>
> +#include
> #include
> #include
> #include
> @@ -85,6 +89,8 @@
> #define AID_2(0x6)
> #define AID_3(0x7)
>
> +#define MAX_BRIGHTNESS (GAMMA_LEVEL_NUM - 1)
> +
> typedef u8 s6e8aa0_gamma_table[GAMMA_TABLE_LEN];
>
> struct s6e8aa0_variant {
> @@ -95,6 +101,7 @@ struct s6e8aa0_variant {
> struct s6e8aa0 {
> struct device *dev;
> struct drm_panel panel;
> + struct backlight_device *bl_dev;
>
> struct regulator_bulk_data supplies[2];
> struct gpio_desc *reset_gpio;
> @@ -110,7 +117,6 @@ struct s6e8aa0 {
> u8 version;
> u8 id;
> const struct s6e8aa0_variant *variant;
> - int brightness;
>
> /* This field is tested by functions directly accessing DSI bus before
>* transfer, transfer is skipped if it is set. In case of transfer
> @@ -321,9 +327,10 @@ static void s6e8aa0_etc_elvss_control(struct s6e8aa0
> *ctx)
>
> static void s6e8aa0_elvss_nvm_set_v142(struct s6e8aa0 *ctx)
> {
> + struct backlight_device *bd = ctx->bl_dev;
> u8 br;
>
> - switch (ctx->brightness) {
> + switch (bd->props.brightness) {
> case 0 ... 6: /* 30cd ~ 100cd */
> br = 0xdf;
> break;
> @@ -762,24 +769,6 @@ static const struct s6e8aa0_variant s6e8aa0_variants[] =
> {
> }
> };
>
> -static void s6e8aa0_brightness_set(struct s6e8aa0 *ctx)
> -{
> - const u8 *gamma;
> -
> - if (ctx->error)
> - return;
> -
> - gamma = ctx->variant->gamma_tables[ctx->brightness];
> -
> - if (ctx->version >= 142)
> - s6e8aa0_elvss_nvm_set(ctx);
> -
> - s6e8aa0_dcs_write(ctx, gamma, GAMMA_TABLE_LEN);
> -
> - /* update gamma table. */
> - s6e8aa0_dcs_write_seq_static(ctx, 0xf7, 0x03);
> -}
> -
> static void s6e8aa0_panel_init(struct s6e8aa0 *ctx)
> {
> s6e8aa0_apply_level_1_key(ctx);
> @@ -791,7 +780,7 @@ static void s6e8aa0_panel_init(struct s6e8aa0 *ctx)
>
> s6e8aa0_panel_cond_set(ctx);
> s6e8aa0_display_condition_set(ctx);
> - s6e8aa0_brightness_set(ctx);
> + backlight_enable(ctx->bl_dev);
> s6e8aa0_etc_source_control(ctx);
> s6e8aa0_etc_pentile_control(ctx);
> s6e8aa0_elvss_nvm_set(ctx);
> @@ -974,6 +963,53 @@ static int s6e8aa0_parse_dt(struct s6e8aa0 *ctx)
> return 0;
> }
>
> +static int s6e8aa0_set_brightness(struct backlight_device *bd)
> +{
> + struct s6e8aa0 *ctx = bl_get_data(bd);
> + const u8 *gamma;
> +
> + if (ctx->error)
> + return;
> +
> + gamma = ctx->variant->gamma_tables[bd->props.brightness];
> +
> + if (ctx->version >= 142)
> + s6e8aa0_elvss_nvm_set(ctx);
> +
> + s6e8aa0_dcs_write(ctx, gamma, GAMMA_TABLE_LEN);
> +
> + /* update gamma table. */
> + s6e8aa0_dcs_write_seq_static(ctx, 0xf7, 0x03);
> +
> + return s6e8aa0_clear_error(ctx);
> +}
> +
> +static const struct backlight_ops s6e8aa0_backlight_ops = {
> + .update_status = s6e8aa0_set_brightness,
This is racy, update_status can be called in any time between probe and
remove, particularly:
a) before panel enable,
b) during panel enable,
c) when panel is enabled,
d) during panel disable,
e) after panel disable,
b and d are racy for sure - backlight and drm callbacks are async.
IMO the best solution would be to register backlight after attaching
panel to drm, but for this drm_panel_funcs should have attach/detach
callbacks (like drm_bridge_funcs),
then update_status callback should take some drm_connector lock to
synchronize with drm, and write to hw only when pipe is enabled.
Regards
Andrzej
> +};
> +
> +static int s6e8aa0_backlight_register(struct s6e8aa0 *ctx)
> +{
> + struct backlight_properties props = {
> + .type = BACKLIGHT_RAW,
> + .brightness = MAX_BRIGHTNESS,
> + .max_brightness = MAX_BRIGHTNESS
> + };
> + struct device *dev = ctx->dev;
> + int ret = 0;
> +
> + ctx->bl_dev = devm_backlight_device_register(dev, "panel", dev, ctx,
> + _backlight_ops,
> + );
> + if
Re: [PATCH v1 1/2] dt-bindings: add vendor prefix for logic technologies limited
On Fri, 2019-09-20 at 09:54 +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Add vendor prefix for Logic Technologies Limited [1] which is a > Chinese > display manufacturer e.g. distributed by German Endrich Bauelemente > Vertriebs GmbH [2]. > > [1] https://logictechno.com/contact-us/ > [2] > https://www.endrich.com/isi50_isi30_tft-displays/lt170410-1whc_isi30 > > Signed-off-by: Marcel Ziswiler Reviewed-by: Philippe Schenker > > --- > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 967e78c5ec0a..1441146f394f 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -541,6 +541,8 @@ patternProperties: > description: Linear Technology Corporation >"^logicpd,.*": > description: Logic PD, Inc. > + "^logictechno,.*": > +description: Logic Technologies Limited >"^longcheer,.*": > description: Longcheer Technology (Shanghai) Co., Ltd. >"^lsi,.*":
[PATCH v1 0/2] Add initial support for slimport anx7625
Hi all, The following series add initial support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the first version upload, any mistakes, please let me know, I will fix it in the next series. Thanks, Xin Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver .../bindings/display/bridge/anx7625.yaml | 84 + drivers/gpu/drm/bridge/Makefile|2 +- drivers/gpu/drm/bridge/analogix/Kconfig|6 + drivers/gpu/drm/bridge/analogix/Makefile |1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 2110 drivers/gpu/drm/bridge/analogix/anx7625.h | 405 6 files changed, 2607 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7625.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4
Re: [PATCH v6 2/2] drm/bridge: Add NWL MIPI DSI host controller support
On 22.09.2019 18:47, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found on
> i.MX8 SoCs.
>
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
>
> It has been tested on the Librem 5 devkit using mxsfb.
>
> Signed-off-by: Guido Günther
> Co-developed-by: Robert Chiras
> Signed-off-by: Robert Chiras
> Tested-by: Robert Chiras
> ---
> drivers/gpu/drm/bridge/Kconfig | 16 +
> drivers/gpu/drm/bridge/Makefile |3 +
> drivers/gpu/drm/bridge/nwl-dsi.c | 1180 ++
> drivers/gpu/drm/bridge/nwl-dsi.h | 144
> 4 files changed, 1343 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.c
> create mode 100644 drivers/gpu/drm/bridge/nwl-dsi.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 1cc9f502c1f2..13021f9a6107 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -65,6 +65,22 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
>to DP++. This is used with the i.MX6 imx-ldb
>driver. You are likely to say N here.
>
> +config DRM_NWL_MIPI_DSI
> + tristate "Northwest Logic MIPI DSI Host controller"
> + depends on DRM
> + depends on COMMON_CLK
> + depends on OF && HAS_IOMEM
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL_BRIDGE
> + select GENERIC_PHY_MIPI_DPHY
> + select MFD_SYSCON
> + select MULTIPLEXER
> + select REGMAP_MMIO
> + help
> + This enables the Northwest Logic MIPI DSI Host controller as
> + for example found on NXP's i.MX8 Processors.
> +
> config DRM_NXP_PTN3460
> tristate "NXP PTN3460 DP/LVDS bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf5a6f8..c3f3a43e9b8f 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -16,4 +16,7 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
> obj-y += synopsys/
> +
> +header-test-y += nwl-dsi.h
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> new file mode 100644
> index ..dea5429a1e17
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -0,0 +1,1180 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX8 NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "nwl-dsi.h"
> +
> +#define DRV_NAME "nwl-dsi"
> +
> +/* i.MX8 NWL quirks */
> +/* i.MX8MQ errata E11418 */
> +#define E11418_HS_MODE_QUIRK BIT(0)
> +/* Skip DSI bits in SRC on disable to avoid blank display on enable */
> +#define SRC_RESET_QUIRK BIT(1)
> +
> +#define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
> +
> +enum transfer_direction {
> + DSI_PACKET_SEND,
> + DSI_PACKET_RECEIVE,
> +};
> +
> +/* Possible platform specific clocks */
> +#define NWL_DSI_CLK_CORE "core"
> +#define NWL_DSI_MAX_PLATFORM_CLOCKS 1
> +
> +struct nwl_dsi_plat_clk_config {
> + const char *id;
> + struct clk *clk;
> + bool present;
> +};
> +
> +struct nwl_dsi_transfer {
> + const struct mipi_dsi_msg *msg;
> + struct mipi_dsi_packet packet;
> + struct completion completed;
> +
> + int status; /* status of transmission */
> + enum transfer_direction direction;
> + bool need_bta;
> + u8 cmd;
> + u16 rx_word_count;
> + size_t tx_len; /* in bytes */
> + size_t rx_len; /* in bytes */
> +};
> +
> +struct nwl_dsi {
> + struct drm_bridge bridge;
> + struct mipi_dsi_host dsi_host;
> + struct drm_bridge *panel_bridge;
> + struct device *dev;
> + struct phy *phy;
> + union phy_configure_opts phy_cfg;
> + unsigned int quirks;
> +
> + struct regmap *regmap;
> + int irq;
> + struct reset_control *rstc;
> + struct mux_control *mux;
> +
> + /* DSI clocks */
> + struct clk *phy_ref_clk;
> + struct clk *rx_esc_clk;
> + struct clk *tx_esc_clk;
> + /* Platform dependent clocks */
> + struct nwl_dsi_plat_clk_config clk_config[NWL_DSI_MAX_PLATFORM_CLOCKS];
These clocks are not documented.
> +
> + /* dsi lanes */
> + u32 lanes;
> + enum mipi_dsi_pixel_format format;
> + struct drm_display_mode mode;
> + unsigned long dsi_mode_flags;
> +
> + struct nwl_dsi_transfer *xfer;
> +
> + const struct nwl_dsi_platform_data *pdata;
> +};
> +
>
[Bug 111667] gem_render_copy failing on CCS subtests
https://bugs.freedesktop.org/show_bug.cgi?id=111667 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Chris Wilson --- Forward duping to tie in with cibuglog. *** This bug has been marked as a duplicate of bug 111771 *** -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204227] Visual artefacts and crash from suspend on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204227 Łukasz Żarnowiecki (luk...@zarnowiecki.pl) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #15 from Łukasz Żarnowiecki (luk...@zarnowiecki.pl) --- I updated kernel to 5.3 and problem disappeared. I did not update bios or anything like that. Perhaps the problem you guys are facing is different than originally reported. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
On 22.09.2019 18:47, Guido Günther wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther
> Tested-by: Robert Chiras
> Reviewed-by: Rob Herring
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 176 ++
> 1 file changed, 176 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> new file mode 100644
> index ..31119c7885ff
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -0,0 +1,176 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> https://protect2.fireeye.com/url?k=7c9397fbdbbe3fd5.7c921cb4-87fc4542b5f41502=http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Northwest Logic MIPI-DSI controller on i.MX SoCs
> +
> +maintainers:
> + - Guido Gúnther
> + - Robert Chiras
> +
> +description: |
> + NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi
> bridge for
> + the SOCs NWL MIPI-DSI host controller.
> +
> +properties:
> + compatible:
> +const: fsl,imx8mq-nwl-dsi
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + clocks:
> +items:
> + - description: DSI core clock
> + - description: RX_ESC clock (used in escape mode)
> + - description: TX_ESC clock (used in escape mode)
> + - description: PHY_REF clock
> +
> + clock-names:
> +items:
> + - const: core
> + - const: rx_esc
> + - const: tx_esc
> + - const: phy_ref
> +
> + mux-controls:
> +description:
> + mux controller node to use for operating the input mux
> +
> + phys:
> +maxItems: 1
> +description:
> + A phandle to the phy module representing the DPHY
> +
> + phy-names:
> +items:
> + - const: dphy
> +
> + power-domains:
> +maxItems: 1
> +
> + resets:
> +items:
> + - description: dsi byte reset line
> + - description: dsi dpi reset line
> + - description: dsi esc reset line
> + - description: dsi pclk reset line
> +
> + reset-names:
> +items:
> + - const: byte
> + - const: dpi
> + - const: esc
> + - const: pclk
> +
> + ports:
> +type: object
> +description:
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/graph.txt.
> +properties:
> + port@0:
> +type: object
> +description:
> + Input port node to receive pixel data from the
> + display controller
> +
> + port@1:
> +type: object
> +description:
> + DSI output port node to the panel or the next bridge
> + in the chain
> +
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> +required:
> + - '#address-cells'
> + - '#size-cells'
> + - port@0
> + - port@1
> +
> +additionalProperties: false
> +
> +patternProperties:
> + "^panel@[0-9]+$":
> +type: object
> +
> +required:
> + - '#address-cells'
> + - '#size-cells'
> + - clock-names
> + - clocks
> + - compatible
> + - interrupts
> + - mux-controls
As I understand mux is not a part of the device, so maybe would be safer
to make it optional.
Regards
Andrzej
> + - phy-names
> + - phys
> + - ports
> + - reg
> + - reset-names
> + - resets
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> + mipi_dsi: mipi_dsi@30a0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,imx8mq-nwl-dsi";
> + reg = <0x30A0 0x300>;
> + clocks = < 163>, < 244>, < 245>, < 164>;
> + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> + interrupts = <0 34 4>;
> + mux-controls = < 0>;
> + power-domains = <_mipi>;
> + resets = < 0>, < 1>, < 2>, < 3>;
> + reset-names = "byte", "dpi", "esc", "pclk";
> + phys = <>;
> + phy-names = "dphy";
> +
> + panel@0 {
> + compatible = "rocktech,jh057n00900";
> + reg = <0>;
> + port@0 {
> + panel_in: endpoint {
> + remote-endpoint = <_dsi_out>;
> + };
> + };
> + };
> +
> + ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> + reg =
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 --- Comment #30 from Michel Dänzer --- (In reply to Arianne Brink from comment #29) > My Vega 56 is showing the same problems. However, I noticed that by > disabling xfsettingsd in XFCE and kscreen in Plasma it solved the problem. Disabling those probably just means nothing listens to the spurious hotplug events, thereby avoiding the problem. Just another workaround, not a proper solution. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 15/19] Documentation: kunit: add documentation for KUnit
On Mon, Sep 23, 2019 at 8:48 AM Randy Dunlap wrote: > > On 9/23/19 2:02 AM, Brendan Higgins wrote: > > Add documentation for KUnit, the Linux kernel unit testing framework. > > - Add intro and usage guide for KUnit > > - Add API reference > > > > Signed-off-by: Felix Guo > > Signed-off-by: Brendan Higgins > > Cc: Jonathan Corbet > > Reviewed-by: Greg Kroah-Hartman > > Reviewed-by: Logan Gunthorpe > > Reviewed-by: Stephen Boyd > > --- > > Documentation/dev-tools/index.rst | 1 + > > Documentation/dev-tools/kunit/api/index.rst | 16 + > > Documentation/dev-tools/kunit/api/test.rst | 11 + > > Documentation/dev-tools/kunit/faq.rst | 62 +++ > > Documentation/dev-tools/kunit/index.rst | 79 +++ > > Documentation/dev-tools/kunit/start.rst | 180 ++ > > Documentation/dev-tools/kunit/usage.rst | 576 > > 7 files changed, 925 insertions(+) > > create mode 100644 Documentation/dev-tools/kunit/api/index.rst > > create mode 100644 Documentation/dev-tools/kunit/api/test.rst > > create mode 100644 Documentation/dev-tools/kunit/faq.rst > > create mode 100644 Documentation/dev-tools/kunit/index.rst > > create mode 100644 Documentation/dev-tools/kunit/start.rst > > create mode 100644 Documentation/dev-tools/kunit/usage.rst > > > > diff --git a/Documentation/dev-tools/kunit/start.rst > > b/Documentation/dev-tools/kunit/start.rst > > new file mode 100644 > > index ..6dc229e46bb3 > > --- /dev/null > > +++ b/Documentation/dev-tools/kunit/start.rst > > @@ -0,0 +1,180 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +=== > > +Getting Started > > +=== > > + > > +Installing dependencies > > +=== > > +KUnit has the same dependencies as the Linux kernel. As long as you can > > build > > +the kernel, you can run KUnit. > > + > > +KUnit Wrapper > > += > > +Included with KUnit is a simple Python wrapper that helps format the > > output to > > +easily use and read KUnit output. It handles building and running the > > kernel, as > > +well as formatting the output. > > + > > +The wrapper can be run with: > > + > > +.. code-block:: bash > > + > > + ./tools/testing/kunit/kunit.py run > > + > > +Creating a kunitconfig > > +== > > +The Python script is a thin wrapper around Kbuild as such, it needs to be > >around Kbuild. As such, Thanks for pointing this out. > > > +configured with a ``kunitconfig`` file. This file essentially contains the > > +regular Kernel config, with the specific test targets as well. > > + > > +.. code-block:: bash > > + > > + git clone -b master https://kunit.googlesource.com/kunitconfig > > $PATH_TO_KUNITCONFIG_REPO > > + cd $PATH_TO_LINUX_REPO > > + ln -s $PATH_TO_KUNIT_CONFIG_REPO/kunitconfig kunitconfig > > + > > +You may want to add kunitconfig to your local gitignore. > > + > > +Verifying KUnit Works > > +- > > + > > +To make sure that everything is set up correctly, simply invoke the Python > > +wrapper from your kernel repo: > > + > > +.. code-block:: bash > > + > > + ./tools/testing/kunit/kunit.py > > + > > +.. note:: > > + You may want to run ``make mrproper`` first. > > I normally use O=builddir when building kernels. > Does this support using O=builddir ? Yep, it supports specifying a separate build directory. > > + > > +If everything worked correctly, you should see the following: > > + > > +.. code-block:: bash > > + > > + Generating .config ... > > + Building KUnit Kernel ... > > + Starting KUnit Kernel ... > > + > > +followed by a list of tests that are run. All of them should be passing. > > + > > +.. note:: > > + Because it is building a lot of sources for the first time, the > > ``Building > > + kunit kernel`` step may take a while. > > + > > +Writing your first test > > +=== > > [snip] > > > diff --git a/Documentation/dev-tools/kunit/usage.rst > > b/Documentation/dev-tools/kunit/usage.rst > > new file mode 100644 > > index ..c6e69634e274 > > --- /dev/null > > +++ b/Documentation/dev-tools/kunit/usage.rst > > TBD... What did you mean by this comment? Cheers
[Bug 111122] 2500U: Graphics corruption on kernel 5.2
https://bugs.freedesktop.org/show_bug.cgi?id=22 --- Comment #30 from William Bonnaventure --- Fixed issue with a BIOS update on Lenovo E485 (v1.54 with AMD 2500U) with Fedora 30 KDE. I had an issue on previous BIOS that requires a kernel option to boot on all kernels (ivrs_ioapic[32]=00:14.0). After BIOS update, this option is not needed and there is no longer graphic corruption on Kernel 5.2+. This corruption was impacting at least Firefox, dolphin and the Plasma Desktop. KDE plasma 5.15.5 mesa 19.1.6 xorg-x11-drv-amdgpu 19.0.1 libdrm 2.4.99 As of my observation, the graphic corruption was introduced in the amdgpu driver inside Kernel 5.2 and occurs only when forcing boot with the ivrs_ioapic override. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/36] drm/atmel-hlcdc: use bpp instead of cpp for drm_format_info
Hi Sandy. Thanks for taking care of this, but... On Mon, Sep 23, 2019 at 08:51:45PM +0800, Sandy Huang wrote: > cpp[BytePerPlane] can't describe the 10bit data format correctly, > So we use bpp[BitPerPlane] to instead cpp. > > Signed-off-by: Sandy Huang > --- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > index 89f5a75..ab7d423 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > @@ -644,7 +644,7 @@ static int atmel_hlcdc_plane_atomic_check(struct > drm_plane *p, > int xdiv = i ? fb->format->hsub : 1; > int ydiv = i ? fb->format->vsub : 1; > > - state->bpp[i] = fb->format->cpp[i]; > + state->bpp[i] = fb->format->bpp[i] / 8; > if (!state->bpp[i]) > return -EINVAL; Awaiting conclusion on Daniels comment on PATCH 1 and has dropped this patch for now. And please address the concerns Rob has about bisectability in your cover letter for v2. Sam
Re: [PATCH 01/36] drm/fourcc: Add 2 plane YCbCr 10bit format support
On Mon, Sep 23, 2019 at 06:05:22AM -0700, sandy.huang wrote:
>
> 在 2019/9/23 上午5:53, Ville Syrjälä 写道:
> > On Mon, Sep 23, 2019 at 08:38:50PM +0800, Sandy Huang wrote:
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index 3feeaa3..5fe89e9 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -266,6 +266,21 @@ extern "C" {
> >> #define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
> >> subsampled Cr:Cb plane 16 bits per channel */
> >>
> >> /*
> >> + * 2 plane YCbCr 10bit
> >> + * index 0 = Y plane, [9:0] Y
> >> + * index 1 = Cr:Cb plane, [19:0] Cr:Cb little endian
> >> + * or
> >> + * index 1 = Cb:Cr plane, [19:0] Cb:Cr little endian
> > What does "little endian" even mean for these?
>
> It's Inherited from the following define, the difference is 8bit and 10bit.
> /*
> * 2 plane YCbCr
> * index 0 = Y plane, [7:0] Y
> * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
> * or
> * index 1 = Cb:Cr plane, [15:0] Cb:Cr little endian
> */
> #define DRM_FORMAT_NV12 fourcc_code('N', 'V', '1', '2') /* 2x2
> subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV21 fourcc_code('N', 'V', '2', '1') /* 2x2
> subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV16 fourcc_code('N', 'V', '1', '6') /* 2x1
> subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
> subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4',
Something not aligned to bytes can't have its endianness defined the
same way as these. Just doesn't make sense.
>
>
>
> >
> >> + */
> >> +
> >> +#define DRM_FORMAT_NV12_10fourcc_code('N', 'A', '1', '2') /* 2x2
> >> subsampled Cr:Cb plane */
> >> +#define DRM_FORMAT_NV21_10fourcc_code('N', 'A', '2', '1') /* 2x2
> >> subsampled Cb:Cr plane */
> >> +#define DRM_FORMAT_NV16_10fourcc_code('N', 'A', '1', '6') /* 2x1
> >> subsampled Cr:Cb plane */
> >> +#define DRM_FORMAT_NV61_10fourcc_code('N', 'A', '6', '1') /* 2x1
> >> subsampled Cb:Cr plane */
> >> +#define DRM_FORMAT_NV24_10fourcc_code('N', 'A', '2', '4') /*
> >> non-subsampled Cr:Cb plane */
> >> +#define DRM_FORMAT_NV42_10fourcc_code('N', 'A', '4', '2') /*
> >> non-subsampled Cb:Cr plane */
> >> +
> >> +/*
> >>* 3 plane YCbCr
> >>* index 0: Y plane, [7:0] Y
> >>* index 1: Cb plane, [7:0] Cb
> >> --
> >> 2.7.4
> >>
> >>
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Ville Syrjälä
Intel
Re: [PATCH] drm/panel: samsung: s6e8aa0: Add backlight control support
Hi,
thanks a lot for the review, Andrzej!
Andrzej Hajda:
>> +static const struct backlight_ops s6e8aa0_backlight_ops = {
>> +.update_status = s6e8aa0_set_brightness,
>
>
> This is racy, update_status can be called in any time between probe and
> remove, particularly:
>
> a) before panel enable,
>
> b) during panel enable,
>
> c) when panel is enabled,
>
> d) during panel disable,
>
> e) after panel disable,
>
>
> b and d are racy for sure - backlight and drm callbacks are async.
>
> IMO the best solution would be to register backlight after attaching
> panel to drm, but for this drm_panel_funcs should have attach/detach
> callbacks (like drm_bridge_funcs),
>
> then update_status callback should take some drm_connector lock to
> synchronize with drm, and write to hw only when pipe is enabled.
I will start reading the kernel DRM KMS documentation in order to learn
how the attach callback would fit in the picture and do what you suggest
but it might take a few weeks or months.
Also, as a lot of this code was mimicked from
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c it looks like that is also
having this race condition. Unfortunately, I don't think I have the
s6e63m0 panel so for that I probably cannot fix this issue.
Joonas
Re: [PATCH 5/5] drm/msm/adreno: Add support for Adreno 510 GPU
On Mon, Sep 23, 2019 at 10:27 AM AngeloGioacchino Del Regno
wrote:
>
> Il giorno lun 23 set 2019 alle ore 18:37 Rob Clark
> ha scritto:
> >
> > On Sat, Sep 21, 2019 at 3:04 AM wrote:
> > >
> > > From: "Angelo G. Del Regno"
> > >
> > > The Adreno 510 GPU is a stripped version of the Adreno 5xx,
> > > found in low-end SoCs like 8x56 and 8x76, which has 256K of
> > > GMEM, with no GPMU nor ZAP.
> > > Also, since the Adreno 5xx part of this driver seems to be
> > > developed with high-end Adreno GPUs in mind, and since this
> > > is a lower end one, add a comment making clear which GPUs
> > > which support is not implemented yet is not using the GPMU
> > > related hw init code, so that future developers will not go
> > > crazy with that.
> > >
> > > By the way, the lower end Adreno GPUs with no GPMU are:
> > > A505/A506/A510 (no ZAP firmware)
> > > A508/A509/A512 (with ZAP firmware)
> > >
> >
> > Hi, thanks for the patch.. one comment below about zap firmware...
> > which is not completely to do with this patch, but is my thoughts on
> > how we should clean up zap handling
> >
> > > Signed-off-by: Angelo G. Del Regno
> >
> > [snip]
> >
> > > @@ -679,7 +716,8 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
> > >
> > > a5xx_preempt_hw_init(gpu);
> > >
> > > - a5xx_gpmu_ucode_init(gpu);
> > > + if (!adreno_is_a510(adreno_gpu))
> > > + a5xx_gpmu_ucode_init(gpu);
> > >
> > > ret = a5xx_ucode_init(gpu);
> > > if (ret)
> > > @@ -712,12 +750,18 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
> > > }
> > >
> > > /*
> > > -* Try to load a zap shader into the secure world. If successful
> > > +* If the chip that we are using does support loading one, then
> > > +* try to load a zap shader into the secure world. If successful
> > > * we can use the CP to switch out of secure mode. If not then we
> > > * have no resource but to try to switch ourselves out manually.
> > > If we
> > > * guessed wrong then access to the RBBM_SECVID_TRUST_CNTL
> > > register will
> > > * be blocked and a permissions violation will soon follow.
> > > */
> > > + if (adreno_is_a510(adreno_gpu)) {
> > > + gpu_write(gpu, REG_A5XX_RBBM_SECVID_TRUST_CNTL, 0x0);
> > > + goto skip_zap;
> > > + }
> >
> > This is something we need to cleanup on a6xx as well. But it is
> > actually possible to have the same GPU with and without zap. We have
> > this situation today with sdm845, for example.
> >
> > What I'd like to do is rather than guess whether we can write
> > RBBM_SECVID_TRUST_CNTL or not (since that goes spectacularly wrong
> > when we guess incorrectly), is choose based on the presence of the
> > zap-shader child node in dtb. (Currently a6xx tries to choose based
> > on whether zap firmware is present.. which we need to fix.)
> >
> > Originally I was thinking we could keep the zap-shader node in the
> > SoC's "core" dtsi (ie. msm8996.dtsi, sdm845.dtsi, etc) and using
> > /delete-node/ in per-device dts files for devices without zap.. but
> > (AFAIU) the zap shader ends up being signed with a vendor key in most
> > cases, meaning that to have a "generic" (not device-specific) distro
> > image need to have different zap file names/paths for devices from
> > different vendors. Given this, I think it makes more sense to move
> > the zap-shader node into a per-device (or at least, per-vendor) dts
> > file, ie. something like:
> >
> >/* sdm850-lenovo-yoga-c630.dts: */
> > gpu {
> > zap-shader {
> > memory-region = <_mem>;
> > zap-prefix = "LENOVO";
> > };
> > };
> >
> > which would trigger the driver to try to load
> > /lib/firmware/qcom/LENOVO/a630_zap.mbn
> >
> > (I'd like to, at least for devices that have ACPI/SMBIOS tables,
> > standardize on using the vendor name from SMBIOS tables as this
> > prefix.. so we have a way to construct the firmware path if we
> > eventually have ACPI boot support on the aarch64 laptops.)
> >
> > BR,
> > -R
> >
> > > +
> > > ret = a5xx_zap_shader_init(gpu);
> > > if (!ret) {
> > > OUT_PKT7(gpu->rb[0], CP_SET_SECURE_MODE, 1);
> > > @@ -733,6 +777,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
> > > gpu_write(gpu, REG_A5XX_RBBM_SECVID_TRUST_CNTL, 0x0);
> > > }
> > >
> > > +skip_zap:
> > > /* Last step - yield the ringbuffer */
> > > a5xx_preempt_start(gpu);
> > >
> > > @@ -1066,6 +,7 @@ static void a5xx_dump(struct msm_gpu *gpu)
>
> Thanks to you for the review.
> What I've documented there about the A5xx chips having ZAP and the ones not
> having it, came out after a research in the downstream KGSL driver, where qcom
> does this distinction based on just the Adreno model, which is the main reason
> why I did it like that :)))
>
> I am personally not aware of any A5xx chip having this behavior, so that's
> why I
> didn't even
Re: [PATCH v18 15/19] Documentation: kunit: add documentation for KUnit
On 9/23/19 11:06 AM, Brendan Higgins wrote: > On Mon, Sep 23, 2019 at 8:48 AM Randy Dunlap wrote: >> >> On 9/23/19 2:02 AM, Brendan Higgins wrote: >>> Add documentation for KUnit, the Linux kernel unit testing framework. >>> - Add intro and usage guide for KUnit >>> - Add API reference >>> >>> Signed-off-by: Felix Guo >>> Signed-off-by: Brendan Higgins >>> Cc: Jonathan Corbet >>> Reviewed-by: Greg Kroah-Hartman >>> Reviewed-by: Logan Gunthorpe >>> Reviewed-by: Stephen Boyd >>> --- >>> Documentation/dev-tools/index.rst | 1 + >>> Documentation/dev-tools/kunit/api/index.rst | 16 + >>> Documentation/dev-tools/kunit/api/test.rst | 11 + >>> Documentation/dev-tools/kunit/faq.rst | 62 +++ >>> Documentation/dev-tools/kunit/index.rst | 79 +++ >>> Documentation/dev-tools/kunit/start.rst | 180 ++ >>> Documentation/dev-tools/kunit/usage.rst | 576 >>> 7 files changed, 925 insertions(+) >>> create mode 100644 Documentation/dev-tools/kunit/api/index.rst >>> create mode 100644 Documentation/dev-tools/kunit/api/test.rst >>> create mode 100644 Documentation/dev-tools/kunit/faq.rst >>> create mode 100644 Documentation/dev-tools/kunit/index.rst >>> create mode 100644 Documentation/dev-tools/kunit/start.rst >>> create mode 100644 Documentation/dev-tools/kunit/usage.rst >> >> >>> diff --git a/Documentation/dev-tools/kunit/start.rst >>> b/Documentation/dev-tools/kunit/start.rst >>> new file mode 100644 >>> index ..6dc229e46bb3 >>> --- /dev/null >>> +++ b/Documentation/dev-tools/kunit/start.rst >>> @@ -0,0 +1,180 @@ >>> +.. SPDX-License-Identifier: GPL-2.0 >>> + >>> +=== >>> +Getting Started >>> +=== >>> + >>> +Installing dependencies >>> +=== >>> +KUnit has the same dependencies as the Linux kernel. As long as you can >>> build >>> +the kernel, you can run KUnit. >>> + >>> +KUnit Wrapper >>> += >>> +Included with KUnit is a simple Python wrapper that helps format the >>> output to >>> +easily use and read KUnit output. It handles building and running the >>> kernel, as >>> +well as formatting the output. >>> + >>> +The wrapper can be run with: >>> + >>> +.. code-block:: bash >>> + >>> + ./tools/testing/kunit/kunit.py run >>> + >>> +Creating a kunitconfig >>> +== >>> +The Python script is a thin wrapper around Kbuild as such, it needs to be >> >>around Kbuild. As such, > > Thanks for pointing this out. > >> >>> +configured with a ``kunitconfig`` file. This file essentially contains the >>> +regular Kernel config, with the specific test targets as well. >>> + >>> +.. code-block:: bash >>> + >>> + git clone -b master https://kunit.googlesource.com/kunitconfig >>> $PATH_TO_KUNITCONFIG_REPO >>> + cd $PATH_TO_LINUX_REPO >>> + ln -s $PATH_TO_KUNIT_CONFIG_REPO/kunitconfig kunitconfig >>> + >>> +You may want to add kunitconfig to your local gitignore. >>> + >>> +Verifying KUnit Works >>> +- >>> + >>> +To make sure that everything is set up correctly, simply invoke the Python >>> +wrapper from your kernel repo: >>> + >>> +.. code-block:: bash >>> + >>> + ./tools/testing/kunit/kunit.py >>> + >>> +.. note:: >>> + You may want to run ``make mrproper`` first. >> >> I normally use O=builddir when building kernels. >> Does this support using O=builddir ? > > Yep, it supports specifying a separate build directory. > >>> + >>> +If everything worked correctly, you should see the following: >>> + >>> +.. code-block:: bash >>> + >>> + Generating .config ... >>> + Building KUnit Kernel ... >>> + Starting KUnit Kernel ... >>> + >>> +followed by a list of tests that are run. All of them should be passing. >>> + >>> +.. note:: >>> + Because it is building a lot of sources for the first time, the >>> ``Building >>> + kunit kernel`` step may take a while. >>> + >>> +Writing your first test >>> +=== >> >> [snip] >> >>> diff --git a/Documentation/dev-tools/kunit/usage.rst >>> b/Documentation/dev-tools/kunit/usage.rst >>> new file mode 100644 >>> index ..c6e69634e274 >>> --- /dev/null >>> +++ b/Documentation/dev-tools/kunit/usage.rst >> >> TBD... > > What did you mean by this comment? I plan to review usage.rst soon... (To Be Done :) -- ~Randy
[PATCH v2 03/12] drm/ast: Move cursor update code to ast_show_cursor()
A call to ast's show-cursor function now receives the cursor image
and updates the buffer. The change splits off image update and
base-address update into separate functions.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 120 +++--
1 file changed, 69 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index a4cbf2d5ee0a..1294f0612fd5 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1064,23 +1064,6 @@ static void ast_i2c_destroy(struct ast_i2c_chan *i2c)
kfree(i2c);
}
-static void ast_show_cursor(struct drm_crtc *crtc)
-{
- struct ast_private *ast = crtc->dev->dev_private;
- u8 jreg;
-
- jreg = 0x2;
- /* enable ARGB cursor */
- jreg |= 1;
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, jreg);
-}
-
-static void ast_hide_cursor(struct drm_crtc *crtc)
-{
- struct ast_private *ast = crtc->dev->dev_private;
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, 0x00);
-}
-
static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int height)
{
union {
@@ -1137,6 +1120,72 @@ static u32 copy_cursor_image(u8 *src, u8 *dst, int
width, int height)
return csum;
}
+static int ast_cursor_update(void *dst, void *src, unsigned int width,
+unsigned int height)
+{
+ u32 csum;
+
+ /* do data transfer to cursor cache */
+ csum = copy_cursor_image(src, dst, width, height);
+
+ /* write checksum + signature */
+ dst += AST_HWC_SIZE;
+ writel(csum, dst);
+ writel(width, dst + AST_HWC_SIGNATURE_SizeX);
+ writel(height, dst + AST_HWC_SIGNATURE_SizeY);
+ writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTX);
+ writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTY);
+
+ return 0;
+}
+
+static void ast_cursor_set_base(struct ast_private *ast, u64 address)
+{
+ u8 addr0 = (address >> 3) & 0xff;
+ u8 addr1 = (address >> 11) & 0xff;
+ u8 addr2 = (address >> 19) & 0xff;
+
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc8, addr0);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc9, addr1);
+ ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xca, addr2);
+}
+
+static int ast_show_cursor(struct drm_crtc *crtc, void *dst, void *src,
+ unsigned int width, unsigned int height,
+ u64 dst_gpu)
+{
+ struct ast_private *ast = crtc->dev->dev_private;
+ struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
+ int ret;
+ u8 jreg;
+
+ dst += (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE)*ast->next_cursor;
+
+ ret = ast_cursor_update(dst, src, width, height);
+ if (ret)
+ return ret;
+ ast_cursor_set_base(ast, dst_gpu);
+
+ ast->next_cursor = (ast->next_cursor + 1) % AST_DEFAULT_HWC_NUM;
+
+ ast_crtc->offset_x = AST_MAX_HWC_WIDTH - width;
+ ast_crtc->offset_y = AST_MAX_HWC_WIDTH - height;
+
+ jreg = 0x2;
+ /* enable ARGB cursor */
+ jreg |= 1;
+ ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, jreg);
+
+ return 0;
+}
+
+static void ast_hide_cursor(struct drm_crtc *crtc)
+{
+ struct ast_private *ast = crtc->dev->dev_private;
+
+ ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, 0x00);
+}
+
static int ast_cursor_set(struct drm_crtc *crtc,
struct drm_file *file_priv,
uint32_t handle,
@@ -1144,12 +1193,9 @@ static int ast_cursor_set(struct drm_crtc *crtc,
uint32_t height)
{
struct ast_private *ast = crtc->dev->dev_private;
- struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
struct drm_gem_object *obj;
struct drm_gem_vram_object *gbo;
s64 dst_gpu;
- u64 gpu_addr;
- u32 csum;
int ret;
u8 *src, *dst;
@@ -1185,37 +1231,9 @@ static int ast_cursor_set(struct drm_crtc *crtc,
goto err_drm_gem_vram_vunmap;
}
- dst += (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE)*ast->next_cursor;
-
- /* do data transfer to cursor cache */
- csum = copy_cursor_image(src, dst, width, height);
-
- /* write checksum + signature */
- {
- struct drm_gem_vram_object *dst_gbo =
- drm_gem_vram_of_gem(ast->cursor_cache);
- u8 *dst = drm_gem_vram_kmap(dst_gbo, false, NULL);
- dst += (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE)*ast->next_cursor
+ AST_HWC_SIZE;
- writel(csum, dst);
- writel(width, dst + AST_HWC_SIGNATURE_SizeX);
- writel(height, dst + AST_HWC_SIGNATURE_SizeY);
- writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTX);
- writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTY);
-
- /* set pattern offset */
- gpu_addr = (u64)dst_gpu;
-
[PATCH v2 02/12] drm/ast: Don't call ast_show_cursor() from ast_cursor_move()
Separating the cursor's move() function from the show() function in preparation of further rework of the cursor update code. 'Showing' the cursor from within the move() function is required to update the cursor position. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_mode.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 6caa6ebfeaa8..a4cbf2d5ee0a 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -1236,6 +1236,7 @@ static int ast_cursor_move(struct drm_crtc *crtc, struct ast_private *ast = crtc->dev->dev_private; int x_offset, y_offset; u8 *sig; + u8 jreg; sig = drm_gem_vram_kmap(drm_gem_vram_of_gem(ast->cursor_cache), false, NULL); @@ -1262,7 +1263,9 @@ static int ast_cursor_move(struct drm_crtc *crtc, ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, ((y >> 8) & 0x07)); /* dummy write to fire HWC */ - ast_show_cursor(crtc); + jreg = 0x02 | + 0x01; /* enable ARGB cursor */ + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, jreg); return 0; } -- 2.23.0
[PATCH v2 07/12] drm/mgag200: Add init and fini functions for cursor handling
Moving the cursor initialization and cleanup into separate functions
makes the overall code slightly more readable.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 28
drivers/gpu/drm/mgag200/mgag200_drv.h| 2 ++
drivers/gpu/drm/mgag200/mgag200_main.c | 18 +--
3 files changed, 35 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 3df70d86af21..d39e2bc57a70 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -25,6 +25,34 @@ static void mgag200_hide_cursor(struct mga_device *mdev)
mdev->cursor.pixels_current = NULL;
}
+int mgag200_cursor_init(struct mga_device *mdev)
+{
+ struct drm_device *dev = mdev->dev;
+
+ /*
+* Make small buffers to store a hardware cursor (double
+* buffered icon updates)
+*/
+ mdev->cursor.pixels_1 = drm_gem_vram_create(dev, >vram_mm->bdev,
+ roundup(48*64, PAGE_SIZE),
+ 0, 0);
+ mdev->cursor.pixels_2 = drm_gem_vram_create(dev, >vram_mm->bdev,
+ roundup(48*64, PAGE_SIZE),
+ 0, 0);
+ if (IS_ERR(mdev->cursor.pixels_2) || IS_ERR(mdev->cursor.pixels_1)) {
+ mdev->cursor.pixels_1 = NULL;
+ mdev->cursor.pixels_2 = NULL;
+ dev_warn(>pdev->dev,
+ "Could not allocate space for cursors. Not doing
hardware cursors.\n");
+ }
+ mdev->cursor.pixels_current = NULL;
+
+ return 0;
+}
+
+void mgag200_cursor_fini(struct mga_device *mdev)
+{ }
+
int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file *file_priv,
uint32_t handle, uint32_t width, uint32_t height)
{
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 5244e3fa4203..01243fa6397c 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -203,6 +203,8 @@ int mgag200_mm_init(struct mga_device *mdev);
void mgag200_mm_fini(struct mga_device *mdev);
int mgag200_mmap(struct file *filp, struct vm_area_struct *vma);
+int mgag200_cursor_init(struct mga_device *mdev);
+void mgag200_cursor_fini(struct mga_device *mdev);
int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file *file_priv,
uint32_t handle, uint32_t width, uint32_t height);
int mgag200_crtc_cursor_move(struct drm_crtc *crtc, int x, int y);
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index a9773334dedf..2b59280777a5 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -171,20 +171,10 @@ int mgag200_driver_load(struct drm_device *dev, unsigned
long flags)
goto err_modeset;
}
- /* Make small buffers to store a hardware cursor (double buffered icon
updates) */
- mdev->cursor.pixels_1 = drm_gem_vram_create(dev, >vram_mm->bdev,
- roundup(48*64, PAGE_SIZE),
- 0, 0);
- mdev->cursor.pixels_2 = drm_gem_vram_create(dev, >vram_mm->bdev,
- roundup(48*64, PAGE_SIZE),
- 0, 0);
- if (IS_ERR(mdev->cursor.pixels_2) || IS_ERR(mdev->cursor.pixels_1)) {
- mdev->cursor.pixels_1 = NULL;
- mdev->cursor.pixels_2 = NULL;
+ r = mgag200_cursor_init(mdev);
+ if (r)
dev_warn(>pdev->dev,
- "Could not allocate space for cursors. Not doing
hardware cursors.\n");
- }
- mdev->cursor.pixels_current = NULL;
+ "Could not initialize cursors. Not doing hardware
cursors.\n");
r = drm_fbdev_generic_setup(mdev->dev, 0);
if (r)
@@ -194,6 +184,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned
long flags)
err_modeset:
drm_mode_config_cleanup(dev);
+ mgag200_cursor_fini(mdev);
mgag200_mm_fini(mdev);
err_mm:
dev->dev_private = NULL;
@@ -209,6 +200,7 @@ void mgag200_driver_unload(struct drm_device *dev)
return;
mgag200_modeset_fini(mdev);
drm_mode_config_cleanup(dev);
+ mgag200_cursor_fini(mdev);
mgag200_mm_fini(mdev);
dev->dev_private = NULL;
}
--
2.23.0
[PATCH v2 05/12] drm/ast: Allocate cursor BOs at high end of video memory
By putting cursor BOs at the high end of the video memory, we can avoid
memory fragmentation. Starting at the low end, contiguous video memory is
available for framebuffers.
The patch also simplifies the buffer swapping by splitting
struct ast_private.cursor_cache BO into two separate boffer objects. Cursor
images alternate between these buffers instead of offsets within cursor_cache.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 43 +---
drivers/gpu/drm/ast/ast_mode.c | 91 ++
2 files changed, 73 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 244cc7c382af..fc35163c7541 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -82,6 +82,25 @@ enum ast_tx_chip {
#define AST_DRAM_4Gx16 7
#define AST_DRAM_8Gx16 8
+
+#define AST_MAX_HWC_WIDTH 64
+#define AST_MAX_HWC_HEIGHT 64
+
+#define AST_HWC_SIZE (AST_MAX_HWC_WIDTH * AST_MAX_HWC_HEIGHT * 2)
+#define AST_HWC_SIGNATURE_SIZE 32
+
+#define AST_DEFAULT_HWC_NUM2
+
+/* define for signature structure */
+#define AST_HWC_SIGNATURE_CHECKSUM 0x00
+#define AST_HWC_SIGNATURE_SizeX0x04
+#define AST_HWC_SIGNATURE_SizeY0x08
+#define AST_HWC_SIGNATURE_X0x0C
+#define AST_HWC_SIGNATURE_Y0x10
+#define AST_HWC_SIGNATURE_HOTSPOTX 0x14
+#define AST_HWC_SIGNATURE_HOTSPOTY 0x18
+
+
struct ast_private {
struct drm_device *dev;
@@ -97,8 +116,11 @@ struct ast_private {
int fb_mtrr;
- struct drm_gem_object *cursor_cache;
- int next_cursor;
+ struct {
+ struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
+ unsigned int next_index;
+ } cursor;
+
bool support_wide_screen;
enum {
ast_use_p2a,
@@ -199,23 +221,6 @@ static inline void ast_open_key(struct ast_private *ast)
#define AST_VIDMEM_DEFAULT_SIZE AST_VIDMEM_SIZE_8M
-#define AST_MAX_HWC_WIDTH 64
-#define AST_MAX_HWC_HEIGHT 64
-
-#define AST_HWC_SIZE(AST_MAX_HWC_WIDTH*AST_MAX_HWC_HEIGHT*2)
-#define AST_HWC_SIGNATURE_SIZE 32
-
-#define AST_DEFAULT_HWC_NUM 2
-/* define for signature structure */
-#define AST_HWC_SIGNATURE_CHECKSUM 0x00
-#define AST_HWC_SIGNATURE_SizeX 0x04
-#define AST_HWC_SIGNATURE_SizeY 0x08
-#define AST_HWC_SIGNATURE_X 0x0C
-#define AST_HWC_SIGNATURE_Y 0x10
-#define AST_HWC_SIGNATURE_HOTSPOTX 0x14
-#define AST_HWC_SIGNATURE_HOTSPOTY 0x18
-
-
struct ast_i2c_chan {
struct i2c_adapter adapter;
struct drm_device *dev;
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 6a517ffb1c5c..b13eaa2619ab 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -883,50 +883,53 @@ static int ast_connector_init(struct drm_device *dev)
static int ast_cursor_init(struct drm_device *dev)
{
struct ast_private *ast = dev->dev_private;
- int size;
- int ret;
- struct drm_gem_object *obj;
+ size_t size, i;
struct drm_gem_vram_object *gbo;
- s64 gpu_addr;
- void *base;
+ int ret;
- size = (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE) * AST_DEFAULT_HWC_NUM;
+ size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
- ret = ast_gem_create(dev, size, true, );
- if (ret)
- return ret;
- gbo = drm_gem_vram_of_gem(obj);
- ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
- if (ret)
- goto fail;
- gpu_addr = drm_gem_vram_offset(gbo);
- if (gpu_addr < 0) {
- drm_gem_vram_unpin(gbo);
- ret = (int)gpu_addr;
- goto fail;
- }
+ for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+ gbo = drm_gem_vram_create(dev, >vram_mm->bdev,
+ size, 0, false);
+ if (IS_ERR(gbo)) {
+ ret = PTR_ERR(gbo);
+ goto err_drm_gem_vram_put;
+ }
+ ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
+ DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
+ if (ret) {
+ drm_gem_vram_put(gbo);
+ goto err_drm_gem_vram_put;
+ }
- /* kmap the object */
- base = drm_gem_vram_kmap(gbo, true, NULL);
- if (IS_ERR(base)) {
- ret = PTR_ERR(base);
- goto fail;
+ ast->cursor.gbo[i] = gbo;
}
- ast->cursor_cache = obj;
return 0;
-fail:
+
+err_drm_gem_vram_put:
+ while (i) {
+ --i;
+ gbo = ast->cursor.gbo[i];
+ drm_gem_vram_unpin(gbo);
+ drm_gem_vram_put(gbo);
+ ast->cursor.gbo[i] = NULL;
+ }
return
[PATCH v2 12/12] drm/mgag200: Allocate cursor BOs at high end of video memory
By putting cursor BOs at the high end of the video memory, we can avoid
memory fragmentation. Starting at the low end, contiguous video memory is
available for framebuffers.
The patch also simplifies the buffer swapping and aligns it with the
ast driver. If there are more drivers with similar requirements, the
code could be moved into a shared place.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 94 +---
drivers/gpu/drm/mgag200/mgag200_drv.h| 12 +--
2 files changed, 52 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 7f48abf80a6a..d65ee94d540c 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -121,39 +121,25 @@ static int mgag200_show_cursor(struct mga_device *mdev,
void *src,
unsigned int width, unsigned int height)
{
struct drm_device *dev = mdev->dev;
- struct drm_gem_vram_object *pixels_1 = mdev->cursor.pixels_1;
- struct drm_gem_vram_object *pixels_2 = mdev->cursor.pixels_2;
- struct drm_gem_vram_object *pixels_current =
mdev->cursor.pixels_current;
- struct drm_gem_vram_object *pixels_next;
+ struct drm_gem_vram_object *gbo;
void *dst;
s64 off;
int ret;
- if (!pixels_1 || !pixels_2) {
+ gbo = mdev->cursor.gbo[mdev->cursor.next_index];
+ if (!gbo) {
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
return -ENOTSUPP; /* Didn't allocate space for cursors */
}
-
- if (WARN_ON(pixels_current &&
- pixels_1 != pixels_current &&
- pixels_2 != pixels_current)) {
- return -ENOTSUPP; /* inconsistent state */
- }
-
- if (pixels_current == pixels_1)
- pixels_next = pixels_2;
- else
- pixels_next = pixels_1;
-
- dst = drm_gem_vram_vmap(pixels_next);
+ dst = drm_gem_vram_vmap(gbo);
if (IS_ERR(dst)) {
ret = PTR_ERR(dst);
dev_err(>pdev->dev,
"failed to map cursor updates: %d\n", ret);
return ret;
}
- off = drm_gem_vram_offset(pixels_next);
+ off = drm_gem_vram_offset(gbo);
if (off < 0) {
ret = (int)off;
dev_err(>pdev->dev,
@@ -169,16 +155,15 @@ static int mgag200_show_cursor(struct mga_device *mdev,
void *src,
/* Adjust cursor control register to turn on the cursor */
WREG_DAC(MGA1064_CURSOR_CTL, 4); /* 16-colour palletized cursor mode */
- if (pixels_current)
- drm_gem_vram_unpin(pixels_current);
- mdev->cursor.pixels_current = pixels_next;
+ drm_gem_vram_vunmap(gbo, dst);
- drm_gem_vram_vunmap(pixels_next, dst);
+ ++mdev->cursor.next_index;
+ mdev->cursor.next_index %= ARRAY_SIZE(mdev->cursor.gbo);
return 0;
err_drm_gem_vram_vunmap:
- drm_gem_vram_vunmap(pixels_next, dst);
+ drm_gem_vram_vunmap(gbo, dst);
return ret;
}
@@ -190,9 +175,6 @@ static void mgag200_hide_cursor(struct mga_device *mdev)
{
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
- if (mdev->cursor.pixels_current)
- drm_gem_vram_unpin(mdev->cursor.pixels_current);
- mdev->cursor.pixels_current = NULL;
}
static void mgag200_move_cursor(struct mga_device *mdev, int x, int y)
@@ -216,27 +198,32 @@ static void mgag200_move_cursor(struct mga_device *mdev,
int x, int y)
int mgag200_cursor_init(struct mga_device *mdev)
{
struct drm_device *dev = mdev->dev;
+ size_t ncursors = ARRAY_SIZE(mdev->cursor.gbo);
size_t size;
+ int ret;
+ size_t i;
+ struct drm_gem_vram_object *gbo;
size = roundup(64 * 48, PAGE_SIZE);
- if (size * 2 > mdev->vram_fb_available)
+ if (size * ncursors > mdev->vram_fb_available)
return -ENOMEM;
- /*
-* Make small buffers to store a hardware cursor (double
-* buffered icon updates)
-*/
- mdev->cursor.pixels_1 = drm_gem_vram_create(dev, >vram_mm->bdev,
- size, 0, 0);
- mdev->cursor.pixels_2 = drm_gem_vram_create(dev, >vram_mm->bdev,
- size, 0, 0);
- if (IS_ERR(mdev->cursor.pixels_2) || IS_ERR(mdev->cursor.pixels_1)) {
- mdev->cursor.pixels_1 = NULL;
- mdev->cursor.pixels_2 = NULL;
- dev_warn(>pdev->dev,
- "Could not allocate space for cursors. Not doing
hardware cursors.\n");
+ for (i = 0; i < ncursors; ++i) {
+ gbo = drm_gem_vram_create(dev, >vram_mm->bdev,
+ size, 0, false);
+ if (IS_ERR(gbo)) {
+
[PATCH v2 06/12] drm/mgag200: Rename cursor functions to use mgag200_ prefix
Although the driver source code is fairly inconsistent wrt naming, the
prefix should be mgag200. Rename cursor functions accordingly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 19 ---
drivers/gpu/drm/mgag200/mgag200_drv.h| 6 +++---
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 ++--
3 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 89f61573a497..3df70d86af21 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -13,10 +13,10 @@ static bool warn_transparent = true;
static bool warn_palette = true;
/*
- Hide the cursor off screen. We can't disable the cursor hardware because it
- takes too long to re-activate and causes momentary corruption
-*/
-static void mga_hide_cursor(struct mga_device *mdev)
+ * Hide the cursor off screen. We can't disable the cursor hardware because
+ * it takes too long to re-activate and causes momentary corruption.
+ */
+static void mgag200_hide_cursor(struct mga_device *mdev)
{
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
@@ -25,11 +25,8 @@ static void mga_hide_cursor(struct mga_device *mdev)
mdev->cursor.pixels_current = NULL;
}
-int mga_crtc_cursor_set(struct drm_crtc *crtc,
- struct drm_file *file_priv,
- uint32_t handle,
- uint32_t width,
- uint32_t height)
+int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file *file_priv,
+ uint32_t handle, uint32_t width, uint32_t height)
{
struct drm_device *dev = crtc->dev;
struct mga_device *mdev = (struct mga_device *)dev->dev_private;
@@ -66,7 +63,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
}
if (!handle || !file_priv) {
- mga_hide_cursor(mdev);
+ mgag200_hide_cursor(mdev);
return 0;
}
@@ -224,7 +221,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
return ret;
}
-int mga_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
+int mgag200_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
{
struct mga_device *mdev = (struct mga_device *)crtc->dev->dev_private;
/* Our origin is at (64,64) */
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 37c003ed57c0..5244e3fa4203 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -203,8 +203,8 @@ int mgag200_mm_init(struct mga_device *mdev);
void mgag200_mm_fini(struct mga_device *mdev);
int mgag200_mmap(struct file *filp, struct vm_area_struct *vma);
-int mga_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file *file_priv,
- uint32_t handle, uint32_t
width, uint32_t height);
-int mga_crtc_cursor_move(struct drm_crtc *crtc, int x, int y);
+int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file *file_priv,
+ uint32_t handle, uint32_t width, uint32_t height);
+int mgag200_crtc_cursor_move(struct drm_crtc *crtc, int x, int y);
#endif /* __MGAG200_DRV_H__ */
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 68226556044b..0cf5608c3644 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1413,8 +1413,8 @@ static void mga_crtc_disable(struct drm_crtc *crtc)
/* These provide the minimum set of functions required to handle a CRTC */
static const struct drm_crtc_funcs mga_crtc_funcs = {
- .cursor_set = mga_crtc_cursor_set,
- .cursor_move = mga_crtc_cursor_move,
+ .cursor_set = mgag200_crtc_cursor_set,
+ .cursor_move = mgag200_crtc_cursor_move,
.gamma_set = mga_crtc_gamma_set,
.set_config = drm_crtc_helper_set_config,
.destroy = mga_crtc_destroy,
--
2.23.0
[PATCH v2 10/12] drm/mgag200: Move cursor BO swapping into mgag200_show_cursor()
Selecting the correct BO for the new cursor image is not relevant
outside of mgag200_show_cursor(). Let the function do the work.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 120 +++
1 file changed, 56 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 13daa0ce1c9e..4a5b1aa921e0 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -117,21 +117,69 @@ static void mgag200_cursor_set_base(struct mga_device
*mdev, u64 address)
WREG_DAC(MGA1064_CURSOR_BASE_ADR_HI, addrh);
}
-static int mgag200_show_cursor(struct mga_device *mdev, void *dst, void *src,
- unsigned int width, unsigned int height,
- u64 dst_gpu)
+static int mgag200_show_cursor(struct mga_device *mdev, void *src,
+ unsigned int width, unsigned int height)
{
+ struct drm_device *dev = mdev->dev;
+ struct drm_gem_vram_object *pixels_1 = mdev->cursor.pixels_1;
+ struct drm_gem_vram_object *pixels_2 = mdev->cursor.pixels_2;
+ struct drm_gem_vram_object *pixels_current =
mdev->cursor.pixels_current;
+ struct drm_gem_vram_object *pixels_next;
+ void *dst;
+ s64 off;
int ret;
+ if (!pixels_1 || !pixels_2) {
+ WREG8(MGA_CURPOSXL, 0);
+ WREG8(MGA_CURPOSXH, 0);
+ return -ENOTSUPP; /* Didn't allocate space for cursors */
+ }
+
+ if (WARN_ON(pixels_current &&
+ pixels_1 != pixels_current &&
+ pixels_2 != pixels_current)) {
+ return -ENOTSUPP; /* inconsistent state */
+ }
+
+ if (pixels_current == pixels_1)
+ pixels_next = pixels_2;
+ else
+ pixels_next = pixels_1;
+
+ dst = drm_gem_vram_vmap(pixels_next);
+ if (IS_ERR(dst)) {
+ ret = PTR_ERR(dst);
+ dev_err(>pdev->dev,
+ "failed to map cursor updates: %d\n", ret);
+ return ret;
+ }
+ off = drm_gem_vram_offset(pixels_next);
+ if (off < 0) {
+ ret = (int)off;
+ dev_err(>pdev->dev,
+ "failed to get cursor scanout address: %d\n", ret);
+ goto err_drm_gem_vram_vunmap;
+ }
+
ret = mgag200_cursor_update(mdev, dst, src, width, height);
if (ret)
- return ret;
- mgag200_cursor_set_base(mdev, dst_gpu);
+ goto err_drm_gem_vram_vunmap;
+ mgag200_cursor_set_base(mdev, off);
/* Adjust cursor control register to turn on the cursor */
WREG_DAC(MGA1064_CURSOR_CTL, 4); /* 16-colour palletized cursor mode */
+ if (pixels_current)
+ drm_gem_vram_unpin(pixels_current);
+ mdev->cursor.pixels_current = pixels_next;
+
+ drm_gem_vram_vunmap(pixels_next, dst);
+
return 0;
+
+err_drm_gem_vram_vunmap:
+ drm_gem_vram_vunmap(pixels_next, dst);
+ return ret;
}
/*
@@ -198,28 +246,10 @@ int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
{
struct drm_device *dev = crtc->dev;
struct mga_device *mdev = (struct mga_device *)dev->dev_private;
- struct drm_gem_vram_object *pixels_1 = mdev->cursor.pixels_1;
- struct drm_gem_vram_object *pixels_2 = mdev->cursor.pixels_2;
- struct drm_gem_vram_object *pixels_current =
mdev->cursor.pixels_current;
- struct drm_gem_vram_object *pixels_next;
struct drm_gem_object *obj;
struct drm_gem_vram_object *gbo = NULL;
int ret;
- u8 *src, *dst;
- s64 gpu_addr;
- u64 dst_gpu;
-
- if (!pixels_1 || !pixels_2) {
- WREG8(MGA_CURPOSXL, 0);
- WREG8(MGA_CURPOSXH, 0);
- return -ENOTSUPP; /* Didn't allocate space for cursors */
- }
-
- if (WARN_ON(pixels_current &&
- pixels_1 != pixels_current &&
- pixels_2 != pixels_current)) {
- return -ENOTSUPP; /* inconsistent state */
- }
+ u8 *src;
if (!handle || !file_priv) {
mgag200_hide_cursor(mdev);
@@ -232,11 +262,6 @@ int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
return -EINVAL;
}
- if (pixels_current == pixels_1)
- pixels_next = pixels_2;
- else
- pixels_next = pixels_1;
-
obj = drm_gem_object_lookup(file_priv, handle);
if (!obj)
return -ENOENT;
@@ -249,48 +274,15 @@ int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
goto err_drm_gem_object_put_unlocked;
}
- /* Pin and map up-coming buffer to write colour indices */
- ret =
[PATCH v2 00/12] drm/ast/mgag200: Place cursor BOs at VRAM high-end
(was: drm/vram: Add VRAM buffers for HW cursors) This patchset cleans up the memory management of HW cursors in ast and mgag200. It further moves the allocated cursor BOs to the of the video RAM to reduce memory fragmentation. The ast and mgag200 drivers support HW cursors of uncommon pixel formats. Both drivers manage cursor memory in dedicated GEM VRAM buffer objects with a double buffering scheme; either by alternating between two GEM BOs, or by alternating between offsets within the same GEM BO. The code is convoluted and can lead to memory fragmentation if the BO is stored the middle of VRAM. This is especially a problem on devices with only a small amount of video memory. With this patchset, the cursor handling in ast and mgag200 is first split up into separate functions for copying cursor images, managing buffer objects, setting scanout addresses, and moving and hiding the cursor. Furthermore, each driver dedicates a few KiB at the high end of each device's video memory to storing the cursor's buffer objects. This reduces memory fragmentation, which may prevent displaying the framebuffer on low-memory devices. The patchset has been tested on ast and mgag200 hardware. v2: * remove VRAM buffers in favor of GEM BOs * manage BO placement with pin flag Thomas Zimmermann (12): drm/vram: Support top-down placement flag drm/ast: Don't call ast_show_cursor() from ast_cursor_move() drm/ast: Move cursor update code to ast_show_cursor() drm/ast: Move cursor offset swapping into ast_show_cursor() drm/ast: Allocate cursor BOs at high end of video memory drm/mgag200: Rename cursor functions to use mgag200_ prefix drm/mgag200: Add init and fini functions for cursor handling drm/mgag200: Add separate move-cursor function drm/mgag200: Move cursor-image update to mgag200_show_cursor() drm/mgag200: Move cursor BO swapping into mgag200_show_cursor() drm/mgag200: Reserve video memory for cursor plane drm/mgag200: Allocate cursor BOs at high end of video memory drivers/gpu/drm/ast/ast_drv.h| 43 +-- drivers/gpu/drm/ast/ast_mode.c | 235 + drivers/gpu/drm/drm_gem_vram_helper.c| 14 +- drivers/gpu/drm/mgag200/mgag200_cursor.c | 316 ++- drivers/gpu/drm/mgag200/mgag200_drv.h| 22 +- drivers/gpu/drm/mgag200/mgag200_main.c | 20 +- drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +- drivers/gpu/drm/mgag200/mgag200_ttm.c| 4 + include/drm/drm_gem_vram_helper.h| 1 + 9 files changed, 387 insertions(+), 274 deletions(-) -- 2.23.0
[PATCH v2 08/12] drm/mgag200: Add separate move-cursor function
Adding mgag200_move_cursor() makes the cursor code more consistent and
will become handy when we move to universal cursor planes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 29
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index d39e2bc57a70..621960723a3a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -25,6 +25,24 @@ static void mgag200_hide_cursor(struct mga_device *mdev)
mdev->cursor.pixels_current = NULL;
}
+static void mgag200_move_cursor(struct mga_device *mdev, int x, int y)
+{
+ if (WARN_ON(x <= 0))
+ return;
+ if (WARN_ON(y <= 0))
+ return;
+ if (WARN_ON(x & ~0x))
+ return;
+ if (WARN_ON(y & ~0x))
+ return;
+
+ WREG8(MGA_CURPOSXL, x & 0xff);
+ WREG8(MGA_CURPOSXH, (x>>8) & 0xff);
+
+ WREG8(MGA_CURPOSYL, y & 0xff);
+ WREG8(MGA_CURPOSYH, (y>>8) & 0xff);
+}
+
int mgag200_cursor_init(struct mga_device *mdev)
{
struct drm_device *dev = mdev->dev;
@@ -252,19 +270,12 @@ int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
int mgag200_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
{
struct mga_device *mdev = (struct mga_device *)crtc->dev->dev_private;
+
/* Our origin is at (64,64) */
x += 64;
y += 64;
- BUG_ON(x <= 0);
- BUG_ON(y <= 0);
- BUG_ON(x & ~0x);
- BUG_ON(y & ~0x);
+ mgag200_move_cursor(mdev, x, y);
- WREG8(MGA_CURPOSXL, x & 0xff);
- WREG8(MGA_CURPOSXH, (x>>8) & 0xff);
-
- WREG8(MGA_CURPOSYL, y & 0xff);
- WREG8(MGA_CURPOSYH, (y>>8) & 0xff);
return 0;
}
--
2.23.0
[PATCH v2 11/12] drm/mgag200: Reserve video memory for cursor plane
The double-buffered cursor image is currently stored in video memory
by creating two BOs and pinning them to VRAM. The exact location is
chosen by VRAM helpers. The pinned cursor BOs can conflict with
framebuffer BOs and prevent the primary plane from displaying its
framebuffer.
As a first step to solving this problem, we reserve dedicated space at
the high end of the video memory for the cursor images. As the amount
of video memory now differs from the amount of available framebuffer
memory, size tests are adapted accordingly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 19 +++
drivers/gpu/drm/mgag200/mgag200_drv.h| 2 ++
drivers/gpu/drm/mgag200/mgag200_main.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c| 4
5 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 4a5b1aa921e0..7f48abf80a6a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -216,17 +216,20 @@ static void mgag200_move_cursor(struct mga_device *mdev,
int x, int y)
int mgag200_cursor_init(struct mga_device *mdev)
{
struct drm_device *dev = mdev->dev;
+ size_t size;
+
+ size = roundup(64 * 48, PAGE_SIZE);
+ if (size * 2 > mdev->vram_fb_available)
+ return -ENOMEM;
/*
* Make small buffers to store a hardware cursor (double
* buffered icon updates)
*/
mdev->cursor.pixels_1 = drm_gem_vram_create(dev, >vram_mm->bdev,
- roundup(48*64, PAGE_SIZE),
- 0, 0);
+ size, 0, 0);
mdev->cursor.pixels_2 = drm_gem_vram_create(dev, >vram_mm->bdev,
- roundup(48*64, PAGE_SIZE),
- 0, 0);
+ size, 0, 0);
if (IS_ERR(mdev->cursor.pixels_2) || IS_ERR(mdev->cursor.pixels_1)) {
mdev->cursor.pixels_1 = NULL;
mdev->cursor.pixels_2 = NULL;
@@ -235,6 +238,14 @@ int mgag200_cursor_init(struct mga_device *mdev)
}
mdev->cursor.pixels_current = NULL;
+ /*
+* At the high end of video memory, we reserve space for
+* buffer objects. The cursor plane uses this memory to store
+* a double-buffered image of the current cursor. Hence, it's
+* not available for framebuffers.
+*/
+ mdev->vram_fb_available -= 2 * size;
+
return 0;
}
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 01243fa6397c..5d6cfc88697a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -173,6 +173,8 @@ struct mga_device {
struct mga_cursor cursor;
+ size_t vram_fb_available;
+
boolsuspended;
int num_crtc;
enum mga_type type;
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 2b59280777a5..5f74aabcd3df 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -159,7 +159,7 @@ int mgag200_driver_load(struct drm_device *dev, unsigned
long flags)
drm_mode_config_init(dev);
dev->mode_config.funcs = (void *)_mode_funcs;
- if (IS_G200_SE(mdev) && mdev->mc.vram_size < (2048*1024))
+ if (IS_G200_SE(mdev) && mdev->vram_fb_available < (2048*1024))
dev->mode_config.preferred_depth = 16;
else
dev->mode_config.preferred_depth = 32;
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 0cf5608c3644..5ec697148fc1 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1629,7 +1629,7 @@ static enum drm_mode_status mga_vga_mode_valid(struct
drm_connector *connector,
bpp = connector->cmdline_mode.bpp;
}
- if ((mode->hdisplay * mode->vdisplay * (bpp/8)) > mdev->mc.vram_size) {
+ if ((mode->hdisplay * mode->vdisplay * (bpp/8)) >
mdev->vram_fb_available) {
if (connector->cmdline_mode.specified)
connector->cmdline_mode.specified = false;
return MODE_BAD;
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 69c81ebf3745..7d737362 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -50,6 +50,8 @@ int mgag200_mm_init(struct mga_device *mdev)
mdev->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev,
[PATCH v2 04/12] drm/ast: Move cursor offset swapping into ast_show_cursor()
Selecting the correct offset for the new cursor image is not relevant
outside of ast_show_cursor(). Let the function do the work.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 57 ++
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 1294f0612fd5..6a517ffb1c5c 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1150,23 +1150,34 @@ static void ast_cursor_set_base(struct ast_private
*ast, u64 address)
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xca, addr2);
}
-static int ast_show_cursor(struct drm_crtc *crtc, void *dst, void *src,
- unsigned int width, unsigned int height,
- u64 dst_gpu)
+static int ast_show_cursor(struct drm_crtc *crtc, void *src,
+ unsigned int width, unsigned int height)
{
struct ast_private *ast = crtc->dev->dev_private;
struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
+ struct drm_gem_vram_object *gbo;
+ u8 *dst, *dst_next;
+ s64 off;
int ret;
u8 jreg;
- dst += (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE)*ast->next_cursor;
+ gbo = drm_gem_vram_of_gem(ast->cursor_cache);
+ dst = drm_gem_vram_vmap(gbo);
+ if (IS_ERR(dst))
+ return PTR_ERR(dst);
+ off = drm_gem_vram_offset(gbo);
+ if (off < 0) {
+ ret = (int)off;
+ goto err_drm_gem_vram_vunmap;
+ }
- ret = ast_cursor_update(dst, src, width, height);
- if (ret)
- return ret;
- ast_cursor_set_base(ast, dst_gpu);
+ dst_next = dst + (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE) *
+ ast->next_cursor;
- ast->next_cursor = (ast->next_cursor + 1) % AST_DEFAULT_HWC_NUM;
+ ret = ast_cursor_update(dst_next, src, width, height);
+ if (ret)
+ goto err_drm_gem_vram_vunmap;
+ ast_cursor_set_base(ast, off);
ast_crtc->offset_x = AST_MAX_HWC_WIDTH - width;
ast_crtc->offset_y = AST_MAX_HWC_WIDTH - height;
@@ -1176,7 +1187,15 @@ static int ast_show_cursor(struct drm_crtc *crtc, void
*dst, void *src,
jreg |= 1;
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, jreg);
+ ast->next_cursor = (ast->next_cursor + 1) % AST_DEFAULT_HWC_NUM;
+
+ drm_gem_vram_vunmap(gbo, dst);
+
return 0;
+
+err_drm_gem_vram_vunmap:
+ drm_gem_vram_vunmap(gbo, dst);
+ return ret;
}
static void ast_hide_cursor(struct drm_crtc *crtc)
@@ -1192,12 +1211,10 @@ static int ast_cursor_set(struct drm_crtc *crtc,
uint32_t width,
uint32_t height)
{
- struct ast_private *ast = crtc->dev->dev_private;
struct drm_gem_object *obj;
struct drm_gem_vram_object *gbo;
- s64 dst_gpu;
+ u8 *src;
int ret;
- u8 *src, *dst;
if (!handle) {
ast_hide_cursor(crtc);
@@ -1219,21 +1236,9 @@ static int ast_cursor_set(struct drm_crtc *crtc,
goto err_drm_gem_object_put_unlocked;
}
- dst = drm_gem_vram_kmap(drm_gem_vram_of_gem(ast->cursor_cache),
- false, NULL);
- if (IS_ERR(dst)) {
- ret = PTR_ERR(dst);
- goto err_drm_gem_vram_vunmap;
- }
- dst_gpu = drm_gem_vram_offset(drm_gem_vram_of_gem(ast->cursor_cache));
- if (dst_gpu < 0) {
- ret = (int)dst_gpu;
- goto err_drm_gem_vram_vunmap;
- }
-
- ret = ast_show_cursor(crtc, dst, src, width, height, dst_gpu);
+ ret = ast_show_cursor(crtc, src, width, height);
if (ret)
- goto err_drm_gem_vram_kunmap;
+ goto err_drm_gem_vram_vunmap;
drm_gem_vram_vunmap(gbo, src);
drm_gem_object_put_unlocked(obj);
--
2.23.0
[PATCH v2 01/12] drm/vram: Support top-down placement flag
Pinning lots of small buffer objects, such as cursors or sprites, to video
memory can lead to fragmentation, which is a problem for devices with only
a small amount of memory. As a result, framebuffer images might not get
pinned, even though there's enough space available overall.
The flag DRM_GEM_VRAM_PL_FLAG_TOPDOWN marks buffer objects to be pinned at
the high end of video memory. This leaves contiguous space available at
the memory's low end.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 14 ++
include/drm/drm_gem_vram_helper.h | 1 +
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 49588de88959..91baf3f279f1 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -58,6 +58,7 @@ static void drm_gem_vram_placement(struct drm_gem_vram_object
*gbo,
{
unsigned int i;
unsigned int c = 0;
+ u32 invariant_flags = pl_flag & TTM_PL_FLAG_TOPDOWN;
gbo->placement.placement = gbo->placements;
gbo->placement.busy_placement = gbo->placements;
@@ -65,15 +66,18 @@ static void drm_gem_vram_placement(struct
drm_gem_vram_object *gbo,
if (pl_flag & TTM_PL_FLAG_VRAM)
gbo->placements[c++].flags = TTM_PL_FLAG_WC |
TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_VRAM;
+TTM_PL_FLAG_VRAM |
+invariant_flags;
if (pl_flag & TTM_PL_FLAG_SYSTEM)
gbo->placements[c++].flags = TTM_PL_MASK_CACHING |
-TTM_PL_FLAG_SYSTEM;
+TTM_PL_FLAG_SYSTEM |
+invariant_flags;
if (!c)
gbo->placements[c++].flags = TTM_PL_MASK_CACHING |
-TTM_PL_FLAG_SYSTEM;
+TTM_PL_FLAG_SYSTEM |
+invariant_flags;
gbo->placement.num_placement = c;
gbo->placement.num_busy_placement = c;
@@ -236,7 +240,9 @@ static int drm_gem_vram_pin_locked(struct
drm_gem_vram_object *gbo,
* a memory region. A pinned buffer object has to be unpinned before
* it can be pinned to another region. If the pl_flag argument is 0,
* the buffer is pinned at its current location (video RAM or system
- * memory).
+ * memory). The modifier DRM_GEM_VRAM_PL_FLAG_TOPDOWN marks the buffer
+ * object to be pinned at the high end of the memory region. Set this
+ * flag to avoid memory fragmentation.
*
* Returns:
* 0 on success, or
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 418eb1122861..354a9cd358a3 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
#define DRM_GEM_VRAM_PL_FLAG_VRAM TTM_PL_FLAG_VRAM
#define DRM_GEM_VRAM_PL_FLAG_SYSTEMTTM_PL_FLAG_SYSTEM
+#define DRM_GEM_VRAM_PL_FLAG_TOPDOWN TTM_PL_FLAG_TOPDOWN
/*
* Buffer-object helpers
--
2.23.0
[PATCH v2 09/12] drm/mgag200: Move cursor-image update to mgag200_show_cursor()
Separating the management of buffer objects from updating the hardware
cursor buffer gives the code more structure. While doing this, we can
further split the image-update code into code for writing the buffer,
setting the base scan-out address, and enabling the cursor. The first
two operations are in dedicated functions update() and set_base().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 221 +--
1 file changed, 126 insertions(+), 95 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 621960723a3a..13daa0ce1c9e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -12,6 +12,128 @@
static bool warn_transparent = true;
static bool warn_palette = true;
+static int mgag200_cursor_update(struct mga_device *mdev, void *dst, void *src,
+unsigned int width, unsigned int height)
+{
+ struct drm_device *dev = mdev->dev;
+ unsigned int i, row, col;
+ uint32_t colour_set[16];
+ uint32_t *next_space = _set[0];
+ uint32_t *palette_iter;
+ uint32_t this_colour;
+ bool found = false;
+ int colour_count = 0;
+ u8 reg_index;
+ u8 this_row[48];
+
+ memset(_set[0], 0, sizeof(uint32_t)*16);
+ /* width*height*4 = 16384 */
+ for (i = 0; i < 16384; i += 4) {
+ this_colour = ioread32(src + i);
+ /* No transparency */
+ if (this_colour>>24 != 0xff &&
+ this_colour>>24 != 0x0) {
+ if (warn_transparent) {
+ dev_info(>pdev->dev, "Video card doesn't
support cursors with partial transparency.\n");
+ dev_info(>pdev->dev, "Not enabling
hardware cursor.\n");
+ warn_transparent = false; /* Only tell the user
once. */
+ }
+ return -EINVAL;
+ }
+ /* Don't need to store transparent pixels as colours */
+ if (this_colour>>24 == 0x0)
+ continue;
+ found = false;
+ for (palette_iter = _set[0]; palette_iter != next_space;
palette_iter++) {
+ if (*palette_iter == this_colour) {
+ found = true;
+ break;
+ }
+ }
+ if (found)
+ continue;
+ /* We only support 4bit paletted cursors */
+ if (colour_count >= 16) {
+ if (warn_palette) {
+ dev_info(>pdev->dev, "Video card only
supports cursors with up to 16 colours.\n");
+ dev_info(>pdev->dev, "Not enabling
hardware cursor.\n");
+ warn_palette = false; /* Only tell the user
once. */
+ }
+ return -EINVAL;
+ }
+ *next_space = this_colour;
+ next_space++;
+ colour_count++;
+ }
+
+ /* Program colours from cursor icon into palette */
+ for (i = 0; i < colour_count; i++) {
+ if (i <= 2)
+ reg_index = 0x8 + i*0x4;
+ else
+ reg_index = 0x60 + i*0x3;
+ WREG_DAC(reg_index, colour_set[i] & 0xff);
+ WREG_DAC(reg_index+1, colour_set[i]>>8 & 0xff);
+ WREG_DAC(reg_index+2, colour_set[i]>>16 & 0xff);
+ if (WARN_ON((colour_set[i]>>24 & 0xff) != 0xff))
+ return -EINVAL;
+ }
+
+ /* now write colour indices into hardware cursor buffer */
+ for (row = 0; row < 64; row++) {
+ memset(_row[0], 0, 48);
+ for (col = 0; col < 64; col++) {
+ this_colour = ioread32(src + 4*(col + 64*row));
+ /* write transparent pixels */
+ if (this_colour>>24 == 0x0) {
+ this_row[47 - col/8] |= 0x80>>(col%8);
+ continue;
+ }
+
+ /* write colour index here */
+ for (i = 0; i < colour_count; i++) {
+ if (colour_set[i] == this_colour) {
+ if (col % 2)
+ this_row[col/2] |= i<<4;
+ else
+ this_row[col/2] |= i;
+ break;
+ }
+ }
+ }
+ memcpy_toio(dst + row*48, _row[0], 48);
+ }
+
+ return 0;
+}
+
+static void mgag200_cursor_set_base(struct mga_device
[Bug 111789] drm/etnaviv: command buffer outside valid memory window (on cubox i4), Linux 5.3
https://bugs.freedesktop.org/show_bug.cgi?id=111789 Bug ID: 111789 Summary: drm/etnaviv: command buffer outside valid memory window (on cubox i4), Linux 5.3 Product: DRI Version: unspecified Hardware: ARM OS: Linux (All) Status: NEW Severity: not set Priority: not set Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: rech...@vlado-do.de Created attachment 145475 --> https://bugs.freedesktop.org/attachment.cgi?id=145475=edit dmesg from kernel 5.3, loading firmware I'm trying to get somewhat accelerated video output out of my CuBox i4 (imx6 cpu, GC2000 graphics), but I don't have any luck with kernels 5.0, 5.2, or 5.3. I tried recent Armbian and Fedora (30 and 31 beta). The etnaviv messages from dmesg are: [ 18.891291] etnaviv etnaviv: bound 13.gpu (ops gpu_ops [etnaviv]) [ 18.895022] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops [etnaviv]) [ 18.898366] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops [etnaviv]) [ 18.898385] etnaviv-gpu 13.gpu: model: GC2000, revision: 5108 [ 18.929873] etnaviv-gpu 13.gpu: command buffer outside valid memory window [ 18.931182] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 [ 19.075240] etnaviv-gpu 134000.gpu: command buffer outside valid memory window [ 19.076522] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 [ 19.076542] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 [ 19.083510] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on minor 1 I'll attach the complete dmesg - or you can see it here: http://ix.io/1WAW Google brought me to Russell King's similar problem from June: https://lists.freedesktop.org/archives/dri-devel/2019-June/224474.html I don't know why the problem disappeared for him, though. Initially I reported the problem at the armbian forum: https://forum.armbian.com/topic/11539-no-hdmi-with-linux-image-dev-cubox-kernel-5211/ I'm more of a user than a developer, especially when it comes to the Linux kernel. But I can test switches or patches. Any help would be appreciated! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111761] Latest Git Kernel doesn’t boot with Radeon NI with the drm-next-2019-09-18 updates
https://bugs.freedesktop.org/show_bug.cgi?id=111761 --- Comment #2 from Christian Zigotzky --- The changes of the following files are responsible for the boot issue. - drivers/gpu/drm/drm_* - include/drm/* The kernel doesn't boot with the updates in the files above from the drm-next-2019-09-18 so I can't attach the output of dmesg and the Xorg log file. Which of the files in - drivers/gpu/drm/drm_* - include/drm/* are responsible at the beginning of the kernel boot? Is there a patch in the dri git for the files above? I can bisect but actually I need only to know which of the files above are responsible at the beginning of the kernel boot. Could someone please test the latest Git kernel with a Radeon HD NI graphics card? Thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111792] [AMD tahiti xt] amd-staging-drm-next broken since linux 5.3.0-rc3 rebase
https://bugs.freedesktop.org/show_bug.cgi?id=111792 --- Comment #1 from Sylvain BERTRAND --- Created attachment 145480 --> https://bugs.freedesktop.org/attachment.cgi?id=145480=edit dmesg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111792] [AMD tahiti xt] amd-staging-drm-next broken since linux 5.3.0-rc3 rebase
https://bugs.freedesktop.org/show_bug.cgi?id=111792 Bug ID: 111792 Summary: [AMD tahiti xt] amd-staging-drm-next broken since linux 5.3.0-rc3 rebase Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: highest Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: sylvain.bertr...@gmail.com got the rebased amd-staging-drm-next branch today, configured and compiled linux, xorg hangs while probing card0. See provided logs. yes, I can bisect. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 5/5] kselftests: Add dma-heap test
Hi John,
I didn't see any response about using the test harness. Did you decide
against it?
On Fri, Sep 06, 2019 at 06:47:12PM +, John Stultz wrote:
> Add very trivial allocation and import test for dma-heaps,
> utilizing the vgem driver as a test importer.
>
> A good chunk of this code taken from:
> tools/testing/selftests/android/ion/ionmap_test.c
> Originally by Laura Abbott
>
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard
> Signed-off-by: John Stultz
> ---
> v2:
> * Switched to use reworked dma-heap apis
> v3:
> * Add simple mmap
> * Utilize dma-buf testdev to test importing
> v4:
> * Rework to use vgem
> * Pass in fd_flags to match interface changes
> * Skip . and .. dirs
> v6:
> * Number of style/cleanups suggested by Brian
> v7:
> * Whitespace fixup for checkpatch
> v8:
> * More checkpatch whitespace fixups
> ---
> tools/testing/selftests/dmabuf-heaps/Makefile | 9 +
> .../selftests/dmabuf-heaps/dmabuf-heap.c | 230 ++
> 2 files changed, 239 insertions(+)
> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
>
> diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
> b/tools/testing/selftests/dmabuf-heaps/Makefile
> new file mode 100644
> index ..8c4c36e2972d
> --- /dev/null
> +++ b/tools/testing/selftests/dmabuf-heaps/Makefile
> @@ -0,0 +1,9 @@
> +# SPDX-License-Identifier: GPL-2.0
> +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall
> +#LDLIBS += -lrt -lpthread -lm
> +
> +# these are all "safe" tests that don't modify
> +# system time or require escalated privileges
> +TEST_GEN_PROGS = dmabuf-heap
> +
> +include ../lib.mk
> diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> new file mode 100644
> index ..e439d6cf3d81
> --- /dev/null
> +++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
> @@ -0,0 +1,230 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "../../../../include/uapi/linux/dma-heap.h"
> +
> +#define DEVPATH "/dev/dma_heap"
> +
> +static int check_vgem(int fd)
> +{
> + drm_version_t version = { 0 };
> + char name[5];
> + int ret;
> +
> + version.name_len = 4;
> + version.name = name;
> +
> + ret = ioctl(fd, DRM_IOCTL_VERSION, );
> + if (ret)
> + return 0;
> +
> + return !strcmp(name, "vgem");
> +}
> +
> +static int open_vgem(void)
> +{
> + int i, fd;
> + const char *drmstr = "/dev/dri/card";
> +
> + fd = -1;
> + for (i = 0; i < 16; i++) {
> + char name[80];
> +
> + sprintf(name, "%s%u", drmstr, i);
> +
> + fd = open(name, O_RDWR);
> + if (fd < 0)
> + continue;
> +
> + if (!check_vgem(fd)) {
> + close(fd);
I didn't spot this last time, but there's an (unlikely) error scenario
here if there's >= 16 DRM devices and none of them are vgem, then
you'll return a stale fd.
> + continue;
> + } else {
> + break;
> + }
> + }
> + return fd;
> +}
> +
> +static int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
> +{
> + struct drm_prime_handle import_handle = {
> + .fd = dma_buf_fd,
> + .flags = 0,
> + .handle = 0,
> + };
> + int ret;
> +
> + ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
> + if (ret == 0)
> + *handle = import_handle.handle;
> + return ret;
> +}
> +
> +static void close_handle(int vgem_fd, uint32_t handle)
> +{
> + struct drm_gem_close close = {
> + .handle = handle,
> + };
> +
> + ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
> +}
> +
> +static int dmabuf_heap_open(char *name)
> +{
> + int ret, fd;
> + char buf[256];
> +
> + ret = sprintf(buf, "%s/%s", DEVPATH, name);
snprintf(), just because why not?
> + if (ret < 0) {
> + printf("sprintf failed!\n");
> + return ret;
> + }
> +
> + fd = open(buf, O_RDWR);
> + if (fd < 0)
> + printf("open %s failed!\n", buf);
> + return fd;
> +}
> +
> +static int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags,
> + int *dmabuf_fd)
> +{
> + struct dma_heap_allocation_data data = {
> + .len = len,
> + .fd_flags = O_RDWR | O_CLOEXEC,
> + .heap_flags = flags,
> + };
> +
RE: [PATCH 1/6] mdev: class id support
Hi Jason,
> -Original Message-
> From: Jason Wang
> Sent: Monday, September 23, 2019 8:03 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh...@nvidia.com; alex.william...@redhat.com; m...@redhat.com;
> tiwei@intel.com
> Cc: virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
> coh...@redhat.com; maxime.coque...@redhat.com;
> cunming.li...@intel.com; zhihong.w...@intel.com;
> rob.mil...@broadcom.com; xiao.w.w...@intel.com;
> haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
> far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
> ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
> borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
> lingshan@intel.com; Ido Shamay ;
> epere...@redhat.com; l...@redhat.com; Parav Pandit
> ; Jason Wang
> Subject: [PATCH 1/6] mdev: class id support
>
> Mdev bus only supports vfio driver right now, so it doesn't implement match
> method. But in the future, we may add drivers other than vfio, one example is
> virtio-mdev[1] driver. This means we need to add device class id support in
> bus
> match method to pair the mdev device and mdev driver correctly.
>
> So this patch adds id_table to mdev_driver and class_id for mdev parent with
> the match method for mdev bus.
>
> Signed-off-by: Jason Wang
> ---
> Documentation/driver-api/vfio-mediated-device.rst | 7 +--
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
> drivers/s390/cio/vfio_ccw_ops.c | 2 +-
> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
> drivers/vfio/mdev/mdev_core.c | 14 --
> drivers/vfio/mdev/mdev_driver.c | 14 ++
> drivers/vfio/mdev/mdev_private.h | 1 +
> drivers/vfio/mdev/vfio_mdev.c | 6 ++
> include/linux/mdev.h | 7 ++-
> include/linux/mod_devicetable.h | 8
> samples/vfio-mdev/mbochs.c| 2 +-
> samples/vfio-mdev/mdpy.c | 2 +-
> samples/vfio-mdev/mtty.c | 2 +-
> 13 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 25eb7d5b834b..0e052072e1d8 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
>* @probe: called when new device created
>* @remove: called when device removed
>* @driver: device driver structure
> + * @id_table: the ids serviced by this driver.
No full stop at the end.
>*/
> struct mdev_driver {
>const char *name;
>int (*probe) (struct device *dev);
>void (*remove) (struct device *dev);
>struct device_driverdriver;
> + const struct mdev_class_id *id_table;
> };
>
> A mediated bus driver for mdev should use this structure in the function
> calls
> @@ -116,7 +118,7 @@ to register and unregister itself with the core driver:
> * Register::
>
> extern int mdev_register_driver(struct mdev_driver *drv,
> -struct module *owner);
> + struct module *owner);
>
Unrelated change in this patch.
> * Unregister::
>
> @@ -163,7 +165,8 @@ A driver should use the mdev_parent_ops structure in
> the function call to register itself with the mdev core driver::
>
> extern int mdev_register_device(struct device *dev,
> - const struct mdev_parent_ops *ops);
> + const struct mdev_parent_ops *ops,
> + u8 class_id);
>
Cover letter from Change-V2 says that it class_id changed from " use u16
instead u8 for class id"
But it is still u8 here?
> However, the mdev_parent_ops structure is not required in the function call
> that a driver should use to unregister itself with the mdev core driver::
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 23aa3e50cbf8..19d51a35f019 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1625,7 +1625,7 @@ static int kvmgt_host_init(struct device *dev, void
> *gvt, const void *ops)
> return -EFAULT;
> intel_vgpu_ops.supported_type_groups = kvm_vgpu_type_groups;
>
> - return mdev_register_device(dev, _vgpu_ops);
> + return
[Bug 111792] [AMD tahiti xt] amd-staging-drm-next broken since linux 5.3.0-rc3 rebase
https://bugs.freedesktop.org/show_bug.cgi?id=111792 --- Comment #2 from Sylvain BERTRAND --- Created attachment 145481 --> https://bugs.freedesktop.org/attachment.cgi?id=145481=edit xorg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 15/19] Documentation: kunit: add documentation for KUnit
On 9/23/19 2:18 PM, shuah wrote: > I would like to apply the series very soon so it gets some soak time > after this move in linux-next and it can still make the rc1. > > Since there changes can be addressed after rc1, I would like to not > require Brendan to do another version before I apply. > > Hope you are okay with that Randy! > > thanks, > -- Shuah Sure, no problem, go for it . -- ~Randy
RE: [PATCH 4/6] virtio: introduce a mdev based transport
> -Original Message-
> From: Jason Wang
> Sent: Monday, September 23, 2019 8:03 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh...@nvidia.com; alex.william...@redhat.com; m...@redhat.com;
> tiwei@intel.com
> Cc: virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
> coh...@redhat.com; maxime.coque...@redhat.com;
> cunming.li...@intel.com; zhihong.w...@intel.com;
> rob.mil...@broadcom.com; xiao.w.w...@intel.com;
> haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
> far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
> ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
> borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
> lingshan@intel.com; Ido Shamay ;
> epere...@redhat.com; l...@redhat.com; Parav Pandit
> ; Jason Wang
> Subject: [PATCH 4/6] virtio: introduce a mdev based transport
>
> This patch introduces a new mdev transport for virtio. This is used to use
> kernel
> virtio driver to drive the mediated device that is capable of populating
> virtqueue directly.
>
> A new virtio-mdev driver will be registered to the mdev bus, when a new
> virtio-
> mdev device is probed, it will register the device with mdev based config ops.
> This means it is a software transport between mdev driver and mdev device.
> The transport was implemented through device specific opswhich is a part of
> mdev_parent_ops now.
>
> Signed-off-by: Jason Wang
> ---
> MAINTAINERS | 1 +
> drivers/vfio/mdev/Kconfig | 7 +
> drivers/vfio/mdev/Makefile | 1 +
> drivers/vfio/mdev/virtio_mdev.c | 416
> 4 files changed, 425 insertions(+)
> create mode 100644 drivers/vfio/mdev/virtio_mdev.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 89832b316500..820ec250cc52 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17202,6 +17202,7 @@ F:include/linux/virtio*.h
> F: include/uapi/linux/virtio_*.h
> F: drivers/crypto/virtio/
> F: mm/balloon_compaction.c
> +F: drivers/vfio/mdev/virtio_mdev.c
>
> VIRTIO BLOCK AND SCSI DRIVERS
> M: "Michael S. Tsirkin"
> diff --git a/drivers/vfio/mdev/Kconfig b/drivers/vfio/mdev/Kconfig index
> 5da27f2100f9..c488c31fc137 100644
> --- a/drivers/vfio/mdev/Kconfig
> +++ b/drivers/vfio/mdev/Kconfig
> @@ -16,3 +16,10 @@ config VFIO_MDEV_DEVICE
> default n
> help
> VFIO based driver for Mediated devices.
> +
> +config VIRTIO_MDEV_DEVICE
> + tristate "VIRTIO driver for Mediated devices"
> + depends on VFIO_MDEV && VIRTIO
> + default n
> + help
> + VIRTIO based driver for Mediated devices.
> diff --git a/drivers/vfio/mdev/Makefile b/drivers/vfio/mdev/Makefile index
> 101516fdf375..99d31e29c23e 100644
> --- a/drivers/vfio/mdev/Makefile
> +++ b/drivers/vfio/mdev/Makefile
> @@ -4,3 +4,4 @@ mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o
>
> obj-$(CONFIG_VFIO_MDEV) += mdev.o
> obj-$(CONFIG_VFIO_MDEV_DEVICE) += vfio_mdev.o
> +obj-$(CONFIG_VIRTIO_MDEV_DEVICE) += virtio_mdev.o
> diff --git a/drivers/vfio/mdev/virtio_mdev.c b/drivers/vfio/mdev/virtio_mdev.c
> new file mode 100644 index ..919a082adc9c
> --- /dev/null
> +++ b/drivers/vfio/mdev/virtio_mdev.c
> @@ -0,0 +1,416 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * VIRTIO based driver for Mediated device
> + *
> + * Copyright (c) 2019, Red Hat. All rights reserved.
> + * Author: Jason Wang
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "mdev_private.h"
> +
> +#define DRIVER_VERSION "0.1"
> +#define DRIVER_AUTHOR "Red Hat Corporation"
> +#define DRIVER_DESC "VIRTIO based driver for Mediated device"
> +
> +#define to_virtio_mdev_device(dev) \
> + container_of(dev, struct virtio_mdev_device, vdev)
> +
> +struct virtio_mdev_device {
> + struct virtio_device vdev;
> + struct mdev_device *mdev;
> + unsigned long version;
> +
> + struct virtqueue **vqs;
Every lock must need a comment to describe what it locks.
I don't see this lock is used in this patch. Please introduce in the patch that
uses it.
> + spinlock_t lock;
> +};
> +
> +struct virtio_mdev_vq_info {
> + /* the actual virtqueue */
> + struct virtqueue *vq;
> +
> + /* the list node for the virtqueues list */
> + struct list_head node;
> +};
> +
> +static struct mdev_device *vm_get_mdev(struct virtio_device *vdev) {
> + struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
> + struct mdev_device *mdev = vm_dev->mdev;
> +
> + return mdev;
> +}
> +
> +static const struct
RE: [PATCH 1/6] mdev: class id support
Hi Jason, > -Original Message- > From: Jason Wang > Sent: Monday, September 23, 2019 8:03 AM > To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; intel- > g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; > kwankh...@nvidia.com; alex.william...@redhat.com; m...@redhat.com; > tiwei@intel.com > Cc: virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org; > coh...@redhat.com; maxime.coque...@redhat.com; > cunming.li...@intel.com; zhihong.w...@intel.com; > rob.mil...@broadcom.com; xiao.w.w...@intel.com; > haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com; > jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; > rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch; > far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com; > ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com; > borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com; > lingshan@intel.com; Ido Shamay ; > epere...@redhat.com; l...@redhat.com; Parav Pandit > ; Jason Wang > Subject: [PATCH 1/6] mdev: class id support > > Mdev bus only supports vfio driver right now, so it doesn't implement match > method. But in the future, we may add drivers other than vfio, one example is > virtio-mdev[1] driver. This means we need to add device class id support in > bus > match method to pair the mdev device and mdev driver correctly. > > So this patch adds id_table to mdev_driver and class_id for mdev parent with > the match method for mdev bus. > > Signed-off-by: Jason Wang > --- > Documentation/driver-api/vfio-mediated-device.rst | 7 +-- > drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- > drivers/s390/cio/vfio_ccw_ops.c | 2 +- > drivers/s390/crypto/vfio_ap_ops.c | 3 ++- > drivers/vfio/mdev/mdev_core.c | 14 -- > drivers/vfio/mdev/mdev_driver.c | 14 ++ > drivers/vfio/mdev/mdev_private.h | 1 + > drivers/vfio/mdev/vfio_mdev.c | 6 ++ > include/linux/mdev.h | 7 ++- > include/linux/mod_devicetable.h | 8 > samples/vfio-mdev/mbochs.c| 2 +- > samples/vfio-mdev/mdpy.c | 2 +- > samples/vfio-mdev/mtty.c | 2 +- > 13 files changed, 59 insertions(+), 11 deletions(-) > You additionally need modpost support for id table integration to modifo, modprobe and other tools. A small patch similar to this one [1] is needed. Please include in the series. [1] https://lore.kernel.org/patchwork/patch/1046991/
Re: [PATCH v18 15/19] Documentation: kunit: add documentation for KUnit
On 9/23/19 1:49 PM, Randy Dunlap wrote: On 9/23/19 11:06 AM, Brendan Higgins wrote: On Mon, Sep 23, 2019 at 8:48 AM Randy Dunlap wrote: On 9/23/19 2:02 AM, Brendan Higgins wrote: Add documentation for KUnit, the Linux kernel unit testing framework. - Add intro and usage guide for KUnit - Add API reference Signed-off-by: Felix Guo Signed-off-by: Brendan Higgins Cc: Jonathan Corbet Reviewed-by: Greg Kroah-Hartman Reviewed-by: Logan Gunthorpe Reviewed-by: Stephen Boyd --- Documentation/dev-tools/index.rst | 1 + Documentation/dev-tools/kunit/api/index.rst | 16 + Documentation/dev-tools/kunit/api/test.rst | 11 + Documentation/dev-tools/kunit/faq.rst | 62 +++ Documentation/dev-tools/kunit/index.rst | 79 +++ Documentation/dev-tools/kunit/start.rst | 180 ++ Documentation/dev-tools/kunit/usage.rst | 576 7 files changed, 925 insertions(+) create mode 100644 Documentation/dev-tools/kunit/api/index.rst create mode 100644 Documentation/dev-tools/kunit/api/test.rst create mode 100644 Documentation/dev-tools/kunit/faq.rst create mode 100644 Documentation/dev-tools/kunit/index.rst create mode 100644 Documentation/dev-tools/kunit/start.rst create mode 100644 Documentation/dev-tools/kunit/usage.rst diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst new file mode 100644 index ..6dc229e46bb3 --- /dev/null +++ b/Documentation/dev-tools/kunit/start.rst @@ -0,0 +1,180 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Getting Started +=== + +Installing dependencies +=== +KUnit has the same dependencies as the Linux kernel. As long as you can build +the kernel, you can run KUnit. + +KUnit Wrapper += +Included with KUnit is a simple Python wrapper that helps format the output to +easily use and read KUnit output. It handles building and running the kernel, as +well as formatting the output. + +The wrapper can be run with: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run + +Creating a kunitconfig +== +The Python script is a thin wrapper around Kbuild as such, it needs to be around Kbuild. As such, Thanks for pointing this out. +configured with a ``kunitconfig`` file. This file essentially contains the +regular Kernel config, with the specific test targets as well. + +.. code-block:: bash + + git clone -b master https://kunit.googlesource.com/kunitconfig $PATH_TO_KUNITCONFIG_REPO + cd $PATH_TO_LINUX_REPO + ln -s $PATH_TO_KUNIT_CONFIG_REPO/kunitconfig kunitconfig + +You may want to add kunitconfig to your local gitignore. + +Verifying KUnit Works +- + +To make sure that everything is set up correctly, simply invoke the Python +wrapper from your kernel repo: + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py + +.. note:: + You may want to run ``make mrproper`` first. I normally use O=builddir when building kernels. Does this support using O=builddir ? Yep, it supports specifying a separate build directory. + +If everything worked correctly, you should see the following: + +.. code-block:: bash + + Generating .config ... + Building KUnit Kernel ... + Starting KUnit Kernel ... + +followed by a list of tests that are run. All of them should be passing. + +.. note:: + Because it is building a lot of sources for the first time, the ``Building + kunit kernel`` step may take a while. + +Writing your first test +=== [snip] diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst new file mode 100644 index ..c6e69634e274 --- /dev/null +++ b/Documentation/dev-tools/kunit/usage.rst TBD... What did you mean by this comment? I plan to review usage.rst soon... (To Be Done :) I would like to apply the series very soon so it gets some soak time after this move in linux-next and it can still make the rc1. Since there changes can be addressed after rc1, I would like to not require Brendan to do another version before I apply. Hope you are okay with that Randy! thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111761] Latest Git Kernel doesn’t boot with Radeon NI with the drm-next-2019-09-18 updates
https://bugs.freedesktop.org/show_bug.cgi?id=111761 --- Comment #3 from Christian Zigotzky --- Created attachment 145482 --> https://bugs.freedesktop.org/attachment.cgi?id=145482=edit DRM patch -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
Hi John,
I spotted one thing below which might be harmless, but best to check.
On Fri, Sep 06, 2019 at 06:47:11PM +, John Stultz wrote:
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
> Benjamin Gaignard, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard
> Signed-off-by: John Stultz
> ---
> v2:
> * Switch allocate to return dmabuf fd
> * Simplify init code
> * Checkpatch fixups
> v3:
> * Switch to inline function for to_cma_heap()
> * Minor cleanups suggested by Brian
> * Fold in new registration style from Andrew
> * Folded in changes from Andrew to use simplified page list
> from the heap helpers
> v4:
> * Use the fd_flags when creating dmabuf fd (Suggested by
> Benjamin)
> * Use precalculated pagecount (Suggested by Andrew)
> v6:
> * Changed variable names to improve clarity, as suggested
> by Brian
> v7:
> * Use newly lower-cased init_heap_helper_buffer helper
> * Use new dmabuf export helper
> v8:
> * Make struct dma_heap_ops const (Suggested by Christoph)
> * Condense dma_heap_buffer and heap_helper_buffer (suggested by
> Christoph)
> * Checkpatch whitespace fixups
> ---
...
> +
> +/* dmabuf heap CMA operations functions */
> +static int cma_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long fd_flags,
> + unsigned long heap_flags)
> +{
> + struct cma_heap *cma_heap = dma_heap_get_data(heap);
> + struct heap_helper_buffer *helper_buffer;
> + struct page *cma_pages;
> + size_t size = PAGE_ALIGN(len);
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + unsigned long align = get_order(size);
> + struct dma_buf *dmabuf;
> + int ret = -ENOMEM;
> + pgoff_t pg;
> +
> + if (align > CONFIG_CMA_ALIGNMENT)
> + align = CONFIG_CMA_ALIGNMENT;
> +
> + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
> + if (!helper_buffer)
> + return -ENOMEM;
> +
> + init_heap_helper_buffer(helper_buffer, cma_heap_free);
> + helper_buffer->flags = heap_flags;
> + helper_buffer->heap = heap;
> + helper_buffer->size = len;
> +
> + cma_pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> + if (!cma_pages)
> + goto free_buf;
> +
> + if (PageHighMem(cma_pages)) {
> + unsigned long nr_clear_pages = nr_pages;
> + struct page *page = cma_pages;
> +
> + while (nr_clear_pages > 0) {
> + void *vaddr = kmap_atomic(page);
> +
> + memset(vaddr, 0, PAGE_SIZE);
> + kunmap_atomic(vaddr);
> + page++;
> + nr_clear_pages--;
> + }
> + } else {
> + memset(page_address(cma_pages), 0, size);
> + }
> +
> + helper_buffer->pagecount = nr_pages;
> + helper_buffer->pages = kmalloc_array(helper_buffer->pagecount,
> + sizeof(*helper_buffer->pages),
> + GFP_KERNEL);
> + if (!helper_buffer->pages) {
> + ret = -ENOMEM;
> + goto free_cma;
> + }
> +
> + for (pg = 0; pg < helper_buffer->pagecount; pg++) {
> + helper_buffer->pages[pg] = _pages[pg];
> + if (!helper_buffer->pages[pg])
Is this ever really possible? If cma_pages is non-NULL (which you
check earlier), then only if the pointer arithmetic overflows right?
If it's just redundant, then you could remove it (and in that case add
my r-b). But maybe you meant to check something else?
Cheers,
-Brian
Re: [RESEND][PATCH v8 1/5] dma-buf: Add dma-buf heaps framework
Hi John,
On Fri, Sep 06, 2019 at 06:47:08PM +, John Stultz wrote:
> From: "Andrew F. Davis"
>
> This framework allows a unified userspace interface for dma-buf
> exporters, allowing userland to allocate specific types of memory
> for use in dma-buf sharing.
>
> Each heap is given its own device node, which a user can allocate
> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>
> This code is an evoluiton of the Android ION implementation,
> and a big thanks is due to its authors/maintainers over time
> for their effort:
> Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
> Laura Abbott, and many other contributors!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard
> Signed-off-by: Andrew F. Davis
> Signed-off-by: John Stultz
One miniscule nit from me below, but whether you change it or not, you
can add my r-b:
Reviewed-by: Brian Starkey
Thanks for pushing this through!
-Brian
> ---
...
> +
> + dev_ret = device_create(dma_heap_class,
> + NULL,
> + heap->heap_devt,
> + NULL,
> + heap->name);
> + if (IS_ERR(dev_ret)) {
> + pr_err("dma_heap: Unable to create device\n");
> + err_ret = (struct dma_heap *)dev_ret;
Tiny nit: ERR_CAST() would be more obvious for me here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
On Fri, Sep 06, 2019 at 06:47:10PM +, John Stultz wrote: > This patch adds system heap to the dma-buf heaps framework. > > This allows applications to get a page-allocator backed dma-buf > for non-contiguous memory. > > This code is an evolution of the Android ION implementation, so > thanks to its original authors and maintainters: > Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others! > > Cc: Laura Abbott > Cc: Benjamin Gaignard > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Pratik Patel > Cc: Brian Starkey > Cc: Vincent Donnefort > Cc: Sudipto Paul > Cc: Andrew F. Davis > Cc: Christoph Hellwig > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Hridya Valsaraju > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Benjamin Gaignard > Signed-off-by: John Stultz LGTM: Reviewed-by: Brian Starkey
[Bug 111791] mesa-19.2-rc4: Fails to execute OpenCL kernel (ac_rtld error: !s->is_rx) on AMD64 and armhf at least
https://bugs.freedesktop.org/show_bug.cgi?id=111791 Bug ID: 111791 Summary: mesa-19.2-rc4: Fails to execute OpenCL kernel (ac_rtld error: !s->is_rx) on AMD64 and armhf at least Product: Mesa Version: 19.2 Hardware: All OS: Linux (All) Status: NEW Severity: critical Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: luis.p.men...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Cannot execute OpenCL kernel (https://github.com/huytd/opencl-benchmark) on GPU with mesa 19.2-rc4 and libclc with AMD RX 550, AMD RX 460, neither on AMD64, nor on armhf. Kernels fails with: ac_rtlf error: !s->is_rx LLVM failed to upload shader This also also happens with Aparapi kernels (https://github.com/Syncleus/aparapi-examples) - test 15 or 16, or others. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110457] System resumes failed and hits [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout on Acer Aspire A315-21G
https://bugs.freedesktop.org/show_bug.cgi?id=110457 --- Comment #13 from darkshvein --- Hello. please, explain. Why I work fine with FX-8320 CPU, but after Ryzen r5 1600 upgrade, I see this OS freezes and bug? is pcie generation any cause? planned obsolescence? or coincidence with amdgpu driver update? part of my log: [49266.138534] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=5660155, emitted seq=5660157 [49266.138578] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Civ6Sub pid 1778 thread Civ6Sub:cs0 pid 1781 [49266.138580] [drm] GPU recovery disabled. [49275.866518] INFO: task Xorg:sh1:1789 blocked for more than 122 seconds. [49275.866521] Tainted: G RO 5.2.10 #2 radeon 7970. mesa utils(8.4.0-1) linux 5.2.10 amdgpu Version: 18.1.99+git20190207-1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111761] Latest Git Kernel doesn’t boot with Radeon NI with the drm-next-2019-09-18 updates
https://bugs.freedesktop.org/show_bug.cgi?id=111761 Christian Zigotzky changed: What|Removed |Added Attachment #145482|0 |1 is obsolete|| --- Comment #4 from Christian Zigotzky --- Created attachment 145483 --> https://bugs.freedesktop.org/attachment.cgi?id=145483=edit This patch reverts the changes in "drivers/gpu/drm/drm" and "include/drm/". I created a patch today. This patch reverts the changes in the following files. - drivers/gpu/drm/drm_* - include/drm/* It also reverts all files which depends on these files above. Now I can boot the latest Git kernel with my Radeon HD NI graphics cards again. Please check the updates in the files - drivers/gpu/drm/drm_* - include/drm/* Thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 2/5] dma-buf: heaps: Add heap helpers
Hi John,
On Fri, Sep 06, 2019 at 06:47:09PM +, John Stultz wrote:
> Add generic helper dmabuf ops for dma heaps, so we can reduce
> the amount of duplicative code for the exported dmabufs.
>
> This code is an evolution of the Android ION implementation, so
> thanks to its original authors and maintainters:
> Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
>
> Cc: Laura Abbott
> Cc: Benjamin Gaignard
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Brian Starkey
> Cc: Vincent Donnefort
> Cc: Sudipto Paul
> Cc: Andrew F. Davis
> Cc: Christoph Hellwig
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Hridya Valsaraju
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Benjamin Gaignard
> Signed-off-by: John Stultz
Two minor things below.
> ---
> v2:
> * Removed cache management performance hack that I had
> accidentally folded in.
> * Removed stats code that was in helpers
> * Lots of checkpatch cleanups
> v3:
> * Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph)
> * Switch to WARN on buffer destroy failure (suggested by Brian)
> * buffer->kmap_cnt decrementing cleanup (suggested by Christoph)
> * Extra buffer->vaddr checking in dma_heap_dma_buf_kmap
> (suggested by Brian)
> * Switch to_helper_buffer from macro to inline function
> (suggested by Benjamin)
> * Rename kmap->vmap (folded in from Andrew)
> * Use vmap for vmapping - not begin_cpu_access (folded in from
> Andrew)
> * Drop kmap for now, as its optional (folded in from Andrew)
> * Fold dma_heap_map_user into the single caller (foled in from
> Andrew)
> * Folded in patch from Andrew to track page list per heap not
> sglist, which simplifies the tracking logic
> v4:
> * Moved dma-heap.h change out to previous patch
> v6:
> * Minor cleanups and typo fixes suggested by Brian
> v7:
> * Removed stray ;
> * Make init_heap_helper_buffer lowercase, as suggested by Christoph
> * Add dmabuf export helper to reduce boilerplate code
> v8:
> * Remove unused private_flags value
> * Condense dma_heap_buffer and heap_helper_buffer (suggested by
> Christoph)
> * Fix indentation by using shorter argument names (suggested by
> Christoph)
> * Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
> (suggested by Christoph)
> * Checkpatch whitespace fixups
> ---
...
> +
> +static void *dma_heap_buffer_vmap_get(struct heap_helper_buffer *buffer)
> +{
> + void *vaddr;
> +
> + if (buffer->vmap_cnt) {
> + buffer->vmap_cnt++;
> + return buffer->vaddr;
> + }
> + vaddr = dma_heap_map_kernel(buffer);
> + if (WARN_ONCE(!vaddr,
> + "heap->ops->map_kernel should return ERR_PTR on error"))
Looks like the message is out-of-date here.
...
> +
> +/**
> + * struct heap_helper_buffer - helper buffer metadata
> + * @heap:back pointer to the heap the buffer came from
> + * @dmabuf: backing dma-buf for this buffer
> + * @size:size of the buffer
> + * @flags: buffer specific flags
> + * @priv_virtpointer to heap specific private value
> + * @lock mutext to protect the data in this structure
> + * @vmap_cnt count of vmap references on the buffer
> + * @vaddrvmap'ed virtual address
> + * @pagecountnumber of pages in the buffer
> + * @pageslist of page pointers
> + * @attachment list of device attachments
s/attachment/attachments/
With those fixed, feel free to add:
Reviewed-by: Brian Starkey
Thanks,
-Brian
i.MX6Q Etnaviv errors
I tired to run some tests on 5.4 and I was getting errors. I went all the way back to 5.0 and I get errors. 4.19 seems to work just fine. I was curious to know if anyone is seeing errors. I'll bisect tomorrow, but I thought I'd ask before I got too far. # LIBGL_DEBUG=verbose glmark2-es2-drm drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 3, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 3, (OK) drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is 3, (OK) drmOpenDevice: node name is /dev/dri/card2 drmOpenDevice: node name is /dev/dri/card3 drmOpenDevice: node name is /dev/dri/card4 drmOpenDevice: node name is /dev/dri/card5 drmOpenDevice: node name is /dev/dri/card6 drmOpenDevice: node name is /dev/dri/card7 drmOpenDevice: node name is /dev/dri/card8 drmOpenDevice: node name is /dev/dri/card9 drmOpenDevice: node name is /dev/dri/card10 drmOpenDevice: node name is /dev/dri/card11 drmOpenDevice: node name is /dev/dri/card12 drmOpenDevice: node name is /dev/dri/card13 drmOpenDevice: node name is /dev/dri/card14 drmOpenDevice: node name is /dev/dri/card15 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 3, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 3, (OK) drmGetBusid returned '' libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. MESA-LOADER: failed to open imx-drm (search paths /usr/lib/dri) failed to load driver: imx-drm libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /root/.drirc: No such file or directory. Error: eglCreateWindowSurface failed with error: 0x3009 Error: eglCreateWindowSurface failed with error: 0x3009 Error: CanvasGeneric: Invalid EGL state Error: main: Could not initialize canvas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/6] mdev: introduce device specific ops
> -Original Message-
> From: Jason Wang
> Sent: Monday, September 23, 2019 8:03 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> kwankh...@nvidia.com; alex.william...@redhat.com; m...@redhat.com;
> tiwei@intel.com
> Cc: virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
> coh...@redhat.com; maxime.coque...@redhat.com;
> cunming.li...@intel.com; zhihong.w...@intel.com;
> rob.mil...@broadcom.com; xiao.w.w...@intel.com;
> haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
> far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
> ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
> borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
> lingshan@intel.com; Ido Shamay ;
> epere...@redhat.com; l...@redhat.com; Parav Pandit
> ; Jason Wang
> Subject: [PATCH 2/6] mdev: introduce device specific ops
>
> Currently, except for the create and remove. The rest of mdev_parent_ops is
> designed for vfio-mdev driver only and may not help for kernel mdev driver.
> Follow the class id support by previous patch, this patch introduces device
> specific ops pointer inside parent ops which points to device specific ops
> (e.g
> vfio ops). This allows the future drivers like virtio-mdev to implement its
> own
> device specific ops.
>
> Signed-off-by: Jason Wang
> ---
> .../driver-api/vfio-mediated-device.rst | 4 +-
> MAINTAINERS | 1 +
> drivers/gpu/drm/i915/gvt/kvmgt.c | 15 +++---
> drivers/s390/cio/vfio_ccw_ops.c | 15 --
> drivers/s390/crypto/vfio_ap_ops.c | 11 ++--
> drivers/vfio/mdev/vfio_mdev.c | 31 ++-
> include/linux/mdev.h | 36 ++---
> include/linux/vfio_mdev.h | 53 +++
> samples/vfio-mdev/mbochs.c| 17 +++---
> samples/vfio-mdev/mdpy.c | 17 +++---
> samples/vfio-mdev/mtty.c | 15 --
> 11 files changed, 138 insertions(+), 77 deletions(-) create mode 100644
> include/linux/vfio_mdev.h
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 0e052072e1d8..3ab00e48212f 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -152,7 +152,9 @@ callbacks per mdev parent device, per mdev type, or
> any other categorization.
> Vendor drivers are expected to be fully asynchronous in this respect or
> provide their own internal resource protection.)
>
> -The callbacks in the mdev_parent_ops structure are as follows:
> +The device specific callbacks are referred through device_ops pointer
> +in mdev_parent_ops. For vfio-mdev device, its callbacks in device_ops
> +are as follows:
>
> * open: open callback of mediated device
> * close: close callback of mediated device diff --git a/MAINTAINERS
> b/MAINTAINERS index b2326dece28e..89832b316500 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17075,6 +17075,7 @@ S:Maintained
> F: Documentation/driver-api/vfio-mediated-device.rst
> F: drivers/vfio/mdev/
> F: include/linux/mdev.h
> +F: include/linux/vfio_mdev.h
> F: samples/vfio-mdev/
>
> VFIO PLATFORM DRIVER
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 19d51a35f019..8ea86b1e69f1 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -1600,20 +1601,22 @@ static const struct attribute_group
> *intel_vgpu_groups[] = {
> NULL,
> };
>
> -static struct mdev_parent_ops intel_vgpu_ops = {
> - .mdev_attr_groups = intel_vgpu_groups,
> - .create = intel_vgpu_create,
> - .remove = intel_vgpu_remove,
> -
> +static struct vfio_mdev_parent_ops intel_vfio_vgpu_ops = {
Naming it with _dev prefix as intel_vfio_vgpu_dev_ops is better to
differentiate with parent_ops.
> .open = intel_vgpu_open,
> .release= intel_vgpu_release,
> -
> .read = intel_vgpu_read,
> .write = intel_vgpu_write,
> .mmap = intel_vgpu_mmap,
> .ioctl = intel_vgpu_ioctl,
> };
>
> +static struct mdev_parent_ops intel_vgpu_ops = {
> + .mdev_attr_groups = intel_vgpu_groups,
> + .create = intel_vgpu_create,
> + .remove = intel_vgpu_remove,
> + .device_ops
