FW: [PATCH] drm: should break if already get the best size

-Original Message- From: amd-gfx On Behalf Of Monk Liu Sent: Thursday, November 22, 2018 8:33 PM To: amd-...@lists.freedesktop.org Cc: Liu, Monk Subject: [PATCH] drm: should break if already get the best size Signed-off-by: Monk Liu --- drivers/gpu/drm/drm_mm.c | 2 ++ 1 file changed

FW: [PATCH] drm: should break if already get the best size

-Original Message- From: amd-gfx On Behalf Of Monk Liu Sent: Thursday, November 22, 2018 8:33 PM To: amd-...@lists.freedesktop.org Cc: Liu, Monk Subject: [PATCH] drm: should break if already get the best size Signed-off-by: Monk Liu --- drivers/gpu/drm/drm_mm.c | 2 ++ 1 file changed

Re: [alsa-devel] [Xen-devel][PATCH 3/3] ALSA: xen-front: Use Xen common shared buffer implementation

On 11/22/18 5:47 PM, Takashi Iwai wrote: On Thu, 22 Nov 2018 11:02:30 +0100, Oleksandr Andrushchenko wrote: @@ -214,12 +221,19 @@ static void stream_clear(struct xen_snd_front_pcm_stream_info *stream) stream->out_frames = 0; atomic_set(&stream->hw_ptr, 0); xen_snd_front_

[Bug 108843] Laptop with ATI RX 580 doesn't turn the screen on when resuming.

https://bugs.freedesktop.org/show_bug.cgi?id=108843 --- Comment #2 from Michel Dänzer --- Does amdgpu.dc=1 on the kernel command line help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@l

Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

On Thu, Nov 22, 2018 at 06:55:17PM +, Koenig, Christian wrote: > Am 22.11.18 um 17:51 schrieb Daniel Vetter: > > We need to make sure implementations don't cheat and don't have a > > possible schedule/blocking point deeply burried where review can't > > catch it. > > > > I'm not sure whether th

Re: [PATCH v8 1/7] mm, devm_memremap_pages: Mark devm_memremap_pages() EXPORT_SYMBOL_GPL

On Thu 22-11-18 17:38:58, Christoph Hellwig wrote: > On Thu, Nov 22, 2018 at 02:30:13PM +0100, Michal Hocko wrote: > > Whoever needs a wrapper around arch_add_memory can do so because this > > symbol has no restriction for the usage. > > arch_add_memory is not exported, and it really should not be

Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

On Thu, Nov 22, 2018 at 04:53:34PM +, Chris Wilson wrote: > Quoting Daniel Vetter (2018-11-22 16:51:04) > > Just a bit of paranoia, since if we start pushing this deep into > > callchains it's hard to spot all places where an mmu notifier > > implementation might fail when it's not allowed to.

Re: FW: [PATCH] drm: should break if already get the best size

Quoting Liu, Monk (2018-11-23 08:02:11) > > > -Original Message- > From: amd-gfx On Behalf Of Monk Liu > Sent: Thursday, November 22, 2018 8:33 PM > To: amd-...@lists.freedesktop.org > Cc: Liu, Monk > Subject: [PATCH] drm: should break if already get the best size > > Signed-off-by: Mo

RE: FW: [PATCH] drm: should break if already get the best size

What do you mean the first in the chain ? and also can you explain the " perfect match." ? thanks Assume there is couple nodes equal to the size you requested, without this patch it will traveler to the bottom level of the RB tree and gives you the node that close to the bottom level, which tak

[PATCH v2 03/43] drm/sun4i: Add TODO comment about supporting scaling with the backend

The backend allows integer-only scaling but can handle alpha components, unlike the frontend. It could be useful to add support for this eventually, so add a short TODO comment describing the situation. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_backend.c | 5 + 1 file

[PATCH v2 02/43] drm/sun4i: frontend: Replace ARGB with XRGB as supported format

The frontend documentation (for the A33) mentions that ARGB is supported as output, but with the alpha component always set to 0xff. In practice, this means that the alpha component cannot be preserved when going through the frontend. Since the information is lost, ARGB is not properly supported.

[PATCH v2 04/43] drm/sun4i: backend: Add a helper and a list for supported formats

In order to check whether the backend supports a specific format, an explicit list and a related helper are introduced. The prototype of this helper is added to the header so that it can be called from sun4i_layer later (when introducing tiled mode support). Signed-off-by: Paul Kocialkowski ---

