Re: [PATCH] drm/rockchip: fix coding style and incorrect description

Hi Sandy, Just noticed a typo that I think will be good fix also Missatge de Sandy Huang del dia dl., 27 d’ag. 2018 a les 8:31: > > Align with other drivers, tab + 2 space key for description. > and this option should be enabled on both rk3288 and rk3399. > > Signed-off-by: Sandy Huang > --- >

Re: [PATCH v4 1/2] devicetree/bindings: display: Add document for rockchip RGB output

Hi Sandy, trying to move this forward a bit :-) Am Mittwoch, 4. Juli 2018, 14:09:56 CEST schrieb Sandy Huang: > Hi Rob Herring, > Thanks for your review. > > 在 2018/7/4 2:25, Rob Herring 写道: > > On Tue, Jun 26, 2018 at 03:15:39PM +0800, Sandy Huang wrote: > >> This path add support rv1108 and px

[PATCH v2 0/5] msm/drm: A6xx DCVS series

This patch series starts off with a few bug fixes in devfreq code, followed by refactoring the devfreq code needed for supporting different chipsets, and ends with adding devfreq support for A6xx. Sharat Masetty (5): drm/msm: suspend devfreq on init drm/msm: unregister devfreq upon clean up

[PATCH v2 5/5] drm/msm/A6xx: Add devfreq support for A6xx

Implement routines to estimate GPU busy time and fetching the current frequency for the polling interval. This is required by the devfreq framework which recommends a frequency change if needed. The driver code then tries to set this new frequency on the GPU by sending an Out Of Band(OOB) request t

Re: [PATCH 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc

Hi, On 8/27/2018 12:17 PM, Swati Sharma wrote: From: Vidya Srinivas The following pixel formats are packed format that follows 4:2:2 chroma sampling. For memory represenation each component is allocated 16 bits each. Thus each pixel occupies a DWORD. Y210: Valid data occupies MSB 10 bits.

[PATCH v2 4/5] drm/msm: re-factor devfreq code

The devfreq framework requires the drivers to provide busy time estimations. The GPU driver relies on the hardware performance counteres for the busy time estimations, but different hardware revisions have counters which can be sourced from different clocks. So the busy time estimation will be targ

[PATCH v2 2/5] drm/msm: unregister devfreq upon clean up

Call the devfreq_remove_device() API to remove the GPU devfreq instance during GPU driver cleanup. Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/msm_gpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c index 04f9604..8d

[PATCH v2 3/5] drm/msm/A6xx: Add gmu_read64() register read op

Add a simple function to read 64 registers in the GMU domain Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h index a08ee8f..09fd3

[PATCH v2 1/5] drm/msm: suspend devfreq on init

Devfreq turns on and starts recommending power level as soon as it is initialized. The GPU is still not powered on by the time the devfreq init happens and this leads to problems on GPU's where register access is needed to get/set power levels. So we start suspended and only restart devfreq when GP

Re: [PATCH] gpu: do not double put device node in zx_drm_probe

On Fri, Aug 17, 2018 at 10:24:06AM +0800, zhong jiang wrote: > for_each_available_child_of_node will get and put the node properly, > the following of_node_put will lead to the double put. So just > remove it. > > Signed-off-by: zhong jiang Acked-by: Shawn Guo __

Re: [PATCH 2/4] drm/i915: Add Y210, Y212, Y216 plane control definitions

Hi, Please include platform name in subject line: On 8/27/2018 12:17 PM, Swati Sharma wrote: From: Vidya Srinivas Added needed plane control flag definitions for Y210, Y212 and Y216 formats. may be, add more info in commit message -Mahesh Signed-off-by: Swati Sharma Signed-off-by: Vid

[PATCH RESEND 3/3] drivers/block/z2ram: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)

_PAGE_WRITETHRU is a target specific flag. Prefer generic functions. Signed-off-by: Christophe Leroy --- drivers/block/z2ram.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c index d0c5bc4e0703..cfbd70520eeb 100644 --- a/drivers

[PATCH 1/2] drm/atmel-hlcdc: prefer a higher rate clock as pixel-clock base

If the divider used to get the pixel-clock is small, the granularity of the frequencies possible for the pixel-clock is quite coarse. E.g. requesting a pixel-clock of 65MHz with a sys_clk of 132MHz results in the divider being set to 3 ending up with 44MHz. By preferring the doubled sys_clk as bas

