[PATCH v11 15/25] fs/io_uring: set FOLL_PIN via pin_user_pages()

Convert fs/io_uring to use the new pin_user_pages() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages, and therefore for any code that calls put_user_page(). In partial anticipation of this work, the io_uring code was already calling

[PATCH v11 19/25] vfio, mm: pin_user_pages (FOLL_PIN) and put_user_page() conversion

1. Change vfio from get_user_pages_remote(), to pin_user_pages_remote(). 2. Because all FOLL_PIN-acquired pages must be released via put_user_page(), also convert the put_page() call over to put_user_pages_dirty_lock(). Note that this effectively changes the code's behavior in

[PATCH v11 22/25] mm, tree-wide: rename put_user_page*() to unpin_user_page*()

In order to provide a clearer, more symmetric API for pinning and unpinning DMA pages. This way, pin_user_pages*() calls match up with unpin_user_pages*() calls, and the API is a lot closer to being self-explanatory. Reviewed-by: Jan Kara Signed-off-by: John Hubbard ---

[PATCH v11 02/25] mm/gup: move try_get_compound_head() to top, fix minor issues

An upcoming patch uses try_get_compound_head() more widely, so move it to the top of gup.c. Also fix a tiny spelling error and a checkpatch.pl warning. Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: Ira Weiny Signed-off-by: John Hubbard --- mm/gup.c | 29

[PATCH v11 04/25] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages

An upcoming patch changes and complicates the refcounting and especially the "put page" aspects of it. In order to keep everything clean, refactor the devmap page release routines: * Rename put_devmap_managed_page() to page_is_devmap_managed(), and limit the functionality to "read only": return

[PATCH v11 05/25] goldish_pipe: rename local pin_user_pages() routine

1. Avoid naming conflicts: rename local static function from "pin_user_pages()" to "goldfish_pin_pages()". An upcoming patch will introduce a global pin_user_pages() function. Reviewed-by: Jan Kara Reviewed-by: Jérôme Glisse Reviewed-by: Ira Weiny Signed-off-by: John Hubbard ---

[PATCH v11 06/25] mm: fix get_user_pages_remote()'s handling of FOLL_LONGTERM

As it says in the updated comment in gup.c: current FOLL_LONGTERM behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the FS DAX check requirement on vmas. However, the corresponding restriction in get_user_pages_remote() was slightly stricter than is actually required: it forbade all

[Bug 205879] amdgpu: blank screen on RX 460

https://bugzilla.kernel.org/show_bug.cgi?id=205879 Bjoern Franke (b...@nord-west.org) changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support.