[PATCH v2 01/43] drm/sun4i: Cleanup video/YUV source before enabling a layer

This adds a dedicated function for cleaning the video and YUV source channel layer enable bits. This function is called first on layer atomic update to make sure that there are no leftover bits from previous plane configuration that were not cleaned until now. It fixes issues when alternating betw

[PATCH v2 00/43] drm/sun4i: Support for linear and tiled YUV formats with the frontend

This series implements support for YUV formats using the display engine frontend in the sun4i DRM driver, with various fixes along the way. Scaling is supported for every format handled by the frontend. The tiling mode used by the VPU on Allwinner platforms is also supported by this series and a d

[PATCH v2 11/43] drm/fourcc: Add format info helpers for checking YUV sub-sampling

Display engine drivers often need to distinguish between different types of YUV sub-sampling. This introduces helpers to check for common sub-sampling ratios in their commonly-used denomination from the DRM format info. Signed-off-by: Paul Kocialkowski --- include/drm/drm_fourcc.h | 75 +

[PATCH v2 17/43] drm/sun4i: frontend: Add helpers for input data mode and pixel sequence

This introduces new helpers for retrieving the input data mode and pixel sequence register field values based on the DRM format instead of hardcoding these. This makes it easier to add support for more formats. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 46

[PATCH v2 13/43] drm/sun4i: backend: Use explicit fourcc helpers for packed YUV422 check

Checking for the number of planes is not sufficient to en ensure that the format is a packed YUV422. Use explicit fourcc helpers for the check instead. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_backend.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH v2 08/43] drm/fourcc: Add helper to check if a format uses a YUV colorspace

This adds a new helper to check whether the format described by its fourcc code uses a YUV colorspace, by returning the is_yuv entry for the DRM info entry matching that format. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/drm_fourcc.c | 19 +++ include/drm/drm_fourcc.h

[PATCH v2 07/43] drm/sun4i: backend: Use a specific function to check if a plane is supported

Before this patch, it is assumed that a plane is supported either through the frontend or through the backend alone. However, the DRM interface does not allow finely reporting our hardware capabilities and there are cases where neither are support. In particular, some plane formats are supported b

[PATCH v2 05/43] drm/sun4i: frontend: Add a helper and a list for supported formats

In order to check whether the frontend supports a specific format, an explicit list and a related helper are introduced. Just like in the backend, the prototype of the helper is added to the frontend header so that it can be used later on. The helper is also exported because it will be used outsid

[PATCH v2 12/43] drm/fourcc: Add format helpers for checking YUV sub-sampling

This introduces new format helpers that use the previously-introduced format info helpers for checking YUV sub-sampling. Only the format fourcc is required by these helpers and the formats are iterated from the list. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/drm_fourcc.c | 105 ++

[PATCH v2 06/43] drm/sun4i: backend: Refine the logic behind using the frontend

Checking that scaling is in use is not sufficient as a condition to decide to use the frontend. Since not all layer formats are supported by the frontend, we need to check for that support first. Then, the frontend must only be enabled if the backend doesn't support the format or that scaling is r

[PATCH v2 15/43] drm/sun4i: Rename sun4i_backend_layer_formats to sun4i_layer_formats

Since more formats can be supported by the frontend, rename the variable listing the layer formats to avoid suggesting that the backend itself supports all the listed formats. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_layer.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH v2 14/43] drm/sun4i: backend: Avoid counting YUV planes that use the frontend

Our hardware has a limited number of YUV planes (usually 1) that can be supported using the backend only. However, YUV planes can also be supported by the frontend and must then not be counted when checking for that limitation. Only count the YUV plane when the frontend is not used. Signed-off-by

[PATCH v2 19/43] drm/sun4i: frontend: Determine input mode based on the number of planes

Use the number of planes associated with the DRM format to determine the input mode configuration instead of the format iteself. This way, the helper can be used for all packed formats without future changes. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 10 --

[PATCH v2 16/43] drm/sun4i: frontend: Move CSC bypass setup to format update routine

In order to support YUV to RGB conversion with the frontend (which is generally used for connecting with the backend), the CSC block must not be bypassed. As a result, the bit to enable CSC bypass is moved from the runtime resume routine to the format update routine, so that it can disabled when i

[PATCH v2 23/43] drm/sun4i: backend: Detail the YUV to RGB values coding explanation