[PATCH] drivers/video/fbdev: use ioremap_wc() instead of __ioremap(_PAGE_NO_CACHE)

linux-fb...@vger.kernel.org, linux-ker...@vger.kernel.org, linuxppc-...@lists.ozlabs.org _PAGE_NO_CACHE is a target specific flag. Prefer generic functions. Signed-off-by: Christophe Leroy --- drivers/video/fbdev/chipsfb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/driv

[PATCH] drm/rockchip: Use struct_size() in devm_kzalloc()

One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = devm_kzalloc(dev,

[PATCH RESEND 2/3] drivers/video/fbdev: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)

_PAGE_WRITETHRU is a target specific flag. Prefer generic functions. Signed-off-by: Christophe Leroy --- drivers/video/fbdev/controlfb.c | 3 +-- drivers/video/fbdev/platinumfb.c | 3 +-- drivers/video/fbdev/valkyriefb.c | 10 ++ 3 files changed, 8 insertions(+), 8 deletions(-) diff

[PATCH] backlight: pwm_bl: Fix brightness levels for non-DT case.

Commit '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to human eye")' allows the possibility to compute a default brightness table when there isn't the brightness-levels property in the DT. Unfortunately the changes made broke the pwm backlight for the non-DT boards. Usually

Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On 2018/08/24 20:36, Michal Hocko wrote: >> That is, this API seems to be currently used by only out-of-tree users. Since >> we can't check that nobody has memory allocation dependency, I think that >> hmm_invalidate_range_start() should return -EAGAIN if blockable == false for >> now. > > The co

Re: [PATCH v8 0/4] drm/atmel-hlcdc: bus-width override support

On 2018-08-24 09:51, Boris Brezillon wrote: > Hi Peter, > > On Fri, 10 Aug 2018 15:03:55 +0200 > Peter Rosin wrote: > >> Hi! >> >> The background for these patches is that our PCB interface between >> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and >> this has to be describe

[PATCH v9 1/4] dt-bindings: display: bridge: lvds-transmitter: add ti, ds90c185

Start list of actual chips compatible with "lvds-encoder". Reviewed-by: Laurent Pinchart Reviewed-by: Rob Herring Signed-off-by: Peter Rosin --- .../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documen

[PATCH V5 6/8] backlight: qcom-wled: Add support for WLED4 peripheral

WLED4 peripheral is present on some PMICs like pmi8998 and pm660l. It has a different register map and configurations are also different. Add support for it. Signed-off-by: Kiran Gunda Reviewed-by: Bjorn Andersson --- Changes from V3: - The WLED3 specific changes are splitted out - Merge

Re: atmel-hlcdc select pixel-clock outside of given range

On 2018-08-22 13:50, Peter Rosin wrote: > Hi! > > I just discovered that the atmel-hlcdc driver picks a pixel-clock > way outside the given range when used with a panel with these > timings from the device tree. > > panel-timing { > // 1024x768 @ 60Hz (typical) >

[PATCH 1/3] powerpc/32: Add ioremap_wt()

Other arches have ioremap_wt() to map IO areas write-through. Implement it on PPC as well in order to avoid drivers using __ioremap(_PAGE_WRITETHRU) Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/io.h | 6 ++ arch/powerpc/mm/pgtable_32.c | 8 2 files changed, 14 inser

[PATCH V5 1/8] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

pm8941-wled.c driver is supporting the WLED peripheral on pm8941. Rename it to qcom-wled.c so that it can support WLED on multiple PMICs. Signed-off-by: Kiran Gunda Reviewed-by: Bjorn Andersson Acked-by: Rob Herring Acked-by: Daniel Thompson --- changes from V3: Added Reviewed-by and Acked

[PATCH v2 1/2] drm/atmel-hlcdc: prefer a higher rate clock as pixel-clock base

If the divider used to get the pixel-clock is small, the granularity of the frequencies possible for the pixel-clock is quite coarse. E.g. requesting a pixel-clock of 65MHz with a sys_clk of 132MHz results in the divider being set to 3 ending up with 44MHz. By preferring the doubled sys_clk as bas

[PATCH V5 4/8] backlight: qcom-wled: Rename PM8941* to WLED3

Rename the PM8941* references as WLED3 to make the driver generic and have WLED support for other PMICs. Also rename "i_boost_limit" and "i_limit" variables to "boost_i_limit" and "string_i_limit" respectively to resemble the corresponding register names. Signed-off-by: Kiran Gunda Reviewed-by: D

[PATCH V5 7/8] backlight: qcom-wled: add support for short circuit handling

Handle the short circuit interrupt and check if the short circuit interrupt is valid. Re-enable the module to check if it goes away. Disable the module altogether if the short circuit event persists. Signed-off-by: Kiran Gunda Reviewed-by: Bjorn Andersson --- Changes from V3: - Added Reviewe

[PATCH RESEND 1/3] powerpc/32: Add ioremap_wt()

Other arches have ioremap_wt() to map IO areas write-through. Implement it on PPC as well in order to avoid drivers using __ioremap(_PAGE_WRITETHRU) Signed-off-by: Christophe Leroy --- No change. First serie didn't apply because I generated it on a working branch. arch/powerpc/include/asm/io.h

[PATCH 2/3] drivers/video/fbdev: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)