(Brilliant, I managed to accidentally send the email below, and send it as HTML, sorry about that... ASCII art in gmail is hard ,-( Take 2:) Hi Laurent, > On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart > wrote: > > > > Hello Nicolas and Hsin-Yi, > > > > On Mon, Dec 16, 2019 at 06:19:24PM

Re: [PATCH v11 23/25] mm/gup: track FOLL_PIN pages

On 12/16/19 4:53 AM, Jan Kara wrote: ... I'd move this still a bit higher - just after VM_BUG_ON_PAGE() and before if (flags & FOLL_TOUCH) test. Because touch_pmd() can update page tables and we don't won't that if we're going to fail the fault. Done. I'll post a full v11 series shortly.

Re: [PATCH 05/10] drm/mediatek: plane_state->fb iff plane_state->crtc

Hi, Daniel: On Fri, 2019-12-13 at 18:26 +0100, Daniel Vetter wrote: > Checking both is one too much, so wrap a WARN_ON around it to stope > the copypasta. Even though I don't know what is copypasta, Acked-by: CK Hu > > Signed-off-by: Daniel Vetter > Cc: CK Hu > Cc: Philipp Zabel > Cc:

Re: [PATCH 9/9] drm/bridge: ti-sn65dsi86: Skip non-standard DP rates

Hi, On Sun, Dec 15, 2019 at 5:19 PM Jeffrey Hugo wrote: > > On Fri, Dec 13, 2019 at 5:49 PM Doug Anderson wrote: > > > > Hi, > > > > On Fri, Dec 13, 2019 at 4:07 PM Daniel Vetter wrote: > > > > > > On Fri, Dec 13, 2019 at 03:45:30PM -0800, Douglas Anderson wrote: > > > > The bridge chip

[PATCH v3] drm: Add getfb2 ioctl

From: Daniel Stone getfb2 allows us to pass multiple planes and modifiers, just like addfb2 over addfb. Changes since v2: - add privilege checks from getfb1 since handles should only be returned to master/root Changes since v1: - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID

[PATCH v11 21/25] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1"

Fix the gup benchmark flags to use the symbolic FOLL_WRITE, instead of a hard-coded "1" value. Also, clean up the filtering of gup flags a little, by just doing it once before issuing any of the get_user_pages*() calls. This makes it harder to overlook, instead of having little "gup_flags & 1"

[PATCH v11 24/25] mm/gup_benchmark: support pin_user_pages() and related calls

Up until now, gup_benchmark supported testing of the following kernel functions: * get_user_pages(): via the '-U' command line option * get_user_pages_longterm(): via the '-L' command line option * get_user_pages_fast(): as the default (no options required) Add test coverage for the new

[PATCH v11 13/25] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()

Convert process_vm_access to use the new pin_user_pages_remote() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages. Also, release the pages via put_user_page*(). Also, rename "pages" to "pinned_pages", as this makes for easier reading of

[PATCH v11 16/25] net/xdp: set FOLL_PIN via pin_user_pages()

Convert net/xdp to use the new pin_longterm_pages() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages. In partial anticipation of this work, the net/xdp code was already calling put_user_page() instead of put_page(). Therefore, in order to

[PATCH v11 07/25] vfio: fix FOLL_LONGTERM use, simplify get_user_pages_remote() call

Update VFIO to take advantage of the recently loosened restriction on FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it wasn't setting FOLL_LONGTERM. Also, remove an unnessary pair of calls that were

[PATCH v11 20/25] powerpc: book3s64: convert to pin_user_pages() and put_user_page()

1. Convert from get_user_pages() to pin_user_pages(). 2. As required by pin_user_pages(), release these pages via put_user_page(). Reviewed-by: Jan Kara Signed-off-by: John Hubbard --- arch/powerpc/mm/book3s64/iommu_api.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH v11 12/25] IB/{core, hw, umem}: set FOLL_PIN via pin_user_pages*(), fix up ODP

Convert infiniband to use the new pin_user_pages*() calls. Also, revert earlier changes to Infiniband ODP that had it using put_user_page(). ODP is "Case 3" in Documentation/core-api/pin_user_pages.rst, which is to say, normal get_user_pages() and put_page() is the API to use there. The new

[PATCH v11 25/25] selftests/vm: run_vmtests: invoke gup_benchmark with basic FOLL_PIN coverage

It's good to have basic unit test coverage of the new FOLL_PIN behavior. Fortunately, the gup_benchmark unit test is extremely fast (a few milliseconds), so adding it the the run_vmtests suite is going to cause no noticeable change in running time. So, add two new invocations to run_vmtests: 1)

[PATCH v3] drm: rcar-du: lvds: Get mode from state

The R-Car LVDS encoder driver implements the bridge .mode_set() operation for the sole purpose of storing the mode in the LVDS private data, to be used later when enabling the encoder. Switch to the bridge .atomic_enable() and .atomic_disable() operations in order to access the global atomic

[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)

https://bugzilla.kernel.org/show_bug.cgi?id=200695 Claude Heiland-Allen (cla...@mathr.co.uk) changed: What|Removed |Added Kernel Version|4.17.19, 4.18.5 -- 4.18.20, |4.17.19,

Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support.

