Re: [PULL] drm-intel-next
On Tue, Jun 12, 2018 at 9:59 AM, Jani Nikula wrote: > On Tue, 12 Jun 2018, Dave Airlie wrote: >> On 12 June 2018 at 02:27, Rodrigo Vivi wrote: >>> Hi Dave, >>> >>> This is the first round targeting 4.19. >>> >> Does this tree feed into linux-next already? >> >> Since we shouldn't have new stuff for linux-next feeding into it until >> after rc1. > > I think we'll feed it to linux-next only after merge window closes > i.e. rc1. > >> I won't be pulling this until after rc1 anyways. > > Seems fair; this doesn't conflict with tagging manageable sized batches > in dinq like Rodrigo has done here. So we're good. The scripts don't require to send out a pull request when only tagging, I guess this pull here was just a fumble? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-next
On Tue, Jun 12, 2018 at 9:59 AM, Jani Nikula wrote: > On Tue, 12 Jun 2018, Dave Airlie wrote: >> On 12 June 2018 at 02:27, Rodrigo Vivi wrote: >>> Hi Dave, >>> >>> This is the first round targeting 4.19. >>> >> Does this tree feed into linux-next already? >> >> Since we shouldn't have new stuff for linux-next feeding into it until >> after rc1. > > I think we'll feed it to linux-next only after merge window closes > i.e. rc1. dim indeed takes care of that, but only if the drm-intel-fixes/next-fixes branches are handled correctly. Which is why fast-forwarding them according to the documentation is paramount, for otherwise we upset everyone using linux-next :-) -Daniel > >> I won't be pulling this until after rc1 anyways. > > Seems fair; this doesn't conflict with tagging manageable sized batches > in dinq like Rodrigo has done here. So we're good. > > BR, > Jani. > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] efi/bgrt: Drop __initdata from bgrt_image_size
On 17 June 2018 at 17:32, Hans de Goede wrote:
> bgrt_image_size is necessary to (optionally) show the boot graphics from
> the efifb code. The efifb driver is a platform driver, using a normal
> driver probe() driver callback. So even though it is always builtin it
> cannot reference __initdata.
>
> Signed-off-by: Hans de Goede
Acked-by: Ard Biesheuvel
> ---
> drivers/firmware/efi/efi-bgrt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c
> index 50793fda7819..b22ccfb0c991 100644
> --- a/drivers/firmware/efi/efi-bgrt.c
> +++ b/drivers/firmware/efi/efi-bgrt.c
> @@ -20,7 +20,7 @@
> #include
>
> struct acpi_table_bgrt bgrt_tab;
> -size_t __initdata bgrt_image_size;
> +size_t bgrt_image_size;
>
> struct bmp_header {
> u16 id;
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
no mouse cursor on nv50
Hi! On v4.18-rc1, the mouse cursor is missing on my right monitor. Card is G98 [GeForce 8400 GS Rev. 2]. I have two monitors: one small landscape 1280x1024 on DVI-I-1 left, and one big 1600x1200 (1200x1600 portrait) on HDMI-1 right. Curiously, the cursor is missing not only with proper xrandr setup after logging in but even in mirrored mode at the lightdm greeter[1]. How is this even possible if both screens are supposed to be identical? Bisected: # bad: [ce397d215ccd07b8ae3f71db689aedb85d56ab40] Linux 4.18-rc1 # good: [29dcea88779c856c7dc92040a0c01233263101d4] Linux 4.17 git bisect start 'v4.18-rc1' 'v4.17' # bad: [1c8c5a9d38f607c0b6fd12c91cbe1a4418762a21] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect bad 1c8c5a9d38f607c0b6fd12c91cbe1a4418762a21 # bad: [135c5504a600ff9b06e321694fbcac78a9530cd4] Merge tag 'drm-next-2018-06-06-1' of git://anongit.freedesktop.org/drm/drm git bisect bad 135c5504a600ff9b06e321694fbcac78a9530cd4 # good: [5231804cf9e584f3e7e763a0d6d2fffe011c1bce] Merge tag 'leds_for_4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds git bisect good 5231804cf9e584f3e7e763a0d6d2fffe011c1bce # good: [315852b422972e6ebb1dfddaadada09e46a2681a] drm: rcar-du: Fix build failure git bisect good 315852b422972e6ebb1dfddaadada09e46a2681a # good: [ec064d3c6b40697fd72f4b1eeabbf293b7947a04] Merge tag 'driver-core-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect good ec064d3c6b40697fd72f4b1eeabbf293b7947a04 # bad: [ce234ccc03cfee004e168a1ae4b9d0cfb1974a32] Merge tag 'drm/tegra/for-4.18-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next git bisect bad ce234ccc03cfee004e168a1ae4b9d0cfb1974a32 # bad: [d7c6e97a32329032ba7af1f53cab2767832fed77] drm/nouveau/kms/nv50-: modify base allocation so the code can be split git bisect bad d7c6e97a32329032ba7af1f53cab2767832fed77 # good: [0a5b97304b9e2cd07c78a399c5395d5fb0118341] drm/nouveau/gr/gf100-: virtualise init_sked_hww_esr git bisect good 0a5b97304b9e2cd07c78a399c5395d5fb0118341 # good: [18d17221dd58741a8590ba0a40a9ded82aa5d619] drm/nouveau/gr/gf100-: virtualise r419e00 git bisect good 18d17221dd58741a8590ba0a40a9ded82aa5d619 # good: [e9d03335f604a1123b8de3103ce8e06db4ad777a] drm/nouveau/gr/gp100-: use correct registers for zbc colour/depth setup git bisect good e9d03335f604a1123b8de3103ce8e06db4ad777a # good: [512fa0b8a398539c3c2db251f6c40da4ef065d09] drm/nouveau/drm/nv50-: remove allocation of sw class git bisect good 512fa0b8a398539c3c2db251f6c40da4ef065d09 # good: [62b290fc7b36e8fec2a370b946d7117c1899b6c1] drm/nouveau/kms/nv50-: fix i2c-over-aux on anx9805 git bisect good 62b290fc7b36e8fec2a370b946d7117c1899b6c1 # bad: [a97c530eb968bad8d945d4f64fb550fa37a9d362] drm/nouveau/kms/nv50-: modify overlay allocation so the code can be split git bisect bad a97c530eb968bad8d945d4f64fb550fa37a9d362 # bad: [5bca1621c07c3ad37b5a4943450a892e18984df0] drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows git bisect bad 5bca1621c07c3ad37b5a4943450a892e18984df0 # first bad commit: [5bca1621c07c3ad37b5a4943450a892e18984df0] drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows Alas, the bad commit can't be easily reverted as there's a lot of further work on the file on question. Meow! [1]. It's possible to setup lightdm for proper layout even on the login screen, but that gives only aesthetic bonus while possibly causing problems when the layout changes. -- ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes ⠈⠳⣄ go back and forth wrt their intended target. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 2/5] drm/bridge: add support for sn65dsi86 bridge driver
On 2018-06-15 16:59, Andrzej Hajda wrote: Hi Sandeep, Thanks for the patch, I hope it will be merged soon. On 15.06.2018 08:43, Sandeep Panda wrote: Add support for TI's sn65dsi86 dsi2edp bridge chip. The chip converts DSI transmitted signal to eDP signal, which is fed to the connected eDP panel. This chip can be controlled via either i2c interface or dsi interface. Currently in driver all the control registers are being accessed through i2c interface only. Also as of now HPD support has not been added to bridge chip driver. Changes in v1: - Split the dt-bindings and the driver support into separate patches (Andrzej Hajda). - Use of gpiod APIs to parse and configure gpios instead of obsolete ones (Andrzej Hajda). - Use macros to define the register offsets (Andrzej Hajda). Changes in v2: - Separate out edp panel specific HW resource handling from bridge driver and create a separate edp panel drivers to handle panel specific mode information and HW resources (Sean Paul). - Replace pr_* APIs to DRM_* APIs to log error or debug information (Sean Paul). - Remove some of the unnecessary structure/variable from driver (Sean Paul). - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge" (Sean Paul / Rob Herring). - Remove most of the hard-coding and modified the bridge init sequence based on current mode (Sean Paul). - Remove the existing function to retrieve the EDID data and implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul). - Remove the dummy irq handler implementation, will add back the proper irq handling later (Sean Paul). - Capture the required enable gpios in a single array based on dt entry instead of having individual descriptor for each gpio (Sean Paul). Changes in v3: - Remove usage of irq_gpio and replace it as "interrupts" property (Rob Herring). - Remove the unnecessary header file inclusions (Sean Paul). - Rearrange the header files in alphabetical order (Sean Paul). - Use regmap interface to perform i2c transactions. - Update Copyright/License field and address other review comments (Jordan Crouse). Changes in v4: - Update License/Copyright (Sean Paul). - Add Kconfig and Makefile changes (Sean Paul). - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios will be handled by i2c master. - Update required supplies names. - Remove unnecessary goto statements (Sean Paul). - Add mutex lock to power_ctrl API to avoid race conditions (Sean Paul). - Add support to parse reference clk frequency from dt(optional). - Update the bridge chip enable/disable sequence. Changes in v5: - Fixed Kbuild test service reported warnings. Changes in v6: - Use PM runtime based ref-counting instead of local ref_count mechanism (Stephen Boyd). - Clean up some debug logs and indentations (Sean Paul). - Simplify dp rate calculation (Sean Paul). - Add support to configure refclk based on input REFCLK pin or DACP/N pin (Stephen Boyd). Changes in v7: - Use static supply entries instead of dynamic allocation (Andrzej Hajda). - Defer bridge driver probe if panel is not probed (Andrzej Hajda). - Update of_graph APIs for correct node reference management. (Andrzej Hajda). - Remove local display_mode object (Andrzej Hajda). - Remove version id check function from driver. Changes in v8: - Move dsi register/attach function to bridge driver probe (Andrzej Hajda). - Introduce a new helper function to write 16bit words into consecutive registers (Andrzej Hajda). - Remove unnecessary macros (Andrzej Hajda). Changes in v9: - Remove dsi register/attach from bridge probe, since dsi dev register completion also waits for any panel or bridge to get added. This creates deadlock situation when bridge driver calls dsi dev register and attach before bridge add, in its probe function. - Fix issues faced during testing of bridge driver on actual HW. - Remove unnecessary initializations (Stephen Boyd). - Use local refclk lut size instead of global macro (Sean Paul). Changes in v10: - Use refclk to determine if continuous dsi clock is needed or not. Changes in v11: - Read DPPLL_SRC register to determine continuous clock instead of using refclk handle (Stephen Boyd). Signed-off-by: Sandeep Panda --- drivers/gpu/drm/bridge/Kconfig| 9 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 696 ++ 3 files changed, 706 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 3b99d5a..8153150 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -108,6 +108,15 @@ config DRM_TI_TFP410 ---help--- Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI86 + tristate "TI SN65DSI86 DSI to eDP bridge" +
Re: [PATCH v4 0/9] xen: dma-buf support for grant device
Boris, Juergen! Thank you so much for your comments and time spent on this series. Appreciate that very much! Thank you, Oleksandr On 06/15/2018 09:27 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This work is in response to my previous attempt to introduce Xen/DRM zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based frontends/backends. There is also an existing hyper_dmabuf approach available [3] which, if reworked to utilize the proposed solution, can greatly benefit as well. RFC for this series was published and discussed [9], comments addressed. The original rationale behind this work was to enable zero-copying use-cases while working with Xen para-virtual display driver [4]: when using Xen PV DRM frontend driver then on backend side one will need to do copying of display buffers' contents (filled by the frontend's user-space) into buffers allocated at the backend side. Taking into account the size of display buffers and frames per second it may result in unneeded huge data bus occupation and performance loss. The helper driver [4] allows implementing zero-copying use-cases when using Xen para-virtualized frontend display driver by implementing a DRM/KMS helper driver running on backend's side. It utilizes PRIME buffers API (implemented on top of Linux dma-buf) to share frontend's buffers with physical device drivers on backend's side: - a dumb buffer created on backend's side can be shared with the Xen PV frontend driver, so it directly writes into backend's domain memory (into the buffer exported from DRM/KMS driver of a physical display device) - a dumb buffer allocated by the frontend can be imported into physical device DRM/KMS driver, thus allowing to achieve no copying as well Finally, it was discussed and decided ([1], [5]) that it is worth implementing such use-cases via extension of the existing Xen gntdev driver instead of introducing new DRM specific driver. Please note, that the support of dma-buf is Linux only, as dma-buf is a Linux only thing. Now to the proposed solution. The changes to the existing Xen drivers in the Linux kernel fall into 2 categories: 1. DMA-able memory buffer allocation and increasing/decreasing memory reservation of the pages of such a buffer. This is required if we are about to share dma-buf with the hardware that does require those to be allocated with dma_alloc_xxx API. (It is still possible to allocate a dma-buf from any system memory, e.g. system pages). 2. Extension of the gntdev driver to enable it to import/export dma-buf’s. The first six patches are in preparation for Xen dma-buf support, but I consider those usable regardless of the dma-buf use-case, e.g. other frontend/backend kernel modules may also benefit from these for better code reuse: 0001-xen-grant-table-Export-gnttab_-alloc-free-_pages-as-.patch 0002-xen-grant-table-Make-set-clear-page-private-code-sha.patch 0003-xen-balloon-Share-common-memory-reservation-routines.patch 0004-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch 0005-xen-gntdev-Allow-mappings-for-DMA-buffers.patch 0006-xen-gntdev-Make-private-routines-structures-accessib.patch The next three patches are Xen implementation of dma-buf as part of the grant device: 0007-xen-gntdev-Add-initial-support-for-dma-buf-UAPI.patch 0008-xen-gntdev-Implement-dma-buf-export-functionality.patch 0009-xen-gntdev-Implement-dma-buf-import-functionality.patch The corresponding libxengnttab changes are available at [6]. All the above was tested with display backend [7] and its accompanying helper library [8] on Renesas ARM64 based board. Basic balloon tests on x86. *To all the communities*: I would like to ask you to review the proposed solution and give feedback on it, so I can improve and send final patches for review (this is still work in progress, but enough to start discussing the implementation). Thank you in advance, Oleksandr Andrushchenko [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html [2] https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/dma-buf.rst [3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html [4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen [5] https://patchwork.kernel.org/patch/10279681/ [6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1 [7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1 [8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1 [9] https://lkml.org/lkml/2018/5/17/215 Changes since v3: * - added r-b tags - minor fixes - removed gntdev_remove_map as it can be coded directly now - moved IOCTL code to gntdev-dmabuf.c - removed usless wait list walks and changed some walks to use normal version of list iterators instead of safe ones as we run under a lock anyways - cleaned up comments, descriptions, pr_debug messages Changes since
Re: [PATCH v4 5/9] xen/gntdev: Allow mappings for DMA buffers
On 06/16/2018 12:07 AM, Boris Ostrovsky wrote: On 06/15/2018 02:50 AM, Oleksandr Andrushchenko wrote: On 06/15/2018 09:46 AM, Juergen Gross wrote: On 15/06/18 08:32, Oleksandr Andrushchenko wrote: Please note, that this will need a change (attached) while applying to the mainline kernel because of API changes [1]. Unfortunately, current Xen tip kernel tree is v4.17-rc5 based, so I cannot make the change in this patch now. I don't see any chance this series could go into 4.18, as the merge window is just closing. So please post the patch based on current Linux master of torvalds/linux.git Ok, I'll wait for any comments/r-b's and then rebase to torvalds/linux.git and push v5? As I mentioned earlier, I would very much like at least a review of the new interfaces by someone more knowledgeable than me. I am adding "DMA BUFFER SHARING FRAMEWORK" maintainer to the list. Sumit, could please help reviewing this? The whole work here is to add dma-buf to Xen's grant device driver. Intel could probably also say couple of words as they also might re-use this work. BTW, is there any plan to rebase Xen tip kernel? It is typically rebased to rc5 or r6, at which point patches for the next merge window are applied. -borsi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 3/5] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On 2018-06-15 12:53, Andrzej Hajda wrote: On 15.06.2018 08:43, Sandeep Panda wrote: Document the bindings used for the sn65dsi86 DSI to eDP bridge. Changes in v1: - Rephrase the dt-binding descriptions to be more inline with existing bindings (Andrzej Hajda). - Add missing dt-binding that are parsed by corresponding driver (Andrzej Hajda). Changes in v2: - Remove edp panel specific dt-binding entries. Only keep bridge specific entries (Sean Paul). - Remove custom-modes dt entry since its usage is removed from driver also (Sean Paul). - Remove is-pluggable dt entry since this will not be needed anymore (Sean Paul). Changes in v3: - Remove irq-gpio dt entry and instead populate is an interrupt property (Rob Herring). Changes in v4: - Add link to bridge chip datasheet (Stephen Boyd) - Add vpll and vcc regulator supply bindings (Stephen Boyd) - Add ref clk optional dt binding (Stephen Boyd) - Add gpio-controller optional dt binding (Stephen Boyd) Changes in v5: - Use clock property to specify the input refclk (Stephen Boyd). - Update gpio cell and pwm cell numbers (Stephen Boyd). Changes in v6: - Add property to mention the lane mapping scheme and polarity inversion (Stephen Boyd). Changes in v7: - Detail description of lane mapping scheme dt property (Andrzej Hajda/ Rob Herring). - Removed HDP gpio binding, since the bridge uses IRQ signal to determine HPD, and IRQ property is already documented in binding. Changes in v8: - Removed unnecessary explanation of lane mapping and polarity dt property, since these are already explained in media/video-interface dt binidng (Rob Herring). Changes in v9: - Avoid putting re-definition of lane mapping and polarity dt binding (Rob Herring). Signed-off-by: Sandeep Panda --- .../bindings/display/bridge/ti,sn65dsi86.txt | 87 ++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt new file mode 100644 index 000..507efbb --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt @@ -0,0 +1,87 @@ +SN65DSI86 DSI to eDP bridge chip + + +This is the binding for Texas Instruments SN65DSI86 bridge. +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf + +Required properties: +- compatible: Must be "ti,sn65dsi86" +- reg: i2c address of the chip, 0x2d as per datasheet +- enable-gpios: OF device-tree gpio specification for bridge_en pin (active high) + +- vccio-supply: A 1.8V supply that powers up the digital IOs. +- vpll-supply: A 1.8V supply that powers up the displayport PLL. +- vcca-supply: A 1.2V supply that powers up the analog circuits. +- vcc-supply: A 1.2V supply that powers up the digital core. Since there are only two voltage levels (1.8 and 1.2) and power on/off sequence does not require specific order I guess you could merge supplies with the same level, but this is just an idea, up to you. For example you can drop (or make optional) vpll-supply and vcca-supply. + Since the bridge datasheet mentions about 4 different power supplies and there was also comment from other reviewers to keep all of them so i have put it like this. Also this will help in scenarios where board design has 4 different sources for these 4 power supplies. +Optional properties: +- interrupts: Specifier for the SN65DSI86 interrupt line. or interrupts-extended + +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing + +- gpio-controller: Marks the device has a GPIO controller. +- #gpio-cells: Should be two. The first cell is the pin number and + the second cell is used to specify flags. + See ../../gpio/gpio.txt for more information. +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of + the cell formats. + +- clock-names: should be "refclk" +- clocks: Specification for input reference clock. The reference + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. + +- data-lanes: See ../../media/video-interface.txt +- lane-polarities: See ../../media/video-interface.txt Either you should describe which port these properties are related to, either put them into endpoint node. According to ./../media/video-interface.txt only the latter is correct. Data lane and lane-polarity is applicable to both DSI and eDP interface. I have updated the same in ../../media/video-interface.txt. Do you want to explicitly mention here that this property is for eDP data lanes mapping? + +Required nodes: +This device has two video ports. Their connections are modelled using the +OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video por
Re: [PATCH] qxl: don't unref cursor bo inside atomic section (release mapping).
On Mon, Jun 18, 2018 at 12:32:29PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Fixes: 9428088c (drm/qxl: reapply cursor after resetting primary)
> Reported-by: Mike Galbraith
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index b8cda9449241..768207fbbae3 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -623,7 +623,7 @@ static void qxl_cursor_atomic_update(struct drm_plane
> *plane,
> struct qxl_cursor_cmd *cmd;
> struct qxl_cursor *cursor;
> struct drm_gem_object *obj;
> - struct qxl_bo *cursor_bo = NULL, *user_bo = NULL;
> + struct qxl_bo *cursor_bo = NULL, *user_bo = NULL, *old_cursor_bo = NULL;
> int ret;
> void *user_ptr;
> int size = 64*64*4;
> @@ -677,7 +677,7 @@ static void qxl_cursor_atomic_update(struct drm_plane
> *plane,
> cursor_bo, 0);
> cmd->type = QXL_CURSOR_SET;
>
> - qxl_bo_unref(&qcrtc->cursor_bo);
> + old_cursor_bo = qcrtc->cursor_bo;
> qcrtc->cursor_bo = cursor_bo;
> cursor_bo = NULL;
> } else {
> @@ -697,6 +697,9 @@ static void qxl_cursor_atomic_update(struct drm_plane
> *plane,
> qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
> qxl_release_fence_buffer_objects(release);
>
> + if (old_cursor_bo)
> + qxl_bo_unref(&old_cursor_bo);
> +
> qxl_bo_unref(&cursor_bo);
>
> return;
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote: > On 06/16/2018 12:42 AM, Leonard Crestez wrote: > > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote: > >> On 06/15/2018 10:58 PM, Leonard Crestez wrote: > >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote: > On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez > wrote: > > > > The FBDEV driver uses the same name and both can't be registered at the > > same time. Fix this by renaming the drm driver to mxsfb-drm > > Stefan sent the same patch a few days ago: > >>> > >>> In that thread there is a proposal for removing the old fbdev/mxsfb > >>> driver entirely. > >>> > >>> That would break old DTBs, isn't this generally considered bad? Also, > >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features? > >>> > >>> What my series does is make both drivers work with the same kernel > >>> image and turns the choice into a board-level dtb decision. Supporting > >>> everything at once seems desirable to me and it allows for a very > >>> smooth upgrade path. > >> > >> Having two drivers in the kernel with different set of bugs is always bad. > >> > >>> The old driver could be removed later, after all users are converted. > >> > >> Both drivers were in for long enough already. And let's be realistic, > >> how many MX23/MX28 users of old DTs with new kernels are there who > >> cannot update the DT as well ? > > > > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old > > bindings are also used by 3rd-party boards for imx6/7: > > * imx6sx-nitrogen6sx > > * imx6ul-geam > > * imx6ul-isiot > > * imx6ul-opos6uldev > > * imx6ul-pico-hobbit > > * imx6ul-tx6ul > > * imx7d-nitrogen7 > > Er, yes, a handful of boards which could be updated :) > > > Converting everything might be quite a bit of work, and explicitly > > supporting old bindings is also work. > > Does adding support for old bindings justify the effort invested ? I > doubt so, it only adds more code to maintain. > > > It is very confusing that there is a whole set of displays for imx6/7 > > which are supported by upstream but only with a non-default config. > > While it is extremely common in the embedded field to have custom > > configs the default one in the kernel should try to "just work". > > > > Couldn't this patch series be considered a bugfix? It was also > > surprisingly small. > > I think it's just a workaround which allows you to postpone the real > fix, and I don't like that. Yeah agreed, imo the proper fix here would be to either update the dts for the affected boards and/or make mxsfb accept the old dt bindings for backwards compat. Artificially extending the life of the fbdev drivers seems silly. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/6] mfd: cros-ec: Increase maximum mkbp event size
On Fri, 01 Jun 2018, Neil Armstrong wrote:
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson
> Signed-off-by: Neil Armstrong
> Tested-by: Enric Balletbo i Serra
> ---
> drivers/platform/chrome/cros_ec_proto.c | 40
> +
> include/linux/mfd/cros_ec.h | 2 +-
> include/linux/mfd/cros_ec_commands.h| 19
> 3 files changed, 51 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index e7bbdf9..c4f6c44 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device
> *ec_dev,
> }
> EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>
> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
> +struct cros_ec_command *msg,
> +int version, uint32_t size)
> +{
> + int ret;
> +
> + msg->version = version;
> + msg->command = EC_CMD_GET_NEXT_EVENT;
> + msg->insize = size;
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer(ec_dev, msg);
> + if (ret > 0) {
> + ec_dev->event_size = ret - 1;
> + memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
> + }
> +
> + return ret;
> +}
> +
> static int get_next_event(struct cros_ec_device *ec_dev)
> {
> u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
> struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
> + static int cmd_version = 1;
> int ret;
>
> if (ec_dev->suspended) {
> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
> return -EHOSTDOWN;
> }
>
> - msg->version = 0;
> - msg->command = EC_CMD_GET_NEXT_EVENT;
> - msg->insize = sizeof(ec_dev->event_data);
> - msg->outsize = 0;
> + if (cmd_version == 1) {
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event_v1));
> + if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> + return ret;
>
> - ret = cros_ec_cmd_xfer(ec_dev, msg);
> - if (ret > 0) {
> - ec_dev->event_size = ret - 1;
> - memcpy(&ec_dev->event_data, msg->data,
> -sizeof(ec_dev->event_data));
> + /* Fallback to version 0 for future send attempts */
> + cmd_version = 0;
> }
>
> + ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event));
> +
> return ret;
> }
>
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index f36125e..32caef3 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -147,7 +147,7 @@ struct cros_ec_device {
> bool mkbp_event_supported;
> struct blocking_notifier_head event_notifier;
>
> - struct ec_response_get_next_event event_data;
> + struct ec_response_get_next_event_v1 event_data;
> int event_size;
> u32 host_event_wake_mask;
> };
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index f2edd99..cc0768e 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
> uint32_t sysrq;
> } __packed;
>
> +union ec_response_get_next_data_v1 {
> + uint8_t key_matrix[16];
> +
> + /* Unaligned */
That's funny!
> + uint32_t host_event;
> +
> + uint32_t buttons;
> + uint32_t switches;
> + uint32_t sysrq;
> + uint32_t cec_events;
> + uint8_tcec_message[16];
Since there are some whitespace alignment issues in here.
> +} __packed;
How come these guys have kerneldoc headers?
> struct ec_response_get_next_event {
> uint8_t event_type;
> /* Followed by event data if any */
> union ec_response_get_next_data data;
> } __packed;
>
> +struct ec_response_get_next_event_v1 {
> + uint8_t event_type;
> + /* Followed by event data if any */
> + union ec_response_get_next_data_v1 data;
> +} __packed;
> +
> /* Bit indices for buttons and switches.*/
> /* Buttons */
> #define EC_MKBP_POWER_BUTTON 0
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/6] mfd: cros-ec: Introduce CEC commands and events definitions.
On Fri, 01 Jun 2018, Neil Armstrong wrote: > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > > Signed-off-by: Neil Armstrong > Tested-by: Enric Balletbo i Serra > Reviewed-by: Hans Verkuil > --- > include/linux/mfd/cros_ec_commands.h | 81 > > 1 file changed, 81 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/14] drm/sti: Remove pointless casts
2018-06-15 18:49 GMT+02:00 Ville Syrjala : > From: Ville Syrjälä > > There's no point in the cast for accessing the base class. Just > take the address of the struct instead. > > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Signed-off-by: Ville Syrjälä Acked-by: Benjamin Gaignard Thanks. > --- > drivers/gpu/drm/sti/sti_tvout.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c > index ea4a3b87fa55..7d495307fe79 100644 > --- a/drivers/gpu/drm/sti/sti_tvout.c > +++ b/drivers/gpu/drm/sti/sti_tvout.c > @@ -665,7 +665,7 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *)encoder; > + drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 0; > @@ -718,7 +718,7 @@ static struct drm_encoder > *sti_tvout_create_hda_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *) encoder; > + drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 0; > @@ -767,7 +767,7 @@ static struct drm_encoder > *sti_tvout_create_hdmi_encoder(struct drm_device *dev, > > encoder->tvout = tvout; > > - drm_encoder = (struct drm_encoder *) encoder; > + drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > drm_encoder->possible_clones = 1 << 1; > -- > 2.16.4 > -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/etnaviv: properly implement mmaping of imported buffers
On Thu, May 31, 2018 at 10:41:25AM +0200, Lucas Stach wrote: > Am Dienstag, den 29.05.2018, 14:34 +0200 schrieb Daniel Vetter: > > On Tue, May 29, 2018 at 11:08 AM, Lucas Stach > > wrote: > > > Am Dienstag, den 29.05.2018, 10:20 +0200 schrieb Daniel Vetter: > > > > On Fri, May 25, 2018 at 03:42:54PM +0200, Lucas Stach wrote: > > > > > The intention of the existing code was to deflect the actual work > > > > > of mmaping a dma-buf to the exporter, as that one probably knows best > > > > > how to handle the buffer. Unfortunately the call to drm_gem_mmap did > > > > > more than what etnaviv needs in this case by actually setting up the > > > > > mapping. > > > > > > > > > > Move mapping setup to the shm buffer type mmap implementation so we > > > > > only need to look up the BO and call the buffer type mmap function > > > > > from the handler. > > > > > > > > > > Fixes mmap behavior with dma-buf imported and userptr buffers. > > > > > > > > You allow mmap on userptr buffers? That sounds really nasty ... > > > > > > No, we don't because that's obviously crazy, even more so on ARM with > > > it's special rules about aliasing mappings. The current code is buggy > > > in that it first sets up the mapping and then tells userspace the mmap > > > failed. After this patch we properly reject userptr mmap outright. > > > > Ah, I didn't realize that. It sounded more like making userptr mmap > > work, not rejecting it. Can't you instead just never register the mmap > > offset for userptr objects? That would catch the invalid request even > > earlier, and make it more obvious that mmap is not ok for userptr. > > Would also remove the need to hand-roll an etnaviv version of > > drm_gem_obj_mmap. > > Makes sense for userptr, not so much for imported dma-bufs, see below. > > > > > Also not really thrilled about dma-buf mmap forwarding either, since you > > > > don't seem to forward the begin/end_cpu_access stuff either. > > > > > > Yeah, that's still missing, but IMHO more of a correctness fix (which > > > can be done in a follow on patch), distinct of the bugfix in this > > > patch. > > > > Yeah drm_gem_obj_mmap should check for obj->import_attach imo and > > scream. Maybe we should even have that check when allocating the mmap > > offset, since having an mmap offset for something you can never mmap > > is silly. And obj->import_attach isn't allowed to change over the > > lifetime of an object. > > Agreed for drm_gem_obj_mmap, but I don't follow why we would reject > mmap of an imported dma-buf. This seems to be a feature we want today > for drivers that need to talk to multiple DRM devices, like Etnaviv, > Tegra and VC4 in some cases. Making the mmap look uniform by allowing > the mmap on one device and internally deflecting to the exporter is a > big pro from the userspace driver writer PoV. > > Also if you think about stuff like ION (not that I would agree that ION > is a good idea in general, but whatever), a lot of buffers end up being > allocated by ION. I don't want driver writers to care where a buffer > was allocated, but rather call the usual mmap on the device they are > working with and do the right thing in the kernel. > > Maybe we can just generalize the deflecting to the exporter and > implement it in the DRM core, rather than rolling our own version in > etnaviv. The problem is more that most driver uapi for mmap doesn't bother much with cache coherency ioctls (I think yours does), which makes dma-buf mmap in the general case a no-go. So relying on it working seems ill-advised. But in the end it's a matter of making stuff work in reality, not for the full general case, and for that I guess you sufficiently control all the pieces (e.g. you know you'll only ever deal with coherent buffers) to make this work. I guess if there's demand, a general mmap reflector for gem would be much better than the state of the art of everyone copypasting the same logic. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
On 18.06.2018 09:43, Daniel Vetter wrote: > On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote: >> On 06/16/2018 12:42 AM, Leonard Crestez wrote: >> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote: >> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote: >> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote: >> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez >> wrote: >> > >> > The FBDEV driver uses the same name and both can't be registered at the >> > same time. Fix this by renaming the drm driver to mxsfb-drm >> >> Stefan sent the same patch a few days ago: >> >>> >> >>> In that thread there is a proposal for removing the old fbdev/mxsfb >> >>> driver entirely. >> >>> >> >>> That would break old DTBs, isn't this generally considered bad? Also, >> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features? >> >>> >> >>> What my series does is make both drivers work with the same kernel >> >>> image and turns the choice into a board-level dtb decision. Supporting >> >>> everything at once seems desirable to me and it allows for a very >> >>> smooth upgrade path. >> >> >> >> Having two drivers in the kernel with different set of bugs is always bad. >> >> >> >>> The old driver could be removed later, after all users are converted. >> >> >> >> Both drivers were in for long enough already. And let's be realistic, >> >> how many MX23/MX28 users of old DTs with new kernels are there who >> >> cannot update the DT as well ? >> > >> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old >> > bindings are also used by 3rd-party boards for imx6/7: >> > * imx6sx-nitrogen6sx >> > * imx6ul-geam >> > * imx6ul-isiot >> > * imx6ul-opos6uldev >> > * imx6ul-pico-hobbit >> > * imx6ul-tx6ul >> > * imx7d-nitrogen7 >> >> Er, yes, a handful of boards which could be updated :) >> >> > Converting everything might be quite a bit of work, and explicitly >> > supporting old bindings is also work. >> >> Does adding support for old bindings justify the effort invested ? I >> doubt so, it only adds more code to maintain. >> >> > It is very confusing that there is a whole set of displays for imx6/7 >> > which are supported by upstream but only with a non-default config. >> > While it is extremely common in the embedded field to have custom >> > configs the default one in the kernel should try to "just work". >> > >> > Couldn't this patch series be considered a bugfix? It was also >> > surprisingly small. >> >> I think it's just a workaround which allows you to postpone the real >> fix, and I don't like that. > > Yeah agreed, imo the proper fix here would be to either update the dts for > the affected boards and/or make mxsfb accept the old dt bindings for > backwards compat. Artificially extending the life of the fbdev drivers > seems silly. We shouldn't have merged a DRM driver with a driver name which conflicts with an existing driver... If anything, this is artificially shortening the lifetime of the fbdev driver :-) Again, I am ok with removing the driver. I just think it is silly to do it just because of the conflicting driver name. Maybe Sascha, original author of the mxs fbdev driver has an opinion on this? -- Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] dma_buf: remove device parameter from attach callback
On Fri, Jun 01, 2018 at 02:00:16PM +0200, Christian König wrote:
> The device parameter is completely unused because it is available in the
> attachment structure as well.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-buf.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 3 +--
> drivers/gpu/drm/drm_prime.c | 3 +--
> drivers/gpu/drm/udl/udl_dmabuf.c | 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 1 -
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 2 +-
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 2 +-
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 2 +-
> include/drm/drm_prime.h | 2 +-
> include/linux/dma-buf.h | 3 +--
> 10 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index d78d5fc173dc..e99a8d19991b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -568,7 +568,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
> *dmabuf,
> mutex_lock(&dmabuf->lock);
>
> if (dmabuf->ops->attach) {
> - ret = dmabuf->ops->attach(dmabuf, dev, attach);
> + ret = dmabuf->ops->attach(dmabuf, attach);
> if (ret)
> goto err_attach;
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index 4683626b065f..f1500f1ec0f5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> @@ -133,7 +133,6 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
> }
>
> static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
> - struct device *target_dev,
>struct dma_buf_attachment *attach)
> {
> struct drm_gem_object *obj = dma_buf->priv;
> @@ -141,7 +140,7 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> long r;
>
> - r = drm_gem_map_attach(dma_buf, target_dev, attach);
> + r = drm_gem_map_attach(dma_buf, attach);
> if (r)
> return r;
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7856a9b3f8a8..4a3a232fea67 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -186,7 +186,6 @@ static int drm_prime_lookup_buf_handle(struct
> drm_prime_file_private *prime_fpri
> /**
> * drm_gem_map_attach - dma_buf attach implementation for GEM
> * @dma_buf: buffer to attach device to
> - * @target_dev: not used
> * @attach: buffer attachment data
> *
> * Allocates &drm_prime_attachment and calls &drm_driver.gem_prime_pin for
> @@ -195,7 +194,7 @@ static int drm_prime_lookup_buf_handle(struct
> drm_prime_file_private *prime_fpri
> *
> * Returns 0 on success, negative error code on failure.
> */
> -int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
> +int drm_gem_map_attach(struct dma_buf *dma_buf,
> struct dma_buf_attachment *attach)
> {
> struct drm_prime_attachment *prime_attach;
> diff --git a/drivers/gpu/drm/udl/udl_dmabuf.c
> b/drivers/gpu/drm/udl/udl_dmabuf.c
> index 2867ed155ff6..5fdc8bdc2026 100644
> --- a/drivers/gpu/drm/udl/udl_dmabuf.c
> +++ b/drivers/gpu/drm/udl/udl_dmabuf.c
> @@ -29,7 +29,6 @@ struct udl_drm_dmabuf_attachment {
> };
>
> static int udl_attach_dma_buf(struct dma_buf *dmabuf,
> - struct device *dev,
> struct dma_buf_attachment *attach)
> {
> struct udl_drm_dmabuf_attachment *udl_attach;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
> index 0d42a46521fc..fbffb37ccf42 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
> @@ -40,7 +40,6 @@
> */
>
> static int vmw_prime_map_attach(struct dma_buf *dma_buf,
> - struct device *target_dev,
> struct dma_buf_attachment *attach)
> {
> return -ENOSYS;
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index f1178f6f434d..12d0072c52c2 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -222,7 +222,7 @@ struct vb2_dc_attachment {
> enum dma_data_direction dma_dir;
> };
>
> -static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device *dev,
> +static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf,
> struct dma_buf_attachment *dbuf_attach)
> {
> struct vb2_dc_attachment *attach;
> diff --git a/drivers/media/common/videobuf2/v
[Bug 106879] Ugly bug present in kernels 4.14, 4.15, 4.16, 4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106879 --- Comment #3 from javcasalc --- $ cat /var/log/Xorg.0.log [ 6.892] (--) Log file renamed from "/var/log/Xorg.pid-1146.log" to "/var/log/Xorg.0.log" [ 6.893] X.Org X Server 1.19.6 Release Date: 2017-12-20 [ 6.893] X Protocol Version 11, Revision 0 [ 6.893] Build Operating System: Linux 4.17.0-1-MANJARO x86_64 [ 6.893] Current Operating System: Linux hpzbook 4.17.0-2-MANJARO #1 SMP PREEMPT Fri Jun 8 07:13:17 UTC 2018 x86_64 [ 6.893] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.17-x86_64 root=UUID=a3029513-f1e8-4a4d-8ca9-29722da10afd rw quiet splash resume=UUID=4d14319d-10d0-47c3-8253-66a8880dd983 [ 6.893] Build Date: 20 May 2018 06:17:37PM [ 6.893] [ 6.893] Current version of pixman: 0.34.0 [ 6.893]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 6.893] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 6.893] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jun 18 10:11:28 2018 [ 6.894] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 6.894] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 6.894] (==) No Layout section. Using the first Screen section. [ 6.894] (==) No screen section available. Using defaults. [ 6.894] (**) |-->Screen "Default Screen Section" (0) [ 6.894] (**) | |-->Monitor "" [ 6.895] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 6.895] (==) Automatically adding devices [ 6.895] (==) Automatically enabling devices [ 6.895] (==) Automatically adding GPU devices [ 6.895] (==) Automatically binding GPU devices [ 6.895] (==) Max clients allowed: 256, resource mask: 0x1f [ 6.895] (WW) The directory "/usr/share/fonts/OTF/" does not exist. [ 6.895]Entry deleted from font path. [ 6.895] (WW) The directory "/usr/share/fonts/Type1/" does not exist. [ 6.895]Entry deleted from font path. [ 6.895] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/100dpi/". [ 6.895]Entry deleted from font path. [ 6.895](Run 'mkfontdir' on "/usr/share/fonts/100dpi/"). [ 6.895] (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/75dpi/". [ 6.895]Entry deleted from font path. [ 6.895](Run 'mkfontdir' on "/usr/share/fonts/75dpi/"). [ 6.895] (==) FontPath set to: /usr/share/fonts/misc/, /usr/share/fonts/TTF/ [ 6.895] (==) ModulePath set to "/usr/lib/xorg/modules" [ 6.895] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 6.895] (II) Loader magic: 0x561eb7409d40 [ 6.895] (II) Module ABI versions: [ 6.895]X.Org ANSI C Emulation: 0.4 [ 6.895]X.Org Video Driver: 23.0 [ 6.895]X.Org XInput driver : 24.1 [ 6.895]X.Org Server Extension : 10.0 [ 6.896] (++) using VT number 1 [ 6.897] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [ 6.898] (II) xfree86: Adding drm device (/dev/dri/card0) [ 6.900] (II) xfree86: Adding drm device (/dev/dri/card1) [ 6.906] (--) PCI:*(0:0:2:0) 8086:5917:103c:83b2 rev 7, Mem @ 0x1ff200/16777216, 0xb000/268435456, I/O @ 0x4000/64, BIOS @ 0x/131072 [ 6.906] (--) PCI: (0:1:0:0) 1002:6985:103c:83b5 rev 0, Mem @ 0xc000/268435456, 0xd000/2097152, 0xea30/262144, I/O @ 0x3000/256, BIOS @ 0x/131072 [ 6.906] (II) Open ACPI successful (/var/run/acpid.socket) [ 6.906] (II) LoadModule: "glx" [ 6.907] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 6.909] (II) Module glx: vendor="X.Org Foundation" [ 6.909]compiled for 1.19.6, module version = 1.0.0 [ 6.909]ABI class: X.Org Server Extension, version 10.0 [ 6.909] (II) Applying OutputClass "intel" to /dev/dri/card0 [ 6.909]loading driver: modesetting [ 6.909] (II) Applying OutputClass "AMDgpu" to /dev/dri/card1 [ 6.910]loading driver: amdgpu [ 6.910] (==) Matched modesetting as autoconfigured driver 0 [ 6.910] (==) Matched intel as autoconfigured driver 1 [ 6.910] (==) Matched amdgpu as autoconfigured driver 2 [ 6.910] (==) Matched ati as autoconfigured driver 3 [ 6.910] (==) Matched intel as autoconfigured driver 4 [ 6.910] (==) Matched modesetting as autoconfigured driver 5 [ 6.910] (==) Matched fbdev as autoconfigured driver 6 [ 6.910] (==) Matched vesa as autoconfigured driver 7 [ 6.910] (==) Assigned the driver to the xf86ConfigLayout [ 6.910] (II) LoadModule: "modesetting" [ 6.910] (II) Loading /usr/lib/x
Re: [PATCH 05/14] drm/sti: Try to fix up the tvout possible clones
2018-06-15 18:49 GMT+02:00 Ville Syrjala : > From: Ville Syrjälä > > The current possible_clones setup doesn't look sensible. I'm assuming > the 0 and 1 are supposed to refer to the indexes of the hdmi and hda > encoders? So it kinda looks like we want hda+hdmi cloning, but then > dvo also claims to be cloneable with hdmi, but hdmi won't recipricate. All cloning combinaisons are possible: hdmi+hda, hda+dvo, hdmi+dvo. The correct solution should be: possible_clones = drm_encoder_mask(tvout->hdmi) | drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); Thanks, Benjamin > > So let's assume we just want hdmi+hda and nothing more and populate the > possible_clones to match. The docs say the encoder itself should always > be included in the possible_clones bitmask so we'll throw it in there > as well. For hda we'll leave possible_clones==0 and we'll add a global > fallback for that case to add the encoder itself to the bitmask since > that makes life easier for most drivers. > > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/sti/sti_tvout.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c > index 7d495307fe79..2359c111c7ed 100644 > --- a/drivers/gpu/drm/sti/sti_tvout.c > +++ b/drivers/gpu/drm/sti/sti_tvout.c > @@ -668,7 +668,6 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, > drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > &sti_tvout_encoder_funcs, DRM_MODE_ENCODER_LVDS, > @@ -721,7 +720,6 @@ static struct drm_encoder > *sti_tvout_create_hda_encoder(struct drm_device *dev, > drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > &sti_tvout_encoder_funcs, DRM_MODE_ENCODER_DAC, NULL); > @@ -770,7 +768,6 @@ static struct drm_encoder > *sti_tvout_create_hdmi_encoder(struct drm_device *dev, > drm_encoder = &encoder->encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 1; > > drm_encoder_init(dev, drm_encoder, > &sti_tvout_encoder_funcs, DRM_MODE_ENCODER_TMDS, > NULL); > @@ -786,6 +783,12 @@ static void sti_tvout_create_encoders(struct drm_device > *dev, > tvout->hdmi = sti_tvout_create_hdmi_encoder(dev, tvout); > tvout->hda = sti_tvout_create_hda_encoder(dev, tvout); > tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout); > + > + /* FIXME what's the correct thing here? */ > + tvout->hdmi->possible_clones = > + drm_encoder_mask(tvout->hdmi) | drm_encoder_mask(tvout->hda); > + tvout->hda->possible_clones = > + drm_encoder_mask(tvout->hdmi) | drm_encoder_mask(tvout->hda); > } > > static void sti_tvout_destroy_encoders(struct sti_tvout *tvout) > -- > 2.16.4 > -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: no mouse cursor on nv50
On Mon, Jun 18, 2018 at 7:46 AM, Adam Borowski wrote: > Hi! > On v4.18-rc1, the mouse cursor is missing on my right monitor. > Card is G98 [GeForce 8400 GS Rev. 2]. > > I have two monitors: one small landscape 1280x1024 on DVI-I-1 left, and one > big 1600x1200 (1200x1600 portrait) on HDMI-1 right. Curiously, the cursor > is missing not only with proper xrandr setup after logging in but even in > mirrored mode at the lightdm greeter[1]. How is this even possible if both > screens are supposed to be identical? > > Bisected: > # bad: [ce397d215ccd07b8ae3f71db689aedb85d56ab40] Linux 4.18-rc1 > # good: [29dcea88779c856c7dc92040a0c01233263101d4] Linux 4.17 > git bisect start 'v4.18-rc1' 'v4.17' > # bad: [1c8c5a9d38f607c0b6fd12c91cbe1a4418762a21] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next > git bisect bad 1c8c5a9d38f607c0b6fd12c91cbe1a4418762a21 > # bad: [135c5504a600ff9b06e321694fbcac78a9530cd4] Merge tag > 'drm-next-2018-06-06-1' of git://anongit.freedesktop.org/drm/drm > git bisect bad 135c5504a600ff9b06e321694fbcac78a9530cd4 > # good: [5231804cf9e584f3e7e763a0d6d2fffe011c1bce] Merge tag > 'leds_for_4.18-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds > git bisect good 5231804cf9e584f3e7e763a0d6d2fffe011c1bce > # good: [315852b422972e6ebb1dfddaadada09e46a2681a] drm: rcar-du: Fix build > failure > git bisect good 315852b422972e6ebb1dfddaadada09e46a2681a > # good: [ec064d3c6b40697fd72f4b1eeabbf293b7947a04] Merge tag > 'driver-core-4.18-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core > git bisect good ec064d3c6b40697fd72f4b1eeabbf293b7947a04 > # bad: [ce234ccc03cfee004e168a1ae4b9d0cfb1974a32] Merge tag > 'drm/tegra/for-4.18-rc1' of git://anongit.freedesktop.org/tegra/linux into > drm-next > git bisect bad ce234ccc03cfee004e168a1ae4b9d0cfb1974a32 > # bad: [d7c6e97a32329032ba7af1f53cab2767832fed77] drm/nouveau/kms/nv50-: > modify base allocation so the code can be split > git bisect bad d7c6e97a32329032ba7af1f53cab2767832fed77 > # good: [0a5b97304b9e2cd07c78a399c5395d5fb0118341] drm/nouveau/gr/gf100-: > virtualise init_sked_hww_esr > git bisect good 0a5b97304b9e2cd07c78a399c5395d5fb0118341 > # good: [18d17221dd58741a8590ba0a40a9ded82aa5d619] drm/nouveau/gr/gf100-: > virtualise r419e00 > git bisect good 18d17221dd58741a8590ba0a40a9ded82aa5d619 > # good: [e9d03335f604a1123b8de3103ce8e06db4ad777a] drm/nouveau/gr/gp100-: use > correct registers for zbc colour/depth setup > git bisect good e9d03335f604a1123b8de3103ce8e06db4ad777a > # good: [512fa0b8a398539c3c2db251f6c40da4ef065d09] drm/nouveau/drm/nv50-: > remove allocation of sw class > git bisect good 512fa0b8a398539c3c2db251f6c40da4ef065d09 > # good: [62b290fc7b36e8fec2a370b946d7117c1899b6c1] drm/nouveau/kms/nv50-: fix > i2c-over-aux on anx9805 > git bisect good 62b290fc7b36e8fec2a370b946d7117c1899b6c1 > # bad: [a97c530eb968bad8d945d4f64fb550fa37a9d362] drm/nouveau/kms/nv50-: > modify overlay allocation so the code can be split > git bisect bad a97c530eb968bad8d945d4f64fb550fa37a9d362 > # bad: [5bca1621c07c3ad37b5a4943450a892e18984df0] drm/nouveau/kms/nv50-: move > fb ctxdma tracking into windows > git bisect bad 5bca1621c07c3ad37b5a4943450a892e18984df0 > # first bad commit: [5bca1621c07c3ad37b5a4943450a892e18984df0] > drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows > > Alas, the bad commit can't be easily reverted as there's a lot of further > work on the file on question. Thanks for the report! Can you give https://github.com/skeggsb/linux/commit/fffdc521f313031b1745a264ec0d5c848c2475d1 a try and see if it helps the issue you're seeing? I'm presuming gnome must either render the cursor in sw, or at lease have some kind of fallback, as multi-head cursors are working fine here, which is why I didn't notice the issue earlier. Ben. > > Meow! > > [1]. It's possible to setup lightdm for proper layout even on the login > screen, but that gives only aesthetic bonus while possibly causing problems > when the layout changes. > -- > ⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones. > ⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes > ⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious. It's also interesting to see OSes > ⠈⠳⣄ go back and forth wrt their intended target. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm: Replace drm_dev_unref with drm_dev_put
2018-06-09 15:18 GMT+02:00 Thomas Zimmermann : > This patch unifies the naming of DRM functions for reference counting > of struct drm_device. The resulting code is more aligned with the rest > of the Linux kernel interfaces. > > The patch also deletes the old function and removes it from the > Coccinelle script. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 ++-- > drivers/gpu/drm/arc/arcpgu_drv.c | 8 > drivers/gpu/drm/armada/armada_drv.c| 6 +++--- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 > drivers/gpu/drm/drm_drv.c | 13 - > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 > drivers/gpu/drm/exynos/exynos_drm_drv.c| 4 ++-- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 8 > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c| 4 ++-- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c| 8 > drivers/gpu/drm/i915/selftests/huge_pages.c| 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_context.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_evict.c| 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_object.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 2 +- > drivers/gpu/drm/imx/imx-drm-core.c | 8 > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +++--- > drivers/gpu/drm/msm/msm_drv.c | 8 > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 ++-- > drivers/gpu/drm/nouveau/nouveau_platform.c | 2 +- > drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++-- > drivers/gpu/drm/pl111/pl111_drv.c | 14 +++--- > drivers/gpu/drm/qxl/qxl_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 4 ++-- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 ++-- > drivers/gpu/drm/sti/sti_drv.c | 8 For sti: Acked-by: Benjamin Gaignard > drivers/gpu/drm/stm/drv.c | 10 +- > drivers/gpu/drm/sun4i/sun4i_drv.c | 4 ++-- > drivers/gpu/drm/tegra/drm.c| 8 > drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 6 +++--- > drivers/gpu/drm/tve200/tve200_drv.c| 10 +- > drivers/gpu/drm/udl/udl_drv.c | 2 +- > drivers/gpu/drm/vc4/vc4_drv.c | 8 > drivers/gpu/drm/vgem/vgem_drv.c| 2 +- > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 2 +- > drivers/gpu/drm/zte/zx_drm_drv.c | 4 ++-- > include/drm/drm_drv.h | 1 - > scripts/coccinelle/api/drm-get-put.cocci | 3 --- > 43 files changed, 99 insertions(+), 116 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index b0bf2f24da48..cf5b18e7d8db 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -664,7 +664,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, > err_pci: > pci_disable_device(pdev); > err_free: > - drm_dev_unref(dev); > + drm_dev_put(dev); > return ret; > } > > @@ -674,7 +674,7 @@ amdgpu_pci_remove(struct pci_dev *pdev) > struct drm_device *dev = pci_get_drvdata(pdev); > > drm_dev_unregister(dev); > - drm_dev_unref(dev); > + drm_dev_put(dev); > pci_disable_device(pdev); > pci_set_drvdata(pdev, NULL); > } > diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c > b/drivers/gpu/drm/arc/arcpgu_drv.c > index f067de4e1e82..27d426bf7d01 100644 > --- a/drivers/gpu/drm/arc/arcpgu_drv.c > +++ b/drivers/gpu/drm/arc/arcpgu_drv.c > @@ -204,7 +204,7 @@ static int arcpgu_probe(struct platform_device *pdev) > > ret = arcpgu_load(drm); > if (ret) > - goto err_unref; > + goto err_put; > > ret = drm_dev_register(drm, 0); > if (ret) > @@ -215,8 +215,8 @@ static int arcpgu_probe(struct platform_device *pdev) > err_unload: > arcpgu_unload(drm); > > -err_unref: > - drm_dev_unref(drm); > +err_put: > + drm_dev_put(drm); > > return ret; > } > @@ -227,7 +227,7 @@ static int arcpgu_remove(struct platform_device *pdev) > > drm_dev_unregister(drm); > arcpgu_unload(drm); > - drm_dev_unref(drm); > + drm_dev_put(drm); > > return 0; > } > diff --git a/drivers/gpu/drm/armada/armada_drv.c > b/dr
Re: [PATCH 2/5] dma-buf: remove kmap_atomic interface
On Fri, Jun 01, 2018 at 02:00:17PM +0200, Christian König wrote:
> Neither used nor correctly implemented anywhere. Just completely remove
> the interface.
>
> Signed-off-by: Christian König
I wonder whether we can nuke the normal kmap stuff too ... everyone seems
to want/use the vmap stuff for kernel-internal mapping needs.
Anyway, this looks good.
> ---
> drivers/dma-buf/dma-buf.c | 44
> --
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 2 -
> drivers/gpu/drm/armada/armada_gem.c| 2 -
> drivers/gpu/drm/drm_prime.c| 26 -
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 11 --
> drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 2 -
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 -
> drivers/gpu/drm/tegra/gem.c| 14 ---
> drivers/gpu/drm/udl/udl_dmabuf.c | 17 -
> drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 13 ---
> .../media/common/videobuf2/videobuf2-dma-contig.c | 1 -
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 1 -
> drivers/media/common/videobuf2/videobuf2-vmalloc.c | 1 -
> drivers/staging/android/ion/ion.c | 2 -
> drivers/tee/tee_shm.c | 6 ---
> include/drm/drm_prime.h| 4 --
> include/linux/dma-buf.h| 4 --
> 17 files changed, 152 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index e99a8d19991b..e4c657d9fad7 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,7 +405,6 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> - || !exp_info->ops->map_atomic
> || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
> return ERR_PTR(-EINVAL);
> @@ -687,14 +686,6 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> * void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
> * void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
> *
> - * There are also atomic variants of these interfaces. Like for kmap they
> - * facilitate non-blocking fast-paths. Neither the importer nor the
> exporter
> - * (in the callback) is allowed to block when using these.
> - *
> - * Interfaces::
> - * void \*dma_buf_kmap_atomic(struct dma_buf \*, unsigned long);
> - * void dma_buf_kunmap_atomic(struct dma_buf \*, unsigned long, void
> \*);
> - *
> * For importers all the restrictions of using kmap apply, like the limited
> * supply of kmap_atomic slots. Hence an importer shall only hold onto at
> * max 2 atomic dma_buf kmaps at the same time (in any given process
> context).
This is also about atomic kmap ...
And the subsequent language around "Note that these calls need to always
succeed." is also not true, might be good to update that stating that kmap
is optional (like we say already for vmap).
With those docs nits addressed:
Reviewed-by: Daniel Vetter
> @@ -859,41 +850,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> }
> EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
>
> -/**
> - * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address
> - * space. The same restrictions as for kmap_atomic and friends apply.
> - * @dmabuf: [in]buffer to map page from.
> - * @page_num:[in]page in PAGE_SIZE units to map.
> - *
> - * This call must always succeed, any necessary preparations that might fail
> - * need to be done in begin_cpu_access.
> - */
> -void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num)
> -{
> - WARN_ON(!dmabuf);
> -
> - return dmabuf->ops->map_atomic(dmabuf, page_num);
> -}
> -EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
> -
> -/**
> - * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic.
> - * @dmabuf: [in]buffer to unmap page from.
> - * @page_num:[in]page in PAGE_SIZE units to unmap.
> - * @vaddr: [in]kernel space pointer obtained from dma_buf_kmap_atomic.
> - *
> - * This call must always succeed.
> - */
> -void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num,
> -void *vaddr)
> -{
> - WARN_ON(!dmabuf);
> -
> - if (dmabuf->ops->unmap_atomic)
> - dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
> -}
> -EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
> -
> /**
> * dma_buf_kmap - Map a page of the buffer object into kernel address space.
> The
> * same restrictions as for kmap and friends apply.
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index f1500f1e
Re: [PATCH v4 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
Hi Marc,
Am Mittwoch, 13. Juni 2018, 15:01:27 CEST schrieb Marc Zyngier:
> On 12/06/18 14:20, Heiko Stuebner wrote:
> > From: Sandy Huang
> >
> > The vop irq is shared between vop and iommu and irq probing in the
> > iommu driver moved to the probe function recently. This can in some
> > cases lead to a stall if the irq is triggered while the vop driver
> > still has it disabled, but the vop irq handler gets called.
> >
> > But there is no real need to disable the irq, as the vop can simply
> > also track its enabled state and ignore irqs in that case.
> > For this we can simply check the power-domain state of the vop,
> > similar to how the iommu driver does it.
> >
> > So remove the enable/disable handling and add appropriate condition
> > to the irq handler.
> >
> > changes in v2:
> > - move to just check the power-domain state
> > - add clock handling
> > changes in v3:
> > - clarify comment to speak of runtime-pm not power-domain
> > changes in v4:
> > - address Marc's comments (clk-enable WARN_ON and style improvement)
> >
> > Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Sandy Huang
> > Signed-off-by: Heiko Stuebner
> > Tested-by: Ezequiel Garcia
>
> Reviewed-by: Marc Zyngier
could I ask you to also look at patch1 of this series, to give it an
Ack or Review? drm-misc documentation very strongly suggests [0]
to have at least another set of eyes on a patch and so far noone
came forward ;-)
This of course also applies to everybody else in the Cc list :-D .
Thanks
Heiko
[0]
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#merge-criteria
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] dma-buf: lock the reservation object during (un)map_dma_buf
On Fri, Jun 01, 2018 at 02:00:18PM +0200, Christian König wrote:
> First step towards unpinned DMA buf operation.
>
> I've checked the DRM drivers to potential locking of the reservation
> object, but essentially we need to audit all implementations of the
> dma_buf _ops for this to work.
>
> Signed-off-by: Christian König
Agreed in principle, but I expect a fireworks show with just this patch
applied. It's not just that we need to audit all the implementations of
dma-buf-ops, we also need to audit all the callers.
No idea yet how to go about merging this, but for a start might be good to
throw this at the intel-gfx CI (just Cc: the intel-gfx mailing lists, but
make sure your series applies without amd-staging-next stuff which isn't
in drm.git yet).
-Daniel
> ---
> drivers/dma-buf/dma-buf.c | 4
> include/linux/dma-buf.h | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index e4c657d9fad7..4f0708cb58a7 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -631,7 +631,9 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> if (WARN_ON(!attach || !attach->dmabuf))
> return ERR_PTR(-EINVAL);
>
> + reservation_object_lock(attach->dmabuf->resv, NULL);
> sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> + reservation_object_unlock(attach->dmabuf->resv);
> if (!sg_table)
> sg_table = ERR_PTR(-ENOMEM);
>
> @@ -658,8 +660,10 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
> return;
>
> + reservation_object_lock(attach->dmabuf->resv, NULL);
> attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
> direction);
> + reservation_object_unlock(attach->dmabuf->resv);
> }
> EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d17cadd76802..d2ba7a027a78 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -118,6 +118,8 @@ struct dma_buf_ops {
>* any other kind of sharing that the exporter might wish to make
>* available to buffer-users.
>*
> + * This is called with the dmabuf->resv object locked.
> + *
>* Returns:
>*
>* A &sg_table scatter list of or the backing storage of the DMA buffer,
> @@ -138,6 +140,8 @@ struct dma_buf_ops {
>* It should also unpin the backing storage if this is the last mapping
>* of the DMA buffer, it the exporter supports backing storage
>* migration.
> + *
> + * This is called with the dmabuf->resv object locked.
>*/
> void (*unmap_dma_buf)(struct dma_buf_attachment *,
> struct sg_table *,
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
On Wed, Jun 13, 2018 at 10:16:47AM +0200, Paul Kocialkowski wrote: > This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70. > > The offending commit triggers a run-time fault when accessing the panel > element of the sun4i_tcon structure when no such panel is attached. > > It was apparently assumed in said commit that a panel is always used with > the TCON. Although it is often the case, this is not always true. > For instance a bridge might be used instead of a panel. > > This issue was discovered using an A13-OLinuXino, that uses the TCON > in RGB mode for a simple DAC-based VGA bridge. > > Cc: sta...@vger.kernel.org > Signed-off-by: Paul Kocialkowski Applied, thanks Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] dma-buf: add dma_buf_(un)map_attachment_locked variants
On Fri, Jun 01, 2018 at 02:00:19PM +0200, Christian König wrote:
> Add function variants which can be called with the reservation lock
> already held.
>
> Signed-off-by: Christian König
I expect that we'll need this patch before patch 3 and then roll it out to
drivers doing reservation locking already, before we can add the
reservation stuff for all other callers.
> ---
> drivers/dma-buf/dma-buf.c | 60
> ++-
> include/linux/dma-buf.h | 5
> 2 files changed, 59 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 4f0708cb58a7..3371509b468e 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -606,6 +606,38 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
> dma_buf_attachment *attach)
> }
> EXPORT_SYMBOL_GPL(dma_buf_detach);
>
> +/**
> + * dma_buf_map_attachment_locked - Maps the buffer into _device_ address
> space
> + * with the reservation lock held. Is a wrapper for map_dma_buf() of the
> + *
> + * Returns the scatterlist table of the attachment;
> + * dma_buf_ops.
> + * @attach: [in]attachment whose scatterlist is to be returned
> + * @direction: [in]direction of DMA transfer
> + *
> + * Returns sg_table containing the scatterlist to be returned; returns
> ERR_PTR
> + * on error. May return -EINTR if it is interrupted by a signal.
> + *
> + * A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that
_locked
Also please reference the other variants here for doc completeness.
> + * the underlying backing storage is pinned for as long as a mapping exists,
> + * therefore users/importers should not hold onto a mapping for undue
> amounts of
> + * time.
> + */
> +struct sg_table *
> +dma_buf_map_attachment_locked(struct dma_buf_attachment *attach,
> + enum dma_data_direction direction)
> +{
> + struct sg_table *sg_table;
> +
> + might_sleep();
Needs a lockdep_assert_held here.
> + sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> + if (!sg_table)
> + sg_table = ERR_PTR(-ENOMEM);
> +
> + return sg_table;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_map_attachment_locked);
> +
> /**
> * dma_buf_map_attachment - Returns the scatterlist table of the attachment;
> * mapped into _device_ address space. Is a wrapper for map_dma_buf() of the
> @@ -626,13 +658,12 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> {
> struct sg_table *sg_table;
>
> - might_sleep();
>
> if (WARN_ON(!attach || !attach->dmabuf))
> return ERR_PTR(-EINVAL);
>
> reservation_object_lock(attach->dmabuf->resv, NULL);
> - sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> + sg_table = dma_buf_map_attachment_locked(attach, direction);
> reservation_object_unlock(attach->dmabuf->resv);
> if (!sg_table)
> sg_table = ERR_PTR(-ENOMEM);
> @@ -641,6 +672,26 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> }
> EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
>
> +/**
> + * dma_buf_unmap_attachment_locked - unmaps the buffer with reservation lock
> + * held, should deallocate the associated scatterlist. Is a wrapper for
> + * unmap_dma_buf() of dma_buf_ops.
> + * @attach: [in]attachment to unmap buffer from
> + * @sg_table:[in]scatterlist info of the buffer to unmap
> + * @direction: [in]direction of DMA transfer
> + *
> + * This unmaps a DMA mapping for @attached obtained by
> dma_buf_map_attachment().
_locked
> + */
> +void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *attach,
> + struct sg_table *sg_table,
> + enum dma_data_direction direction)
> +{
> + might_sleep();
Needs a lockdep_assert_held here.
Otherwise lgtm, but there's the big caveat of that I expect lockdep
fireworks on mass with this, but drivers not yet converted.
-Daniel
> + attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
> + direction);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
> +
> /**
> * dma_buf_unmap_attachment - unmaps and decreases usecount of the
> buffer;might
> * deallocate the scatterlist associated. Is a wrapper for unmap_dma_buf() of
> @@ -655,14 +706,11 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> struct sg_table *sg_table,
> enum dma_data_direction direction)
> {
> - might_sleep();
> -
> if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
> return;
>
> reservation_object_lock(attach->dmabuf->resv, NULL);
> - attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
> - direction);
> + dma_buf_unmap_attachment_lock
[PATCH 4.16 059/279] drm/msm: dont deref error pointer in the msm_fbdev_create error path
4.16-stable review patch. If anyone has any objections, please let me know.
--
From: Emil Velikov
[ Upstream commit 789d4c300e10eb2096ee83c3497118e67ccc951e ]
Currently the error pointer returned by msm_alloc_stolen_fb gets passed
to drm_framebuffer_remove. The latter handles only NULL pointers, thus
a nasty crash will occur.
Drop the unnecessary fail label and the associated checks - both err and
fb will be set at this stage.
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Emil Velikov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/msm/msm_fbdev.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -92,8 +92,7 @@ static int msm_fbdev_create(struct drm_f
if (IS_ERR(fb)) {
dev_err(dev->dev, "failed to allocate fb\n");
- ret = PTR_ERR(fb);
- goto fail;
+ return PTR_ERR(fb);
}
bo = msm_framebuffer_bo(fb, 0);
@@ -151,13 +150,7 @@ static int msm_fbdev_create(struct drm_f
fail_unlock:
mutex_unlock(&dev->struct_mutex);
-fail:
-
- if (ret) {
- if (fb)
- drm_framebuffer_remove(fb);
- }
-
+ drm_framebuffer_remove(fb);
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/amdgpu: add independent DMA-buf export v3
On Fri, Jun 01, 2018 at 02:00:20PM +0200, Christian König wrote:
> The caching of SGT's done by the DRM code is actually quite harmful and
> should probably removed altogether in the long term.
Hm, why is it harmful? We've done it because it's expensive, and people
started screaming about the overhead ... hence the caching. Doing an
amdgpu copypasta seems like working around issues in shared code.
-Daniel
>
> Start by providing a separate DMA-buf export implementation in amdgpu. This is
> also a prerequisite of unpinned DMA-buf handling.
>
> v2: fix unintended recursion, remove debugging leftovers
> v3: split out from unpinned DMA-buf work
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 73
> ++-
> 3 files changed, 32 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 2d7500921c0b..93dc57d74fc2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -373,7 +373,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
> void amdgpu_gem_object_close(struct drm_gem_object *obj,
> struct drm_file *file_priv);
> unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
> -struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
> struct drm_gem_object *
> amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
>struct dma_buf_attachment *attach,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index b0bf2f24da48..270b8ad927ea 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -907,7 +907,6 @@ static struct drm_driver kms_driver = {
> .gem_prime_export = amdgpu_gem_prime_export,
> .gem_prime_import = amdgpu_gem_prime_import,
> .gem_prime_res_obj = amdgpu_gem_prime_res_obj,
> - .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
> .gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
> .gem_prime_vmap = amdgpu_gem_prime_vmap,
> .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index a156b3891a3f..0c5a75b06648 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> @@ -32,14 +32,6 @@
>
> static const struct dma_buf_ops amdgpu_dmabuf_ops;
>
> -struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
> -{
> - struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> - int npages = bo->tbo.num_pages;
> -
> - return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
> -}
> -
> void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
> {
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> @@ -132,23 +124,17 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
> return ERR_PTR(ret);
> }
>
> -static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
> - struct dma_buf_attachment *attach)
> +static struct sg_table *
> +amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
> +enum dma_data_direction dir)
> {
> + struct dma_buf *dma_buf = attach->dmabuf;
> struct drm_gem_object *obj = dma_buf->priv;
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> + struct sg_table *sgt;
> long r;
>
> - r = drm_gem_map_attach(dma_buf, attach);
> - if (r)
> - return r;
> -
> - r = amdgpu_bo_reserve(bo, false);
> - if (unlikely(r != 0))
> - goto error_detach;
> -
> -
> if (attach->dev->driver != adev->dev->driver) {
> /*
>* Wait for all shared fences to complete before we switch to
> future
> @@ -159,46 +145,53 @@ static int amdgpu_gem_map_attach(struct dma_buf
> *dma_buf,
> MAX_SCHEDULE_TIMEOUT);
> if (unlikely(r < 0)) {
> DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
> - goto error_unreserve;
> + return ERR_PTR(r);
> }
> }
>
> /* pin buffer into GTT */
> r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
> if (r)
> - goto error_unreserve;
> + return ERR_PTR(r);
> +
> + sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
> + if (IS_ERR(sgt))
> + return sgt;
> +
> + if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
> + DMA_ATTR_SKIP_CPU_SYNC))
> + goto error_free;
>
> if (attach->dev->dr
Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
Hi,
On 18-06-18 09:36, Ard Biesheuvel wrote:
Hallo Hans,
On 17 June 2018 at 17:32, Hans de Goede wrote:
On systems where fbcon is configured for deferred console takeover, the
intend is for the framebuffer to show the boot graphics (e.g a vendor
logo) until some message (e.g. an error) is printed or a graphical
session takes over.
Some firmware however relies on the OS to show the boot graphics
(indicated by bgrt_tab.status being 0) and the boot graphics may have
been destroyed by e.g. the grub boot menu.
This patch adds support to efifb to show the boot graphics and
automatically enables this when fbcon is configured for deferred
console takeover.
Signed-off-by: Hans de Goede
I have tested this code on ARM QEMU/mach-virt, and with a little tweak
(which I will post separately), the code works as expected, i.e., it
redraws the boot logo based on the contents of the BGRT table.
That is great.
However, what it doesn't do is clear the screen, which means the logo
is drawn on top of whatever the boot environment left behind, and I
end up with something like this.
http://people.linaro.org/~ard.biesheuvel/mach-virt-bgrt-logo-redrawn.png
Hmm, less great. I'm not sure how to deal with this, on x86 it is more
or less guaranteed that the screen is already cleared when we load and
clearing a 4k screen means writing about 32MB, which I guess with modern
RAM speeds is not that bad actually.
I see that you got this picture by manual booting from the EFI shell,
in what state does the firmware / bootloader normally leave the
framebuffer? I'm asking because if normally it is either cleared
to black, or already showing the logo I wonder if we should take the
(small) penalty of clearing ?
Given that we are talking about only 32 MB I could do a v2 which just
memsets the rest of the screen to 0.
So we get:
for (y= 0; y < height; y++) {
if (line_part_of_bgrt) {
memset(left-of-bgrt);
draw_bgrt_line(y);
memset(right-of-bgrt);
} else {
memset(line);
}
}
Note I've deliberately done the if on a per line
base to keep the actual blit part of the loop
efficient and without any extra conditionals in
there. I also don't simply first memset the entire
fb to 0 to avoid a flash / tearing if the bgrt
image is already in place (which happens often on
x86).
Implementing this is easy and as said the extra execution time should
be quite small, still I wonder what others think about this?
I'm leaning towards doing the clearing / memsets since I've seen
some firmwares leave some artifacts from not completely clearing
things like a "Press F2 to enter setup" message, missing a few
pixels and leaving those on screen.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 Michel Dänzer changed: What|Removed |Added CC||harry.wentl...@amd.com --- Comment #2 from Michel Dänzer --- Can you 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
[PATCH 4.14 038/189] drm/msm: dont deref error pointer in the msm_fbdev_create error path
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Emil Velikov
[ Upstream commit 789d4c300e10eb2096ee83c3497118e67ccc951e ]
Currently the error pointer returned by msm_alloc_stolen_fb gets passed
to drm_framebuffer_remove. The latter handles only NULL pointers, thus
a nasty crash will occur.
Drop the unnecessary fail label and the associated checks - both err and
fb will be set at this stage.
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Emil Velikov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/msm/msm_fbdev.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -92,8 +92,7 @@ static int msm_fbdev_create(struct drm_f
if (IS_ERR(fb)) {
dev_err(dev->dev, "failed to allocate fb\n");
- ret = PTR_ERR(fb);
- goto fail;
+ return PTR_ERR(fb);
}
bo = msm_framebuffer_bo(fb, 0);
@@ -151,13 +150,7 @@ static int msm_fbdev_create(struct drm_f
fail_unlock:
mutex_unlock(&dev->struct_mutex);
-fail:
-
- if (ret) {
- if (fb)
- drm_framebuffer_remove(fb);
- }
-
+ drm_framebuffer_remove(fb);
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200121] New: [amdgpu] DC: Unable to find connected outputs
https://bugzilla.kernel.org/show_bug.cgi?id=200121 Bug ID: 200121 Summary: [amdgpu] DC: Unable to find connected outputs Product: Drivers Version: 2.5 Kernel Version: 4.17.2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: nanericw...@gmail.com Regression: No Created attachment 276643 --> https://bugzilla.kernel.org/attachment.cgi?id=276643&action=edit Xorg log After upgrading to 4.17, the screen is totally blank. The X.org log shows: (WW) modeset(0): No outputs definitely connected, trying again... (WW) modeset(0): Unable to find connected outputs - setting 1024x768 initial framebuffer -- 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
[Bug 200121] [amdgpu] DC: Unable to find connected outputs
https://bugzilla.kernel.org/show_bug.cgi?id=200121 --- Comment #1 from nanericw...@gmail.com --- Created attachment 276645 --> https://bugzilla.kernel.org/attachment.cgi?id=276645&action=edit dmesg -- 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
[Bug 200121] [amdgpu] DC: Unable to find connected outputs
https://bugzilla.kernel.org/show_bug.cgi?id=200121 nanericw...@gmail.com changed: What|Removed |Added Attachment #276645|application/octet-stream|text/plain mime type|| Attachment #276645|dmesg |dmesg.log description|| -- 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 v7 3/6] mfd: cros-ec: Increase maximum mkbp event size
Hi Lee,
On 18/06/2018 09:44, Lee Jones wrote:
> On Fri, 01 Jun 2018, Neil Armstrong wrote:
>
>> Having a 16 byte mkbp event size makes it possible to send CEC
>> messages from the EC to the AP directly inside the mkbp event
>> instead of first doing a notification and then a read.
>>
>> Signed-off-by: Stefan Adolfsson
>> Signed-off-by: Neil Armstrong
>> Tested-by: Enric Balletbo i Serra
>> ---
>> drivers/platform/chrome/cros_ec_proto.c | 40
>> +
>> include/linux/mfd/cros_ec.h | 2 +-
>> include/linux/mfd/cros_ec_commands.h| 19
>> 3 files changed, 51 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_proto.c
>> b/drivers/platform/chrome/cros_ec_proto.c
>> index e7bbdf9..c4f6c44 100644
>> --- a/drivers/platform/chrome/cros_ec_proto.c
>> +++ b/drivers/platform/chrome/cros_ec_proto.c
>> @@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device
>> *ec_dev,
>> }
>> EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
>>
>> +static int get_next_event_xfer(struct cros_ec_device *ec_dev,
>> + struct cros_ec_command *msg,
>> + int version, uint32_t size)
>> +{
>> +int ret;
>> +
>> +msg->version = version;
>> +msg->command = EC_CMD_GET_NEXT_EVENT;
>> +msg->insize = size;
>> +msg->outsize = 0;
>> +
>> +ret = cros_ec_cmd_xfer(ec_dev, msg);
>> +if (ret > 0) {
>> +ec_dev->event_size = ret - 1;
>> +memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
>> +}
>> +
>> +return ret;
>> +}
>> +
>> static int get_next_event(struct cros_ec_device *ec_dev)
>> {
>> u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>> struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
>> +static int cmd_version = 1;
>> int ret;
>>
>> if (ec_dev->suspended) {
>> @@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device
>> *ec_dev)
>> return -EHOSTDOWN;
>> }
>>
>> -msg->version = 0;
>> -msg->command = EC_CMD_GET_NEXT_EVENT;
>> -msg->insize = sizeof(ec_dev->event_data);
>> -msg->outsize = 0;
>> +if (cmd_version == 1) {
>> +ret = get_next_event_xfer(ec_dev, msg, cmd_version,
>> +sizeof(struct ec_response_get_next_event_v1));
>> +if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
>> +return ret;
>>
>> -ret = cros_ec_cmd_xfer(ec_dev, msg);
>> -if (ret > 0) {
>> -ec_dev->event_size = ret - 1;
>> -memcpy(&ec_dev->event_data, msg->data,
>> - sizeof(ec_dev->event_data));
>> +/* Fallback to version 0 for future send attempts */
>> +cmd_version = 0;
>> }
>>
>> +ret = get_next_event_xfer(ec_dev, msg, cmd_version,
>> + sizeof(struct ec_response_get_next_event));
>> +
>> return ret;
>> }
>>
>> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
>> index f36125e..32caef3 100644
>> --- a/include/linux/mfd/cros_ec.h
>> +++ b/include/linux/mfd/cros_ec.h
>> @@ -147,7 +147,7 @@ struct cros_ec_device {
>> bool mkbp_event_supported;
>> struct blocking_notifier_head event_notifier;
>>
>> -struct ec_response_get_next_event event_data;
>> +struct ec_response_get_next_event_v1 event_data;
>> int event_size;
>> u32 host_event_wake_mask;
>> };
>> diff --git a/include/linux/mfd/cros_ec_commands.h
>> b/include/linux/mfd/cros_ec_commands.h
>> index f2edd99..cc0768e 100644
>> --- a/include/linux/mfd/cros_ec_commands.h
>> +++ b/include/linux/mfd/cros_ec_commands.h
>> @@ -2093,12 +2093,31 @@ union ec_response_get_next_data {
>> uint32_t sysrq;
>> } __packed;
>>
>> +union ec_response_get_next_data_v1 {
>> +uint8_t key_matrix[16];
>> +
>> +/* Unaligned */
>
> That's funny!
>
>> +uint32_t host_event;
>> +
>> +uint32_t buttons;
>> +uint32_t switches;
>> +uint32_t sysrq;
>> +uint32_t cec_events;
>> +uint8_tcec_message[16];
>
> Since there are some whitespace alignment issues in here.
>
>> +} __packed;
>
> How come these guys have kerneldoc headers?
Can you explicit what should be changed here ?
Thanks,
Neil
>
>> struct ec_response_get_next_event {
>> uint8_t event_type;
>> /* Followed by event data if any */
>> union ec_response_get_next_data data;
>> } __packed;
>>
>> +struct ec_response_get_next_event_v1 {
>> +uint8_t event_type;
>> +/* Followed by event data if any */
>> +union ec_response_get_next_data_v1 data;
>> +} __packed;
>> +
>> /* Bit indices for buttons and switches.*/
>> /* Buttons */
>> #define EC_MKBP_POWER_BUTTON0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/doc: Make naming consistent for Core Driver Infrastructure
On Wed, Jun 13, 2018 at 01:45:23PM -0400, Alex Deucher wrote: > On Mon, Jun 4, 2018 at 5:11 AM, Michel Dänzer wrote: > > > > Adding dri-devel. > > > > Any opinions? 100% meh, i.e. if you care, go with whatever, you have my ack. Anyone who cares about making docs more consistent makes me a happy camper :-) Cheers, Daniel > > Alex > > > > > On 2018-06-01 08:03 PM, Alex Deucher wrote: > >> Use chapter rather than section to align with the rst markup. > >> > >> Signed-off-by: Alex Deucher > >> --- > >> Documentation/gpu/amdgpu.rst | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst > >> index 1d726b90a619..e99732553c71 100644 > >> --- a/Documentation/gpu/amdgpu.rst > >> +++ b/Documentation/gpu/amdgpu.rst > >> @@ -8,7 +8,7 @@ Next (GCN) architecture. > >> Core Driver Infrastructure > >> == > >> > >> -This section covers core driver infrastructure. > >> +This chapter covers core driver infrastructure. > >> > >> PRIME Buffer Sharing > >> > > > > I don't mind either way, but I copied the "section" wording from i915.rst. > > > > > > -- > > Earthling Michel Dänzer | http://www.amd.com > > Libre software enthusiast | Mesa and X developer > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Constify mode argument to connector .mode_valid() helper operation
On Mon, Jun 11, 2018 at 07:51:01PM +0300, Ville Syrjälä wrote: > On Thu, Jun 07, 2018 at 03:13:23PM +0300, Laurent Pinchart wrote: > > Hi Ville, > > > > On Thursday, 7 June 2018 15:03:12 EEST Ville Syrjälä wrote: > > > On Wed, Jun 06, 2018 at 12:08:12PM +0300, Laurent Pinchart wrote: > > > > The drm_connector_helper_funcs .mode_valid() operation should not modify > > > > the mode it receives in any way. To make this explicit, constify the > > > > mode pointer as done for all other .mode_valid() operations, and update > > > > all drivers accordingly. > > > > > > > > Signed-off-by: Laurent Pinchart > > > > > > Didn't spot anything wrong. I think the omap case should be fine as > > > well since the probe helper will populate the vrefresh for the mode > > > eventually. > > > > > > Reviewed-by: Ville Syrjälä > > > > The patch has lived in my public tree for a few days now and the kbuild bot > > hasn't complained (or rather it complained on the previous version that I > > hadn't posted to the list yet, and I've fixed the problems before posting > > this > > version). Given the risk of conflicts I'd rather get this merged sooner > > than > > later. Is that fine with you ? > > Seems safe to me. So IMO just push if no one has complained. Hm I haven't seen this land yet. Since you (= Laurent) have commit rights, I assume it'll hapen without my involvement ... -Daniel > > > > > > > --- > > > > > > > > This patch touches lots of drivers, so checkpatch.pl created a huge CC > > > > list that would likely be too large for the mailing list. As changes to > > > > most files just boil down to adding a const keyword, I've decided to > > > > only > > > > CC the DRM misc maintainers, as well as Tomi for omapdrm as the change > > > > to > > > > that driver is slightly more complex. > > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 8 > > > > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +- > > > > drivers/gpu/drm/amd/amdgpu/atombios_dp.h | 2 +- > > > > drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 2 +- > > > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2 +- > > > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h| 2 +- > > > > drivers/gpu/drm/ast/ast_mode.c | 2 +- > > > > drivers/gpu/drm/bochs/bochs_kms.c| 2 +- > > > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 4 ++-- > > > > drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 2 +- > > > > drivers/gpu/drm/bridge/sii902x.c | 2 +- > > > > drivers/gpu/drm/bridge/tc358767.c| 2 +- > > > > drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- > > > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 2 +- > > > > drivers/gpu/drm/gma500/cdv_intel_crt.c | 2 +- > > > > drivers/gpu/drm/gma500/cdv_intel_dp.c| 2 +- > > > > drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +- > > > > drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- > > > > drivers/gpu/drm/gma500/mdfld_dsi_output.c| 2 +- > > > > drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +- > > > > drivers/gpu/drm/gma500/psb_intel_drv.h | 2 +- > > > > drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +- > > > > drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +- > > > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +- > > > > drivers/gpu/drm/i2c/ch7006_drv.c | 2 +- > > > > drivers/gpu/drm/i2c/sil164_drv.c | 2 +- > > > > drivers/gpu/drm/i2c/tda998x_drv.c| 2 +- > > > > drivers/gpu/drm/i915/dvo.h | 2 +- > > > > drivers/gpu/drm/i915/dvo_ch7017.c| 2 +- > > > > drivers/gpu/drm/i915/dvo_ch7xxx.c| 2 +- > > > > drivers/gpu/drm/i915/dvo_ivch.c | 2 +- > > > > drivers/gpu/drm/i915/dvo_ns2501.c| 2 +- > > > > drivers/gpu/drm/i915/dvo_sil164.c| 2 +- > > > > drivers/gpu/drm/i915/dvo_tfp410.c| 2 +- > > > > drivers/gpu/drm/i915/intel_crt.c | 2 +- > > > > drivers/gpu/drm/i915/intel_dp.c | 2 +- > > > > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +- > > > > drivers/gpu/drm/i915/intel_dsi.c | 2 +- > > > > drivers/gpu/drm/i915/intel_dvo.c | 2 +- > > > > drivers/gpu/drm/i915/intel_hdmi.c| 2 +- > > > > drivers/gpu/drm/i915/intel_lvds.c| 2 +- > > > > drivers/gpu/drm/i915/intel_sdvo.c| 2 +- > > > > drivers/gpu/drm/i915/intel_tv.c
Re: [PATCH v3 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
Hi Heiko,
On Tue, Jun 12, 2018 at 9:15 PM Heiko Stuebner wrote:
>
> From: Sandy Huang
>
> The vop irq is shared between vop and iommu and irq probing in the
> iommu driver moved to the probe function recently. This can in some
> cases lead to a stall if the irq is triggered while the vop driver
> still has it disabled, but the vop irq handler gets called.
>
> But there is no real need to disable the irq, as the vop can simply
> also track its enabled state and ignore irqs in that case.
> For this we can simply check the power-domain state of the vop,
> similar to how the iommu driver does it.
>
> So remove the enable/disable handling and add appropriate condition
> to the irq handler.
>
> changes in v2:
> - move to just check the power-domain state
> - add clock handling
> changes in v3:
> - clarify comment to speak of runtime-pm not power-domain
[snip]
> @@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
> spin_unlock(&vop->irq_lock);
>
> /* This is expected for vop iommu irqs, since the irq is shared */
> - if (!active_irqs)
> - return IRQ_NONE;
> + if (!active_irqs) {
> + ret = IRQ_NONE;
> + vop_core_clks_disable(vop);
nit: If we're adding "out:", couldn't we also add "out_clks:" and move
the call to vop_core_clks_disable() there?
> + goto out;
> + }
>
> if (active_irqs & DSP_HOLD_VALID_INTR) {
> complete(&vop->dsp_hold_completion);
> @@ -1236,6 +1245,10 @@ static irqreturn_t vop_isr(int irq, void *data)
> DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
> active_irqs);
>
> + vop_core_clks_disable(vop);
> +
> +out:
> + pm_runtime_put(vop->dev);
> return ret;
> }
Other than that:
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200121] [amdgpu] DC: Unable to find connected outputs
https://bugzilla.kernel.org/show_bug.cgi?id=200121 Michel Dänzer (mic...@daenzer.net) changed: What|Removed |Added CC||harry.wentl...@amd.com --- Comment #2 from Michel Dänzer (mic...@daenzer.net) --- DC doesn't fully support Kabini yet, disable it with amdgpu.dc=0 for now. -- 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 0/7] Replace {un/reference} with {put,get} functions
On Sat, Jun 09, 2018 at 03:17:58PM +0200, Thomas Zimmermann wrote:
> This patch set replaces functions named {un,reference} by their {put,get}
> counterparts. Each patch also removes the replaced functions from the DRM
> core and deletes them from the related Coccinelle script.
> Affected data types are struct drm_connector, struct drm_framebuffer,
> struct drm_gem_object, and struct drm_device.
>
> This change fixes the related item on the DRM TODO list.
>
> With the reference-counting functions being named {put,get}, the DRM
> interface is more aligned to Linux kernel nameing standard. The patch
> set does not change driver-internal interfaces.
>
> Possible future changes: Most of DRM's remaining {un/ref} functions
> perform additional tasks besides reference counting and should
> probably not be renamed. Exceptions are ttm_bo_{reference,unref} and
> ttm_object_file_{un/ref}. These functions mostly perform reference
> counting, but would require additional changes to the calling code
> besides renaming.
>
>
> Thomas Zimmermann (7):
> drm: Replace drm_connector_{un/reference} with drm_connector_{put,get}
> drm: Replace drm_framebuffer_{un/reference} with
> drm_framebuffer_{put,get}
> drm: Replace drm_gem_object_{un/reference} with
> drm_gem_object_{put,get}
> drm: Replace __drm_gem_object_unreference with __drm_gem_object_put
> drm: Replace drm_gem_object_unreference_unlocked with put function
> drm: Replace drm_dev_unref with drm_dev_put
> drm: Clean up after DRM put/get conversion
You're touching lots of drivers here, which needs at least some acks from
driver maintainers. scripts/get_maintainers.pl helps with figuring that
out.
It might also be good to split up some of the patches into per-driver
patches.
-Daniel
>
> Documentation/gpu/todo.rst | 17 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 +-
> drivers/gpu/drm/arc/arcpgu_drv.c | 8 +--
> drivers/gpu/drm/armada/armada_crtc.c | 8 +--
> drivers/gpu/drm/armada/armada_drv.c| 6 +-
> drivers/gpu/drm/armada/armada_overlay.c| 2 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 +--
> drivers/gpu/drm/bochs/bochs_fbdev.c| 2 +-
> drivers/gpu/drm/bochs/bochs_mm.c | 10 +--
> drivers/gpu/drm/drm_drv.c | 13
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 +--
> drivers/gpu/drm/exynos/exynos_drm_drv.c| 4 +-
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c| 10 +--
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 8 +--
> drivers/gpu/drm/gma500/framebuffer.c | 2 +-
> drivers/gpu/drm/gma500/gem.c | 2 +-
> drivers/gpu/drm/gma500/gma_display.c | 6 +-
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c| 4 +-
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c| 8 +--
> drivers/gpu/drm/i915/i915_gem_object.h | 13 +---
> drivers/gpu/drm/i915/intel_display.c | 4 +-
> drivers/gpu/drm/i915/intel_dp_mst.c| 2 +-
> drivers/gpu/drm/i915/selftests/huge_pages.c| 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem_evict.c| 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
> drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 2 +-
> drivers/gpu/drm/imx/imx-drm-core.c | 8 +--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +-
> drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +-
> drivers/gpu/drm/msm/adreno/a5xx_power.c| 2 +-
> drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 2 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 +-
> drivers/gpu/drm/msm/msm_drv.c | 8 +--
> drivers/gpu/drm/msm/msm_gem_submit.c | 4 +-
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 +-
> drivers/gpu/drm/nouveau/dispnv04/crtc.c| 2 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c| 2 +-
> drivers/gpu/drm/nouveau/nouveau_abi16.c| 2 +-
> drivers/gpu/drm/nouveau/nouveau_display.c | 8 +--
> drivers/gpu/drm/nouveau/nouveau_fbcon.c| 2 +-
> drivers/gpu/drm/nouveau/nouveau_gem.c | 14 ++--
> drivers/gpu/drm/nouveau/nouveau_platform.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 +-
> drivers/gpu/drm/omapdrm/omap_fb.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_fbdev
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #3 from Michel Dänzer --- Please attach the following for 4.18.0-rc1 and the last working kernel: The dmesg output, the .config file and the Xorg log file. -- 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 106303] amdgpu on RX 560: memory and core clocks not lowered on idle
https://bugs.freedesktop.org/show_bug.cgi?id=106303 --- Comment #7 from Mike --- Power usage partially improved with kernel 4.17.2 Both MCLK and SCLK now lowered to full idle - when monitor is turned OFF. Also MCLK seems to go idle (300MHz) periodically under low load (2D and browsing). However, SCLK is still run at top values when monitor is ON, regardless of GPU load (it is about 1-2% according to radeontop utility). -- 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: [Intel-gfx] [PATCH 3/3] drm/i915: Print prop name/id when rejecting it
On Mon, Jun 11, 2018 at 10:34:03PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the '[PROP:id:name]' format I introduced for the core in the driver
> debug messages as well.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
I'm wondering whether there's not some kind of macro magic we could do,
but unfortunately printf style stuff is really not composable :-/ And our
stuff isn't important enough to warant new %p modes either ...
-Daniel
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 6 --
> drivers/gpu/drm/i915/intel_atomic_plane.c | 6 --
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 61ddb5871d8a..b04952bacf77 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -59,7 +59,8 @@ int intel_digital_connector_atomic_get_property(struct
> drm_connector *connector,
> else if (property == dev_priv->broadcast_rgb_property)
> *val = intel_conn_state->broadcast_rgb;
> else {
> - DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
> + DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
> + property->base.id, property->name);
> return -EINVAL;
> }
>
> @@ -95,7 +96,8 @@ int intel_digital_connector_atomic_set_property(struct
> drm_connector *connector,
> return 0;
> }
>
> - DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
> + DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
> + property->base.id, property->name);
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index e8bf4cc499e1..dcba645cabb8 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -265,7 +265,8 @@ intel_plane_atomic_get_property(struct drm_plane *plane,
> struct drm_property *property,
> uint64_t *val)
> {
> - DRM_DEBUG_KMS("Unknown plane property '%s'\n", property->name);
> + DRM_DEBUG_KMS("Unknown property [PROP:%d:%s]\n",
> + property->base.id, property->name);
> return -EINVAL;
> }
>
> @@ -287,6 +288,7 @@ intel_plane_atomic_set_property(struct drm_plane *plane,
> struct drm_property *property,
> uint64_t val)
> {
> - DRM_DEBUG_KMS("Unknown plane property '%s'\n", property->name);
> + DRM_DEBUG_KMS("Unknown property [PROP:%d:%s]\n",
> + property->base.id, property->name);
> return -EINVAL;
> }
> --
> 2.16.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199749] amdgpu on Ryzen 2400G freeze randomly
https://bugzilla.kernel.org/show_bug.cgi?id=199749 --- Comment #11 from Michel Dänzer (mic...@daenzer.net) --- Other Raven Ridge users have reported that updating to the current microcode files from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu has fixed stability issues. Make sure your system BIOS and CPU microcode are up to date as well. -- 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] drm: Document mode_config.max_width/height as the max fb dimensions
On Fri, Jun 15, 2018 at 08:39:39PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The meaning of the mode_config max_width/height fields has not been
> entirely clear. They are used both as the max framebuffer dimensions,
> and they are also used by drm_mode_getconnector() to filter out
> any mode whose hdisplay/vdisplay exceed those limits.
>
> Let's put it in writing that max_width/height only refrer to the max
> framebuffer dimensions, and should those be higher than the hardware
> limits for display timings the driver must validate the latter using
> some other means.
>
> We'll keep the max_width/height usage in drm_mode_getconnector()
> because setcrtc treats hdisplay/vdisplay also as the primary plane
> width, and having a plane bigger than the max fb size doesn't make
> much sense (if we ignore scaling that is). It all works out fine
> as long as the max fb dimensions are at least equal to the max
> timing limits. If the opposite were true we may want to rethink
> what drm_mode_getconnector() does. Maybe do the mode filtering
> only for non-atomic userspace?
Defacto uapi is that if you do a modeset using the primary plane at full
res using a XRGB format, it Will Work (tm). There's way too much
userspace out there that just blindly assumes that, and I think drivers
need to cope with that expectation.
That's why we have format conversion code in tinydrm, and that's why we
have fancy code in msm to use multiple hw planes if the framebuffer is
over the limit. So yeah, I think documentating the expectation that fb
limits >= scanout limits as a hard requirement for reasonable drivers
(i.e. stuff you expect a normal linux distro to boot on) seems reasonable.
Just as an aside, if you want to clarify this furhter. Ack on the patch
itself.
Cheers, Daniel
>
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drm_mode_config.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index fb45839179dd..f796691b2d09 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -329,10 +329,10 @@ struct drm_mode_config_funcs {
>
> /**
> * struct drm_mode_config - Mode configuration control structure
> - * @min_width: minimum pixel width on this device
> - * @min_height: minimum pixel height on this device
> - * @max_width: maximum pixel width on this device
> - * @max_height: maximum pixel height on this device
> + * @min_width: minimum fb pixel width on this device
> + * @min_height: minimum fb pixel height on this device
> + * @max_width: maximum fb pixel width on this device
> + * @max_height: maximum fb pixel height on this device
> * @funcs: core driver provided mode setting functions
> * @fb_base: base address of the framebuffer
> * @poll_enabled: track polling support for this device
> --
> 2.16.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
Hi, On 18-06-18 10:53, Môshe van der Sterre wrote: Hi Hans, On 06/17/2018 05:32 PM, Hans de Goede wrote: On systems where fbcon is configured for deferred console takeover, the intend is for the framebuffer to show the boot graphics (e.g a vendor logo) until some message (e.g. an error) is printed or a graphical session takes over. Some firmware however relies on the OS to show the boot graphics (indicated by bgrt_tab.status being 0) and the boot graphics may have been destroyed by e.g. the grub boot menu. It may be clearer to just say that the boot graphics may have been destroyed. The reference to the status field and firmware expectations only confuses the intention of this patch, imho. (This ties in to what I say below) This patch adds support to efifb to show the boot graphics and automatically enables this when fbcon is configured for deferred console takeover. + /* +* We do not check bgrt_tab.status here because this seems to only +* reflect if the firmware has shown the boot graphics at all, if it +* later got destroyed by something status will still be 1. +* Since we draw the exact same graphic at the exact same place this +* will not lead to any tearing if the boot graphic is already there. +*/ I agree that ignoring bgrt_tab.status is the absolute best option. The status (valid-bit) can, in the real world, be any value with any meaning. I checked this on a few machines as part of commit 66dbe99cfe30. - My workstation always has 0. - An old server that I checked always has 1. - My laptop has 1 if the boot is uninterrupted, 0 if I request the UEFI boot menu. So, I have the same reservation about this comment as I have about the commit message. Imho, simply mentioning that the status field cannot be relied upon (in any case), would get the point across. Ok, I will simplify both the commit message and comment bits to just state that the status field is unreliable. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200121] [amdgpu] DC: Unable to find connected outputs
https://bugzilla.kernel.org/show_bug.cgi?id=200121 --- Comment #3 from nanericw...@gmail.com --- alright. when will kabini be supported? is it in the timeline? -- 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 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
Hi,
On 18-06-18 10:43, Ard Biesheuvel wrote:
On 18 June 2018 at 10:30, Hans de Goede wrote:
Hi,
On 18-06-18 09:36, Ard Biesheuvel wrote:
Hallo Hans,
On 17 June 2018 at 17:32, Hans de Goede wrote:
On systems where fbcon is configured for deferred console takeover, the
intend is for the framebuffer to show the boot graphics (e.g a vendor
logo) until some message (e.g. an error) is printed or a graphical
session takes over.
Some firmware however relies on the OS to show the boot graphics
(indicated by bgrt_tab.status being 0) and the boot graphics may have
been destroyed by e.g. the grub boot menu.
This patch adds support to efifb to show the boot graphics and
automatically enables this when fbcon is configured for deferred
console takeover.
Signed-off-by: Hans de Goede
I have tested this code on ARM QEMU/mach-virt, and with a little tweak
(which I will post separately), the code works as expected, i.e., it
redraws the boot logo based on the contents of the BGRT table.
That is great.
However, what it doesn't do is clear the screen, which means the logo
is drawn on top of whatever the boot environment left behind, and I
end up with something like this.
http://people.linaro.org/~ard.biesheuvel/mach-virt-bgrt-logo-redrawn.png
Hmm, less great. I'm not sure how to deal with this, on x86 it is more
or less guaranteed that the screen is already cleared when we load and
clearing a 4k screen means writing about 32MB, which I guess with modern
RAM speeds is not that bad actually.
I see that you got this picture by manual booting from the EFI shell,
in what state does the firmware / bootloader normally leave the
framebuffer?
UEFI does not usually clear the screen when it boots the default
entry, so it is entirely dependent on the boot loader that runs next.
I guess GRUB usually clears the screen unconditionally?
It depends, GRUB either leaves it completely alone (leaving the
BGRT graphics which the firmware hopefully has put up already
in place) or if it actually draws anything, then it clears iit
before starting the kernel.
In any case, I think it is reasonable to clear the screen if you
redraw the logo, but I do wonder if it is safe to assume that the
background color is black.
Instead, we may decide to clear the screen before ExitBootServices()
[using EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.ClearScreen()].
On most x86 machines (but not all, GRR) the firmware itself will
draw the logo already. I actually have grub patches pending to make
it not do any text-output related calls at all unless it actually
has a message / menu it wants to display.
Calling EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.ClearScreen() will cause
a bootup sequence like this:
firmware draws logo
clearscreen
redraw logo
Which will cause an ugly flash to black. Where as the purpose
is to have a smooth boot with the logo being on screen all
the time without any flickers / flashes.
I've never seen a machine where the background is not black,
the background not being black would also break the spinning
dots which microsofts draws on top of the background while
booting, so a memset to 0 seems sensible to me.
I'm asking because if normally it is either cleared
to black, or already showing the logo I wonder if we should take the
(small) penalty of clearing ?
Given that we are talking about only 32 MB I could do a v2 which just
memsets the rest of the screen to 0.
So we get:
for (y= 0; y < height; y++) {
if (line_part_of_bgrt) {
memset(left-of-bgrt);
draw_bgrt_line(y);
memset(right-of-bgrt);
} else {
memset(line);
}
}
Note I've deliberately done the if on a per line
base to keep the actual blit part of the loop
efficient and without any extra conditionals in
there. I also don't simply first memset the entire
fb to 0 to avoid a flash / tearing if the bgrt
image is already in place (which happens often on
x86).
Implementing this is easy and as said the extra execution time should
be quite small, still I wonder what others think about this?
I'm leaning towards doing the clearing / memsets since I've seen
some firmwares leave some artifacts from not completely clearing
things like a "Press F2 to enter setup" message, missing a few
pixels and leaving those on screen.
I think the overhead of doing the clearing is not going to be the
bottleneck. But redrawing a logo on black background that was designed
to be displayed over another color is going to look really ugly ...
Do you know of any examples of this ?
There seems to be no known way to get the background color, so black /
all 0 seems the be the best bet.
I would expect any non black background logos to simply be screen
filling.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] efifb: Copy the ACPI BGRT boot graphics to the
On Sun, Jun 17, 2018 at 05:32:33PM +0200, Hans de Goede wrote: > Hi All, > > Here is a patch-set to make sure that the efifb contains the boot > graphics from the ACPI BGRT extension when the kernel is configured > to use the (new) deferred fbcon console takeover support. > > Let me explain why this is desirable (same reason as for the deferred > fbcon console takeover support itself): > > Various (desktop oriented) Linux distributions have spend a lot of time > to not show way too technial boot messages to end users during bootup. > What we would really like for the boot experience is something like > MacOS X / Windows 10 do. The (EFI) firmware boots up a logo and we > leave that in place until the login-manager (e.g. gdm) starts and then > the login-manager takes over the framebuffer including the current logo > contents and fades that into the login screen. > > The deferred fbcon console takeover (combined with shim and grub) > patches makes the desired boot experience possible, but this assumes > that the firmware starts shim with the framebuffer containing the > boot graphics. This is not always the case, this patch ensures that the > boot graphics are in place. > > Since the bgrt.status field is not exactly reliable, this commit simply > always copies over the bootgraphics. If they are already there this > effectively is a no-op. > > The first patch in this series makes a trivial change to > drivers/firmware/efi/efi-bgrt.c, dropping __initdata from bgrt_image_size. > > Ard, since the second patch depends on the first and the change is > really trivial, can we please have your ack for merging the efi-bgrt.c > change through the fbdev tree? Random side-comment ... plans to roll out the same for drm drivers? With the client infrastructure Noralf is working on doing that should be fairly straight-forward. Interim step would be to add it to the shared fbdev emulation layer (but that's a bit a hack, and precludes the use of this on fbcon-less systems). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] efifb: Copy the ACPI BGRT boot graphics to the
Hi, On 18-06-18 11:23, Daniel Vetter wrote: On Sun, Jun 17, 2018 at 05:32:33PM +0200, Hans de Goede wrote: Hi All, Here is a patch-set to make sure that the efifb contains the boot graphics from the ACPI BGRT extension when the kernel is configured to use the (new) deferred fbcon console takeover support. Let me explain why this is desirable (same reason as for the deferred fbcon console takeover support itself): Various (desktop oriented) Linux distributions have spend a lot of time to not show way too technial boot messages to end users during bootup. What we would really like for the boot experience is something like MacOS X / Windows 10 do. The (EFI) firmware boots up a logo and we leave that in place until the login-manager (e.g. gdm) starts and then the login-manager takes over the framebuffer including the current logo contents and fades that into the login screen. The deferred fbcon console takeover (combined with shim and grub) patches makes the desired boot experience possible, but this assumes that the firmware starts shim with the framebuffer containing the boot graphics. This is not always the case, this patch ensures that the boot graphics are in place. Since the bgrt.status field is not exactly reliable, this commit simply always copies over the bootgraphics. If they are already there this effectively is a no-op. The first patch in this series makes a trivial change to drivers/firmware/efi/efi-bgrt.c, dropping __initdata from bgrt_image_size. Ard, since the second patch depends on the first and the change is really trivial, can we please have your ack for merging the efi-bgrt.c change through the fbdev tree? Random side-comment ... plans to roll out the same for drm drivers? With the client infrastructure Noralf is working on doing that should be fairly straight-forward. Interim step would be to add it to the shared fbdev emulation layer (but that's a bit a hack, and precludes the use of this on fbcon-less systems). I had not really thought about this yet. AFAICT the ACPI BGRT table is part of UEFI, so having it also means having an UEFI framebuffer and I expect us to always use that to be able to show error messages initializing the real drm/kms driver. But I guess in the future the plan it to stop using the efifb linux driver and instead use simple drm, then we will certainly want this in drm. And thinking more about this, currently I'm relying (for a flickerfree experience) on the kms driver taking over the fb setup by the firmware. But I guess it may not always succeed and if it does not succeed, then restoring the bootgraphics (on a quiet boot) would be good too. Once I've everything upstream to make flickerfree work for i915 I plan to look at the amd / nouveau cases next. For those adding BGRT graphics restoration to the drm drivers might make for a good quick fix. We would still get a flicker from the modeset but at least the screen would not be just black until the gui loads if we restore the boot graphics from the drm driver and I guess we could prime the fb with the bootgraphics before the modeset to make the flicker as small as possible. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
Am Montag, 18. Juni 2018, 10:44:58 CEST schrieb Tomasz Figa:
> Hi Heiko,
>
> On Tue, Jun 12, 2018 at 9:15 PM Heiko Stuebner wrote:
> >
> > From: Sandy Huang
> >
> > The vop irq is shared between vop and iommu and irq probing in the
> > iommu driver moved to the probe function recently. This can in some
> > cases lead to a stall if the irq is triggered while the vop driver
> > still has it disabled, but the vop irq handler gets called.
> >
> > But there is no real need to disable the irq, as the vop can simply
> > also track its enabled state and ignore irqs in that case.
> > For this we can simply check the power-domain state of the vop,
> > similar to how the iommu driver does it.
> >
> > So remove the enable/disable handling and add appropriate condition
> > to the irq handler.
> >
> > changes in v2:
> > - move to just check the power-domain state
> > - add clock handling
> > changes in v3:
> > - clarify comment to speak of runtime-pm not power-domain
> [snip]
> > @@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
> > spin_unlock(&vop->irq_lock);
> >
> > /* This is expected for vop iommu irqs, since the irq is shared */
> > - if (!active_irqs)
> > - return IRQ_NONE;
> > + if (!active_irqs) {
> > + ret = IRQ_NONE;
> > + vop_core_clks_disable(vop);
>
> nit: If we're adding "out:", couldn't we also add "out_clks:" and move
> the call to vop_core_clks_disable() there?
>
> > + goto out;
> > + }
> >
> > if (active_irqs & DSP_HOLD_VALID_INTR) {
> > complete(&vop->dsp_hold_completion);
> > @@ -1236,6 +1245,10 @@ static irqreturn_t vop_isr(int irq, void *data)
> > DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
> > active_irqs);
> >
> > + vop_core_clks_disable(vop);
> > +
> > +out:
> > + pm_runtime_put(vop->dev);
> > return ret;
> > }
>
> Other than that:
>
> Reviewed-by: Tomasz Figa
That's similar to what Marc suggested and thus already part of v4
posted last tuesday, so I'll just carry over your Reviewed-by.
Could you possibly also give patch1 a nod of approval? So I can honor
the strong suggestion in the drm-misc documentation? ;-)
Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/rockchip: vop: split out core clock enablement into separate functions
Hi Heiko,
On Tue, Jun 12, 2018 at 10:20 PM Heiko Stuebner wrote:
>
> Judging from the iommu code, both the hclk and aclk are necessary for
> register access. Split them off into separate functions from the regular
> vop enablement, so that we can use them elsewhere as well.
>
> Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Heiko Stuebner
> Tested-by: Ezequiel Garcia
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 44 +++--
> 1 file changed, 31 insertions(+), 13 deletions(-)
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106949] Mandatory amdgpu DC on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=106949 Bug ID: 106949 Summary: Mandatory amdgpu DC on Polaris Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: terapy-sess...@bk.ru After disabling AMDGPU DC on my RX460, my Arch does not load. It was shown on 4.16.13 and earlier, and is now on new 4.17.2. Inclusion should be mandatory for Vega and Raven Ridge, but not Polaris. -- 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: [Xen-devel] [PATCH v2] drm/xen-front: fix pointer casts
Hi, On 25/05/18 06:32, Oleksandr Andrushchenko wrote: > On 05/23/2018 02:46 PM, Juergen Gross wrote: >> On 23/05/18 13:36, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Building for a 32-bit target results in warnings from casting >>> between a 32-bit pointer and a 64-bit integer. Fix the warnings >>> by casting those pointers to uintptr_t first. >>> >>> Signed-off-by: Oleksandr Andrushchenko >>> >> Reviewed-by: Juergen Gross > Thank you, applied to drm-misc-next Is this the right branch? Shouldn't this go to drm-misc-fixes instead, so it reaches the tree before the 4.18 release? Just stumbled over the issue when compiling 4.18-rc1 for arm32, so it definitely needs fixing in this cycle. Cheers, Andre. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106949] Mandatory amdgpu DC on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=106949 --- Comment #1 from Michel Dänzer --- It's a bit unclear what you're saying. Disabling DC (via amdgpu.dc=0?) worked with 4.16.13, but doesn't anymore with 4.17.2? Please attach the dmesg output from a good case and if possible from a bad case. -- 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
[PATCH v2 4/8] dt-bindings: display: rockchip: update DSI controller
From: Nickey Yang
This patch update describe panel/port links, including
unit addresses in documentation of device tree bindings
for the rockchip DSI controller based on the Synopsys
DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
Reviewed-by: Brian Norris
Signed-off-by: Heiko Stuebner
---
.../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index 6bb59ab39f2f..ce4c1fc9116c 100644
---
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -14,6 +14,8 @@ Required properties:
- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
- ports: contain a port node with endpoint definitions as defined in [2].
For vopb,set the reg = <0> and set the reg = <1> for vopl.
+- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
+- video port 1 for either a panel or subsequent encoder
Optional properties:
- power-domains: a phandle to mipi dsi power domain node.
@@ -40,11 +42,12 @@ Example:
ports {
#address-cells = <1>;
#size-cells = <0>;
- reg = <1>;
- mipi_in: port {
+ mipi_in: port@0 {
+ reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
+
mipi_in_vopb: endpoint@0 {
reg = <0>;
remote-endpoint = <&vopb_out_mipi>;
@@ -54,6 +57,16 @@ Example:
remote-endpoint = <&vopl_out_mipi>;
};
};
+
+ mipi_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_out_panel: endpoint {
+ remote-endpoint = <&panel_in_mipi>;
+ };
+ };
};
panel {
@@ -64,5 +77,11 @@ Example:
pinctrl-names = "default";
pinctrl-0 = <&lcd_en>;
backlight = <&backlight>;
+
+ port {
+ panel_in_mipi: endpoint {
+ remote-endpoint = <&mipi_out_panel>;
+ };
+ };
};
};
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/8] drm/rockchip: migrate to common dw-mipi-dsi bridge and dual-dsi
The Rockchip DSI driver was separate till now, not using the common
bridge driver that was introduced a bit later. So this series migrates
over to use that common bridge driver and then also adds support for
dual-dsi to both the bridge and Rockchip glue code.
The bridge-migration itself is based on Nickeys earlier v8
work, but adapted to current kernels and with a new split between probe
and bind, so that we do not create and drop the dsi-host on each deferred
bind attempt.
changes in v2:
- rebase against newer drm code (dsi-bridge+rockchip changes)
- add SPDX header to new glue driver
- expect regular interface lanes from panel (like 4) not the double number
Similar to tegra
- keep links to both master and slave
The dual-dsi setup follows the port description introduced by Archit [0],
in that the panel defines two input ports that get connected to both
dsi-controllers instances. So on Gru-Scarlett this looks for example
like:
&mipi_dsi {
status = "okay";
clock-master;
ports {
mipi_out: port@1 {
reg = <1>;
mipi_out_panel: endpoint {
remote-endpoint = <&mipi_in_panel>;
};
};
};
mipi_panel: panel@0 {
/* 2 different panels are used, compatibles are in dts files */
reg = <0>;
backlight = <&backlight>;
enable-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&display_rst_l>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
mipi_in_panel: endpoint {
remote-endpoint = <&mipi_out_panel>;
};
};
port@1 {
reg = <1>;
mipi1_in_panel: endpoint@1 {
remote-endpoint = <&mipi1_out_panel>;
};
};
};
};
};
&mipi_dsi1 {
status = "okay";
ports {
mipi1_out: port@1 {
reg = <1>;
mipi1_out_panel: endpoint {
remote-endpoint = <&mipi1_in_panel>;
};
};
};
};
The driver internal setup is pretty similar to what tegra does with
its ganged-mode [1][2]. But here a new helper function allows to traverse
the devicetree from one controller port through the panel to find
another dsi-controller using that same panel. This way we don't need
a special phandle-property to link the controllers together.
For the CRTC it is still one single display to handle, only with
an additional switch that enables the dual-dsi output.
For practical purposes it is possible to just pick half the series
(till patch 5) to get the migration to the bridge driver first,
so that we can get rid of the dw-dsi copy in the Rockchip driver.
But of course Acks / Reviews of the dsi-bridge changes would be needed.
[0] https://patchwork.kernel.org/patch/10172381/
[1] https://lkml.org/lkml/2014/8/5/396
[2] https://patchwork.kernel.org/patch/5075161/
Heiko Stuebner (5):
drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to
__dw_mipi_dsi_remove
drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from
dw_mipi_dsi_bind
drm/bridge/synopsys: dsi: defer probing if panel not available in
bridge-attach
drm/dsi: add helper function to find the second host in a dual-dsi
setup
drm/rockchip: dsi: add dual mipi support
Nickey Yang (3):
dt-bindings: display: rockchip: update DSI controller
drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver
drm/bridge/synopsys: dsi: add dual-dsi support
.../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +-
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 115 +-
drivers/gpu/drm/drm_mipi_dsi.c| 56 +
drivers/gpu/drm/rockchip/Kconfig |2 +-
drivers/gpu/drm/rockchip/Makefile |2 +-
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 992
drivers/gpu/drm/rockchip/dw-mipi-dsi.c| 1349 -
drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h |3 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h |4 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c |1 +
include/drm/bridge/dw_mipi_dsi.h |6 +-
include/drm/drm_mipi_dsi.h|2 +
14 files changed, 1179 insertions(+), 1381 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi
[PATCH v2 8/8] drm/rockchip: dsi: add dual mipi support
Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well.
As described in the general dual-dsi devicetree binding, the panel should
define two input ports and point each of them to one of the used dsi-
controllers, as well as declare one of them as clock-master.
This is used to determine the dual-dsi state and get access to both
controller instances.
Signed-off-by: Heiko Stuebner
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 67 ++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 ++
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
5 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 12e4dacc7970..3382ad5a1b0d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -218,6 +218,10 @@ struct dw_mipi_dsi_rockchip {
struct clk *grf_clk;
struct clk *phy_cfg_clk;
+ /* dual-channel */
+ bool is_slave;
+ struct dw_mipi_dsi_rockchip *slave;
+
unsigned int lane_mbps; /* per lane */
u16 input_div;
u16 feedback_div;
@@ -604,6 +608,8 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder
*encoder,
}
dw_mipi_dsi_rockchip_config(dsi, mux);
+ if (dsi->slave)
+ dw_mipi_dsi_rockchip_config(dsi->slave, mux);
clk_disable_unprepare(dsi->grf_clk);
}
@@ -632,6 +638,8 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder
*encoder,
}
s->output_type = DRM_MODE_CONNECTOR_DSI;
+ if (dsi->slave)
+ s->output_flags = ROCKCHIP_OUTPUT_DSI_DUAL;
return 0;
}
@@ -641,6 +649,8 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
pm_runtime_put(dsi->dev);
+ if (dsi->slave)
+ pm_runtime_put(dsi->slave->dev);
}
static const struct drm_encoder_helper_funcs
@@ -681,18 +691,70 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
{
struct dw_mipi_dsi_rockchip *dsi = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+ struct device_node *second_np;
struct drm_bridge *bridge;
struct drm_panel *panel;
+ bool master1, master2;
int ret;
/*
-* Handle probe-deferrals due to missing display.
+* At this point both DSIs (if in use) should have probed and found
+* any connected displays or bridges.
+* This also takes care of handling possible probe-deferrals.
*/
ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0,
&panel, &bridge);
if (ret)
return ret;
+ second_np = of_mipi_dsi_find_second_host(dsi->dev->of_node, 1, 0);
+ if (IS_ERR(second_np))
+ return PTR_ERR(second_np);
+
+ if (second_np) {
+ struct platform_device *pdev;
+
+ master1 = of_property_read_bool(dsi->dev->of_node,
+ "clock-master");
+ master2 = of_property_read_bool(second_np, "clock-master");
+
+ if (master1 && master2) {
+ DRM_DEV_ERROR(dsi->dev, "only one clock-master
allowed\n");
+ of_node_put(second_np);
+ return -EINVAL;
+ }
+
+ if (!master1 && !master2) {
+ DRM_DEV_ERROR(dsi->dev, "no clock-master defined\n");
+ of_node_put(second_np);
+ return -EINVAL;
+ }
+
+ /* we are the slave in dual-DSI */
+ if (!master1) {
+ dsi->is_slave = true;
+ of_node_put(second_np);
+ return 0;
+ }
+
+ pdev = of_find_device_by_node(second_np);
+ if (!pdev) {
+ DRM_DEV_ERROR(dev, "could not find slave controller\n");
+ return -ENODEV;
+ }
+
+ dsi->slave = platform_get_drvdata(pdev);
+ if (!dsi->slave) {
+ DRM_DEV_ERROR(dev, "could not get slaves
platform-data\n");
+ return -ENODEV;
+ }
+
+ dsi->slave->is_slave = true;
+ dw_mipi_dsi_set_slave(dsi->dmd, dsi->slave->dmd);
+
+ of_node_put(second_np);
+ }
+
ret = rockchip_dsi_drm_create_encoder(dsi, drm_dev);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to create drm encoder\n");
@@ -714,6 +776,9 @@ static void dw_mipi_dsi_rockchip_unbind(struct device *dev,
{
struct dw_mipi_dsi_rockchip *dsi = dev_get_d
[PATCH v2 1/8] drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to __dw_mipi_dsi_remove
Right now the host is only unregistered when the driver is used via the
bridge api and not via the component api, leading to the host staying
registered in cases like probe deferral.
So move the host unregister to the general remove function, so that it
gets cleaned up in all cases.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index fd7999642cf8..07cde255cab2 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -941,6 +941,8 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
static void __dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
{
+ mipi_dsi_host_unregister(&dsi->dsi_host);
+
pm_runtime_disable(dsi->dev);
}
@@ -957,8 +959,6 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
{
- mipi_dsi_host_unregister(&dsi->dsi_host);
-
__dw_mipi_dsi_remove(dsi);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/8] drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver
From: Nickey Yang Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge and remove the old separate one. changes: v2: add err_pllref, remove unnecessary encoder.enable & disable correct spelling mistakes v3: call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind() fix typo, use of_device_get_match_data(), change some bind() logic into probe() add 'dev_set_drvdata()' v4: return -EINVAL when can not get best_freq add a clarifying comment when get vco add review tag v5: keep our power domain enabled while touching GRF v6: change func name dw_mipi_encoder_disable to dw_mipi_dsi_encoder_disable v7: none v8: Heiko add Archit's Review tag adapt to recent changes in the original rockchip-dsi driver beautify grf-handling split hw-setup (resources, dsi-host) from bind into probe v2-new: Heiko add SPDX header instead of license blurb drop old versioning to not confuse people Signed-off-by: Nickey Yang Signed-off-by: Brian Norris Reviewed-by: Brian Norris Reviewed-by: Sean Paul Reviewed-by: Archit Taneja Signed-off-by: Heiko Stuebner --- drivers/gpu/drm/rockchip/Kconfig |2 +- drivers/gpu/drm/rockchip/Makefile |2 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 927 +++ drivers/gpu/drm/rockchip/dw-mipi-dsi.c| 1349 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +- 6 files changed, 931 insertions(+), 1353 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0ccc76217ee4..9eb4795596d3 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -7,7 +7,7 @@ config DRM_ROCKCHIP select VIDEOMODE_HELPERS select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP select DRM_DW_HDMI if ROCKCHIP_DW_HDMI - select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI + select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC help Choose this option if you have a Rockchip soc chipset. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index a314e2109e76..0f22dad1c996 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -11,7 +11,7 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o -rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c new file mode 100644 index ..12e4dacc7970 --- /dev/null +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c @@ -0,0 +1,927 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: + * Chris Zhong + * Nickey Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "rockchip_drm_drv.h" +#include "rockchip_drm_vop.h" + +#define DSI_PHY_RSTZ 0xa0 +#define PHY_DISFORCEPLL0 +#define PHY_ENFORCEPLL BIT(3) +#define PHY_DISABLECLK 0 +#define PHY_ENABLECLK BIT(2) +#define PHY_RSTZ 0 +#define PHY_UNRSTZ BIT(1) +#define PHY_SHUTDOWNZ 0 +#define PHY_UNSHUTDOWNZBIT(0) + +#define DSI_PHY_IF_CFG 0xa4 +#define N_LANES(n) n) - 1) & 0x3) << 0) +#define PHY_STOP_WAIT_TIME(cycle) (((cycle) & 0xff) << 8) + +#define DSI_PHY_STATUS 0xb0 +#define LOCK BIT(0) +#define STOP_STATE_CLK_LANEBIT(2) + +#define DSI_PHY_TST_CTRL0 0xb4 +#define PHY_TESTCLKBIT(1) +#define PHY_UNTESTCLK 0 +#define PHY_TESTCLRBIT(0) +#define PHY_UNTESTCLR 0 + +#define DSI_PHY_TST_CTRL1 0xb8 +#define PHY_TESTEN BIT(16) +#define PHY_UNTESTEN 0 +#define PHY_TESTDOUT(n)(((n) & 0xff) << 8) +#define PHY_TESTDIN(n) (((n) & 0xff) << 0) + +#define DSI_INT_ST00xbc +#define DSI_INT_ST10xc0 +#define
[PATCH v2 3/8] drm/bridge/synopsys: dsi: defer probing if panel not available in bridge-attach
When the panel-driver is build as a module it currently fails hard as the panel cannot be probed directly: dw_mipi_dsi_bind() __dw_mipi_dsi_probe() creates dsi bus creates panel device triggers panel module load panel not probed (module not loaded or panel probe slow) drm_bridge_attach fails with -EINVAL due to empty panel_bridge So emit a -EPROBE_DEFER in that case to give the driver another chance at getting the display later. Signed-off-by: Heiko Stuebner --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index bb4aeca5c0f9..bd503f000ed5 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -835,6 +835,9 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge *bridge) return -ENODEV; } + if (!dsi->panel_bridge) + return -EPROBE_DEFER; + /* Set the encoder type as caller does not know it */ bridge->encoder->encoder_type = DRM_MODE_ENCODER_DSI; -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/8] drm/bridge/synopsys: dsi: add dual-dsi support
From: Nickey Yang
Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi
setup. This will require additional implementation-specific
code to look up the slave instance and do specific setup.
Also will probably need code in the specific crtcs as dual-dsi
does not equal two separate dsi outputs.
To activate, the implementation-specific code should set the slave
using dw_mipi_dsi_set_slave() before calling __dw_mipi_dsi_bind().
v2:
- expect real interface number of lanes
- keep links to both master and slave
Signed-off-by: Nickey Yang
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 93 +--
include/drm/bridge/dw_mipi_dsi.h | 1 +
2 files changed, 86 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index bd503f000ed5..6a345d1dde25 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -230,9 +230,20 @@ struct dw_mipi_dsi {
u32 format;
unsigned long mode_flags;
+ struct dw_mipi_dsi *master; /* dual-dsi master ptr */
+ struct dw_mipi_dsi *slave; /* dual-dsi slave ptr */
+
const struct dw_mipi_dsi_plat_data *plat_data;
};
+/*
+ * Check if either a link to a master or slave is present
+ */
+static inline bool dw_mipi_is_dual_mode(struct dw_mipi_dsi *dsi)
+{
+ return dsi->slave || dsi->master;
+}
+
/*
* The controller should generate 2 frames before
* preparing the peripheral.
@@ -273,18 +284,26 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
struct drm_bridge *bridge;
struct drm_panel *panel;
int ret;
+ int lanes = device->lanes;
- if (device->lanes > dsi->plat_data->max_data_lanes) {
+ if (lanes > dsi->plat_data->max_data_lanes) {
dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
device->lanes);
return -EINVAL;
}
- dsi->lanes = device->lanes;
+ dsi->lanes = lanes;
dsi->channel = device->channel;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
+ if (dsi->slave) {
+ dsi->slave->lanes = dsi->lanes;
+ dsi->slave->channel = dsi->channel;
+ dsi->slave->format = dsi->format;
+ dsi->slave->mode_flags = dsi->mode_flags;
+ }
+
ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
&panel, &bridge);
if (ret)
@@ -441,10 +460,17 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
}
dw_mipi_message_config(dsi, msg);
+ if (dsi->slave)
+ dw_mipi_message_config(dsi->slave, msg);
ret = dw_mipi_dsi_write(dsi, &packet);
if (ret)
return ret;
+ if (dsi->slave) {
+ ret = dw_mipi_dsi_write(dsi->slave, &packet);
+ if (ret)
+ return ret;
+ }
if (msg->rx_buf && msg->rx_len) {
ret = dw_mipi_dsi_read(dsi, msg);
@@ -583,7 +609,15 @@ static void dw_mipi_dsi_video_packet_config(struct
dw_mipi_dsi *dsi,
* DSI_VNPCR.NPSIZE... especially because this driver supports
* non-burst video modes, see dw_mipi_dsi_video_mode_config()...
*/
- dsi_write(dsi, DSI_VID_PKT_SIZE, VID_PKT_SIZE(mode->hdisplay));
+
+ int pkt_size;
+
+ if (dw_mipi_is_dual_mode(dsi))
+ pkt_size = VID_PKT_SIZE(mode->hdisplay / 2);
+ else
+ pkt_size = VID_PKT_SIZE(mode->hdisplay);
+
+ dsi_write(dsi, DSI_VID_PKT_SIZE, pkt_size);
}
static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)
@@ -756,23 +790,39 @@ static void dw_mipi_dsi_bridge_post_disable(struct
drm_bridge *bridge)
dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
dw_mipi_dsi_disable(dsi);
+ if (dsi->slave) {
+ dw_mipi_dsi_disable(dsi->slave);
+ clk_disable_unprepare(dsi->slave->pclk);
+ pm_runtime_put(dsi->slave->dev);
+ }
+
clk_disable_unprepare(dsi->pclk);
pm_runtime_put(dsi->dev);
}
-static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+static unsigned int dw_mipi_dsi_get_lanes(struct dw_mipi_dsi *dsi)
+{
+ if (dsi->master)
+ return dsi->master->lanes + dsi->lanes;
+
+ if (dsi->slave)
+ return dsi->lanes + dsi->slave->lanes;
+
+ return dsi->lanes;
+}
+
+static void dw_mipi_dsi_mode_set(struct dw_mipi_dsi *dsi,
+ struct drm_display_mode *adjusted_mode)
{
- struct dw_mipi_dsi *dsi = bridge_to_dsi(br
[PATCH v2 2/8] drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from dw_mipi_dsi_bind
__dw_mipi_dsi_probe() does all the grabbing of resources and does it using
devm-helpers. So this is happening on each try of master bringup possibly
slowing down things a lot.
Drivers using the component framework may instead want call dw_mipi_dsi_probe
separately in their probe function setup resources early. That way the dsi
bus also gets created earlier and also not recreated on each bind-try, so
that attached panels can load their modules and be probed way before the
bridge-attach in the bind call.
So drop the call to __dw_mipi_dsi_probe and modify the function to take
a struct dw_mipi_dsi instead of the platform-device.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 15 +++
include/drm/bridge/dw_mipi_dsi.h | 5 +
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 07cde255cab2..bb4aeca5c0f9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -966,31 +966,22 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
/*
* Bind/unbind API, used from platforms based on the component framework.
*/
-struct dw_mipi_dsi *
-dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_mipi_dsi_plat_data *plat_data)
+int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder)
{
- struct dw_mipi_dsi *dsi;
int ret;
- dsi = __dw_mipi_dsi_probe(pdev, plat_data);
- if (IS_ERR(dsi))
- return dsi;
-
ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
if (ret) {
- dw_mipi_dsi_remove(dsi);
DRM_ERROR("Failed to initialize bridge with drm\n");
- return ERR_PTR(ret);
+ return ret;
}
- return dsi;
+ return ret;
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
{
- __dw_mipi_dsi_remove(dsi);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
index d9c6d549f971..6d7f8eb5d9f2 100644
--- a/include/drm/bridge/dw_mipi_dsi.h
+++ b/include/drm/bridge/dw_mipi_dsi.h
@@ -35,10 +35,7 @@ struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device
*pdev,
const struct dw_mipi_dsi_plat_data
*plat_data);
void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
-struct dw_mipi_dsi *dw_mipi_dsi_bind(struct platform_device *pdev,
-struct drm_encoder *encoder,
-const struct dw_mipi_dsi_plat_data
-*plat_data);
+int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder);
void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi);
#endif /* __DW_MIPI_DSI__ */
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/8] drm/dsi: add helper function to find the second host in a dual-dsi setup
From a specified output port of one dsi controller this function allows to
iterate over the list of registered dsi controllers trying to find a second
instance connected to the same display, like it is used in dual-dsi setups.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/drm_mipi_dsi.c | 56 ++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index bc73b7f5b9fc..0c3c9c7aa3b8 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -282,6 +283,61 @@ struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct
device_node *node)
}
EXPORT_SYMBOL(of_find_mipi_dsi_host_by_node);
+struct device_node *of_mipi_dsi_find_second_host(struct device_node *first_np,
+int port, int endpoint)
+{
+ struct mipi_dsi_host *first, *host;
+ struct device_node *remote, *np, *second_np = NULL;
+ int num = 0;
+
+ first = of_find_mipi_dsi_host_by_node(first_np);
+ if (!first) {
+ pr_err("no dsi-host for node %s\n", first_np->full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ /* output-node of the known dsi-host */
+ remote = of_graph_get_remote_node(first_np, port, endpoint);
+ if (!remote) {
+ dev_err(first->dev, "no output node found\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ mutex_lock(&host_lock);
+
+ list_for_each_entry(host, &host_list, list) {
+ np = of_graph_get_remote_node(host->dev->of_node,
+ port, endpoint);
+
+ /* found a host connected to this panel */
+ if (np == remote)
+ num++;
+
+ /* found one second host */
+ if (host->dev->of_node != first_np)
+ second_np = host->dev->of_node;
+
+ of_node_put(np);
+ }
+
+ /* of_node_get the node under host_lock */
+ if (num == 2)
+ of_node_get(second_np);
+
+ mutex_unlock(&host_lock);
+
+ of_node_put(remote);
+
+ if (num > 2) {
+ dev_err(first->dev,
+ "too many DSI links for output: %d links\n", num);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return second_np;
+}
+EXPORT_SYMBOL(of_mipi_dsi_find_second_host);
+
int mipi_dsi_host_register(struct mipi_dsi_host *host)
{
struct device_node *node;
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 4fef19064b0f..89532ae69c91 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -107,6 +107,8 @@ struct mipi_dsi_host {
int mipi_dsi_host_register(struct mipi_dsi_host *host);
void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node);
+struct device_node *of_mipi_dsi_find_second_host(struct device_node *first_np,
+int port, int endpoint);
/* DSI mode flags */
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] dt-bindings: display: rockchip: update DSI controller
Am Montag, 18. Juni 2018, 12:28:02 CEST schrieb Heiko Stuebner: > From: Nickey Yang > > This patch update describe panel/port links, including > unit addresses in documentation of device tree bindings > for the rockchip DSI controller based on the Synopsys > DesignWare MIPI DSI host controller. > > Signed-off-by: Nickey Yang > Reviewed-by: Brian Norris > Signed-off-by: Heiko Stuebner forgot to carry over the Reviewed-by: Rob Herring from v1. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106949] Mandatory amdgpu DC on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=106949 --- Comment #2 from Dmitry --- Almost. The shutdown did not work on 4.16.13 and earlier. And there is now on my fresh 4.17.2. Disable by removing amdgpu.dc=1 of the string. P.S. I noticed that there is a bug and when you disable TearFree in the config. -- 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 106949] Mandatory amdgpu DC on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=106949 --- Comment #3 from Dmitry --- Created attachment 140192 --> https://bugs.freedesktop.org/attachment.cgi?id=140192&action=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 106949] Mandatory amdgpu DC on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=106949 --- Comment #4 from Michel Dänzer --- (In reply to Dmitry from comment #2) > Almost. The shutdown did not work on 4.16.13 and earlier. And there is now > on my fresh 4.17.2. What is there now? > Disable by removing amdgpu.dc=1 of the string. DC is enabled by default as of 4.17, you have to explicitly disable it with amdgpu.dc=0. > P.S. I noticed that there is a bug and when you disable TearFree in the > config. Please file a separate report about that against product xorg, component Driver/AMDgpu. -- 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 106949] Mandatory amdgpu DC on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=106949 --- Comment #5 from Dmitry --- >> What is there now? Same thing. The system is not loaded beyond the point "Reached target graphic Interface". But there is one point, helps pressing Enter, sometimes two presses. >> DC is enabled by default as of 4.17, you have to explicitly disable it with >> amdgpu.dc=0. I understood the update meant that it was no longer necessary to specify startup parameters such as amdgpu.dc=1. Tried with amdgpu.dc=0, but the same problem. -- 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 106938] Module *radeon* takes over two seconds to load
https://bugs.freedesktop.org/show_bug.cgi?id=106938 Christian König changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #3 from Christian König --- That is expected behavior. Because of stability issues we don't enable power management during startup initially which makes the hardware run at it's default clock (usually between 17 and 100MHz) during startup. -- 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
[PATCH 3/5] drm/i915: Replace __drm_gem_object_unreference with __drm_gem_object_put
This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/i915_gem_object.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index da6e849f41a4..0042496216fe 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -345,7 +345,7 @@ __attribute__((nonnull))
static inline void
i915_gem_object_put(struct drm_i915_gem_object *obj)
{
- __drm_gem_object_unreference(&obj->base);
+ __drm_gem_object_put(&obj->base);
}
__deprecated
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/i915: Replace drm_gem_object_{un/reference} with {put, get} functions
This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/i915_gem_object.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index 54f00b350779..da6e849f41a4 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -337,13 +337,10 @@ __attribute__((nonnull))
static inline struct drm_i915_gem_object *
i915_gem_object_get(struct drm_i915_gem_object *obj)
{
- drm_gem_object_reference(&obj->base);
+ drm_gem_object_get(&obj->base);
return obj;
}
-__deprecated
-extern void drm_gem_object_reference(struct drm_gem_object *);
-
__attribute__((nonnull))
static inline void
i915_gem_object_put(struct drm_i915_gem_object *obj)
@@ -351,9 +348,6 @@ i915_gem_object_put(struct drm_i915_gem_object *obj)
__drm_gem_object_unreference(&obj->base);
}
-__deprecated
-extern void drm_gem_object_unreference(struct drm_gem_object *);
-
__deprecated
extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *);
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/i915: Replace drm_gem_object_unreference_unlocked with put function
This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/i915_gem_object.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index 0042496216fe..c3c6f2e588fb 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -348,9 +348,6 @@ i915_gem_object_put(struct drm_i915_gem_object *obj)
__drm_gem_object_put(&obj->base);
}
-__deprecated
-extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *);
-
static inline void i915_gem_object_lock(struct drm_i915_gem_object *obj)
{
reservation_object_lock(obj->resv, NULL);
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/i915: Replace drm_connector_{un/reference} with put, get functions
This patch unifies the naming of DRM functions for reference counting
of struct drm_connector. The resulting code is more aligned with the
rest of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9939e092d9aa..593979cbd215 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10725,7 +10725,7 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
drm_connector_list_iter_begin(dev, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
if (connector->base.state->crtc)
- drm_connector_unreference(&connector->base);
+ drm_connector_put(&connector->base);
if (connector->base.encoder) {
connector->base.state->best_encoder =
@@ -10733,7 +10733,7 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
connector->base.state->crtc =
connector->base.encoder->crtc;
- drm_connector_reference(&connector->base);
+ drm_connector_get(&connector->base);
} else {
connector->base.state->best_encoder = NULL;
connector->base.state->crtc = NULL;
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 5890500a3a8b..789a403e9f99 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -524,7 +524,7 @@ static void intel_dp_destroy_mst_connector(struct
drm_dp_mst_topology_mgr *mgr,
intel_connector->mst_port = NULL;
drm_modeset_unlock(&connector->dev->mode_config.connection_mutex);
- drm_connector_unreference(connector);
+ drm_connector_put(connector);
}
static void intel_dp_mst_hotplug(struct drm_dp_mst_topology_mgr *mgr)
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/i915: Replace drm_dev_unref with drm_dev_put
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/i915/selftests/huge_pages.c| 2 +- drivers/gpu/drm/i915/selftests/i915_gem_context.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_evict.c| 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_object.c | 2 +- drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/huge_pages.c b/drivers/gpu/drm/i915/selftests/huge_pages.c index fbe4324116d7..b5e87fcdcdae 100644 --- a/drivers/gpu/drm/i915/selftests/huge_pages.c +++ b/drivers/gpu/drm/i915/selftests/huge_pages.c @@ -1724,7 +1724,7 @@ int i915_gem_huge_page_mock_selftests(void) i915_modparams.enable_ppgtt = saved_ppgtt; - drm_dev_unref(&dev_priv->drm); + drm_dev_put(&dev_priv->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/selftests/i915_gem_context.c index 836f1af8b833..07fd3fe24157 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c @@ -586,7 +586,7 @@ int i915_gem_context_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c index 89dc25a5a53b..a7055b12e53c 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c @@ -389,7 +389,7 @@ int i915_gem_dmabuf_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c index 2dc72a984d45..8059268800fa 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c @@ -490,7 +490,7 @@ int i915_gem_evict_mock_selftests(void) err = i915_subtests(tests, i915); mutex_unlock(&i915->drm.struct_mutex); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index a4060238bef0..a28ee0cc6a63 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -1644,7 +1644,7 @@ int i915_gem_gtt_mock_selftests(void) err = i915_subtests(tests, i915); mutex_unlock(&i915->drm.struct_mutex); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c b/drivers/gpu/drm/i915/selftests/i915_gem_object.c index 2b2dde94526f..549707b9d738 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_object.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c @@ -586,7 +586,7 @@ int i915_gem_object_mock_selftests(void) err = i915_subtests(tests, i915); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c b/drivers/gpu/drm/i915/selftests/i915_request.c index 63cd9486cc13..521ae4a90ddf 100644 --- a/drivers/gpu/drm/i915/selftests/i915_request.c +++ b/drivers/gpu/drm/i915/selftests/i915_request.c @@ -262,7 +262,7 @@ int i915_request_mock_selftests(void) return -ENOMEM; err = i915_subtests(tests, i915); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c b/drivers/gpu/drm/i915/selftests/i915_vma.c index 8400a8cc5cf2..ffa74290e054 100644 --- a/drivers/gpu/drm/i915/selftests/i915_vma.c +++ b/drivers/gpu/drm/i915/selftests/i915_vma.c @@ -733,7 +733,7 @@ int i915_vma_mock_selftests(void) err = i915_subtests(tests, i915); mutex_unlock(&i915->drm.struct_mutex); - drm_dev_unref(&i915->drm); + drm_dev_put(&i915->drm); return err; } diff --git a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c index d6926e7820e5..f03b407fdbe2 100644 --- a/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c @@ -464,7 +464,7 @@ int intel_breadcrumbs_mock_selftests(void) return -ENOMEM; err = i915_s
[PATCH 0/5] drm/i915: Replace {un/reference} with {put, get} functions
This patch set replaces functions named {un,reference} by their
{put,get} counterparts. Affected data types are struct drm_connector,
struct drm_gem_object, and struct drm_device.
With the reference-counting functions being named {put,get}, the DRM
interface is more aligned to Linux kernel nameing standard. The patch
set does not change driver-internal interfaces.
Thomas Zimmermann (5):
drm/i915: Replace drm_connector_{un/reference} with put,get functions
drm/i915: Replace drm_gem_object_{un/reference} with {put,get}
functions
drm/i915: Replace __drm_gem_object_unreference with
__drm_gem_object_put
drm/i915: Replace drm_gem_object_unreference_unlocked with put
function
drm/i915: Replace drm_dev_unref with drm_dev_put
drivers/gpu/drm/i915/i915_gem_object.h | 13 ++---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_dp_mst.c| 2 +-
drivers/gpu/drm/i915/selftests/huge_pages.c| 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_evict.c| 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 2 +-
12 files changed, 14 insertions(+), 23 deletions(-)
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/7] Replace {un/reference} with {put,get} functions
Hi > It might also be good to split up some of the patches into per-driver > patches. Thanks for the feedback. I'll do the (major) drivers first and will get back with whatever will be left of this patch set. Best regards Thomas > -Daniel > >> >> Documentation/gpu/todo.rst | 17 - >> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 +- >> drivers/gpu/drm/arc/arcpgu_drv.c | 8 +-- >> drivers/gpu/drm/armada/armada_crtc.c | 8 +-- >> drivers/gpu/drm/armada/armada_drv.c| 6 +- >> drivers/gpu/drm/armada/armada_overlay.c| 2 +- >> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 +-- >> drivers/gpu/drm/bochs/bochs_fbdev.c| 2 +- >> drivers/gpu/drm/bochs/bochs_mm.c | 10 +-- >> drivers/gpu/drm/drm_drv.c | 13 >> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 +-- >> drivers/gpu/drm/exynos/exynos_drm_drv.c| 4 +- >> drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 +- >> drivers/gpu/drm/exynos/exynos_drm_gem.c| 10 +-- >> drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +- >> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 8 +-- >> drivers/gpu/drm/gma500/framebuffer.c | 2 +- >> drivers/gpu/drm/gma500/gem.c | 2 +- >> drivers/gpu/drm/gma500/gma_display.c | 6 +- >> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c| 4 +- >> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c| 8 +-- >> drivers/gpu/drm/i915/i915_gem_object.h | 13 +--- >> drivers/gpu/drm/i915/intel_display.c | 4 +- >> drivers/gpu/drm/i915/intel_dp_mst.c| 2 +- >> drivers/gpu/drm/i915/selftests/huge_pages.c| 2 +- >> drivers/gpu/drm/i915/selftests/i915_gem_context.c | 2 +- >> drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c | 2 +- >> drivers/gpu/drm/i915/selftests/i915_gem_evict.c| 2 +- >> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- >> drivers/gpu/drm/i915/selftests/i915_gem_object.c | 2 +- >> drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- >> drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- >> drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 2 +- >> drivers/gpu/drm/imx/imx-drm-core.c | 8 +-- >> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +- >> drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +- >> drivers/gpu/drm/msm/adreno/a5xx_power.c| 2 +- >> drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 2 +- >> drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 +- >> drivers/gpu/drm/msm/msm_drv.c | 8 +-- >> drivers/gpu/drm/msm/msm_gem_submit.c | 4 +- >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 +- >> drivers/gpu/drm/nouveau/dispnv04/crtc.c| 2 +- >> drivers/gpu/drm/nouveau/dispnv50/disp.c| 2 +- >> drivers/gpu/drm/nouveau/nouveau_abi16.c| 2 +- >> drivers/gpu/drm/nouveau/nouveau_display.c | 8 +-- >> drivers/gpu/drm/nouveau/nouveau_fbcon.c| 2 +- >> drivers/gpu/drm/nouveau/nouveau_gem.c | 14 ++-- >> drivers/gpu/drm/nouveau/nouveau_platform.c | 2 +- >> drivers/gpu/drm/omapdrm/omap_drv.c | 6 +- >> drivers/gpu/drm/omapdrm/omap_fb.c | 2 +- >> drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +- >> drivers/gpu/drm/omapdrm/omap_gem.c | 4 +- >> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 +- >> drivers/gpu/drm/pl111/pl111_drv.c | 14 ++-- >> drivers/gpu/drm/qxl/qxl_drv.c | 2 +- >> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- >> drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 4 +- >> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +- >> drivers/gpu/drm/sti/sti_drv.c | 8 +-- >> drivers/gpu/drm/stm/drv.c | 10 +-- >> drivers/gpu/drm/sun4i/sun4i_drv.c | 4 +- >> drivers/gpu/drm/tegra/drm.c| 8 +-- >> drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 6 +- >> drivers/gpu/drm/tve200/tve200_drv.c| 10 +-- >> drivers/gpu/drm/udl/udl_drv.c | 2 +- >> drivers/gpu/drm/vc4/vc4_drv.c | 8 +-- >> drivers/gpu/drm/vgem/vgem_drv.c| 2 +- >> drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 2 +- >> drivers/gpu/drm/zte/zx_drm_drv.c | 4 +- >> include/drm/drm_connector.h| 24 --- >> include/drm/drm_drv.h | 1 - >> include/drm/drm_framebuffer.h | 24 --- >> include/drm/drm_gem.h | 50 -- >> scripts/coccinelle/api/drm-get-put.c
[Bug 106938] Module *radeon* takes over two seconds to load
https://bugs.freedesktop.org/show_bug.cgi?id=106938 --- Comment #4 from Paul Menzel --- Is there a switch to override that behavior? -- 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #4 from SET --- Created attachment 140195 --> https://bugs.freedesktop.org/attachment.cgi?id=140195&action=edit Bad .config -- 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #5 from SET --- Created attachment 140197 --> https://bugs.freedesktop.org/attachment.cgi?id=140197&action=edit Bad 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #6 from SET --- Created attachment 140198 --> https://bugs.freedesktop.org/attachment.cgi?id=140198&action=edit Bad 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #7 from SET --- Created attachment 140199 --> https://bugs.freedesktop.org/attachment.cgi?id=140199&action=edit Good .config -- 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #8 from SET --- Created attachment 140200 --> https://bugs.freedesktop.org/attachment.cgi?id=140200&action=edit Good 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #9 from SET --- Created attachment 140201 --> https://bugs.freedesktop.org/attachment.cgi?id=140201&action=edit Good 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #10 from SET --- Created attachment 140202 --> https://bugs.freedesktop.org/attachment.cgi?id=140202&action=edit Good and bad git commits -- 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 106949] Mandatory amdgpu DC on Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=106949 --- Comment #6 from Dmitry --- Found out that this bug with SDDM which I use. It is happening because of a change in configuration or any other reason. -- 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 106938] Module *radeon* takes over two seconds to load
https://bugs.freedesktop.org/show_bug.cgi?id=106938 --- Comment #5 from Christian König --- (In reply to Paul Menzel from comment #4) > Is there a switch to override that behavior? Long story short, no there isn't. You could try to disable certain blocks with radeon.uvd=0 and radeon.vce=0 to speed up boot a bit if you don't need that functionality. But that's basically all you can do without implementing a different approach to power management. -- 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 v3 2/2] locking: Implement an algorithm choice for Wound-Wait mutexes
On 06/15/2018 06:46 PM, Peter Zijlstra wrote:
On Fri, Jun 15, 2018 at 02:08:27PM +0200, Thomas Hellstrom wrote:
@@ -772,6 +856,25 @@ __ww_mutex_add_waiter(struct mutex_waiter *waiter,
}
list_add_tail(&waiter->list, pos);
+ if (__mutex_waiter_is_first(lock, waiter))
+ __mutex_set_flag(lock, MUTEX_FLAG_WAITERS);
+
+ /*
+* Wound-Wait: if we're blocking on a mutex owned by a younger context,
+* wound that such that we might proceed.
+*/
+ if (!is_wait_die) {
+ struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
+
+ /*
+* See ww_mutex_set_context_fastpath(). Orders setting
+* MUTEX_FLAG_WAITERS (atomic operation) vs the ww->ctx load,
+* such that either we or the fastpath will wound @ww->ctx.
+*/
+ smp_mb__after_atomic();
+
+ __ww_mutex_wound(lock, ww_ctx, ww->ctx);
+ }
I think we want the smp_mb__after_atomic() in the same branch as
__mutex_set_flag(). So something like:
if (__mutex_waiter_is_first()) {
__mutex_set_flag();
if (!is_wait_die)
smp_mb__after_atomic();
}
Or possibly even without the !is_wait_die. The rules for
smp_mb__*_atomic() are such that we want it unconditional after an
atomic, otherwise the semantics get too fuzzy.
Alan (rightfully) complained about that a while ago when he was auditing
users.
Hmm, yes that's understandable, although I must admit that when one of
the accesses we want to order is actually an atomic this shouldn't
really be causing much confusion.
But I'll think I'll change it back to an smp_mb() then. It's in a
slowpath, and awkward constructs around smp_mb__after_atomic() might be
causing grief in the future.
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/pp: Fix uninitialized variable
Applied. Thanks.
Best Regards
Rex
From: rajan.v...@gmail.com
Sent: Monday, June 18, 2018 3:31 PM
To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); Zhu, Rex;
StDenis, Tom
Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org; Rajan Vaja
Subject: [PATCH] drm/amd/pp: Fix uninitialized variable
From: Rajan Vaja
Initialize variable to 0 before performing logical OR operation.
Signed-off-by: Rajan Vaja
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
index a9efd855..bde01d4 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
@@ -1090,7 +1090,7 @@ static int vega10_disable_se_edc_config(struct pp_hwmgr
*hwmgr)
static int vega10_enable_psm_gc_edc_config(struct pp_hwmgr *hwmgr)
{
struct amdgpu_device *adev = hwmgr->adev;
- int result;
+ int result = 0;
uint32_t num_se = 0;
uint32_t count, data;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Print prop name/id when rejecting it
On Mon, Jun 18, 2018 at 10:53:13AM +0200, Daniel Vetter wrote: > On Mon, Jun 11, 2018 at 10:34:03PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Use the '[PROP:id:name]' format I introduced for the core in the driver > > debug messages as well. > > > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Daniel Vetter > > I'm wondering whether there's not some kind of macro magic we could do, > but unfortunately printf style stuff is really not composable :-/ And our > stuff isn't important enough to warant new %p modes either ... I should have DRM_PLANE_FMT, DRM_PLANE_ARGS(), etc. in some branch. Never posted that stuff because I wasn't entirely convinced it's all that useful. Opinions? -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
On 18 June 2018 at 10:30, Hans de Goede wrote:
> Hi,
>
> On 18-06-18 09:36, Ard Biesheuvel wrote:
>>
>> Hallo Hans,
>>
>> On 17 June 2018 at 17:32, Hans de Goede wrote:
>>>
>>> On systems where fbcon is configured for deferred console takeover, the
>>> intend is for the framebuffer to show the boot graphics (e.g a vendor
>>> logo) until some message (e.g. an error) is printed or a graphical
>>> session takes over.
>>>
>>> Some firmware however relies on the OS to show the boot graphics
>>> (indicated by bgrt_tab.status being 0) and the boot graphics may have
>>> been destroyed by e.g. the grub boot menu.
>>>
>>> This patch adds support to efifb to show the boot graphics and
>>> automatically enables this when fbcon is configured for deferred
>>> console takeover.
>>>
>>> Signed-off-by: Hans de Goede
>>
>>
>> I have tested this code on ARM QEMU/mach-virt, and with a little tweak
>> (which I will post separately), the code works as expected, i.e., it
>> redraws the boot logo based on the contents of the BGRT table.
>
>
> That is great.
>
>> However, what it doesn't do is clear the screen, which means the logo
>> is drawn on top of whatever the boot environment left behind, and I
>> end up with something like this.
>>
>> http://people.linaro.org/~ard.biesheuvel/mach-virt-bgrt-logo-redrawn.png
>
>
> Hmm, less great. I'm not sure how to deal with this, on x86 it is more
> or less guaranteed that the screen is already cleared when we load and
> clearing a 4k screen means writing about 32MB, which I guess with modern
> RAM speeds is not that bad actually.
>
> I see that you got this picture by manual booting from the EFI shell,
> in what state does the firmware / bootloader normally leave the
> framebuffer?
UEFI does not usually clear the screen when it boots the default
entry, so it is entirely dependent on the boot loader that runs next.
I guess GRUB usually clears the screen unconditionally?
In any case, I think it is reasonable to clear the screen if you
redraw the logo, but I do wonder if it is safe to assume that the
background color is black.
Instead, we may decide to clear the screen before ExitBootServices()
[using EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.ClearScreen()].
> I'm asking because if normally it is either cleared
> to black, or already showing the logo I wonder if we should take the
> (small) penalty of clearing ?
>
> Given that we are talking about only 32 MB I could do a v2 which just
> memsets the rest of the screen to 0.
>
> So we get:
>
> for (y= 0; y < height; y++) {
> if (line_part_of_bgrt) {
> memset(left-of-bgrt);
> draw_bgrt_line(y);
> memset(right-of-bgrt);
> } else {
> memset(line);
> }
> }
>
> Note I've deliberately done the if on a per line
> base to keep the actual blit part of the loop
> efficient and without any extra conditionals in
> there. I also don't simply first memset the entire
> fb to 0 to avoid a flash / tearing if the bgrt
> image is already in place (which happens often on
> x86).
>
> Implementing this is easy and as said the extra execution time should
> be quite small, still I wonder what others think about this?
>
> I'm leaning towards doing the clearing / memsets since I've seen
> some firmwares leave some artifacts from not completely clearing
> things like a "Press F2 to enter setup" message, missing a few
> pixels and leaving those on screen.
>
I think the overhead of doing the clearing is not going to be the
bottleneck. But redrawing a logo on black background that was designed
to be displayed over another color is going to look really ugly ...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t
On Thu, May 24, 2018 at 6:27 PM, Daniel Vetter wrote:
> On Wed, May 23, 2018 at 03:05:35PM +0530, Souptick Joarder wrote:
>> On Mon, May 14, 2018 at 9:56 PM, Daniel Vetter wrote:
>> > On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
>> >> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
>> >> > Hi Sean,
>> >> >
>> >> > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder
>> >> > wrote:
>> >> > > Use new return type vm_fault_t for fault handler.
>> >> > >
>> >> > > Signed-off-by: Souptick Joarder
>> >> > > Reviewed-by: Matthew Wilcox
>> >> > > ---
>> >> > > drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
>> >> > > 1 file changed, 2 insertions(+), 3 deletions(-)
>> >> > >
>> >> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
>> >> > > b/drivers/gpu/drm/vgem/vgem_drv.c
>> >> > > index 2524ff1..c64a859 100644
>> >> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
>> >> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>> >> > > @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct
>> >> > > drm_gem_object *obj)
>> >> > > kfree(vgem_obj);
>> >> > > }
>> >> > >
>> >> > > -static int vgem_gem_fault(struct vm_fault *vmf)
>> >> > > +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
>> >> > > {
>> >> > > struct vm_area_struct *vma = vmf->vma;
>> >> > > struct drm_vgem_gem_object *obj = vma->vm_private_data;
>> >> > > /* We don't use vmf->pgoff since that has the fake offset */
>> >> > > unsigned long vaddr = vmf->address;
>> >> > > - int ret;
>> >> > > + vm_fault_t ret = VM_FAULT_SIGBUS;
>> >> > > loff_t num_pages;
>> >> > > pgoff_t page_offset;
>> >> > > page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
>> >> > > @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
>> >> > > if (page_offset > num_pages)
>> >> > > return VM_FAULT_SIGBUS;
>> >> > >
>> >> > > - ret = -ENOENT;
>> >> > > mutex_lock(&obj->pages_lock);
>> >> > > if (obj->pages) {
>> >> > > get_page(obj->pages[page_offset]);
>> >> > > --
>> >> > > 1.9.1
>> >> > >
>> >> >
>> >> > Any further comment on this patch ?
>> >>
>> >> Patch looks good to me. My build test fails, though, since vm_fault_t
>> >> doesn't
>> >> exist in drm-misc-next yet.
>> >
>> > vm_fault_t is already in upstream, just needs Maarten to do a backmerge.
>> > Which I think he's done by now ... Otherwise nag him more :-)
>> > -Daniel
>> >
>> >>
>> >> So, for now,
>> >>
>> >> Reviewed-by: Sean Paul
>> >>
>> >>
>> >> --
>> >> Sean Paul, Software Engineer, Google / Chromium OS
>> >> ___
>> >> dri-devel mailing list
>> >> dri-devel@lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >
>> > --
>> > Daniel Vetter
>> > Software Engineer, Intel Corporation
>> > http://blog.ffwll.ch
>>
>> Daniel/ Sean, is this patch already merged for 4.18 ?
>
> Nope, fell through the cracks. Thanks for the reminder, queued for 4.18
> now.
> -Daniel
>
Daniel, This patch is not available in 4.18-rc-1 :-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/pp: Fix uninitialized variable
From: Rajan Vaja
Initialize variable to 0 before performing logical OR operation.
Signed-off-by: Rajan Vaja
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
index a9efd855..bde01d4 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c
@@ -1090,7 +1090,7 @@ static int vega10_disable_se_edc_config(struct pp_hwmgr
*hwmgr)
static int vega10_enable_psm_gc_edc_config(struct pp_hwmgr *hwmgr)
{
struct amdgpu_device *adev = hwmgr->adev;
- int result;
+ int result = 0;
uint32_t num_se = 0;
uint32_t count, data;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
On 18 June 2018 at 11:13, Hans de Goede wrote:
> Hi,
>
>
> On 18-06-18 10:43, Ard Biesheuvel wrote:
>>
>> On 18 June 2018 at 10:30, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 18-06-18 09:36, Ard Biesheuvel wrote:
Hallo Hans,
On 17 June 2018 at 17:32, Hans de Goede wrote:
>
>
> On systems where fbcon is configured for deferred console takeover, the
> intend is for the framebuffer to show the boot graphics (e.g a vendor
> logo) until some message (e.g. an error) is printed or a graphical
> session takes over.
>
> Some firmware however relies on the OS to show the boot graphics
> (indicated by bgrt_tab.status being 0) and the boot graphics may have
> been destroyed by e.g. the grub boot menu.
>
> This patch adds support to efifb to show the boot graphics and
> automatically enables this when fbcon is configured for deferred
> console takeover.
>
> Signed-off-by: Hans de Goede
I have tested this code on ARM QEMU/mach-virt, and with a little tweak
(which I will post separately), the code works as expected, i.e., it
redraws the boot logo based on the contents of the BGRT table.
>>>
>>>
>>>
>>> That is great.
>>>
However, what it doesn't do is clear the screen, which means the logo
is drawn on top of whatever the boot environment left behind, and I
end up with something like this.
http://people.linaro.org/~ard.biesheuvel/mach-virt-bgrt-logo-redrawn.png
>>>
>>>
>>>
>>> Hmm, less great. I'm not sure how to deal with this, on x86 it is more
>>> or less guaranteed that the screen is already cleared when we load and
>>> clearing a 4k screen means writing about 32MB, which I guess with modern
>>> RAM speeds is not that bad actually.
>>>
>>> I see that you got this picture by manual booting from the EFI shell,
>>> in what state does the firmware / bootloader normally leave the
>>> framebuffer?
>>
>>
>> UEFI does not usually clear the screen when it boots the default
>> entry, so it is entirely dependent on the boot loader that runs next.
>> I guess GRUB usually clears the screen unconditionally?
>
>
> It depends, GRUB either leaves it completely alone (leaving the
> BGRT graphics which the firmware hopefully has put up already
> in place) or if it actually draws anything, then it clears iit
> before starting the kernel.
>
>> In any case, I think it is reasonable to clear the screen if you
>> redraw the logo, but I do wonder if it is safe to assume that the
>> background color is black.
>>
>> Instead, we may decide to clear the screen before ExitBootServices()
>> [using EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.ClearScreen()].
>
>
> On most x86 machines (but not all, GRR) the firmware itself will
> draw the logo already. I actually have grub patches pending to make
> it not do any text-output related calls at all unless it actually
> has a message / menu it wants to display.
>
> Calling EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.ClearScreen() will cause
> a bootup sequence like this:
>
> firmware draws logo
> clearscreen
> redraw logo
>
> Which will cause an ugly flash to black. Where as the purpose
> is to have a smooth boot with the logo being on screen all
> the time without any flickers / flashes.
>
> I've never seen a machine where the background is not black,
> the background not being black would also break the spinning
> dots which microsofts draws on top of the background while
> booting, so a memset to 0 seems sensible to me.
>
>
>>> I'm asking because if normally it is either cleared
>>> to black, or already showing the logo I wonder if we should take the
>>> (small) penalty of clearing ?
>>>
>>> Given that we are talking about only 32 MB I could do a v2 which just
>>> memsets the rest of the screen to 0.
>>>
>>> So we get:
>>>
>>> for (y= 0; y < height; y++) {
>>> if (line_part_of_bgrt) {
>>> memset(left-of-bgrt);
>>> draw_bgrt_line(y);
>>> memset(right-of-bgrt);
>>> } else {
>>> memset(line);
>>> }
>>> }
>>>
>>> Note I've deliberately done the if on a per line
>>> base to keep the actual blit part of the loop
>>> efficient and without any extra conditionals in
>>> there. I also don't simply first memset the entire
>>> fb to 0 to avoid a flash / tearing if the bgrt
>>> image is already in place (which happens often on
>>> x86).
>>>
>>> Implementing this is easy and as said the extra execution time should
>>> be quite small, still I wonder what others think about this?
>>>
>>> I'm leaning towards doing the clearing / memsets since I've seen
>>> some firmwares leave some artifacts from not completely clearing
>>> things like a "Press F2 to enter setup" message, missing a few
>>> pixels and leaving those on screen.
>>>
>>
>> I think the overhead of doing the clearing is not going to be the
>> bottleneck. But redrawing
Re: [PATCH v2 08/10] drm/bridge: tc358764: Add DSI to LVDS bridge driver
On 05/31/2018 08:51 AM, Archit Taneja wrote: > Hi, > > On Wednesday 30 May 2018 05:45 PM, Maciej Purski wrote: >> From: Andrzej Hajda >> >> Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge. >> >> Signed-off-by: Andrzej Hajda >> Signed-off-by: Maciej Purski >> --- >> drivers/gpu/drm/bridge/Kconfig | 9 + >> drivers/gpu/drm/bridge/Makefile | 1 + >> drivers/gpu/drm/bridge/tc358764.c | 547 >> ++ >> 3 files changed, 557 insertions(+) >> create mode 100644 drivers/gpu/drm/bridge/tc358764.c >> >> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig >> index fa2c799..9bd3eb8 100644 >> --- a/drivers/gpu/drm/bridge/Kconfig >> +++ b/drivers/gpu/drm/bridge/Kconfig >> @@ -110,6 +110,15 @@ config DRM_THINE_THC63LVD1024 >> ---help--- >> Thine THC63LVD1024 LVDS/parallel converter driver. >> +config DRM_TOSHIBA_TC358764 >> + tristate "TC358764 DSI/LVDS bridge" >> + depends on DRM && DRM_PANEL >> + depends on OF >> + select DRM_MIPI_DSI >> + select VIDEOMODE_HELPERS > > I don't see videomode usage in the driver, can we drop this if it isn't > used? > It seems that those are some remains of old versions. It is not required now. >> + help >> + Toshiba TC358764 DSI/LVDS bridge driver >> + >> config DRM_TOSHIBA_TC358767 >> tristate "Toshiba TC358767 eDP bridge" >> depends on OF >> diff --git a/drivers/gpu/drm/bridge/Makefile >> b/drivers/gpu/drm/bridge/Makefile >> index 35f88d4..bf7c0ce 100644 >> --- a/drivers/gpu/drm/bridge/Makefile >> +++ b/drivers/gpu/drm/bridge/Makefile >> @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o >> obj-$(CONFIG_DRM_SII902X) += sii902x.o >> 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/ >> diff --git a/drivers/gpu/drm/bridge/tc358764.c >> b/drivers/gpu/drm/bridge/tc358764.c >> new file mode 100644 >> index 000..3109eba >> --- /dev/null >> +++ b/drivers/gpu/drm/bridge/tc358764.c >> @@ -0,0 +1,547 @@ > > We'd need a SPDX license here? >> +/* >> + * Copyright (C) 2018 Samsung Electronics Co., Ltd >> + * >> + * Authors: >> + * Andrzej Hajda >> + * Maciej Purski >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program. >> + * >> + */ >> + >> +#include >> + >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> + >> +#define FLD_MASK(start, end) (((1 << ((start) - (end) + 1)) - 1) << >> (end)) >> +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) >> + >> +/* PPI layer registers */ >> +#define PPI_STARTPPI 0x0104 /* START control bit */ >> +#define PPI_LPTXTIMECNT 0x0114 /* LPTX timing signal */ >> +#define PPI_LANEENABLE 0x0134 /* Enables each lane */ >> +#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */ >> +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */ >> +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */ >> +#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */ >> +#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */ >> +#define PPI_START_FUNCTION 1 >> + >> +/* DSI layer registers */ >> +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */ >> +#define DSI_LANEENABLE 0x0210 /* Enables each lane */ >> +#define DSI_RX_START 1 >> + >> +/* Video path registers */ >> +#define VP_CTRL 0x0450 /* Video Path Control */ >> +#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */ >> +#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */ >> +#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */ >> +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */ >> +#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */ >> +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */ >> +#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */ >> +#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */ >> +#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1
Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
Hallo Hans,
On 17 June 2018 at 17:32, Hans de Goede wrote:
> On systems where fbcon is configured for deferred console takeover, the
> intend is for the framebuffer to show the boot graphics (e.g a vendor
> logo) until some message (e.g. an error) is printed or a graphical
> session takes over.
>
> Some firmware however relies on the OS to show the boot graphics
> (indicated by bgrt_tab.status being 0) and the boot graphics may have
> been destroyed by e.g. the grub boot menu.
>
> This patch adds support to efifb to show the boot graphics and
> automatically enables this when fbcon is configured for deferred
> console takeover.
>
> Signed-off-by: Hans de Goede
I have tested this code on ARM QEMU/mach-virt, and with a little tweak
(which I will post separately), the code works as expected, i.e., it
redraws the boot logo based on the contents of the BGRT table.
However, what it doesn't do is clear the screen, which means the logo
is drawn on top of whatever the boot environment left behind, and I
end up with something like this.
http://people.linaro.org/~ard.biesheuvel/mach-virt-bgrt-logo-redrawn.png
> ---
> drivers/video/fbdev/efifb.c | 147
> 1 file changed, 147 insertions(+)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 46a4484e3da7..b041d936a438 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -9,16 +9,39 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include /* For drm_get_panel_orientation_quirk */
> #include /* For DRM_MODE_PANEL_ORIENTATION_* */
>
> +struct bmp_file_header {
> + u16 id;
> + u32 file_size;
> + u32 reserved;
> + u32 bitmap_offset;
> +} __packed;
> +
> +struct bmp_dib_header {
> + u32 dib_header_size;
> + s32 width;
> + s32 height;
> + u16 planes;
> + u16 bpp;
> + u32 compression;
> + u32 bitmap_size;
> + u32 horz_resolution;
> + u32 vert_resolution;
> + u32 colors_used;
> + u32 colors_important;
> +} __packed;
> +
> static bool request_mem_succeeded = false;
> static bool nowc = false;
>
> @@ -66,6 +89,128 @@ static int efifb_setcolreg(unsigned regno, unsigned red,
> unsigned green,
> return 0;
> }
>
> +/*
> + * If fbcon deffered console takeover is configured, the intent is for the
> + * framebuffer to show the boot graphics (e.g. vendor logo) until there is
> some
> + * (error) message to display. But the boot graphics may have been destroyed
> by
> + * e.g. option ROM output, detect this and restore the boot graphics.
> + */
> +#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
> +defined CONFIG_ACPI_BGRT
> +static void efifb_show_boot_graphics(struct fb_info *info)
> +{
> + u32 *dst, bmp_width, bmp_height, bmp_pitch, screen_pitch;
> + struct screen_info *si = &screen_info;
> + struct bmp_file_header *file_header;
> + struct bmp_dib_header *dib_header;
> + void *bgrt_image = NULL;
> + u8 *src, r, g, b;
> + s32 x, y;
> +
> + if (!bgrt_tab.image_address) {
> + pr_info("efifb: No BGRT, not showing boot graphics\n");
> + return;
> + }
> +
> + /* Avoid flashing the logo if we're going to print std probe messages
> */
> + if (console_loglevel > CONSOLE_LOGLEVEL_QUIET)
> + return;
> +
> + /*
> +* We do not check bgrt_tab.status here because this seems to only
> +* reflect if the firmware has shown the boot graphics at all, if it
> +* later got destroyed by something status will still be 1.
> +* Since we draw the exact same graphic at the exact same place this
> +* will not lead to any tearing if the boot graphic is already there.
> +*/
> +
> + if (si->lfb_depth != 32) {
> + pr_info("efifb: not 32 bits, not showing boot graphics\n");
> + return;
> + }
> +
> + bgrt_image = memremap(bgrt_tab.image_address, bgrt_image_size,
> + MEMREMAP_WB);
> + if (!bgrt_image) {
> + pr_warn("efifb: Ignoring BGRT: failed to map image memory\n");
> + return;
> + }
> +
> + if (bgrt_image_size < (sizeof(*file_header) + sizeof(*dib_header)))
> + goto error;
> +
> + file_header = bgrt_image;
> + if (file_header->id != 0x4d42 || file_header->reserved != 0)
> + goto error;
> +
> + dib_header = bgrt_image + sizeof(*file_header);
> + if (dib_header->dib_header_size != 40 || dib_header->width < 0 ||
> + dib_header->planes != 1 || dib_header->bpp != 24 ||
> + dib_header->compression != 0)
> + goto error;
> +
> + bmp_width = dib_header->width;
> + bmp_height = abs(dib_header->height);
> + bmp_pitch =
Re: [PATCH v2 07/10] dt-bindings: tc358754: add DT bindings
On 05/31/2018 06:02 AM, Rob Herring wrote:
> On Wed, May 30, 2018 at 02:15:58PM +0200, Maciej Purski wrote:
>> From: Andrzej Hajda
>>
>> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
>> Bindings describe power supplies, reset gpio and video interfaces.
>>
>> Signed-off-by: Andrzej Hajda
>> Signed-off-by: Maciej Purski
>> ---
>> .../bindings/display/bridge/toshiba,tc358764.txt | 37
>> ++
>> 1 file changed, 37 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>> new file mode 100644
>> index 000..6eda14f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>> @@ -0,0 +1,37 @@
>> +TC358764 MIPI-DSI to LVDS panel bridge
>> +
>> +Required properties:
>> + - compatible: "toshiba,tc358764"
>> + - reg: the virtual channel number of a DSI peripheral
>> + - vddc-supply: core voltage supply, 1.2V
>> + - vddio-supply: I/O voltage supply, 1.8V or 3.3V
>> + - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
>> + - reset-gpios: a GPIO spec for the reset pin
>> +
>> +The device node can contain zero to two 'port' child nodes, each with one
>
> How would 0 ports be valid?
>
I'll fix this. In my opinion the output LVDS port should be mandatory
and the input DSI port should be optional, as the bridge might be a DSI
child node. According to documentation, the bridge can also be I2C controlled.
In this case, it should contain a DSI input port and LVDS output port.
>> +child 'endpoint' node, according to the bindings defined in [1].
>> +The following are properties specific to those nodes.
>> +
>> +port:
>> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
>> +
>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +
>> +bridge@0 {
>> +reg = <0>;
>> +compatible = "toshiba,tc358764";
>> +vddc-supply = <&vcc_1v2_reg>;
>> +vddio-supply = <&vcc_1v8_reg>;
>> +vddlvds-supply = <&vcc_3v3_reg>;
>> +reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +port@1 {
>> +reg = <1>;
>> +lvds_ep: endpoint {
>> +remote-endpoint = <&panel_ep>;
>> +};
>> +};
>> +};
>> --
>> 2.7.4
>>
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2] drm/xen-front: fix pointer casts
On 06/18/2018 01:06 PM, Andre Przywara wrote: Hi, On 25/05/18 06:32, Oleksandr Andrushchenko wrote: On 05/23/2018 02:46 PM, Juergen Gross wrote: On 23/05/18 13:36, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Building for a 32-bit target results in warnings from casting between a 32-bit pointer and a 64-bit integer. Fix the warnings by casting those pointers to uintptr_t first. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Juergen Gross Thank you, applied to drm-misc-next Is this the right branch? Shouldn't this go to drm-misc-fixes instead, so it reaches the tree before the 4.18 release? Just stumbled over the issue when compiling 4.18-rc1 for arm32, so it definitely needs fixing in this cycle. Maarten, can this be done please? Cheers, Andre. Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gvt: Use ARRAY_SIZE macro
From: Rajan Vaja Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element. This fixes below warning reported by Coccinelle: drivers/gpu/drm//i915/gvt/vgpu.c:122:30-31: WARNING: Use ARRAY_SIZE Signed-off-by: Rajan Vaja --- drivers/gpu/drm/i915/gvt/vgpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c index 2e0a02a..e4c3368 100644 --- a/drivers/gpu/drm/i915/gvt/vgpu.c +++ b/drivers/gpu/drm/i915/gvt/vgpu.c @@ -119,7 +119,7 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt) */ low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE; high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE; - num_types = sizeof(vgpu_types) / sizeof(vgpu_types[0]); + num_types = ARRAY_SIZE(vgpu_types); gvt->types = kzalloc(num_types * sizeof(struct intel_vgpu_type), GFP_KERNEL); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/10] dt-bindings: tc358754: add DT bindings
On 05/30/2018 02:36 PM, Laurent Pinchart wrote:
> Hi Maciej,
>
> On Wednesday, 30 May 2018 15:15:58 EEST Maciej Purski wrote:
>> From: Andrzej Hajda
>>
>> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
>> Bindings describe power supplies, reset gpio and video interfaces.
>>
>> Signed-off-by: Andrzej Hajda
>> Signed-off-by: Maciej Purski
>> ---
>> .../bindings/display/bridge/toshiba,tc358764.txt | 37 +++
>> 1 file changed, 37 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt new
>> file mode 100644
>> index 000..6eda14f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>> @@ -0,0 +1,37 @@
>> +TC358764 MIPI-DSI to LVDS panel bridge
>> +
>> +Required properties:
>> + - compatible: "toshiba,tc358764"
>> + - reg: the virtual channel number of a DSI peripheral
>> + - vddc-supply: core voltage supply, 1.2V
>> + - vddio-supply: I/O voltage supply, 1.8V or 3.3V
>> + - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
>> + - reset-gpios: a GPIO spec for the reset pin
>> +
>> +The device node can contain zero to two 'port' child nodes, each with one
>> +child 'endpoint' node, according to the bindings defined in [1].
>> +The following are properties specific to those nodes.
>> +
>> +port:
>> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
>> +
>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>
> Could you please take the comments I made on v1 into account when you'll post
> v3 ?
>
For now I'm going to stick with the old convention and make port 0 optional,
when the bridge is a DSI child and LVDS port 1 mandatory.
The current policy does not seem to have been changed. There's a quiet new
binding,
which follows the old convention:
Documentation/devicetree/bindings/connector/usb-connector.txt
If you can find an example of new bindings, which follow your convention and you
convince Rob, then I'll be completely okay with it and I'll change it the way
you propose.
>> +Example:
>> +
>> +bridge@0 {
>> +reg = <0>;
>> +compatible = "toshiba,tc358764";
>> +vddc-supply = <&vcc_1v2_reg>;
>> +vddio-supply = <&vcc_1v8_reg>;
>> +vddlvds-supply = <&vcc_3v3_reg>;
>> +reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +port@1 {
>> +reg = <1>;
>> +lvds_ep: endpoint {
>> +remote-endpoint = <&panel_ep>;
>> +};
>> +};
>> +};
>
>
Best regards,
Maciej Purski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
Hi Hans, On 06/17/2018 05:32 PM, Hans de Goede wrote: > On systems where fbcon is configured for deferred console takeover, the > intend is for the framebuffer to show the boot graphics (e.g a vendor > logo) until some message (e.g. an error) is printed or a graphical > session takes over. > > Some firmware however relies on the OS to show the boot graphics > (indicated by bgrt_tab.status being 0) and the boot graphics may have > been destroyed by e.g. the grub boot menu. It may be clearer to just say that the boot graphics may have been destroyed. The reference to the status field and firmware expectations only confuses the intention of this patch, imho. (This ties in to what I say below) > This patch adds support to efifb to show the boot graphics and > automatically enables this when fbcon is configured for deferred > console takeover. > > + /* > + * We do not check bgrt_tab.status here because this seems to only > + * reflect if the firmware has shown the boot graphics at all, if it > + * later got destroyed by something status will still be 1. > + * Since we draw the exact same graphic at the exact same place this > + * will not lead to any tearing if the boot graphic is already there. > + */ I agree that ignoring bgrt_tab.status is the absolute best option. The status (valid-bit) can, in the real world, be any value with any meaning. I checked this on a few machines as part of commit 66dbe99cfe30. - My workstation always has 0. - An old server that I checked always has 1. - My laptop has 1 if the boot is uninterrupted, 0 if I request the UEFI boot menu. So, I have the same reservation about this comment as I have about the commit message. Imho, simply mentioning that the status field cannot be relied upon (in any case), would get the point across. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