_PAGE_WRITETHRU is a target specific flag. Prefer generic functions. Signed-off-by: Christophe Leroy --- drivers/video/fbdev/controlfb.c | 3 +-- drivers/video/fbdev/platinumfb.c | 3 +-- drivers/video/fbdev/valkyriefb.c | 10 ++ 3 files changed, 8 insertions(+), 8 deletions(-) diff

[PATCH 3/3] drivers/block/z2ram: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)

_PAGE_WRITETHRU is a target specific flag. Prefer generic functions. Signed-off-by: Christophe Leroy --- drivers/block/z2ram.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c index d0c5bc4e0703..cfbd70520eeb 100644 --- a/drivers

[PATCH V5 5/8] backlight: qcom-wled: Restructure the driver for WLED3

Restructure the driver to add the support for new WLED peripherals. Signed-off-by: Kiran Gunda Acked-by: Daniel Thompson --- Changes from V3: - This is the new patch after splitting the "backlight: qcom-wled: Add support for WLED4 peripheral" patch to seperate the WLED3 specific

[PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support

Hi! The background for these patches is that our PCB interface between the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and this has to be described somewhere, or the atmel-hlcdc driver have no chance of selecting the correct output mode. Since we have similar problems with a tda19

[PATCH 0/2] drm/atmel-hlcdc: revise selection of pixel-clock frequency divider

Hi! Some background can be found here: https://lists.freedesktop.org/archives/dri-devel/2018-August/187182.html The "10 times" discriminator in patch 2/2 can certainly be discussed... Cheers, Peter Peter Rosin (2): drm/atmel-hlcdc: prefer a higher rate clock as pixel-clock base drm/atmel-hl

[PATCH v9 4/4] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes

This beats the heuristic that the connector is involved in what format should be output for cases where this fails. E.g. if there is a bridge that changes format between the encoder and the connector, or if some of the RGB pins between the lcd controller and the encoder are not routed on the PCB.

Re: [PATCH] drivers/video/fbdev: use ioremap_wc() instead of __ioremap(_PAGE_NO_CACHE)

On Fri, Aug 24, 2018 at 10:16:22AM +, Christophe Leroy wrote: > _PAGE_NO_CACHE is a target specific flag. Prefer generic functions. > #ifdef CONFIG_PPC > - p->screen_base = __ioremap(addr, 0x20, _PAGE_NO_CACHE); > + p->screen_base = ioremap_wc(addr, 0x20); > #else But that i

Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On 2018/08/24 22:32, Michal Hocko wrote: > On Fri 24-08-18 22:02:23, Tetsuo Handa wrote: >> I worry that (currently >> out-of-tree) users of this API are involving work / recursion. > > I do not give a slightest about out-of-tree modules. They will have to > accomodate to the new API. I have no pr

[PATCH v2 2/2] drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested

But only if the highest pixel-clock frequency lower than requested is significantly less accurate than the lowest frequency higher than requested. I pulled "10 times" as the discriminator out of the hat, and went with that. This is useful, if e.g. the target pixel-clock is 65MHz and the sys_clk i

[PATCH 2/2] drm/atmel-hlcdc: allow selecting a higher pixel-clock that requested

But only if the highest pixel-clock frequency lower than requested is significantly much less accurate that the lowest frequency higher than requested. I pulled "10 times" as the discriminator out of the hat, and went with that. This is useful, if e.g. the target pixel-clock is 65MHz and the sys_

Re: [PATCH] drivers/video/fbdev: use ioremap_wc() instead of __ioremap(_PAGE_NO_CACHE)

Le 24/08/2018 à 13:05, Segher Boessenkool a écrit : On Fri, Aug 24, 2018 at 10:16:22AM +, Christophe Leroy wrote: _PAGE_NO_CACHE is a target specific flag. Prefer generic functions. #ifdef CONFIG_PPC - p->screen_base = __ioremap(addr, 0x20, _PAGE_NO_CACHE); + p->screen

[PATCH V5 3/8] backlight: qcom-wled: Add new properties for PMI8998

Update the bindings with the new properties used for PMI8998. Signed-off-by: Kiran Gunda Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Acked-by: Daniel Thompson --- Changes from V3: - Removed the default values. - Removed pmi8998 example. Changes from V4: - modified qcom,e

[PATCH RESEND 3/3] drivers/block/z2ram: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)