Hi Nicolas, On Tue, Dec 17, 2019 at 08:40:51AM +0800, Nicolas Boichat wrote: > (Brilliant, I managed to accidentally send the email below, and send > it as HTML, sorry about that... ASCII art in gmail is hard ,-( No worries. I have been told it's indeed painful. > Take 2:) > > Hi Laurent, > >

[PATCH] drm/tegra: Use more descriptive format modifiers

Advertise and accept both the existing DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based format modifiers and the more descriptive DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D()-based format modifiers, preserving backwards compatibility with existing userspace drivers, but providing forwards compatibility with

Re: [PATCH] drm/mediatek: reduce the hbp and hfp for phy timing

Hi, On Mon, 2019-12-16 at 11:30 +0100, Enric Balletbo Serra wrote: > Hi all, > > Missatge de Hsin-Yi Wang del dia dl., 16 de des. > 2019 a les 3:42: > > > > On Fri, Dec 13, 2019 at 9:52 AM Jitao Shi wrote: > > > > > > There are some extra data transfer in dsi. > > > ex. LPX, hs_prepare,

Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support.

Hi Laurent, On Tue, Dec 17, 2019 at 12:39 AM Laurent Pinchart < laurent.pinch...@ideasonboard.com> wrote: > > Hello Nicolas and Hsin-Yi, > > On Mon, Dec 16, 2019 at 06:19:24PM +0800, Nicolas Boichat wrote: > > On Mon, Dec 16, 2019 at 4:46 PM Hsin-Yi Wang wrote: > > > On Sat, Dec 14, 2019 at 6:38

[PATCH] drm/nouveau: Fix ttm move init with multiple GPUs

The pointer used to walk the table of move ops and pick the right one for the current GPU was declared static, meaning its state was carried over between invocations of the function, and also made the function non-rentrant and thread-unsafe. Since the table is ordered such that newer GPU methods

[PATCH] drm/nouveau: Add correct turing page kinds

Turing introduced a new simplified page kind scheme, reducing the number of possible page kinds from 256 to 16. It also is the first NVIDIA GPU in which the highest possible page kind value is not reserved as an "invalid" page kind. To address this, the invalid page kind is made an explicit

[PATCH v2 3/3] drm/nouveau: Support NVIDIA format modifiers

Allow setting the block layout of a nouveau FB object using DRM format modifiers. When specified, the format modifier block layout and kind overrides the GEM buffer's implicit layout and kind. The specified format modifier is validated against he list of modifiers supported by the target display

[PATCH v2 0/3] drm/nouveau: Support NVIDIA format modifiers

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available here: https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work But those

[PATCH v2 2/3] drm/nouveau: Check framebuffer size against bo

Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++ 1 file changed, 93 insertions(+) diff --git

[PATCH v11 23/25] mm/gup: track FOLL_PIN pages

Add tracking of pages that were pinned via FOLL_PIN. As mentioned in the FOLL_PIN documentation, callers who effectively set FOLL_PIN are required to ultimately free such pages via unpin_user_page(). The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET for DIO and/or RDMA use".

[PATCH v11 17/25] media/v4l2-core: set pages dirty upon releasing DMA buffers

After DMA is complete, and the device and CPU caches are synchronized, it's still required to mark the CPU pages as dirty, if the data was coming from the device. However, this driver was just issuing a bare put_page() call, without any set_page_dirty*() call. Fix the problem, by calling

[PATCH v11 08/25] mm/gup: allow FOLL_FORCE for get_user_pages_fast()

Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast(). This, combined with the fact that get_user_pages_fast() falls back to "slow gup", which *does* accept FOLL_FORCE, leads to an odd situation: if you need

[PATCH v11 10/25] mm/gup: introduce pin_user_pages*() and FOLL_PIN

Introduce pin_user_pages*() variations of get_user_pages*() calls, and also pin_longterm_pages*() variations. For now, these are placeholder calls, until the various call sites are converted to use the correct get_user_pages*() or pin_user_pages*() API. These variants will eventually all set

[PATCH v11 14/25] drm/via: set FOLL_PIN via pin_user_pages_fast()

Convert drm/via to use the new pin_user_pages_fast() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages, and therefore for any code that calls put_user_page(). In partial anticipation of this work, the drm/via driver was already calling

[PATCH v11 09/25] IB/umem: use get_user_pages_fast() to pin DMA pages

And get rid of the mmap_sem calls, as part of that. Note that get_user_pages_fast() will, if necessary, fall back to __gup_longterm_unlocked(), which takes the mmap_sem as needed. Reviewed-by: Leon Romanovsky Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: Jason Gunthorpe

[PATCH v11 18/25] media/v4l2-core: pin_user_pages (FOLL_PIN) and put_user_page() conversion

1. Change v4l2 from get_user_pages() to pin_user_pages(). 2. Because all FOLL_PIN-acquired pages must be released via put_user_page(), also convert the put_page() call over to put_user_pages_dirty_lock(). Acked-by: Hans Verkuil Cc: Ira Weiny Signed-off-by: John Hubbard ---

[PATCH v11 03/25] mm: Cleanup __put_devmap_managed_page() vs ->page_free()

From: Dan Williams After the removal of the device-public infrastructure there are only 2 ->page_free() call backs in the kernel. One of those is a device-private callback in the nouveau driver, the other is a generic wakeup needed in the DAX case. In the hopes that all ->page_free() callbacks

Re: [Nouveau] [PATCH 3/3] drm/nouveau: Support NVIDIA format modifiers

On 12/12/19 6:51 PM, James Jones wrote: On 12/11/19 1:13 PM, Ilia Mirkin wrote: On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote: Allow setting the block layout of a nouveau FB object using DRM format modifiers.  When specified, the format modifier block layout and kind overrides the GEM

Re: [PATCH 5/6] drm/mediatek: Convert to use CMA helpers

Hi Rob, On Thu, Oct 24, 2019 at 03:02:57PM +0800, CK Hu wrote: > On Wed, 2019-10-23 at 17:56 -0500, Rob Herring wrote: > > On Wed, Oct 23, 2019 at 4:06 PM CK Hu wrote: > > > On Wed, 2019-10-23 at 12:42 -0500, Rob Herring wrote: > > > > On Tue, Oct 22, 2019 at 12:07 PM Matthias Brugger wrote: > >

[PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN

Hi, This implements an API naming change (put_user_page*() --> unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It extends that tracking to a few select subsystems. More subsystems will be added in follow up work. Christoph Hellwig, a point of interest: a) I've moved the

[PATCH v11 01/25] mm/gup: factor out duplicate code from four routines

There are four locations in gup.c that have a fair amount of code duplication. This means that changing one requires making the same changes in four places, not to mention reading the same code four times, and wondering if there are subtle differences. Factor out the common code into static

[PATCH v11 11/25] goldish_pipe: convert to pin_user_pages() and put_user_page()

1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages(). 2. As required by pin_user_pages(), release these pages via put_user_page(). In this case, do so via put_user_pages_dirty_lock(). That has the side effect of calling set_page_dirty_lock(), instead of set_page_dirty(). This

[Bug 204609] amdgpu: powerplay failed send message

https://bugzilla.kernel.org/show_bug.cgi?id=204609 Błażej Szczygieł (spa...@wp.pl) changed: What|Removed |Added CC||spa...@wp.pl ---

[PATCH v2 1/3] drm/nouveau: Add format mod prop to base/ovly/nvdisp

Advertise support for the full list of format modifiers supported by each class of NVIDIA desktop GPU display hardware. Stash the array of modifiers in the nouveau_display struct for use when validating userspace framebuffer creation requests, which will be supportd in a subsequent change.

Re: linux-next: Tree for Dec 16 (drm_panel & intel_panel)

Hi Randy. On Mon, Dec 16, 2019 at 08:25:11AM -0800, Randy Dunlap wrote: > On 12/15/19 9:22 PM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20191213: > > > > on x86_64: > > ld: drivers/gpu/drm/drm_panel.o: in function `drm_panel_of_backlight': > (.text+0x2ee): undefined reference

Re: [PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support.

Hi, On Tue, Dec 17, 2019 at 8:52 AM Laurent Pinchart wrote: > > Hi Nicolas, > > On Tue, Dec 17, 2019 at 08:40:51AM +0800, Nicolas Boichat wrote: > > (Brilliant, I managed to accidentally send the email below, and send > > it as HTML, sorry about that... ASCII art in gmail is hard ,-( > > No

Re: [PATCH v3 18/50] drm/omap: dss: Cleanup DSS ports on initialisation failure

On 11/12/2019 00:57, Laurent Pinchart wrote: When the DSS initialises its output DPI and SDI ports, failures don't clean up previous successfully initialised ports. This can lead to resource leak or memory corruption. Fix it. Reported-by: Hans Verkuil Signed-off-by: Laurent Pinchart ---

Re: [PATCH v3 17/50] drm/omap: Fix possible object reference leak

On 11/12/2019 00:57, Laurent Pinchart wrote: From: Wen Yang The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings:

Re: [PATCH v11 23/25] mm/gup: track FOLL_PIN pages

On Mon 16-12-19 14:18:59, John Hubbard wrote: > On 12/16/19 4:53 AM, Jan Kara wrote: > > With this fixed, the patch looks good to me so you can then add: > > > > Reviewed-by: Jan Kara > > > > Honza > > > > btw, thanks for the

Re: [PATCH 1/1] drm/sun4i: hdmi: Check for null pointer before cleanup

On Mon, Dec 16, 2019 at 04:43:48PM +0200, Stefan Mavrodiev wrote: > It's possible hdmi->connector and hdmi->encoder divices to be NULL. The wording is broken and s/divices/devices/. I'd write: It's possible that the parent devices of the connector and/or encoder are NULL. This

Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN

Hi! On Mon 16-12-19 14:25:12, John Hubbard wrote: > Hi, > > This implements an API naming change (put_user_page*() --> > unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It > extends that tracking to a few select subsystems. More subsystems will > be added in follow up work.

Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding

On Sat, Dec 14, 2019 at 5:29 AM Rob Herring wrote: > > On Wed, Dec 11, 2019 at 12:19 AM Hsin-Yi Wang wrote: > > > > From: Nicolas Boichat > > > > Add bindings for Generic GPIO mux driver. > > > > Signed-off-by: Nicolas Boichat > > Signed-off-by: Hsin-Yi Wang > > --- > > Change from RFC to v1:

Regression in 5.4 kernel on 32-bit Radeon IBM T40

Regression in 5.4 kernel on 32-bit Radeon IBM T40 triggered by commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 Author: Christoph Hellwig Date:   Thu Aug 15 09:27:00 2019 +0200 Howdy, The above patch has triggered a display problem on IBM Thinkpad T40, where the screen is covered with a lots of

KASAN: use-after-free Read in fbcon_cursor

Hello, syzbot found the following crash on: HEAD commit:07c4b9e9 Merge tag 'scsi-fixes' of git://git.kernel.org/pu.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=14b61f41e0 kernel config: https://syzkaller.appspot.com/x/.config?x=79f79de2a27d3e3d

[PATCH 2/4] dt-binds: display: mediatek: get mipitx calibration data from nvmem

Add properties to get get mipitx calibration data. Signed-off-by: Jitao Shi --- .../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt

Re: [PATCH] drm: rcar-du: Add r8a77980 support

Hi Laurent, On 13/12/2019 00:48, Laurent Pinchart wrote: > Hi Kieran, > > On Mon, Dec 09, 2019 at 12:41:07PM +, Kieran Bingham wrote: >> On 13/09/2019 10:03, Laurent Pinchart wrote: >>> On Fri, Sep 13, 2019 at 10:21:29AM +0200, Simon Horman wrote: On Thu, Sep 12, 2019 at 01:00:41PM

Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight

Hi, On 16-12-2019 10:30, Lee Jones wrote: [...] Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. Since only the i915 driver has access to the VBT, this commit renames the

Re: [PATCH 0/5] drm/i915/dsi: Control panel and backlight enable GPIOs from VBT

Hi, On 16-12-2019 11:26, Linus Walleij wrote: On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote: Linus, this series starts with the already discussed pinctrl change to export the function to unregister a pinctrl-map. We can either merge this through drm-intel, or you could pick it up and

Re: [PATCH v5 0/6] drm/rockchip: px30 dsi support

Hi Neil, Am Montag, 16. Dezember 2019, 11:40:00 CET schrieb Neil Armstrong: > On 09/12/2019 15:31, Heiko Stuebner wrote: > > From: Heiko Stuebner > > > > This series addes support for the px30 Rockchip soc to the dsi driver. > > This includes support for external dsi-phys like used on the px30.

Re: [PATCH] backlight: corgi: Convert to use GPIO descriptors

On Sat, 14 Dec 2019, Linus Walleij wrote: > On Fri, Dec 13, 2019 at 6:24 PM Robert Jarzmik wrote: > > Linus Walleij writes: > > > On Sun, Dec 8, 2019 at 9:06 PM Robert Jarzmik > > > wrote: > > >> Linus Walleij writes: > > > > So it will theoretically "spi0.1" > > > > > > Beware about bugs

[PATCH 0/4] Config mipi tx drive current and impedance

Changes in this patch: - add the mipitx driving current control. - config the mipitx impedance with calibration data in nvmem. Jitao Shi (4): dt-binds: display: mediatek: add property to control mipi tx drive current dt-binds: display: mediatek: get mipitx calibration data from nvmem

Re: [PATCH v3] drm: Funnel drm logs to tracepoints

On Fri, 13 Dec 2019 11:54:33 -0500 Sean Paul wrote: > On Fri, Dec 13, 2019 at 01:34:46PM +0200, Pekka Paalanen wrote: > > On Thu, 12 Dec 2019 15:32:35 -0500 > > Sean Paul wrote: > > > > > From: Sean Paul > > > > > > For a long while now, we (ChromeOS) have been struggling getting any > > >

Re: [PATCH v3 16/50] drm: Add helper to create a connector for a chain of bridges

On Wed, 11 Dec 2019 00:57:16 +0200 Laurent Pinchart wrote: > Most bridge drivers create a DRM connector to model the connector at the > output of the bridge. This model is historical and has worked pretty > well so far, but causes several issues: > > - It prevents supporting more complex

Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight

[...] > > > > > > > > > Which use a Crystal Cove PMIC, yet the LCD is connected to > > > > > > > > > the SoC/LPSS > > > > > > > > > PWM controller (and the VBT correctly indicates this), so > > > > > > > > > here our old > > > > > > > > > heuristics fail. > > > > > > > > > > > > > > > > > >

Re: [PATCH] drm/i915: Remove unneeded semicolon

On 2019.12.16 11:44:05 +0800, zhengbin wrote: > Fixes coccicheck warning: > > drivers/gpu/drm/i915/gem/i915_gem_region.c:88:2-3: Unneeded semicolon > drivers/gpu/drm/i915/gvt/gtt.c:1285:2-3: Unneeded semicolon > > Reported-by: Hulk Robot > Signed-off-by: zhengbin > --- >

Re: [PATCH v2] drm/panfrost: Prefix interrupt handlers' names

On 14/12/2019 04:59, Ezequiel Garcia wrote: > Currently, the interrupt lines requested by Panfrost > use unmeaningful names, which adds some obscurity > to interrupt introspection (i.e. any tool based > on procfs' interrupts file). > > In order to improve this, prefix each requested > interrupt

Re: [PATCH 5/5] drm/i915/dsi: Control panel and backlight enable GPIOs on BYT

On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote: > On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels > do not control the LCD panel- and backlight-enable GPIOs. So far, when > the VBT indicates we should use the SoC for backlight control, we have > been relying on these

Re: [PATCH] drm/mediatek: reduce the hbp and hfp for phy timing

Hi all, Missatge de Hsin-Yi Wang del dia dl., 16 de des. 2019 a les 3:42: > > On Fri, Dec 13, 2019 at 9:52 AM Jitao Shi wrote: > > > > There are some extra data transfer in dsi. > > ex. LPX, hs_prepare, hs_zero, hs_exit and the sof/eof of dsi packet. > > This signal will enlarge the line time.

Re: [GIT PULL] drm/arc: Yet another set of minor fixes

On Fri, Dec 13, 2019 at 10:24:42AM +, Alexey Brodkin wrote: > Hi Daniel, > > > -Original Message- > > From: Daniel Vetter > > Sent: Friday, December 13, 2019 1:22 PM > > To: Alexey Brodkin > > Cc: Daniel Vetter ; David Airlie ; arcml > > > a...@lists.infradead.org>; Eugeniy

Re: [PATCH 1/5] drm/i915: Fix eDP DPCD aux max backlight calculations

On Mon, 16 Dec 2019, AceLan Kao wrote: > I tried to reply the patch from the mailing list archive by clicking > the author name > https://lists.freedesktop.org/archives/dri-devel/2019-November/246278.html > >

Re: [PATCH v12 1/7] dt-bindings: sun6i-dsi: Document A64 MIPI-DSI controller

On Wed, Dec 4, 2019 at 7:06 PM Maxime Ripard wrote: > > On Tue, Dec 03, 2019 at 07:18:10PM +0530, Jagan Teki wrote: > > The MIPI DSI controller in Allwinner A64 is similar to A33. > > > > But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid > > to have separate compatible for A64 on

Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes

Hi, > > I suspect for imported dma-bufs we should leave the mmap() to the > > exporter instead of pulling the pages out of the sgt and map them > > ourself. > > Uh yes. If we still do that, then yes very much we shouldn't. Looking again. drm_gem_dumb_map_offset() throws an error in case

[PATCH 4/4] drm/mediatek: config mipitx impedance with calibration data

Read calibration data from nvmem, and config mipitx impedance with calibration data to make sure their impedance are 100ohm. Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1 + drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 63 +++ 2 files

[PATCH 3/4] drm/mediatek: add the mipitx driving control

Add a property in device tree to control the driving by different board. Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 6 ++ drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1 + drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 7 +++ 3 files changed, 14

[PATCH 1/4] dt-binds: display: mediatek: add property to control mipi tx drive current

Add a property to control mipi tx drive current: "mipitx-current-drive" Signed-off-by: Jitao Shi --- .../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt

Re: [PATCH 3/5] drm/i915/dsi: Init panel-enable GPIO to low when the LCD is initially off

On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote: > When the LCD has not been turned on by the firmware/GOP, because e.g. the > device was booted with an external monitor connected over HDMI, we should > not turn on the panel-enable GPIO when we request it. > > Turning on the panel-enable

Re: [PATCH 2/5] drm/i915/dsi: Move poking of panel-enable GPIO to intel_dsi_vbt.c

On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote: > On some older devices (BYT, CHT) which may use v2 VBT MIPI-sequences, > we need to manually control the panel enable GPIO as v2 sequences do > not do this. > > So far we have been carrying the code to do this on BYT/CHT devices > with a

Re: [PATCH v5 1/6] drm/bridge/synopsys: dsi: driver-specific configuration of phy timings

On 09/12/2019 15:31, Heiko Stuebner wrote: > From: Heiko Stuebner > > The timing values for dw-dsi are often dependent on the used display and > according to Philippe Cornu will most likely also depend on the used phy > technology in the soc-specific implementation. > > To solve this and allow

Re: [PATCH] drm: rcar-du: Add r8a77980 support

Hi Kieran, Laurent, On Mon, Dec 16, 2019 at 10:47 AM Kieran Bingham wrote: > On 13/12/2019 00:48, Laurent Pinchart wrote: > > On Mon, Dec 09, 2019 at 12:41:07PM +, Kieran Bingham wrote: > >> On 13/09/2019 10:03, Laurent Pinchart wrote: > >>> On Fri, Sep 13, 2019 at 10:21:29AM +0200, Simon

Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412

On 9/19/19 11:22 PM, Artur Świgoń wrote: > From: Artur Świgoń > > This patch adds two fields to the Exynos4412 DTS: > - parent: to declare connections between nodes that are not in a > parent-child relation in devfreq; > - #interconnect-cells: required by the interconnect framework. > >

[PATCH] drm/bochs: Remove unneeded semicolon

Fixes coccicheck warning: drivers/gpu/drm/bochs/bochs_hw.c:258:2-3: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/bochs/bochs_hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bochs/bochs_hw.c

[PATCH] drm/i915: Remove unneeded semicolon

Fixes coccicheck warning: drivers/gpu/drm/i915/gem/i915_gem_region.c:88:2-3: Unneeded semicolon drivers/gpu/drm/i915/gvt/gtt.c:1285:2-3: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/i915/gem/i915_gem_region.c | 2 +- drivers/gpu/drm/i915/gvt/gtt.c

[RFC v1 0/1] drm: lima: devfreq and cooling device support

This is my attempt at adding devfreq (and cooling device) support to the lima driver. I didn't have much time to do in-depth testing. However, I'm sending this out early because there are many SoCs with Mali-400/450 GPU so I want to avoid duplicating the work with somebody else. The code is

Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412

Hi, On 9/19/19 11:22 PM, Artur Świgoń wrote: > From: Artur Świgoń > > This patch adds two fields to the Exynos4412 DTS: > - parent: to declare connections between nodes that are not in a > parent-child relation in devfreq; > - #interconnect-cells: required by the interconnect framework.

Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412

Hi, Please ignore second reply. It is my mistake to send the duplicate message because of my company firewall issue. Regards, Chanwoo Choi On 12/16/19 9:55 AM, Chanwoo Choi wrote: > Hi, > > On 9/19/19 11:22 PM, Artur Świgoń wrote: >> From: Artur Świgoń >> >> This patch adds two fields to the

Re: [RFC PATCH v2 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412

Hi, On 12/16/19 9:51 AM, Chanwoo Choi wrote: > On 9/19/19 11:22 PM, Artur Świgoń wrote: >> From: Artur Świgoń >> >> This patch adds two fields to the Exynos4412 DTS: >> - parent: to declare connections between nodes that are not in a >> parent-child relation in devfreq; >> -

[PATCH] drm: meson: Remove unneeded semicolon

Fixes coccicheck warning: drivers/gpu/drm/meson/meson_crtc.c:360:3-4: Unneeded semicolon drivers/gpu/drm/meson/meson_plane.c:181:2-3: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/meson/meson_crtc.c | 2 +- drivers/gpu/drm/meson/meson_plane.c | 2 +-

Re: [RFC PATCH v2 05/11] interconnect: Export of_icc_get_from_provider()

On 9/19/19 11:22 PM, Artur Świgoń wrote: > From: Artur Świgoń > > This patch makes the above function public (for use in exynos-bus devfreq > driver). > > Signed-off-by: Artur Świgoń > Reviewed-by: Krzysztof Kozlowski > --- > drivers/interconnect/core.c | 3 ++- >

[PATCH] drm: remove duplicate check on parent and avoid BUG_ON

In drm_dev_init, parent is checked for NULL via assert after checked in devm_drm_dev_init(). The patch removes the duplicate check and replaces the assertion with WARN_ON. Further, it returns -EINVAL consistent with the usage in devm_drm_dev_init. Signed-off-by: Aditya Pakki ---

[RFC v1 1/1] drm/lima: Add optional devfreq support

Most platforms with a Mali-400 or Mali-450 GPU also have support for changing the GPU clock frequency. Add devfreq support so the GPU clock rate is updated based on the actual GPU usage when the "operating-points-v2" property is present in the board.dts. The actual devfreq code is taken from

[PATCH] drm/nouveau/mmu: Remove unneeded semicolon

Fixes coccicheck warning: drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:583:2-3: Unneeded semicolon drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:307:2-3: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: zhengbin --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-

Re: [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus

Hi, On 9/19/19 11:22 PM, Artur Świgoń wrote: > From: Artur Świgoń > > This patch adds interconnect functionality to the exynos-bus devfreq > driver. > > The SoC topology is a graph (or, more specifically, a tree) and most of > its edges are taken from the devfreq parent-child hierarchy (cf. >

Re: [PATCH] drm/mediatek: reduce the hbp and hfp for phy timing

On Fri, Dec 13, 2019 at 9:52 AM Jitao Shi wrote: > > There are some extra data transfer in dsi. > ex. LPX, hs_prepare, hs_zero, hs_exit and the sof/eof of dsi packet. > This signal will enlarge the line time. So the real frame on dsi bus > will be lower than calc by video timing. > > So dsi

Re: [PATCH 9/9] drm/bridge: ti-sn65dsi86: Skip non-standard DP rates

On Fri, Dec 13, 2019 at 5:49 PM Doug Anderson wrote: > > Hi, > > On Fri, Dec 13, 2019 at 4:07 PM Daniel Vetter wrote: > > > > On Fri, Dec 13, 2019 at 03:45:30PM -0800, Douglas Anderson wrote: > > > The bridge chip supports these DP rates according to TI's spec: > > > * 1.62 Gbps (RBR) > > > *

Re: [PATCH 1/5] drm/i915: Fix eDP DPCD aux max backlight calculations

I tried to reply the patch from the mailing list archive by clicking the author name https://lists.freedesktop.org/archives/dri-devel/2019-November/246278.html

Re: [PATCH v3 13/50] drm/bridge: panel: Implement bridge connector operations

On Wed, 11 Dec 2019 00:57:13 +0200 Laurent Pinchart wrote: > Implement the newly added bridge connector operations, allowing the > usage of drm_bridge_panel with drm_bridge_connector. > > Signed-off-by: Laurent Pinchart Reviewed-by: Boris Brezillon > --- > Changes since v2: > > - Use the

Re: [PATCH v3 11/50] drm/bridge: Add bridge driver for display connectors

On Wed, 11 Dec 2019 00:57:11 +0200 Laurent Pinchart wrote: > Display connectors are modelled in DT as a device node, but have so far > been handled manually in several bridge drivers. This resulted in > duplicate code in several bridge drivers, with slightly different (and > thus confusing)

  1   2   3   >