From: Paul Kocialkowski The values in the BT601 YUV to RGB colorspace translation are not simply coded as multiples, but rather as fixed-point signed fractional values on a given number of bits. Add an explanation about that. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_bac

[PATCH v2 26/43] drm/sun4i: frontend: Add support for packed YUV422 input formats

This introduces support for packed YUV formats with 4:2:2 sampling using the frontend. Definitions are introduced for the data format and pixel sequence input format register values. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 22 ++ drivers/

[PATCH v2 29/43] drm/sun4i: Make pitch even for GEM dumb alloc as per hardware constraint

Our hardware requires the pitch to be an even number when using YUV formats with the frontend. Implement a driver-specific callback for GEM dumb allocation that sets the pitch accordingly. Since only the bpp is passed (and not the format), we cannot really distinguish if this alignment is really r

[PATCH v2 10/43] drm/fourcc: Add format helpers for checking YUV planes disposition

This introduces new format helpers that use the previously-introduced format info helpers for checking YUV planes disposition. Only the format fourcc is required by these helpers and the formats are iterated from the list. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/drm_fourcc.c | 60 +

[PATCH v2 09/43] drm/fourcc: Add format info helpers for checking YUV planes disposition

It is often useful to check whether the DRM format info retrieved from the DRM framebuffer matches a specific YUV planes disposition. This introduces helpers to quickly check that a provided format info matches a YUV format with a specific disposition, in commonly-used terminology. The intent of

[PATCH v2 36/43] drm/sun4i: layer: Add tiled modifier support and helper

