[PATCH hmm v2 5/5] mm/hmm: remove the customizable pfn format from hmm_range_fault

From: Jason Gunthorpe Presumably the intent here was that hmm_range_fault() could put the data into some HW specific format and thus avoid some work. However, nothing actually does that, and it isn't clear how anything actually could do that as hmm_range_fault() provides CPU addresses which must

[PATCH hmm v2 1/5] mm/hmm: make CONFIG_DEVICE_PRIVATE into a select

From: Jason Gunthorpe There is no reason for a user to select this or not directly - it should be selected by drivers that are going to use the feature, similar to how CONFIG_HMM_MIRROR works. Currently all drivers provide a feature kconfig that will disable use of DEVICE_PRIVATE in that

[PATCH] video/fbdev/matroxfb: Remove dead code

These are dead code since 3.15. If there is no plan to use it further it can be removed forever. Signed-off-by: Souptick Joarder --- drivers/video/fbdev/matrox/matroxfb_DAC1064.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c

[PATCH] drm/amdgpu: Avoid integer overflow in amdgpu_device_suspend_display_audio

When building with Clang: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4160:53: warning: overflow in expression; result is -294967296 with type 'long' [-Winteger-overflow] expires = ktime_get_mono_fast_ns() + NSEC_PER_SEC * 4L;

[PATCH] drm/stm: Fix an error handling path in 'stm_drm_platform_probe()'

If 'drm_dev_register()' fails, a call to 'drv_load()' must be undone, as already done in the remove function. Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver") Signed-off-by: Christophe JAILLET --- drivers/gpu/drm/stm/drv.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff

[PATCH v4 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API

Replace the manual panel handling code by a drm_panel_bridge. This simplifies the driver and allows all components in the display pipeline to be treated as bridges, paving the way to generic connector handling. Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent Pinchart Acked-by: Sam

[PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep

"The PM core always increments the runtime usage counter before calling the ->suspend() callback and decrements it after calling the ->resume() callback" DPU and DSI are managed as runtime devices. When suspend is triggered, PM core adds a refcount on all the devices and calls device suspend,

[PATCH hmm v2 4/5] mm/hmm: remove HMM_PFN_SPECIAL

From: Jason Gunthorpe This is just an alias for HMM_PFN_ERROR, nothing cares that the error was because of a special page vs any other error case. Acked-by: Felix Kuehling Reviewed-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -

RE: [PATCH v6 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

Hi Laurent, Thank you so much for reviewing the patch and providing valuable comments. Apologies for the delayed response. We are working on your review comments and will send the next version of the driver for review soon. Please see the responses to comments inline below. Thanks & Regards,

[PATCH v4 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver

Convert mtk_dsi to a bridge driver with built-in encoder support for compatibility with existing component drivers. Signed-off-by: Enric Balletbo i Serra Acked-by: Sam Ravnborg --- Changes in v4: - Remove double call to drm_encoder_init(). (Chun-Kuang Hu) - Cleanup the encoder in

[PATCH v4 5/7] drm/mediatek: mtk_dsi: Use simple encoder

The mtk_dsi driver uses an empty implementation for its encoder. Replace the code with the generic simple encoder. Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent Pinchart Acked-by: Sam Ravnborg Reviewed-by: Chun-Kuang Hu --- Changes in v4: None Changes in v3: None Changes in v2:

Re: [PATCH v3 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver

Hi Chun-Kuang, Thank you for the review. On 1/5/20 15:21, Chun-Kuang Hu wrote: > Hi, Enric: > > Enric Balletbo i Serra 於 2020年4月17日 週五 > 下午11:06寫道： >> >> Convert mtk_dsi to a bridge driver with built-in encoder support for >> compatibility with existing component drivers. >> >> Signed-off-by:

RE: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

From: Sebastian Andrzej Siewior > Sent: 01 May 2020 11:42 > On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote: > > Sometimes it's not okay to use SIMD registers, the conditions for which > > have changed subtly from kernel release to kernel release. Usually the > > pattern is to check for

[PATCH hmm v2 3/5] drm/amdgpu: remove dead code after hmm_range_fault()

From: Jason Gunthorpe Since amdgpu does not use the snapshot mode of hmm_range_fault() a successful return already proves that all entries in the pfns are HMM_PFN_VALID, there is no need to check the return result of hmm_device_entry_to_page(). Acked-by: Felix Kuehling Signed-off-by: Jason

[PATCH 0/2] Add support for TM5P5 NT35596 video mode panel

I am aware of the fact that this is probably not the correct naming of this panel, yet I am unable to retrieve any additional information about it, as it is used in a smartphone to which no schematics are released. The driver has been generated with the help of

Re: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

On Fri, May 1, 2020 at 4:42 AM Sebastian Andrzej Siewior wrote: >Reviewed-by: Sebastian Andrzej Siewior Thanks. > > May I ask how large the memcpy can be? I'm asking in case it is large > and an explicit rescheduling point might be needed. Yea I was worried about that too. I'm not an i915

Re: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

On Fri, May 1, 2020 at 12:07 PM Christoph Hellwig wrote: > > On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote: > > Sometimes it's not okay to use SIMD registers, the conditions for which > > have changed subtly from kernel release to kernel release. Usually the > > pattern is to

Re: [PATCH v3 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

Hi Chun-Kuang, Thank you for your review. On 1/5/20 16:26, Chun-Kuang Hu wrote: > Hi, Enric: > > Enric Balletbo i Serra 於 2020年4月17日 週五 > 下午11:06寫道： >> >> Use the drm_bridge_connector helper to create a connector for pipelines >> that use drm_bridge. This allows splitting connector operations

[PATCH 00/14] Move the ReST files from Documentation/*.txt

The main goal of this series is to cleanup the Documentation/ directory. Most of the files under Documentation/*.txt are already in ReST format. They just need to be moved to some place. So, most of the work here is to just move files for them to generate an output using the docs building system.

[PATCH v4 1/7] drm/bridge: ps8640: Get the EDID from eDP control

The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the .get_edid callback and set the flag to indicate the core to use it. Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent Pinchart Acked-by: Sam Ravnborg --- Changes in v4: None Changes in v3: None Changes in v2: None

Re: [PATCH 0/2] Add support for TM5P5 NT35596 video mode panel

Very strange.. I just fetched drm-misc-next and had no issues building... Thanks for your initial thoughts! pt., 1 maj 2020 o 23:00 Sam Ravnborg napisał(a): > > Hi Konrad. > > On Fri, May 01, 2020 at 10:48:21PM +0200, Konrad Dybcio wrote: > > I am aware of the fact that this is probably not the

Re: [PATCH] drm/i915: check to see if SIMD registers are available before using SIMD

On 2020-04-30 16:10:16 [-0600], Jason A. Donenfeld wrote: > Sometimes it's not okay to use SIMD registers, the conditions for which > have changed subtly from kernel release to kernel release. Usually the > pattern is to check for may_use_simd() and then fallback to using > something slower in the

[PATCH 1/2] drivers: drm: panel: Add TM5P5 NT35596 panel driver

This adds support for TMP5P5 NT35596 1080x1920 video mode panel that can be found on some Asus Zenfone 2 Laser (Z00T) devices. Signed-off-by: Konrad Dybcio --- drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 +

[PATCH 2/2] dt-bindings: display: Document TM5P5 NT35596 panel compatible

Signed-off-by: Konrad Dybcio --- .../devicetree/bindings/display/panel/tm5p5,nt35596.txt| 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt diff --git

[PATCH v4 2/7] drm/bridge_connector: Set default status connected for eDP connectors

In an eDP application, HPD is not required and on most bridge chips useless. If HPD is not used, we need to set initial status as connected, otherwise the connector created by the drm_bridge_connector API remains in an unknown state. Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent

Re: [PATCH 11/14] docs: move other kAPI documents to core-api

Hello Mauro, On Fri, May 01, 2020 at 05:37:55PM +0200, Mauro Carvalho Chehab wrote: > There are a number of random documents that seem to be > describing some aspects of the core-api. Move them to such > directory, adding them at the core-api/index.rst file. > > Signed-off-by: Mauro Carvalho

Re: [Nouveau] [PATCH] drm/nouveau/dispnv04: Remove dead code

On Fri, May 1, 2020 at 2:21 AM Ilia Mirkin wrote: > > Interesting. I do remember seeing some snow on NV5's overlay at high > resolutions. Wonder if it was because of this missing code... What was the problem ? Does enabling this dead code will fix the problem ? > > On Thu, Apr 30, 2020 at 4:19

[PATCH hmm v2 2/5] mm/hmm: make hmm_range_fault return 0 or -1

From: Jason Gunthorpe hmm_vma_walk->last is supposed to be updated after every write to the pfns, so that it can be returned by hmm_range_fault(). However, this is not done consistently. Fortunately nothing checks the return code of hmm_range_fault() for anything other than error. More

[PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

The PS8640 dsi-to-eDP bridge driver is using the panel bridge API, however, not all the components in the chain have been ported to the drm_bridge API. Actually, when a panel is attached the default panel's mode is used, but in some cases we can't get display up if mode getting from eDP control

[PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges

Use the drm_bridge_connector helper to create a connector for pipelines that use drm_bridge. This allows splitting connector operations across multiple bridges when necessary, instead of having the last bridge in the chain creating the connector and handling all connector operations internally.

[PATCH v4 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge

This is really a cosmetic change just to make a bit more readable the code after convert the driver to drm_bridge. The bridge variable name will be used by the encoder drm_bridge, and the chained bridge will be named next_bridge. Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent

[PATCH] drivers: gpu: drm: Add MDP5 configuration for MSM8x36 and its derivatives, such as MSM8939.

Signed-off-by: Konrad Dybcio --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 70 1 file changed, 70 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c index e3c4c250238b7..1c7de7d6870cf 100644 ---

Re: [PATCH 1/4] add dts node for drm panel driver ili9341 add dts i2c3 for stmpe touch add dts spi5 for gyro & ili9341

Hi Alexandre, Alexandre Torgue 于2020年4月30日周四 下午7:45写道： > > > On 4/30/20 12:26 PM, dillon min wrote: > > Hi Alexandre, > > > > Alexandre Torgue > > 于2020年4月30日周四 下午5:57写道： > > > > Hi > > > > On 4/30/20 11:43 AM, dillon.min...@gmail.com > >

[PATCH hmm v2 0/5] Adjust hmm_range_fault() API

From: Jason Gunthorpe The API is a bit complicated for the uses we actually have, and disucssions for simplifying have come up a number of times. This small series removes the customizable pfn format and simplifies the return code of hmm_range_fault() All the drivers are adjusted to process in

RE: [RFC PATCH 3/4] drm/etnaviv: Change order of enabling clocks to fix boot on i.MX8MM

> Subject: Re: [RFC PATCH 3/4] drm/etnaviv: Change order of enabling clocks to > fix boot on i.MX8MM > > On 30.04.20 16:35, Lucas Stach wrote: > > Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder: > >> From: Frieder Schrempf > >> > >> On some i.MX8MM devices the boot hangs

Re: [PATCH v9 0/3] IT6505 cover letter

Hi Allen. On Mon, Apr 27, 2020 at 05:16:51PM +0800, allen wrote: > The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully > compliant with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports > color depth of up to 36 bits (12 bits/color) and ensures robust transmission

Re: [PATCH 1/4] add dts node for drm panel driver ili9341 add dts i2c3 for stmpe touch add dts spi5 for gyro & ili9341

Hi dillon min > > okay, thanks alexandre, i will go through these docs. currently i'm on may > day holiday, will be back at next wensday. > after go back to work. i will separate this patch to five part with 9 > patchs , should be more clear > > dts releated > 1, ARM: dts: stm32: Add i2c3

Re: [PATCH 1/2] drivers: drm: panel: Add TM5P5 NT35596 panel driver

Hi Konrad. On Fri, May 01, 2020 at 10:48:22PM +0200, Konrad Dybcio wrote: > This adds support for TMP5P5 NT35596 1080x1920 video > mode panel that can be found on some Asus Zenfone 2 > Laser (Z00T) devices. Very well-writen driver. Only a few small things in the following. Sam > >

Re: [PATCH 1/2] drivers: drm: panel: Add TM5P5 NT35596 panel driver

Hi Konrad. On Sat, May 02, 2020 at 12:09:45PM +0200, Konrad Dybcio wrote: > Hi, > > Thanks for your review. I'll send a v2 soon, however we need to solve the > compat string issue first. > > How should I document tm5p5? I think it's rather some kind of a model no. > along with the nt35596 IC

Re: [PATCH v2 1/1] drm/mm: optimize rb_hole_addr rbtree search

On 5/2/2020 10:00 AM, Chris Wilson wrote: Quoting Nirmoy (2020-04-30 11:30:43) On 4/30/20 12:15 PM, Chris Wilson wrote: Quoting Nirmoy Das (2020-04-30 10:58:39) +void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node) ^ static Ah I forgot! (sparse [make C=1] or make W=1

[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration

https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #12 from Cyrax (ev...@hotmail.com) --- Created attachment 288873 --> https://bugzilla.kernel.org/attachment.cgi?id=288873=edit dmesg from 5.6.8 Additionally dmesg output shows this line : note: kworker/0:3[2251663] exited with

Re: [PATCH v2 1/1] drm/mm: optimize rb_hole_addr rbtree search

Quoting Nirmoy (2020-04-30 11:30:43) > > On 4/30/20 12:15 PM, Chris Wilson wrote: > > Quoting Nirmoy Das (2020-04-30 10:58:39) > >> +void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node) > > ^ static > > > Ah I forgot! > > > > > (sparse [make C=1] or make W=1 will spot this) >

Re: [PATCH 08/10] drm: Add Generic USB Display driver

Den 29.04.2020 14.48, skrev Noralf Trønnes: > This adds a generic USB display driver with the intention that it can be > used with future USB interfaced low end displays/adapters. The Linux > gadget device driver will serve as the canonical device implementation. > > The following DRM

[Bug 207383] [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #9 from Duncan (1i5t5.dun...@cox.net) --- I'm not there yet but it's starting to look like a possibly dud bisect: everything showing good so far. Maybe I didn't wait long enough for the bug to trigger at some step and I'm running up

Re: [PATCH V1 09/10] arch/kmap: Define kmap_atomic_prot() for all arch's

On Fri, May 01, 2020 at 04:20:20AM +0100, Al Viro wrote: > On Fri, May 01, 2020 at 03:37:34AM +0100, Al Viro wrote: > > On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote: > > > > > -static inline void *kmap_atomic(struct page *page) > > > +static inline void