_PAGE_WRITETHRU is a target specific flag. Prefer generic functions. Signed-off-by: Christophe Leroy --- drivers/block/z2ram.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c index d0c5bc4e0703..cfbd70520eeb 100644 --- a/drivers

Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On 2018/08/24 22:52, Michal Hocko wrote: > @@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn) > */ > static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable) > { > - if (blockable) > - mutex_lock(&amn->read_lock); > - else if (!mutex_trylock(&amn-

[PATCH RESEND 2/3] drivers/video/fbdev: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)

_PAGE_WRITETHRU is a target specific flag. Prefer generic functions. Signed-off-by: Christophe Leroy --- drivers/video/fbdev/controlfb.c | 3 +-- drivers/video/fbdev/platinumfb.c | 3 +-- drivers/video/fbdev/valkyriefb.c | 10 ++ 3 files changed, 8 insertions(+), 8 deletions(-) diff

Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Two more worries for this patch. > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c > @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn) > * > * @amn: our notifier > */ > -static void amdgpu_mn_read_lock(struct amdgpu_mn *amn) > +st

[PATCH v9 3/4] drm/atmel-hlcdc: always iterate over the first 4 output endpoints

This enables more flexible devicetrees. You can e.g. have two output nodes where one is not enabled, without the ordering affecting things. Prior to this patch the active nodes had to have endpoint id zero and upwards consecutively. Signed-off-by: Peter Rosin --- drivers/gpu/drm/atmel-hlcdc/atm

[PATCH V5 0/8] backlight: qcom-wled: Support for QCOM wled driver

This patch series renames the pm8941-wled.c driver to qcom-wled.c to add the support for multiple PMICs supported by qualcomm. This patch series supports both PM8941 and PMI8998 WLED. The PMI8998 WLED has the support to handle the OVP (over voltage protection) and the SC (short circuit protection)

Re: [PATCH] backlight: pwm_bl: Fix brightness levels for non-DT case.

Enric Balletbo i Serra writes: > Commit '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED > linearly to human eye")' allows the possibility to compute a default > brightness table when there isn't the brightness-levels property in the > DT. Unfortunately the changes made broke the pwm

[PATCH V5 2/8] backlight: qcom-wled: restructure the qcom-wled bindings

Restructure the qcom-wled bindings for the better readability. Signed-off-by: Kiran Gunda Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Acked-by: Daniel Thompson --- Changes from V3: Added Reviewed-by and Acked-by tags. Changes from V4: None .../bindings/leds/backlight/qcom-

Re: [PATCH] drm/rockchip: Use struct_size() in devm_kzalloc()

On Sun, Aug 26, 2018 at 11:47 AM, Gustavo A. R. Silva wrote: > One of the more common cases of allocation size calculations is finding > the size of a structure that has a zero-sized array at the end, along > with memory for some number of elements for that array. For example: > > struct foo { >

[PATCH v9 2/4] dt-bindings: display: atmel: optional video-interface of endpoints

With bus-type/bus-width properties in the endpoint nodes, the video- interface of the connection can be specified for cases where the heuristic fails to select the correct output mode. This can happen e.g. if not all RGB pins are routed on the PCB; the driver has no way of knowing this, and needs t

[PATCH v2 0/2] drm/atmel-hlcdc: revise selection of pixel-clock frequency divider

Hi! Some background can be found here: https://lists.freedesktop.org/archives/dri-devel/2018-August/187182.html The "10 times" discriminator in patch 2/2 can certainly be discussed... Cheers, Peter Changes since v1https://lkml.org/lkml/2018/8/24/187 - added {} to an if body for symmetry -

[PATCH V5 8/8] backlight: qcom-wled: Add auto string detection logic

The auto string detection algorithm checks if the current WLED sink configuration is valid. It tries enabling every sink and checks if the OVP fault is observed. Based on this information it detects and enables the valid sink configuration. Auto calibration will be triggered when the OVP fault inte

Re: [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

Am 26.08.2018 um 10:40 schrieb Tetsuo Handa: On 2018/08/24 22:52, Michal Hocko wrote: @@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn) */ static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable) { - if (blockable) - mutex_lock(&amn->read_l

[Bug 107696] account request for drm-misc

https://bugs.freedesktop.org/show_bug.cgi?id=107696 Bug ID: 107696 Summary: account request for drm-misc Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priorit

[Bug 107696] account request for drm-misc

https://bugs.freedesktop.org/show_bug.cgi?id=107696 --- Comment #1 from Hans Verkuil --- Created attachment 141296 --> https://bugs.freedesktop.org/attachment.cgi?id=141296&action=edit SSH public key -- You are receiving this mail because: You are the assignee for the bug.

Re: [PATCH 1/4] drm: Add Y210, Y212, Y216 format definitions and fourcc

On 8/27/2018 12:47 PM, Kumar, Mahesh wrote: Hi, On 8/27/2018 12:17 PM, Swati Sharma wrote: From: Vidya Srinivas The following pixel formats are packed format that follows 4:2:2 chroma sampling. For memory represenation each component is allocated 16 bits each. Thus each pixel occupies a DWO

Re: [PATCH 3/4] drm/i915: Preparations for enabling Y210, Y212, Y216 formats

Hi, On 8/27/2018 12:17 PM, Swati Sharma wrote: From: Vidya Srinivas Signed-off-by: Swati Sharma Signed-off-by: Vidya Srinivas --- drivers/gpu/drm/i915/intel_display.c | 15 +++ drivers/gpu/drm/i915/intel_sprite.c | 3 +++ 2 files changed, 18 insertions(+) diff --git a/dri

[PATCHv2 1/5] drm_dp_cec: check that aux has a transfer function

From: Hans Verkuil If aux->transfer == NULL, then just return without doing anything. In that case the function is likely called for a non-(e)DP connector. This never happened for the i915 driver, but the nouveau and amdgpu drivers need this check. The alternative would be to add this check in

[PATCHv2 0/5] drm/nouveau+amdgpu: add DP CEC-Tunneling-over-AUX

From: Hans Verkuil Now that the DisplayPort CEC-Tunneling-over-AUX drm+i915 support has been merged in the mainline kernel it is time to roll this out to nouveau and amdgpu as well. The first patch is required for this: it adds checks that the drm_dp_cec functions are called with a working aux i

[PATCHv2 3/5] drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read()

From: Hans Verkuil When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the result is wrong due to a missing idx increment. This was never noticed since DP_REMOTE_DPCD_READ is currently not used, but if you enable it, then it is all wrong. Signed-off-by: Hans Verkuil Reviewed-by: Lyude

[PATCHv2 2/5] drm_dp_cec: add note about good MegaChips 2900 CEC support

From: Hans Verkuil A big problem with DP CEC-Tunneling-over-AUX is that it is tricky to find adapters with a chipset that supports this AND where the manufacturer actually connected the HDMI CEC line to the chipset. Add a mention of the MegaChips 2900 chipset which seems to support this feature

Re: [PATCH 4/4] drm/i915: Enable Y210, Y212, Y216 format for primary and sprite planes

On 8/27/2018 12:17 PM, Swati Sharma wrote: From: Vidya Srinivas In this patch, a list for icl specific pixel formats is created in which Y210, Y212 and Y216 pixel formats are added along with legacy pixel formats for primary and sprite plane. Signed-off-by: Swati Sharma Signed-off-by: Vidya

[PATCH 4/5] drm/nouveau: add DisplayPort CEC-Tunneling-over-AUX support

Add DisplayPort CEC-Tunneling-over-AUX support to nouveau. Signed-off-by: Hans Verkuil Reviewed-by: Lyude Paul Acked-by: Alex Deucher --- drivers/gpu/drm/nouveau/nouveau_connector.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/n

[PATCHv2 5/5] drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support

Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu. Signed-off-by: Hans Verkuil Acked-by: Alex Deucher Reviewed-by: Harry Wentland --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 9 - .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++ 2 files changed,

[PATCHv2 3/5] drm_dp_mst_topology: fix broken drm_dp_sideband_parse_remote_dpcd_read()

When parsing the reply of a DP_REMOTE_DPCD_READ DPCD command the result is wrong due to a missing idx increment. This was never noticed since DP_REMOTE_DPCD_READ is currently not used, but if you enable it, then it is all wrong. Signed-off-by: Hans Verkuil Reviewed-by: Lyude Paul Acked-by: Alex

Re: [PATCH v4] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"

On Sat, 25 Aug 2018, Lyude Paul wrote: > From: Jan-Marek Glogowski > > This re-applies the workaround for "some DP sinks, [which] are a > little nuts" from commit 1a36147bb939 ("drm/i915: Perform link > quality check unconditionally during long pulse"). > It makes the secondary AOC E2460P monitor

Re: [PATCHv2 0/5] drm/nouveau+amdgpu: add DP CEC-Tunneling-over-AUX

Sorry, this v2 patch series is a bit messy: my git-send-email failed at patch 3 for some reason, so I posted patches 3-5 manually, but I forgot to add 'v2' to the subject of patch 4/5 and for some reason patch 3 now appeared twice. The contents of the patches is correct, though :-) Regards,

[PATCH] drm/sun4i: Remove R40 display pipeline compatibles

Two patches from the R40 display pipeline support series weren't applied with the rest of the series. When they did get applied, the -rc6 deadline for drm-misc-next had past, so they didn't get into 4.19-rc1 with the rest of the series. However, the two patches are crucial in the parsing of the R40

Re: [PATCH v6] Add udmabuf misc device

Hi, > > Covering udmabuf.c maintainance is a different issue. I could just add > > myself to the existing entry, or create a new one specifically for > > udmabuf. > > That's what I meant, do a more specific entry to add yourself just for > udmabuf. Ok. Back from summer vacation, finally foun

[PATCH v7] Add udmabuf misc device

A driver to let userspace turn memfd regions into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full framebuffer display, and hopefully some d

Re: [ANNOUNCE] libdrm 2.4.94

On 2018-08-24 7:44 p.m., Laurent Carlier wrote: > > 11/15 amdgpu-symbol-check FAIL 0.22 s (exit status 1) > > --- command --- > LANG='en_US.UTF-8' SUDO_GID='0' OLDPWD='/build/libdrm/src' > COMMAND_MODE='legacy' USERNAME='builduser' SUDO_COMMAND='/bin/bash -c bash -c > cd

Re: [PATCH V5 1/8] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

On Fri 2018-08-24 15:57:40, Kiran Gunda wrote: > pm8941-wled.c driver is supporting the WLED peripheral > on pm8941. Rename it to qcom-wled.c so that it can support > WLED on multiple PMICs. > > Signed-off-by: Kiran Gunda > Reviewed-by: Bjorn Andersson > Acked-by: Rob Herring > Acked-by: Daniel

Re: [PATCH V5 2/8] backlight: qcom-wled: restructure the qcom-wled bindings

On Fri 2018-08-24 15:57:41, Kiran Gunda wrote: > Restructure the qcom-wled bindings for the better readability. > > Signed-off-by: Kiran Gunda > Reviewed-by: Bjorn Andersson > Reviewed-by: Rob Herring > Acked-by: Daniel Thompson Acked-by: Pavel Machek -- (english) http://www.livejournal.c

Re: [PATCH V5 3/8] backlight: qcom-wled: Add new properties for PMI8998

Hi! On Fri 2018-08-24 15:57:42, Kiran Gunda wrote: > Update the bindings with the new properties used for > PMI8998. > Changes from V3: > - Removed the default values. Why? > +- qcom,current-limit-microamp > + Usage:optional > + Value type: > + Definition: uA; per-s

Re: [ANNOUNCE] libdrm 2.4.94

On 27 August 2018 at 10:38, Michel Dänzer wrote: > On 2018-08-24 7:44 p.m., Laurent Carlier wrote: >> >> 11/15 amdgpu-symbol-check FAIL 0.22 s (exit status 1) >> >> --- command --- >> LANG='en_US.UTF-8' SUDO_GID='0' OLDPWD='/build/libdrm/src' >> COMMAND_MODE='legacy' USERNA

Re: [PATCH V5 4/8] backlight: qcom-wled: Rename PM8941* to WLED3

On Fri 2018-08-24 15:57:43, Kiran Gunda wrote: > Rename the PM8941* references as WLED3 to make the driver > generic and have WLED support for other PMICs. Also rename > "i_boost_limit" and "i_limit" variables to "boost_i_limit" > and "string_i_limit" respectively to resemble the corresponding > re

Re: [ANNOUNCE] libdrm 2.4.94

On 2018-08-27 12:03 p.m., Emil Velikov wrote: > On 27 August 2018 at 10:38, Michel Dänzer wrote: >> On 2018-08-24 7:44 p.m., Laurent Carlier wrote: >>> >>> 11/15 amdgpu-symbol-check FAIL 0.22 s (exit status >>> 1) >>> >>> --- command --- >>> LANG='en_US.UTF-8' SUDO_GID='0'

Re: [PATCH V5 5/8] backlight: qcom-wled: Restructure the driver for WLED3

On Fri 2018-08-24 15:57:44, Kiran Gunda wrote: > Restructure the driver to add the support for new WLED > peripherals. > > Signed-off-by: Kiran Gunda > Acked-by: Daniel Thompson > --- > Changes from V3: > - This is the new patch after splitting the > "backlight: qcom-wled: Add support

Re: [Intel-gfx] [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats

On 21.08.2018 17:26, Sharma, Swati2 wrote: On 16-Aug-18 6:25 PM, Juha-Pekka Heikkila wrote: Preparations for enabling P010, P012 and P016 formats. These formats will extend NV12 for larger bit depths. Signed-off-by: Juha-Pekka Heikkila Reviewed-by: Maarten Lankhorst ---   drivers/gpu/drm/i915

[Bug 107545] radeon - ring 0 stalled - GPU lockup - SI

https://bugs.freedesktop.org/show_bug.cgi?id=107545 --- Comment #12 from Christian König --- (In reply to Julien Isorce from comment #11) > Could it be an issue with pcie (though is works with admgpu, well in fact it > uses kdata on amdgpu) ? Is there anyway I can force a commit/flush just > afte

4.19-rc1 on droid 4: screen not updating

Hi! With Sebastian's patches, display works on Droid 4 in v4.18. I had to do some manual merging, and I see kernel messages in v4.19-rc1, but they are frozen -- no updates. a) does someone have it working? b) is there some way I can help to get it working in mainline? Droid 4 is not exactly new

Re: [PATCH v5 6/7] drm/bridge/synopsys: dsi: add dual-dsi support

On 21.08.2018 16:05, Heiko Stuebner wrote: > 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 specif

Re: [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats

Op 16-08-18 om 14:55 schreef Juha-Pekka Heikkila: > Preparations for enabling P010, P012 and P016 formats. These > formats will extend NV12 for larger bit depths. > > Signed-off-by: Juha-Pekka Heikkila > Reviewed-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/intel_atomic.c | 3 +- >

Re: [PATCH v5 7/7] drm/rockchip: dsi: add dual mipi support

On 21.08.2018 16:05, Heiko Stuebner wrote: > 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 decla

Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings

On 24.08.2018 14:23, Linus Walleij wrote: > This adds bindings for a virtual display to be used with displays > inside entirely virtual environments which do not emulate things > like monitors but just need timing information to be supplied to > its display controller. > > This is inspired by earli

Re: [RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block

Hi Leonard, On Mon, 2018-08-27 at 14:10 +0300, Leonard Crestez wrote: > Adding lcdif nodes to a power domain currently doesn't work, it results > in black/corrupted screens or hangs. While the driver does enable > runtime pm it does not deal correctly with the block being unpowered. > > All patch

Re: [Intel-gfx] [PATCH v4] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"

On Sat, Aug 25, 2018 at 03:10:35PM -0400, Lyude Paul wrote: > From: Jan-Marek Glogowski > > This re-applies the workaround for "some DP sinks, [which] are a > little nuts" from commit 1a36147bb939 ("drm/i915: Perform link > quality check unconditionally during long pulse"). > It makes the seconda

PL111 regression in v4.19-rc1

Hi folks, I'm seeing this on all PL111 systems (several ARM reference designs and Nomadik) with v4.19-rc1: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. [ cut here ] WARNING: CPU: 0 PID: 1 at ../include/linu

Re: PL111 regression in v4.19-rc1

Hi Linus, Den 27.08.2018 14.12, skrev Linus Walleij: Hi folks, I'm seeing this on all PL111 systems (several ARM reference designs and Nomadik) with v4.19-rc1: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. [ cut here

[PATCH] drm/i2c/tda9950.c: set MAX_RETRIES for errors only

The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to prevent the CEC framework from retrying the transmit. If the transmit was successful, then don't set this flag. Found by running 'cec-compliance -A' on a beaglebone box. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/i2c/tda9950.c

Re: [PATCH v6 1/2] drm/panel: Add support for Truly NT35597 panel driver

Hi Abhinav, I have a few comments below. On Fri, 2018-08-17 at 19:06 -0700, Abhinav Kumar wrote: > From: "abhin...@codeaurora.org" > > Add support for Truly NT35597 panel driver used > in MSM reference platforms. > > This panel driver supports both single DSI and dual DSI > modes. > > However

Re: PL111 regression in v4.19-rc1

On Mon, Aug 27, 2018 at 2:21 PM Noralf Trønnes wrote: > This is one suspect: 894a677f4b3e > drm/cma-helper: Use the generic fbdev emulation This doesn't revert cleanly so I couldn't try that right off. But the graphics do work before this commit. I checked out the kernel tree on this commit an

Re: [PATCH 1/3] mach64: fix display corruption on big endian machines

On Sat, Aug 25, 2018 at 03:51:00PM -0400, Mikulas Patocka wrote: > The code for manual bit triple is not endian-clean. It builds the variable > "hostdword" using byte accesses, therefore we must read the variable with > "le32_to_cpu". > > The patch also enables (hardware or software) bit triple on

Re: [PATCH 2/3] mach64: fix image corruption due to reading accelerator registers

On Sat, Aug 25, 2018 at 03:51:52PM -0400, Mikulas Patocka wrote: > Reading the registers without waiting for engine idle returns > unpredictable values. These unpredictable values result in display > corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the > bit DP_HOST_TRIPLE_EN

Re: [PATCH 3/3] mach64: optimize wait_for_fifo

On Sat, Aug 25, 2018 at 03:54:17PM -0400, Mikulas Patocka wrote: > This is a simple optimization for fifo waiting that improves scrolling > performance by 5%. If the queue has more free entries that what we > consume, we can skip the costly register read next time. > > Signed-off-by: Mikulas Patoc

Re: [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats

On 27.08.2018 14:28, Maarten Lankhorst wrote: Op 16-08-18 om 14:55 schreef Juha-Pekka Heikkila: Preparations for enabling P010, P012 and P016 formats. These formats will extend NV12 for larger bit depths. Signed-off-by: Juha-Pekka Heikkila Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/

Re: PL111 regression in v4.19-rc1

On Mon, Aug 27, 2018 at 2:43 PM Linus Walleij wrote: > I'm trying to see if I can fix it, any hints welcome! BTW this is pretty easy to reproduce in QEMU using a cross compilers: I realized we were missing the VGA DAC when testing this... make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- versati

[Bug 107518] polaris powerplay init fails: There must be 1 or more PCIE levels defined in PPTable

https://bugs.freedesktop.org/show_bug.cgi?id=107518 --- Comment #10 from Alex Deucher --- Does this patch help? https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=8242308cc3c4419832126ab78ca409ce7110ab33 -- You are receiving this mail because: You are the assignee for t

[Bug 107696] account request for drm-misc

https://bugs.freedesktop.org/show_bug.cgi?id=107696 Daniel Stone changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

Re: PL111 regression in v4.19-rc1

Den 27.08.2018 14.43, skrev Linus Walleij: On Mon, Aug 27, 2018 at 2:21 PM Noralf Trønnes wrote: This is one suspect: 894a677f4b3e drm/cma-helper: Use the generic fbdev emulation This doesn't revert cleanly so I couldn't try that right off. But the graphics do work before this commit. I ch

  1   2   >