From: Paul Kocialkowski This introduces a list of supported modifiers for the driver, that includes the Allwinner tiled modifier, as well as a format_mod_supported callback. The callback uses both the backend and frontend helpers to indicate per-format modifier support (including for the linear

[PATCH v2 28/43] drm/sun4i: frontend: Add support for planar YUV input formats

Planar YUV formats come with 3 distinct planes, which requires configuring the frontend line stride and address registers for the third plane. Our hardware only supports the YUV planes order and in order to support formats with a YVU plane order, a helper is introduced to indicate whether to inver

[PATCH v2 32/43] drm/sun4i: Pass modifier to backend and frontend format support helpers

To prepare the introduction of tiled mode support, pass the framebuffer format modifier to the helpers dealing with format support. Since only linear mode is supported for now, add corresponding checks in each helper. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_backend.c |

[PATCH v2 30/43] drm/fourcc: Add definitions for Allwinner vendor and VPU tiled format

This introduces specific definitions for vendor Allwinner and its associated tiled format modifier. This modifier is used for the output format of the VPU, that can be imported directly with the display engine hardware supported by the sun4i-drm driver. Signed-off-by: Paul Kocialkowski --- inclu

[PATCH v2 21/43] drm/sun4i: frontend: Add support for the BGRX8888 input format

This introduces support for the BGRX input format for the frontend, with its associated pixel sequence value definition. Other fields are already configured correctly as they no longer depend on the format's fourcc directly. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_fr

[PATCH v2 43/43] drm/sun4i: frontend: Add A20-specific device-tree compatible and quirks

This adds the appropriate device-tree compatible and quirk data for hooking frontend support for the A20. It supports the FIR coefficients ready bit but not the access control bit. It also takes different phase values than the A33 for these coefficients. The compatible is already used in the A20 d

[PATCH v2 27/43] drm/sun4i: frontend: Add support for semi-planar YUV input formats

Semi-planar YUV formats use two distinct planes, one for luminance and one for chrominance. To add support for them, we need to configure the second line stride and buffer address registers to setup the second YUV plane. New definitions are introduced to configure the input format register for the

[PATCH v2 24/43] drm/sun4i: frontend: Configure and enable YUV to RGB CSC when needed

In prevision of adding support for YUV formats, set the YUV to RGB colorspace conversion coefficients if required and don't bypass the CSC engine when converting. The BT601 coefficients from the A33 BSP are copied over from the backend code. Because of module inter-dependency, we can't have the fr

[PATCH v2 40/43] drm/sun4i: Set the coef_rdy bit right after the coef have been set

From: Maxime Ripard The COEF_RDY bit is used to tell the hardware that new FIR filters coefficients have been written to the registers and that the hardware should take them into account starting next frame. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 4 1 fi

[PATCH v2 34/43] drm/sun4i: Add buffer stride and offset configuration for tiling mode

This introduces stride and offset configuration for the VPU tiling mode. Stride is calculated differently than it is for linear formats and an offset is calculated, for which new register definitions are introduced. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 54

[PATCH v2 22/43] drm/sun4i: frontend: Add support for the BGRX8888 output format

This introduces support for the BGRX output format for the frontend, with its associated output format value definition. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 4 drivers/gpu/drm/sun4i/sun4i_frontend.h | 1 + 2 files changed, 5 insertions(+) diff

[PATCH v2 20/43] drm/sun4i: frontend: Determine input format based on colorspace

Since all the RGB input formats have the same value for the DATA_FMT field of the INPUT_FMT register, we can group them when the format is known to be RGB. Here, we assume that a non-YUV format is RGB, because the hardware does not support any other colorspace than RGB and YUV. Thus, we can use the

[PATCH v2 33/43] drm/sun4i: frontend: Add support for tiled YUV input mode configuration

This introduces the data input mode definitions for the tiled YUV mode, that are used in the input mode helper if tiling is requested. The modifier is passed to the helper from the framebuffer to determine if tiling is requested. Only semiplanar and planar YUV formats are supported for tiling mod

[PATCH v2 31/43] drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers

This introduces a dedicated ioctl for allocating buffers for the VPU tiling mode. It allows setting up buffers that comply to the hardware alignment requirements, by aligning the stride and height to 32 bytes. Only YUV semiplanar and planar formats are allowed by the ioctl, as the hardware does no

[PATCH v2 41/43] drm/sun4i: Make COEF_RDY conditional

From: Maxime Ripard The COEF_RDY bit isn't found in all the SoCs featuring some variant of the frontend. Add it to our quirks structure. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 9 + drivers/gpu/drm/sun4i/sun4i_frontend.h | 1 + 2 files changed, 6 inse

[PATCH v2 39/43] drm/sun4i: frontend: Add a quirk structure

From: Maxime Ripard The ACCESS_CTRL bit is not found on all the variants of the frontend, so let's introduce a structure that will hold whether or not we need to set it, and associate it with the compatible. This will be extended for further similar quirks later on. Signed-off-by: Maxime Ripard

[PATCH v2 37/43] drm/sun4i: drv: Allow framebuffer modifiers in mode config

From: Paul Kocialkowski This is the final step to indicate to the core that our driver supports framebuffer modifiers. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm

[PATCH v2 38/43] drm/sun4i: Move access control before setting the register as documented

From: Maxime Ripard Unlike what is currently being done, the ACCESS_CTRL bit documentation asks that this bit should be set before modifying any register. The code in the BSP also does this, so make sure we do this as well. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_frontend.

[PATCH v2 35/43] drm/sun4i: frontend: Add and use helper for checking tiling support

This introduces a helper to check whether a frontend input format supports tiling mode. This helper is used when tiling is requested in the frontend format support helper. Only semiplanar and planar YUV formats are supported by the hardware. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/

[PATCH v2 18/43] drm/sun4i: frontend: Add proper definitions for format registers

This introduces proper definitions for the input and output format configuration registers instead of a macro and raw values in the code, with the intent to increase code readability and reduce indirections. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 14 ++-

[PATCH v2 42/43] drm/sun4i: frontend: Move the FIR filter phases to our quirks

From: Maxime Ripard The FIR filters phase depend on the SoC, so let's move it to our quirks structure instead of removing them. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_frontend.c | 28 -- drivers/gpu/drm/sun4i/sun4i_frontend.h | 5 + 2 files ch

[PATCH v2 25/43] drm/sun4i: frontend: Apply format sub-sampling to CH1 dimensions

The frontend comes with two "channels", that can be configured independently. When used in YUV mode, the first channel (CH0) represents the luminance component while the second channel (CH1) represents the chrominance. In RGB mode, both have to be configured the same way. Use variables (with the Y

RE: FW: [PATCH] drm: should break if already get the best size

Quoting Liu, Monk (2018-11-23 09:11:02) > What do you mean the first in the chain ? and also can you explain the " > perfect match." ? thanks > > Assume there is couple nodes equal to the size you requested, without this > patch it will traveler to the bottom level of the RB tree and gives you

RE: FW: [PATCH] drm: should break if already get the best size

There is no checks at all in this best_hole() ... can you review the patch again ? /Monk -Original Message- From: Chris Wilson Sent: Friday, November 23, 2018 5:34 PM To: Liu, Monk ; dri-devel@lists.freedesktop.org Subject: RE: FW: [PATCH] drm: should break if already get the best size

[PULL] drm-intel-next

Hi Dave - This one superseeds and includes everything in [1] as requested, and is thus pretty big. There are a number of commits that touch non-i915 files, but all relevant acks should be in place. There's also a drm-next backmerge in there. BR, Jani. [1] 87pnvneq5i.fsf@intel.com">http://mid.m

[Bug 108781] 4.19 Regression - Hawaii (R9 390) boot failure - Invalid PCC GPIO / invalid powerlevel state / Fatal error during GPU init

https://bugs.freedesktop.org/show_bug.cgi?id=108781 --- Comment #20 from jamespharve...@gmail.com --- freedesktop, I'm glad to hear removing "amdgpu.dpm=1" allows you to boot 4.19. Unfortunately, I've tried that, and it made no difference. Even if it did allow booting, that would bring back the

FW: [PATCH] drm: should break if already get the best size

Hi Chris Please check the sanity test of the patch from Rex /Monk From: Zhu, Rex Sent: Friday, November 23, 2018 5:45 PM To: Liu, Monk ; amd-...@lists.freedesktop.org Subject: Re: [PATCH] drm: should break if already get the best size Tested-by: Rex Zhu mailto:rex@amd.com>> Without this

Re: [PATCH 7/7] drm/syncobj: use the timeline point in drm_syncobj_find_fence

Am 23.11.18 um 03:36 schrieb zhoucm1: > > > On 2018年11月22日 19:30, Christian König wrote: >> Am 22.11.18 um 07:52 schrieb zhoucm1: >>> >>> >>> On 2018年11月15日 19:12, Christian König wrote: Implement finding the right timeline point in drm_syncobj_find_fence. Signed-off-by: Christian Kö

Re: [PATCH] drm/i915: change i915_sw_fence license to MIT

Quoting Jonathan Gray (2018-11-20 00:31:22) > On Mon, Nov 19, 2018 at 10:09:33AM -0800, Rodrigo Vivi wrote: > > On Sun, Nov 18, 2018 at 08:44:30PM +1100, Jonathan Gray wrote: > > > On Wed, Oct 31, 2018 at 08:43:03AM +, Chris Wilson wrote: > > > > Quoting Jonathan Gray (2018-10-31 00:56:12) > >

Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

Am 23.11.18 um 09:46 schrieb Daniel Vetter: On Thu, Nov 22, 2018 at 06:55:17PM +, Koenig, Christian wrote: Am 22.11.18 um 17:51 schrieb Daniel Vetter: We need to make sure implementations don't cheat and don't have a possible schedule/blocking point deeply burried where review can't catch i

Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE

On 23.11.18 10:54, Anshuman Khandual wrote: > At present there are multiple places where invalid node number is encoded > as -1. Even though implicitly understood it is always better to have macros > in there. Replace these open encodings for an invalid node number with the > global macro NUMA_NO_N

[Bug 108753] [RX570]GOG Dosbox game causes lockup

https://bugs.freedesktop.org/show_bug.cgi?id=108753 --- Comment #5 from baracl...@gmail.com --- I can confirm that the problem does not occur when I load xf86-video-amdgpu driver. -- You are receiving this mail because: You are the assignee for the bug.___

Re: [PATCH v8 4/7] mm, devm_memremap_pages: Add MEMORY_DEVICE_PRIVATE support

On 21.11.18 00:13, Dan Williams wrote: > In preparation for consolidating all ZONE_DEVICE enabling via > devm_memremap_pages(), teach it how to handle the constraints of > MEMORY_DEVICE_PRIVATE ranges. > > Reviewed-by: Jérôme Glisse > [jglisse: call move_pfn_range_to_zone for MEMORY_DEVICE_PRIVAT

[PATCH] drm/meson: Fix an Alpha Primary Plane bug on Meson GXL/GXM SoCs

On the Amlogic GXL & GXM SoCs, a bug occurs on the OSD1 primaty plane when alpha is used where the alpha is not aligned with the pixel content. The woraround Amlogic implemented is to reset the OSD1 plane hardware block each time the plane is updated, solving the issue. In the reset, we still nee

Re: [PATCH 7/7] drm/syncobj: use the timeline point in drm_syncobj_find_fence

On 2018年11月23日 18:10, Koenig, Christian wrote: Am 23.11.18 um 03:36 schrieb zhoucm1: On 2018年11月22日 19:30, Christian König wrote: Am 22.11.18 um 07:52 schrieb zhoucm1: On 2018年11月15日 19:12, Christian König wrote: Implement finding the right timeline point in drm_syncobj_find_fence. Signe

Re: [PATCH v2] drm/panel: Set max rate for Ilitek ILI9881C

On Tue, Nov 20, 2018 at 12:02 PM Andrzej Hajda wrote: > Anyway more I think about it more doubts I have. hs_rate can be helpful > for command mode panels - panel refresh rate (provided by timings) > imposes only lower limit on the speed, max hs rate will impose upper limit. > > In case of video m

Re: [PATCH 7/7] drm/syncobj: use the timeline point in drm_syncobj_find_fence

Am 23.11.18 um 11:56 schrieb zhoucm1: On 2018年11月23日 18:10, Koenig, Christian wrote: Am 23.11.18 um 03:36 schrieb zhoucm1: On 2018年11月22日 19:30, Christian König wrote: Am 22.11.18 um 07:52 schrieb zhoucm1: On 2018年11月15日 19:12, Christian König wrote: Implement finding the right timeline p

Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

On Thu 22-11-18 17:51:05, Daniel Vetter wrote: > We need to make sure implementations don't cheat and don't have a > possible schedule/blocking point deeply burried where review can't > catch it. > > I'm not sure whether this is the best way to make sure all the > might_sleep() callsites trigger,

Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

On Fri 23-11-18 09:49:34, Daniel Vetter wrote: > On Thu, Nov 22, 2018 at 04:53:34PM +, Chris Wilson wrote: > > Quoting Daniel Vetter (2018-11-22 16:51:04) > > > Just a bit of paranoia, since if we start pushing this deep into > > > callchains it's hard to spot all places where an mmu notifier >

Re: [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

On Thu 22-11-18 17:51:04, Daniel Vetter wrote: > Just a bit of paranoia, since if we start pushing this deep into > callchains it's hard to spot all places where an mmu notifier > implementation might fail when it's not allowed to. What does WARN give you more than the existing pr_info? Is really

[Bug 103911] r600/eg: egd_tables.h missing from 17.2.x tarballs

https://bugs.freedesktop.org/show_bug.cgi?id=103911 --- Comment #1 from Jonathan Gray --- Still missing from mesa-18.3.0-rc4.tar.gz and other recent releases. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel maili

Re: [PATCH v2 31/43] drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers

Hi Paul, On Fri, Nov 23, 2018 at 10:25:03AM +0100, Paul Kocialkowski wrote: >This introduces a dedicated ioctl for allocating buffers for the VPU >tiling mode. It allows setting up buffers that comply to the hardware >alignment requirements, by aligning the stride and height to 32 bytes. > >Only Y

[PATCH] drm: rcar-du: Fix DU3 start/stop on M3-N

Group start/stop is controlled by the DRES and DEN bits of DSYSR0 for the first group and DSYSR2 for the second group. On most DU instances, this maps to the first CRTC of the group. On M3-N, however, DU2 doesn't exist, but DSYSR2 does. There is no CRTC object there that maps to the correct DSYSR r

[GIT PULL FOR v4.21] Renesas display drivers updates

/media.git tags/du-next-20181123 for you to fetch changes up to 256856efb8cc2b5468c69edf45eb0ab579833ce7: drm: rcar-du: Reject modes that fail CRTC timing requirements (2018-11-23 13:51:23 +0200) R-Car DU changes for v4.21: - R

Re: [PATCH 4/5] drm: rcar-du: Add R8A7744 support

Hi Fabrizio, On Thursday, 22 November 2018 17:59:32 EET Fabrizio Castro wrote: > On 15 October 2018 23:25 Laurent Pinchart wrote: > > On Friday, 21 September 2018 21:08:30 EEST Fabrizio Castro wrote: > >> From: Biju Das > >> > >> Add support for the R8A7744 DU (which is very similar to the R8A77

Re: [PATCH v2 3/5] drm: rcar-du: Add r8a77470 support

Hi Fabrizio, On Thursday, 22 November 2018 18:03:44 EET Fabrizio Castro wrote: > On 17 October 2018 07:52 Laurent Pinchart wrote: > > On Tuesday, 16 October 2018 19:58:59 EEST Fabrizio Castro wrote: > > > Add RZ/G1C (a.k.a. r8a77470) support to the R-Car DU driver. > >> > >> Signed-off-by: Fabriz

[PATCH 3/3] drm/tegra: falcon: Wait for memory scrubbing to complete

From: Thierry Reding Before booting the Falcon processor, make sure to wait for memory scrubbing to complete. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/falcon.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falc

Re: [PATCH 7/7] drm/syncobj: use the timeline point in drm_syncobj_find_fence

Am 23.11.18 um 12:03 schrieb Christian König: > Am 23.11.18 um 11:56 schrieb zhoucm1: >> >> >> On 2018年11月23日 18:10, Koenig, Christian wrote: >>> Am 23.11.18 um 03:36 schrieb zhoucm1: On 2018年11月22日 19:30, Christian König wrote: > Am 22.11.18 um 07:52 schrieb zhoucm1: >> >> On

[PATCH 1/3] drm/tegra: vic: Implement explicit reset support

From: Thierry Reding Tegra supports generic PM domains on 64-bit ARM, and if that is enabled, the power domain code will make sure that resets are asserted and deasserted at appropriate points in time. If generic PM domains are not implemented, such as on 32-bit Tegra, the resets need to be asse

[PATCH 2/3] drm/tegra: falcon: Fix error handling

From: Thierry Reding The ->alloc() callback in struct falcon_ops returns an ERR_PTR()-encoded error code on failure, so it needs to be properly checked for, otherwise subsequent code may dereference an invalid pointer. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/falcon.c | 6 +++---

[PATCH] drm/nouveau: tegra: Call nouveau_drm_device_init()

From: Thierry Reding As part of commit cfea88a4d866 ("drm/nouveau: Start using new drm_dev initialization helpers"), the initialization of the Nouveau DRM device was reworked and along the way the platform driver initialization was left incomplete. Add a call to nouveau_drm_device_init() to make

Re: [PATCH 7/7] drm/syncobj: use the timeline point in drm_syncobj_find_fence

On Fri, Nov 23, 2018 at 12:02:41PM +, Koenig, Christian wrote: > Am 23.11.18 um 12:03 schrieb Christian König: > > Am 23.11.18 um 11:56 schrieb zhoucm1: > >> > >> > >> On 2018年11月23日 18:10, Koenig, Christian wrote: > >>> Am 23.11.18 um 03:36 schrieb zhoucm1: > > On 2018年11月22日 19:30,

Re: [PATCH] drm/i915: change i915_sw_fence license to MIT

On Fri, Nov 23, 2018 at 12:14:00PM +0200, Joonas Lahtinen wrote: > Quoting Jonathan Gray (2018-11-20 00:31:22) > > On Mon, Nov 19, 2018 at 10:09:33AM -0800, Rodrigo Vivi wrote: > > > On Sun, Nov 18, 2018 at 08:44:30PM +1100, Jonathan Gray wrote: > > > > On Wed, Oct 31, 2018 at 08:43:03AM +, Chr

Re: [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote: > On Thu 22-11-18 17:51:04, Daniel Vetter wrote: > > Just a bit of paranoia, since if we start pushing this deep into > > callchains it's hard to spot all places where an mmu notifier > > implementation might fail when it's not allowed t

[PATCH 3/7] gpu: host1x: Add Tegra194 support

From: Thierry Reding The host1x hardware found on Tegra194 is very similar to the version found on Tegra186, with the notable exceptions of the increased number of syncpoints and mlocks. In addition, some rarely used features such as syncpoint wait bases were dropped and some registers had to mov

[PATCH 6/7] arm64: tegra: Add VIC support on Tegra194

From: Thierry Reding Tegra194 has a version of VIC that is very similar to that on Tegra186. Add the device tree node for it that is enabled by default. Signed-off-by: Thierry Reding --- arch/arm64/boot/dts/nvidia/tegra194.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/

[PATCH 4/7] drm/tegra: vic: Add Tegra194 support

From: Thierry Reding The Video Image Composer (VIC) generation found on Tegra194 is the same as its predecessor found on Tegra186. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/drm.c | 1 + drivers/gpu/drm/tegra/vic.c | 11 +++ 2 files changed, 12 insertions(+) diff --git a

[PATCH 2/7] gpu: host1x: Fix syncpoint ID field size on Tegra186

From: Thierry Reding The number of syncpoints on Tegra186 is 576 and therefore no longer fits into 8 bits. Increase the size of the syncpoint ID field to 10 in order to accomodate all syncpoints. Signed-off-by: Thierry Reding --- drivers/gpu/host1x/hw/hw_host1x06_uclass.h | 2 +- 1 file change

[PATCH 1/7] gpu: host1x: Resize channel register region on Tegra186 and later

From: Thierry Reding The register region allocated per channel was decreased from 16384 bytes to 256 bytes on Tegra186 and later. Resize the region to make sure every channel (instead of only the first) is properly programmed. Suggested-by: Mikko Perttunen Signed-off-by: Thierry Reding --- dr

[PATCH 7/7] arm64: tegra: Enable HDMI on P2972-0000

From: Thierry Reding Add the 5V HDMI regulator and hook up the VDD_1V0 and VDD_1V8HS supplies from the PMIC to the display block. Also enable the display hub which is responsible for instantiating the display controllers. Finally, enable the third SOR that drives the TMDS signals to the HDMI conn

[PATCH 5/7] arm64: tegra: Add display support on Tegra194

From: Thierry Reding Tegra194 contains a display architecture very similar to that found on the Tegra186. One notable exception is that DSI is no longer a supported output. Instead there are four display controllers and four SORs (with a DPAUX associated to each of them) that can drive HDMI or DP

Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

On Fri, Nov 23, 2018 at 12:12:37PM +0100, Michal Hocko wrote: > On Thu 22-11-18 17:51:05, Daniel Vetter wrote: > > We need to make sure implementations don't cheat and don't have a > > possible schedule/blocking point deeply burried where review can't > > catch it. > > > > I'm not sure whether thi

Re: [PATCH 7/7] drm/syncobj: use the timeline point in drm_syncobj_find_fence

Am 23.11.18 um 13:26 schrieb Daniel Vetter: On Fri, Nov 23, 2018 at 12:02:41PM +, Koenig, Christian wrote: Am 23.11.18 um 12:03 schrieb Christian König: Am 23.11.18 um 11:56 schrieb zhoucm1: On 2018年11月23日 18:10, Koenig, Christian wrote: Am 23.11.18 um 03:36 schrieb zhoucm1: On 2018年11月

Re: [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail

On Fri 23-11-18 13:30:57, Daniel Vetter wrote: > On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote: > > On Thu 22-11-18 17:51:04, Daniel Vetter wrote: > > > Just a bit of paranoia, since if we start pushing this deep into > > > callchains it's hard to spot all places where an mmu notifie

Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

On Fri 23-11-18 13:38:38, Daniel Vetter wrote: > On Fri, Nov 23, 2018 at 12:12:37PM +0100, Michal Hocko wrote: > > On Thu 22-11-18 17:51:05, Daniel Vetter wrote: > > > We need to make sure implementations don't cheat and don't have a > > > possible schedule/blocking point deeply burried where revie

Re: [PATCH v2 31/43] drm/sun4i: Add a dedicated ioctl call for allocating tiled buffers

Hi, On Fri, 2018-11-23 at 11:30 +, Brian Starkey wrote: > Hi Paul, > > On Fri, Nov 23, 2018 at 10:25:03AM +0100, Paul Kocialkowski wrote: > > This introduces a dedicated ioctl for allocating buffers for the VPU > > tiling mode. It allows setting up buffers that comply to the hardware > > alig

[PATCH] drm/omap: dss: do not allow devm_kasprintf() to fail

ion-next is next-20181123) drivers/gpu/drm/omapdrm/dss/display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/display.c b/drivers/gpu/drm/omapdrm/dss/display.c index 34b2a4e..7dbe874 100644 --- a/drivers/gpu/drm/omapdrm/dss/display.c +++ b/drivers

Re: [PATCH] drm/i915: change i915_sw_fence license to MIT

Quoting Jonathan Gray (2018-11-23 14:28:37) > On Fri, Nov 23, 2018 at 12:14:00PM +0200, Joonas Lahtinen wrote: > > Quoting Jonathan Gray (2018-11-20 00:31:22) > > > On Mon, Nov 19, 2018 at 10:09:33AM -0800, Rodrigo Vivi wrote: > > > > On Sun, Nov 18, 2018 at 08:44:30PM +1100, Jonathan Gray wrote: >

Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable

On Fri, Nov 23, 2018 at 1:46 PM Michal Hocko wrote: > > On Fri 23-11-18 13:38:38, Daniel Vetter wrote: > > On Fri, Nov 23, 2018 at 12:12:37PM +0100, Michal Hocko wrote: > > > On Thu 22-11-18 17:51:05, Daniel Vetter wrote: > > > > We need to make sure implementations don't cheat and don't have a >

  1   2   >