Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Ben Crocker]

I considered that, but I'm only equipped to test on a few cards--the ones
IBM is interested in.
So this Cedar-specific change fixes the problem on the FirePro 2270; the
other cards seem
perfectly capable of handling 40+ bit DMA addresses on the Power8 platform.


On Thu, Feb 22, 2018 at 11:07 AM, Alex Deucher 
wrote:

> On Thu, Feb 22, 2018 at 10:55 AM, Ben Crocker  wrote:
> > Alex, Christian, et al.
> >
> > Thanks for your rapid response!
> >
> > I can certainly make the change PPC-only (#ifdef CONFIG_PPC64...) and I
> > think
> > that's the safest way to go right now.  It makes the patch very specific
> to
> > Cedar
> > on PowerPC64, so it doesn't break anything that may have come to depend
> on
> > Russell's and Alistair's changes, and my timetable for getting a fix in
> is
> > very short.
>
> If you want to go this route, you might just set need_dma32
> unconditionally for PPC64.  The bus interface hw is pretty much the
> same across all asics in this time period.
>
> Alex
>
>
> >
> > -- Ben
> >
> >
> >
> > On Thu, Feb 22, 2018 at 2:25 AM, Christian König
> >  wrote:
> >>
> >> Am 22.02.2018 um 03:05 schrieb Alex Deucher:
> >>>
> >>> On Wed, Feb 21, 2018 at 6:41 PM, Ben Crocker 
> wrote:
> 
>  In radeon_device_init, set the need_dma32 flag for Cedar chips
>  (e.g. FirePro 2270).  This fixes, or at least works around, a bug
>  on PowerPC exposed by last year's commits
> 
>  8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
> 
>  and
> 
>  253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
> 
>  which enabled the 64-bit DMA iommu bypass.
> 
>  This caused the device to freeze, in some cases unrecoverably, and is
>  the subject of several bug reports internal to Red Hat.
> >>>
> >>> Can we make this ppc only?  40 bit DMA works fine on x86.
> >>
> >>
> >> Yeah and at least when the dma_coherent allocator path is used it should
> >> work fine on PPC as well.
> >>
> >> So that is not really a driver bug, but a platform bug and we should
> think
> >> about reverting or at least disabling those two patches instead.
> >>
> >> Christian.
> >>
> >>>
> >>> Alex
> >>>
>  Signed-off-by: Ben Crocker 
>  ---
>    drivers/gpu/drm/radeon/radeon_device.c | 5 -
>    1 file changed, 4 insertions(+), 1 deletion(-)
> 
>  diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>  b/drivers/gpu/drm/radeon/radeon_device.c
>  index ffc10cadcf34..02538903830d 100644
>  --- a/drivers/gpu/drm/radeon/radeon_device.c
>  +++ b/drivers/gpu/drm/radeon/radeon_device.c
>  @@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device
>  *rdev,
>   if (rdev->flags & RADEON_IS_AGP)
>   rdev->need_dma32 = true;
>   if ((rdev->flags & RADEON_IS_PCI) &&
>  -   (rdev->family <= CHIP_RS740))
>  +   (rdev->family <= CHIP_RS740 || rdev->family ==
> CHIP_CEDAR))
>  +   rdev->need_dma32 = true;
>  +   if ((rdev->flags & RADEON_IS_PCIE) &&
>  +   (rdev->family == CHIP_CEDAR))
>   rdev->need_dma32 = true;
> 
>   dma_bits = rdev->need_dma32 ? 32 : 40;
>  --
>  2.13.6
> 
>  ___
>  dri-devel mailing list
>  dri-devel@lists.freedesktop.org
>  https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>>
> >>> ___
> >>> amd-gfx mailing list
> >>> amd-...@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> >>
> >>
> >
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: mali-dp: Log internal errors

[Liviu Dudau]

Hi Alex,

Thanks for the patch, it is quite useful. I have some small changes to
suggest:

On Thu, Feb 22, 2018 at 04:02:37PM +, Alexandru Gheorghe wrote:
> From: Alexandru Gheorghe 
> 
> Status register contains a lot of bits for reporting internal errors
> inside mali-dp. Currently, we just silently ignore all of the erorrs,

mali-dp is the driver, I think you are actually talking about Mali DP
hardware here, so worth making it "inside Mali DP."

> that doesn't help when we are investigating different bugs, especially
> on the FPGA models which have a lot of constrains, so we could easily
> end up in AXI or underrun errors.
> 
> Add a new KConfig option called CONFIG_DRM_MALI_DISPLAY_DEBUG, which
> enables the logging of the errors present in the status register.
> 
> Errors will be reported in  /sys/kernel/debug/tracing/trace,
> still not noisy enough, but better than silently ignoring them.
> 
> E.g:
> -0 [000] d.h1  2387.240042: malidp_de_irq: error occurred at vblank 
> 596 DE_STATUS is 0x0001
> -0 [000] d.h1  2387.256703: malidp_de_irq: error occurred at vblank 
> 597 DE_STATUS is 0x0001
> -0 [000] d.h1  2387.273458: malidp_de_irq: error occurred at vblank 
> 598 DE_STATUS is 0x0001
> -0 [000] d.h1  2387.290035: malidp_de_irq: error occurred at vblank 
> 599 DE_STATUS is 0x0001
> 
> In addition to that, I removed the setting of MALIDP550_SE_IRQ_AXI_ERR
> bit in the irq_mask, since that bit doesn't exist.
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drivers/gpu/drm/arm/Kconfig   | 10 +
>  drivers/gpu/drm/arm/malidp_hw.c   | 45 
> ---
>  drivers/gpu/drm/arm/malidp_hw.h   |  1 +
>  drivers/gpu/drm/arm/malidp_regs.h |  6 ++
>  4 files changed, 54 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index 9a18e1b..c1e6fc8 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -40,3 +40,13 @@ config DRM_MALI_DISPLAY
> of the hardware.
>  
> If compiled as a module it will be called mali-dp.
> +
> +config DRM_MALI_DISPLAY_DEBUG
> + bool "Enable mali display debugging"

s/mali display/Mali DP/

> + default n
> + depends on DRM_MALI_DISPLAY
> + select FTRACE
> + help
> +   Enable this option to log internal errors that happened during
> +   processing of a frame. Errors will be reported in
> +   /sys/kernel/debug/tracing/trace.
> diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
> index 2bfb542..7d3b2e2 100644
> --- a/drivers/gpu/drm/arm/malidp_hw.c
> +++ b/drivers/gpu/drm/arm/malidp_hw.c
> @@ -632,10 +632,16 @@ const struct malidp_hw 
> malidp_device[MALIDP_MAX_DEVICES] = {
>   MALIDP500_DE_IRQ_VSYNC |
>   MALIDP500_DE_IRQ_GLOBAL,
>   .vsync_irq = MALIDP500_DE_IRQ_VSYNC,
> + .err_mask = MALIDP_DE_IRQ_UNDERRUN |
> + MALIDP500_DE_IRQ_AXI_ERR |
> + MALIDP500_DE_IRQ_SATURATION,
>   },
>   .se_irq_map = {
>   .irq_mask = MALIDP500_SE_IRQ_CONF_MODE,
>   .vsync_irq = 0,
> + .err_mask = MALIDP500_SE_IRQ_INIT_BUSY |
> + MALIDP500_SE_IRQ_AXI_ERROR |
> + MALIDP500_SE_IRQ_OVERRUN,
>   },
>   .dc_irq_map = {
>   .irq_mask = MALIDP500_DE_IRQ_CONF_VALID,
> @@ -669,10 +675,15 @@ const struct malidp_hw 
> malidp_device[MALIDP_MAX_DEVICES] = {
>   .irq_mask = MALIDP_DE_IRQ_UNDERRUN |
>   MALIDP550_DE_IRQ_VSYNC,
>   .vsync_irq = MALIDP550_DE_IRQ_VSYNC,
> + .err_mask = MALIDP_DE_IRQ_UNDERRUN |
> + MALIDP550_DE_IRQ_SATURATION |
> + MALIDP550_DE_IRQ_AXI_ERR,
>   },
>   .se_irq_map = {
> - .irq_mask = MALIDP550_SE_IRQ_EOW |
> - MALIDP550_SE_IRQ_AXI_ERR,
> + .irq_mask = MALIDP550_SE_IRQ_EOW,
> + .err_mask  = MALIDP550_SE_IRQ_AXI_ERR |
> +  MALIDP550_SE_IRQ_OVR |
> +  MALIDP550_SE_IRQ_IBSY,
>   },
>   .dc_irq_map = {
>   .irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
> @@ -707,10 +718,20 @@ const struct malidp_hw 
> 

[Bug 198885] amdgpu.dc=1 on CIK (R4 Mullins APU) brightness impossible to change. by Fn or "echo".

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198885

--- Comment #2 from Przemek (sop...@gmail.com) ---
Hi Michel,

Thank you very much for insane-fast response.

Yes, "actual_brightness" is a bad example, same occurs on this file without
"amdgpu.dc=1".

Here are values from requested files:

"/sys/class/backlight/amdgpu_bl0 # cat brightness
3" 

"/sys/class/backlight/amdgpu_bl0 # cat max_brightness
255"

"/sys/class/backlight/amdgpu_bl0 # cat actual_brightness
3"

I have tried different values also:
"/sys/class/backlight/amdgpu_bl0 # echo 100 > brightness
bash: echo: błąd zapisu: Bad argument
/sys/class/backlight/amdgpu_bl0 # echo 50 > brightness
bash: echo: błąd zapisu: Bad argument
/sys/class/backlight/amdgpu_bl0 # echo 10 > brightness
bash: echo: błąd zapisu: Bad argument"

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/p[111: add CONFIG_OF dependency

[Arnd Bergmann]

We cannot select a symbol without meeting its other dependencies:

warning: (DRM_PL111) selects DRM_DUMB_VGA_DAC which has unmet direct 
dependencies (HAS_IOMEM && DRM && DRM_BRIDGE && OF)
drivers/gpu/drm/bridge/dumb-vga-dac.c: In function 'dumb_vga_probe':
drivers/gpu/drm/bridge/dumb-vga-dac.c:207:13: error: 'struct drm_bridge' has no 
member named 'of_node'
  vga->bridge.of_node = pdev->dev.of_node;
 ^

Here it seems reasonable to depend on CONFIG_OF, as all platforms
using this driver already require that anyway.

Fixes: 49f81d80ab84 ("drm/pl111: Support handling bridge timings")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/pl111/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index 82cb3e60ddc8..776448e8d4ee 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -3,6 +3,7 @@ config DRM_PL111
depends on DRM
depends on ARM || ARM64 || COMPILE_TEST
depends on COMMON_CLK
+   depends on OF
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
-- 
2.9.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix drm_get_max_iomem type mismatch

[Sean Paul]

On Thu, Feb 22, 2018 at 12:47:51PM +0100, Arnd Bergmann wrote:
> When comparing two variables with min()/max(), they should be the same type:
> 
> drivers/gpu/drm/drm_memory.c: In function 'drm_get_max_iomem':
> include/linux/kernel.h:821:16: error: comparison of distinct pointer types 
> lacks a cast [-Werror]
>   (void) ( == );
> 
> This makes the local variable in drm_get_max_iomem make the type
> from resource->end.
> 
> Fixes: 82626363a217 ("drm: add func to get max iomem address v2")
> Signed-off-by: Arnd Bergmann 

Thanks Arnd, I've applied this to drm-misc-next.

Sean

> ---
>  drivers/gpu/drm/drm_memory.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
> index 7ca500b8c399..3c54044214db 100644
> --- a/drivers/gpu/drm/drm_memory.c
> +++ b/drivers/gpu/drm/drm_memory.c
> @@ -153,7 +153,7 @@ EXPORT_SYMBOL(drm_legacy_ioremapfree);
>  u64 drm_get_max_iomem(void)
>  {
>   struct resource *tmp;
> - u64 max_iomem = 0;
> + resource_size_t max_iomem = 0;
>  
>   for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
>   max_iomem = max(max_iomem,  tmp->end);
> -- 
> 2.9.0
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC

[Daniel Vetter]

On Thu, Feb 22, 2018 at 08:12:48AM +0200, Oleksandr Andrushchenko wrote:
> On 02/22/2018 08:09 AM, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko 
> > 
> > It is possible that drm_simple_kms_plane_atomic_check called
> > with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
> > to 0 before doing any actual drawing. This leads to NULL pointer
> > dereference because in this case new CRTC state is NULL and must be
> > checked before accessing.
> > 
> > Signed-off-by: Oleksandr Andrushchenko 
> > Reviewed-by: Daniel Vetter 
> > 
> > ---
> > Changes since initial:
> > - re-worked checks for null CRTC as suggested by Daniel Vetter
> > ---
> >   drivers/gpu/drm/drm_simple_kms_helper.c | 10 +++---
> >   1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 9ca8a4a59b74..4a1dbd88b1ec 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -121,12 +121,6 @@ static int drm_simple_kms_plane_atomic_check(struct 
> > drm_plane *plane,
> > pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> > crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
> >>crtc);
> > -   if (!crtc_state->enable)
> > -   return 0; /* nothing to check when disabling or disabled */
> > -
> > -   if (crtc_state->enable)
> > -   drm_mode_get_hv_timing(_state->mode,
> > -  , );
> > ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
> >   ,
> > @@ -137,7 +131,9 @@ static int drm_simple_kms_plane_atomic_check(struct 
> > drm_plane *plane,
> > return ret;
> > if (!plane_state->visible)
> > -   return -EINVAL;
> Daniel, I have put your R-b tag, but I had removed suggested
> "WARN_ON(crtc_state && crtc_state->enable);"
> here as it fires each time when crtc_state is not NULL.
> Please let me know if this is not ok and you want me to remove
> your R-b tag.

I'm a bit confused why that fires, but oh well. Applied, thanks for your
patch.
-Daniel

> > +   return 0;
> > +
> > +   drm_mode_get_hv_timing(_state->mode, , );
> > if (!pipe->funcs || !pipe->funcs->check)
> > return 0;
> Thank you,
> Oleksandr
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Alex Deucher]

On Thu, Feb 22, 2018 at 10:55 AM, Ben Crocker  wrote:
> Alex, Christian, et al.
>
> Thanks for your rapid response!
>
> I can certainly make the change PPC-only (#ifdef CONFIG_PPC64...) and I
> think
> that's the safest way to go right now.  It makes the patch very specific to
> Cedar
> on PowerPC64, so it doesn't break anything that may have come to depend on
> Russell's and Alistair's changes, and my timetable for getting a fix in is
> very short.

If you want to go this route, you might just set need_dma32
unconditionally for PPC64.  The bus interface hw is pretty much the
same across all asics in this time period.

Alex


>
> -- Ben
>
>
>
> On Thu, Feb 22, 2018 at 2:25 AM, Christian König
>  wrote:
>>
>> Am 22.02.2018 um 03:05 schrieb Alex Deucher:
>>>
>>> On Wed, Feb 21, 2018 at 6:41 PM, Ben Crocker  wrote:

 In radeon_device_init, set the need_dma32 flag for Cedar chips
 (e.g. FirePro 2270).  This fixes, or at least works around, a bug
 on PowerPC exposed by last year's commits

 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)

 and

 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)

 which enabled the 64-bit DMA iommu bypass.

 This caused the device to freeze, in some cases unrecoverably, and is
 the subject of several bug reports internal to Red Hat.
>>>
>>> Can we make this ppc only?  40 bit DMA works fine on x86.
>>
>>
>> Yeah and at least when the dma_coherent allocator path is used it should
>> work fine on PPC as well.
>>
>> So that is not really a driver bug, but a platform bug and we should think
>> about reverting or at least disabling those two patches instead.
>>
>> Christian.
>>
>>>
>>> Alex
>>>
 Signed-off-by: Ben Crocker 
 ---
   drivers/gpu/drm/radeon/radeon_device.c | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_device.c
 b/drivers/gpu/drm/radeon/radeon_device.c
 index ffc10cadcf34..02538903830d 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device
 *rdev,
  if (rdev->flags & RADEON_IS_AGP)
  rdev->need_dma32 = true;
  if ((rdev->flags & RADEON_IS_PCI) &&
 -   (rdev->family <= CHIP_RS740))
 +   (rdev->family <= CHIP_RS740 || rdev->family == CHIP_CEDAR))
 +   rdev->need_dma32 = true;
 +   if ((rdev->flags & RADEON_IS_PCIE) &&
 +   (rdev->family == CHIP_CEDAR))
  rdev->need_dma32 = true;

  dma_bits = rdev->need_dma32 ? 32 : 40;
 --
 2.13.6

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: vboxvideo: remove ttm_pool_* wrappers

[Daniel Vetter]

On Thu, Feb 22, 2018 at 02:54:27PM +0100, Christian König wrote:
> TTM calls the default implementation now.
> 
> Signed-off-by: Christian König 

Reviewed-by: Daniel Vetter 

Is there some sync requirement with drm trees? If so probably simplest if
you stuff this one into drm-misc.
-Daniel


> ---
>  drivers/staging/vboxvideo/vbox_ttm.c | 13 -
>  1 file changed, 13 deletions(-)
> 
> diff --git a/drivers/staging/vboxvideo/vbox_ttm.c 
> b/drivers/staging/vboxvideo/vbox_ttm.c
> index 2ea31589d773..c4b7a6b9abd5 100644
> --- a/drivers/staging/vboxvideo/vbox_ttm.c
> +++ b/drivers/staging/vboxvideo/vbox_ttm.c
> @@ -213,21 +213,8 @@ static struct ttm_tt *vbox_ttm_tt_create(struct 
> ttm_bo_device *bdev,
>   return tt;
>  }
>  
> -static int vbox_ttm_tt_populate(struct ttm_tt *ttm,
> - struct ttm_operation_ctx *ctx)
> -{
> - return ttm_pool_populate(ttm, ctx);
> -}
> -
> -static void vbox_ttm_tt_unpopulate(struct ttm_tt *ttm)
> -{
> - ttm_pool_unpopulate(ttm);
> -}
> -
>  static struct ttm_bo_driver vbox_bo_driver = {
>   .ttm_tt_create = vbox_ttm_tt_create,
> - .ttm_tt_populate = vbox_ttm_tt_populate,
> - .ttm_tt_unpopulate = vbox_ttm_tt_unpopulate,
>   .init_mem_type = vbox_bo_init_mem_type,
>   .eviction_valuable = ttm_bo_eviction_valuable,
>   .evict_flags = vbox_bo_evict_flags,
> -- 
> 2.14.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: mali-dp: Log internal errors

[Alexandru Gheorghe]

From: Alexandru Gheorghe 

Status register contains a lot of bits for reporting internal errors
inside mali-dp. Currently, we just silently ignore all of the erorrs,
that doesn't help when we are investigating different bugs, especially
on the FPGA models which have a lot of constrains, so we could easily
end up in AXI or underrun errors.

Add a new KConfig option called CONFIG_DRM_MALI_DISPLAY_DEBUG, which
enables the logging of the errors present in the status register.

Errors will be reported in  /sys/kernel/debug/tracing/trace,
still not noisy enough, but better than silently ignoring them.

E.g:
-0 [000] d.h1  2387.240042: malidp_de_irq: error occurred at vblank 
596 DE_STATUS is 0x0001
-0 [000] d.h1  2387.256703: malidp_de_irq: error occurred at vblank 
597 DE_STATUS is 0x0001
-0 [000] d.h1  2387.273458: malidp_de_irq: error occurred at vblank 
598 DE_STATUS is 0x0001
-0 [000] d.h1  2387.290035: malidp_de_irq: error occurred at vblank 
599 DE_STATUS is 0x0001

In addition to that, I removed the setting of MALIDP550_SE_IRQ_AXI_ERR
bit in the irq_mask, since that bit doesn't exist.

Signed-off-by: Alexandru Gheorghe 
---
 drivers/gpu/drm/arm/Kconfig   | 10 +
 drivers/gpu/drm/arm/malidp_hw.c   | 45 ---
 drivers/gpu/drm/arm/malidp_hw.h   |  1 +
 drivers/gpu/drm/arm/malidp_regs.h |  6 ++
 4 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 9a18e1b..c1e6fc8 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -40,3 +40,13 @@ config DRM_MALI_DISPLAY
  of the hardware.
 
  If compiled as a module it will be called mali-dp.
+
+config DRM_MALI_DISPLAY_DEBUG
+   bool "Enable mali display debugging"
+   default n
+   depends on DRM_MALI_DISPLAY
+   select FTRACE
+   help
+ Enable this option to log internal errors that happened during
+ processing of a frame. Errors will be reported in
+ /sys/kernel/debug/tracing/trace.
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 2bfb542..7d3b2e2 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -632,10 +632,16 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] 
= {
MALIDP500_DE_IRQ_VSYNC |
MALIDP500_DE_IRQ_GLOBAL,
.vsync_irq = MALIDP500_DE_IRQ_VSYNC,
+   .err_mask = MALIDP_DE_IRQ_UNDERRUN |
+   MALIDP500_DE_IRQ_AXI_ERR |
+   MALIDP500_DE_IRQ_SATURATION,
},
.se_irq_map = {
.irq_mask = MALIDP500_SE_IRQ_CONF_MODE,
.vsync_irq = 0,
+   .err_mask = MALIDP500_SE_IRQ_INIT_BUSY |
+   MALIDP500_SE_IRQ_AXI_ERROR |
+   MALIDP500_SE_IRQ_OVERRUN,
},
.dc_irq_map = {
.irq_mask = MALIDP500_DE_IRQ_CONF_VALID,
@@ -669,10 +675,15 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] 
= {
.irq_mask = MALIDP_DE_IRQ_UNDERRUN |
MALIDP550_DE_IRQ_VSYNC,
.vsync_irq = MALIDP550_DE_IRQ_VSYNC,
+   .err_mask = MALIDP_DE_IRQ_UNDERRUN |
+   MALIDP550_DE_IRQ_SATURATION |
+   MALIDP550_DE_IRQ_AXI_ERR,
},
.se_irq_map = {
-   .irq_mask = MALIDP550_SE_IRQ_EOW |
-   MALIDP550_SE_IRQ_AXI_ERR,
+   .irq_mask = MALIDP550_SE_IRQ_EOW,
+   .err_mask  = MALIDP550_SE_IRQ_AXI_ERR |
+MALIDP550_SE_IRQ_OVR |
+MALIDP550_SE_IRQ_IBSY,
},
.dc_irq_map = {
.irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
@@ -707,10 +718,20 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] 
= {
MALIDP650_DE_IRQ_DRIFT |
MALIDP550_DE_IRQ_VSYNC,
.vsync_irq = MALIDP550_DE_IRQ_VSYNC,
+   .err_mask = MALIDP_DE_IRQ_UNDERRUN |
+   MALIDP650_DE_IRQ_DRIFT |
+   

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104597

--- Comment #15 from Michel Dänzer  ---
(In reply to Luke A. Guest from comment #14)
> It's been pointed out it's not Obs as TyMiles2012 moved back from the Oibaf
> PPA on Ubuntu 17.10.1 back to standard drivers and it no longer affects him.

That doesn't mean it's a Mesa bug, just that the OBS issue was triggered by a
change in Mesa's behaviour (it now exposes 10-bit-per-component colour
configs).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar

[Ben Crocker]

Alex, Christian, et al.

Thanks for your rapid response!

I can certainly make the change PPC-only (#ifdef CONFIG_PPC64...) and I
think
that's the safest way to go right now.  It makes the patch very specific to
Cedar
on PowerPC64, so it doesn't break anything that may have come to depend on
Russell's and Alistair's changes, and my timetable for getting a fix in is
very short.

-- Ben



On Thu, Feb 22, 2018 at 2:25 AM, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:

> Am 22.02.2018 um 03:05 schrieb Alex Deucher:
>
>> On Wed, Feb 21, 2018 at 6:41 PM, Ben Crocker  wrote:
>>
>>> In radeon_device_init, set the need_dma32 flag for Cedar chips
>>> (e.g. FirePro 2270).  This fixes, or at least works around, a bug
>>> on PowerPC exposed by last year's commits
>>>
>>> 8e3f1b1d8255105f31556aacf8aeb6071b00d469 (Russell Currey)
>>>
>>> and
>>>
>>> 253fd51e2f533552ae35a0c661705da6c4842c1b (Alistair Popple)
>>>
>>> which enabled the 64-bit DMA iommu bypass.
>>>
>>> This caused the device to freeze, in some cases unrecoverably, and is
>>> the subject of several bug reports internal to Red Hat.
>>>
>> Can we make this ppc only?  40 bit DMA works fine on x86.
>>
>
> Yeah and at least when the dma_coherent allocator path is used it should
> work fine on PPC as well.
>
> So that is not really a driver bug, but a platform bug and we should think
> about reverting or at least disabling those two patches instead.
>
> Christian.
>
>
>> Alex
>>
>> Signed-off-by: Ben Crocker 
>>> ---
>>>   drivers/gpu/drm/radeon/radeon_device.c | 5 -
>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>>> b/drivers/gpu/drm/radeon/radeon_device.c
>>> index ffc10cadcf34..02538903830d 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>>> @@ -1395,7 +1395,10 @@ int radeon_device_init(struct radeon_device *rdev,
>>>  if (rdev->flags & RADEON_IS_AGP)
>>>  rdev->need_dma32 = true;
>>>  if ((rdev->flags & RADEON_IS_PCI) &&
>>> -   (rdev->family <= CHIP_RS740))
>>> +   (rdev->family <= CHIP_RS740 || rdev->family == CHIP_CEDAR))
>>> +   rdev->need_dma32 = true;
>>> +   if ((rdev->flags & RADEON_IS_PCIE) &&
>>> +   (rdev->family == CHIP_CEDAR))
>>>  rdev->need_dma32 = true;
>>>
>>>  dma_bits = rdev->need_dma32 ? 32 : 40;
>>> --
>>> 2.13.6
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>> ___
>> amd-gfx mailing list
>> amd-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/8] drm/ttm: add default implementations for ttm_tt_(un)populate

[Michel Dänzer]

On 2018-02-22 12:15 PM, Christian König wrote:
> Use ttm_pool_populate/ttm_pool_unpopulate if the driver doesn't provide
> a function.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_tt.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 9fd7115a013a..65bf4eac184b 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -410,7 +410,10 @@ int ttm_tt_populate(struct ttm_tt *ttm, struct 
> ttm_operation_ctx *ctx)
>   if (ttm->state != tt_unpopulated)
>   return 0;
>  
> - ret = ttm->bdev->driver->ttm_tt_populate(ttm, ctx);
> + if (ttm->bdev->driver->ttm_tt_populate)
> + ret = ttm->bdev->driver->ttm_tt_populate(ttm, ctx);
> + else
> + ret = ttm_pool_populate(ttm, ctx);
>   if (!ret)
>   ttm_tt_add_mapping(ttm);
>   return ret;
> @@ -436,5 +439,8 @@ void ttm_tt_unpopulate(struct ttm_tt *ttm)
>   return;
>  
>   ttm_tt_clear_mapping(ttm);
> - ttm->bdev->driver->ttm_tt_unpopulate(ttm);
> + if (ttm->bdev->driver->ttm_tt_unpopulate)
> + ttm->bdev->driver->ttm_tt_unpopulate(ttm);
> + else
> + ttm_pool_unpopulate(ttm);
>  }
> 

Instead of the if/else, have you considered setting
driver->ttm_tt_(un)populate = ttm_pool_(un)populate during
initialization if they're NULL?


Either way, the series is

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104597] [bisected] Compton weird colors

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104597

--- Comment #14 from Luke A. Guest  ---
Looks like it's the same as
https://obsproject.com/forum/threads/xcomposite-colours-all-wrong.81265/ and
https://obsproject.com/forum/threads/xcomposite-window-capture-not-working.81389/.

It's been pointed out it's not Obs as TyMiles2012 moved back from the Oibaf PPA
on Ubuntu 17.10.1 back to standard drivers and it no longer affects him.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/ttm: move ttm_tt_create into ttm_tt.c

[Michel Dänzer]

On 2018-02-22 04:02 PM, Christian König wrote:
> Rename ttm_bo_add_ttm to ttm_tt_create, clean it up and move it into
> ttm_tt.c.

Please split this up into two changes, one which just moves the code and
renames the function, without any actual code changes, and another one
which cleans up the code. Otherwise it's hard to review the cleanup changes.


Patches 1-3 & 6 are

Reviewed-by: Michel Dänzer 


Patch 5 looks fine to me as well, but might want to wait for Thomas'
feedback.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 8/8] drm/sun4i: backend: Remove ARGB spoofing

[Maxime Ripard]

On Thu, Feb 22, 2018 at 10:15:07PM +0800, Chen-Yu Tsai wrote:
> On Sat, Feb 17, 2018 at 1:39 AM, Maxime Ripard
>  wrote:
> > We've had some code for quite some time to prevent the alpha bug from
> > happening on the lowest primary plane. Since we now check for this in our
> > atomic_check, we can simply remove it.
> >
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Chen-Yu Tsai 

Applied the patches 4, 5, 6 and 8 with your reviewed-by.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198885] amdgpu.dc=1 on CIK (R4 Mullins APU) brightness impossible to change. by Fn or "echo".

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198885

Michel Dänzer (mic...@daenzer.net) changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com

--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Przemek from comment #0)
> -r--r--r-- 1 root root 4096 02-22 13:41 actual_brightness
[...]
> "/sys/class/backlight/amdgpu_bl0 # echo 22 > actual_brightness
> bash: actual_brightness: permission denied"

As you can see above, this file is read-only.


> "/sys/class/backlight/amdgpu_bl0 # echo 128 > brightness
> bash: echo: błąd zapisu: Bad argument"

What does

 cat max_brightness

say? If it's a value smaller than 128, does writing a value <= that to the
brightness file work?


> Without "amdgpu.dc=1" in kernel command line changing brightness level is
> working as expected, both Fn keys, and echoing directly to a file.

What values do the brightness, max_brightness and actual_brightness files
contain in that case?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/6] drm/ttm: move ttm_tt defines into ttm_tt.h

[Christian König]

Let's stop mangling everything in a single header and create one header
per object instead.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_tt.c|   6 -
 include/drm/ttm/ttm_bo_driver.h | 237 +-
 include/drm/ttm/ttm_tt.h| 272 
 3 files changed, 273 insertions(+), 242 deletions(-)
 create mode 100644 include/drm/ttm/ttm_tt.h

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 0ee3b8f11605..8e0b525cda00 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -31,17 +31,11 @@
 #define pr_fmt(fmt) "[TTM] " fmt
 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #ifdef CONFIG_X86
 #include 
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 4312b5326f0b..f8e2515b401f 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -42,111 +42,10 @@
 #include "ttm_memory.h"
 #include "ttm_module.h"
 #include "ttm_placement.h"
+#include "ttm_tt.h"
 
 #define TTM_MAX_BO_PRIORITY4U
 
-struct ttm_backend_func {
-   /**
-* struct ttm_backend_func member bind
-*
-* @ttm: Pointer to a struct ttm_tt.
-* @bo_mem: Pointer to a struct ttm_mem_reg describing the
-* memory type and location for binding.
-*
-* Bind the backend pages into the aperture in the location
-* indicated by @bo_mem. This function should be able to handle
-* differences between aperture and system page sizes.
-*/
-   int (*bind) (struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem);
-
-   /**
-* struct ttm_backend_func member unbind
-*
-* @ttm: Pointer to a struct ttm_tt.
-*
-* Unbind previously bound backend pages. This function should be
-* able to handle differences between aperture and system page sizes.
-*/
-   int (*unbind) (struct ttm_tt *ttm);
-
-   /**
-* struct ttm_backend_func member destroy
-*
-* @ttm: Pointer to a struct ttm_tt.
-*
-* Destroy the backend. This will be call back from ttm_tt_destroy so
-* don't call ttm_tt_destroy from the callback or infinite loop.
-*/
-   void (*destroy) (struct ttm_tt *ttm);
-};
-
-#define TTM_PAGE_FLAG_WRITE   (1 << 3)
-#define TTM_PAGE_FLAG_SWAPPED (1 << 4)
-#define TTM_PAGE_FLAG_PERSISTENT_SWAP (1 << 5)
-#define TTM_PAGE_FLAG_ZERO_ALLOC  (1 << 6)
-#define TTM_PAGE_FLAG_DMA32   (1 << 7)
-#define TTM_PAGE_FLAG_SG  (1 << 8)
-#define TTM_PAGE_FLAG_NO_RETRY   (1 << 9)
-
-enum ttm_caching_state {
-   tt_uncached,
-   tt_wc,
-   tt_cached
-};
-
-/**
- * struct ttm_tt
- *
- * @bdev: Pointer to a struct ttm_bo_device.
- * @func: Pointer to a struct ttm_backend_func that describes
- * the backend methods.
- * pointer.
- * @pages: Array of pages backing the data.
- * @num_pages: Number of pages in the page array.
- * @bdev: Pointer to the current struct ttm_bo_device.
- * @be: Pointer to the ttm backend.
- * @swap_storage: Pointer to shmem struct file for swap storage.
- * @caching_state: The current caching state of the pages.
- * @state: The current binding state of the pages.
- *
- * This is a structure holding the pages, caching- and aperture binding
- * status for a buffer object that isn't backed by fixed (VRAM / AGP)
- * memory.
- */
-
-struct ttm_tt {
-   struct ttm_bo_device *bdev;
-   struct ttm_backend_func *func;
-   struct page **pages;
-   uint32_t page_flags;
-   unsigned long num_pages;
-   struct sg_table *sg; /* for SG objects via dma-buf */
-   struct file *swap_storage;
-   enum ttm_caching_state caching_state;
-   enum {
-   tt_bound,
-   tt_unbound,
-   tt_unpopulated,
-   } state;
-};
-
-/**
- * struct ttm_dma_tt
- *
- * @ttm: Base ttm_tt struct.
- * @dma_address: The DMA (bus) addresses of the pages
- * @pages_list: used by some page allocation backend
- *
- * This is a structure holding the pages, caching- and aperture binding
- * status for a buffer object that isn't backed by fixed (VRAM / AGP)
- * memory.
- */
-struct ttm_dma_tt {
-   struct ttm_tt ttm;
-   dma_addr_t *dma_address;
-   struct list_head pages_list;
-};
-
 #define TTM_MEMTYPE_FLAG_FIXED (1 << 0)/* Fixed (on-card) PCI 
memory */
 #define TTM_MEMTYPE_FLAG_MAPPABLE  (1 << 1)/* Memory mappable */
 #define TTM_MEMTYPE_FLAG_CMA   (1 << 3)/* Can't map aperture */
@@ -610,117 +509,6 @@ ttm_flag_masked(uint32_t *old, uint32_t new, uint32_t 
mask)
return *old;
 }
 
-/**
- * ttm_tt_create
- *
- * @bo: pointer to a struct ttm_buffer_object
- * @zero_alloc: true if allocated pages needs to be zeroed
- *
- * Make 

[PATCH 2/6] drm/ttm: drop ttm->glob

[Christian König]

The pointer is available as ttm->bdev->glob as well.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  6 +++---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 11 ++-
 drivers/gpu/drm/ttm/ttm_tt.c |  2 --
 include/drm/ttm/ttm_bo_driver.h  |  1 -
 4 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 5edcd896cd53..2c28c4568c5f 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1072,6 +1072,7 @@ void ttm_page_alloc_fini(void)
 static void
 ttm_pool_unpopulate_helper(struct ttm_tt *ttm, unsigned mem_count_update)
 {
+   struct ttm_mem_global *mem_glob = ttm->bdev->glob->mem_glob;
unsigned i;
 
if (mem_count_update == 0)
@@ -1081,8 +1082,7 @@ ttm_pool_unpopulate_helper(struct ttm_tt *ttm, unsigned 
mem_count_update)
if (!ttm->pages[i])
continue;
 
-   ttm_mem_global_free_page(ttm->glob->mem_glob, ttm->pages[i],
-PAGE_SIZE);
+   ttm_mem_global_free_page(mem_glob, ttm->pages[i], PAGE_SIZE);
}
 
 put_pages:
@@ -1093,7 +1093,7 @@ ttm_pool_unpopulate_helper(struct ttm_tt *ttm, unsigned 
mem_count_update)
 
 int ttm_pool_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
 {
-   struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+   struct ttm_mem_global *mem_glob = ttm->bdev->glob->mem_glob;
unsigned i;
int ret;
 
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index b122f6eee94c..3b4c97011b5c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -929,7 +929,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
struct ttm_operation_ctx *ctx)
 {
struct ttm_tt *ttm = _dma->ttm;
-   struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+   struct ttm_mem_global *mem_glob = ttm->bdev->glob->mem_glob;
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
struct dma_page *d_page;
@@ -1031,6 +1031,7 @@ EXPORT_SYMBOL_GPL(ttm_dma_populate);
 void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev)
 {
struct ttm_tt *ttm = _dma->ttm;
+   struct ttm_mem_global *mem_glob = ttm->bdev->glob->mem_glob;
struct dma_pool *pool;
struct dma_page *d_page, *next;
enum pool_type type;
@@ -1051,8 +1052,8 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
 
count++;
if (d_page->vaddr & VADDR_FLAG_UPDATED_COUNT) {
-   ttm_mem_global_free_page(ttm->glob->mem_glob,
-d_page->p, pool->size);
+   ttm_mem_global_free_page(mem_glob, d_page->p,
+pool->size);
d_page->vaddr &= ~VADDR_FLAG_UPDATED_COUNT;
}
ttm_dma_page_put(pool, d_page);
@@ -1080,8 +1081,8 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
count++;
 
if (d_page->vaddr & VADDR_FLAG_UPDATED_COUNT) {
-   ttm_mem_global_free_page(ttm->glob->mem_glob,
-d_page->p, pool->size);
+   ttm_mem_global_free_page(mem_glob, d_page->p,
+pool->size);
d_page->vaddr &= ~VADDR_FLAG_UPDATED_COUNT;
}
 
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 65bf4eac184b..5d8f7f9b84b1 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -195,7 +195,6 @@ int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device 
*bdev,
struct page *dummy_read_page)
 {
ttm->bdev = bdev;
-   ttm->glob = bdev->glob;
ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
ttm->caching_state = tt_cached;
ttm->page_flags = page_flags;
@@ -226,7 +225,6 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct 
ttm_bo_device *bdev,
struct ttm_tt *ttm = _dma->ttm;
 
ttm->bdev = bdev;
-   ttm->glob = bdev->glob;
ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
ttm->caching_state = tt_cached;
ttm->page_flags = page_flags;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 738bb8d35c44..0e4ae26da093 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -123,7 +123,6 @@ struct ttm_tt {
uint32_t page_flags;
unsigned long num_pages;

[PATCH 6/6] drm/ttm: drop persistent_swap_storage from ttm_bo_init and co

[Christian König]

Never used as parameter, the only driver actually using this is nouveau
and there it is initialized after the BO is initialized.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  |  4 ++--
 drivers/gpu/drm/ast/ast_ttm.c   |  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c|  2 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c |  2 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c|  2 +-
 drivers/gpu/drm/qxl/qxl_object.c|  2 +-
 drivers/gpu/drm/radeon/radeon_object.c  |  4 ++--
 drivers/gpu/drm/ttm/ttm_bo.c|  9 ++---
 drivers/gpu/drm/virtio/virtgpu_object.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |  5 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|  4 ++--
 drivers/staging/vboxvideo/vbox_ttm.c|  2 +-
 include/drm/ttm/ttm_bo_api.h| 16 +---
 16 files changed, 21 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c2a4b7215c46..216799ccb545 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -418,8 +418,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
amdgpu_ttm_placement_from_domain(bo, domain);
 
r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
->placement, page_align, , NULL,
-acc_size, sg, resv, _ttm_bo_destroy);
+>placement, page_align, , acc_size,
+sg, resv, _ttm_bo_destroy);
if (unlikely(r != 0))
return r;
 
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 77d2035dc7b7..211224f6bdd3 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -321,7 +321,7 @@ int ast_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, NULL, ast_bo_ttm_destroy);
if (ret)
goto error;
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 96edf005bfea..73722484e12b 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -368,7 +368,7 @@ static int bochs_bo_create(struct drm_device *dev, int 
size, int align,
 
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, NULL, bochs_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 3413389c0fbe..6cd0233b3bf8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -328,7 +328,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 50e317a2a4ca..8dfffdbb6b07 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -317,7 +317,7 @@ int hibmc_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(>bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, NULL, hibmc_bo_ttm_destroy);
if (ret) {
hibmc_bo_unref();
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index cd55ff5f0f0a..69beb2046008 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -324,7 +324,7 @@ int mgag200_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> 

[PATCH 3/6] drm/ttm: drop ttm->dummy_read_page

[Christian König]

Only used by the AGP backend and there it can be easily accessed using
ttm->bdev->glob.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  5 ++---
 drivers/gpu/drm/ast/ast_ttm.c   |  5 ++---
 drivers/gpu/drm/bochs/bochs_mm.c|  5 ++---
 drivers/gpu/drm/cirrus/cirrus_ttm.c |  5 ++---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c |  5 ++---
 drivers/gpu/drm/mgag200/mgag200_ttm.c   |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_bo.c|  6 +++---
 drivers/gpu/drm/nouveau/nouveau_sgdma.c |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_ttm.h   |  3 +--
 drivers/gpu/drm/qxl/qxl_ttm.c   |  6 ++
 drivers/gpu/drm/radeon/radeon_ttm.c |  7 +++
 drivers/gpu/drm/ttm/ttm_agp_backend.c   |  8 
 drivers/gpu/drm/ttm/ttm_bo.c|  6 ++
 drivers/gpu/drm/ttm/ttm_tt.c|  8 ++--
 drivers/gpu/drm/virtio/virtgpu_ttm.c|  6 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c  |  9 +++--
 drivers/staging/vboxvideo/vbox_ttm.c|  5 ++---
 include/drm/ttm/ttm_bo_driver.h | 17 -
 18 files changed, 42 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b372d8d650a5..e38e6db8f760 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -969,8 +969,7 @@ static struct ttm_backend_func amdgpu_backend_func = {
 };
 
 static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_bo_device *bdev,
-   unsigned long size, uint32_t page_flags,
-   struct page *dummy_read_page)
+   unsigned long size, uint32_t page_flags)
 {
struct amdgpu_device *adev;
struct amdgpu_ttm_tt *gtt;
@@ -983,7 +982,7 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct 
ttm_bo_device *bdev,
}
gtt->ttm.ttm.func = _backend_func;
gtt->adev = adev;
-   if (ttm_dma_tt_init(>ttm, bdev, size, page_flags, 
dummy_read_page)) {
+   if (ttm_dma_tt_init(>ttm, bdev, size, page_flags)) {
kfree(gtt);
return NULL;
}
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 68b9c5522eaa..77d2035dc7b7 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -200,8 +200,7 @@ static struct ttm_backend_func ast_tt_backend_func = {
 
 
 static struct ttm_tt *ast_ttm_tt_create(struct ttm_bo_device *bdev,
-unsigned long size, uint32_t page_flags,
-struct page *dummy_read_page)
+unsigned long size, uint32_t page_flags)
 {
struct ttm_tt *tt;
 
@@ -209,7 +208,7 @@ static struct ttm_tt *ast_ttm_tt_create(struct 
ttm_bo_device *bdev,
if (tt == NULL)
return NULL;
tt->func = _tt_backend_func;
-   if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
+   if (ttm_tt_init(tt, bdev, size, page_flags)) {
kfree(tt);
return NULL;
}
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 5525b6660340..96edf005bfea 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -178,8 +178,7 @@ static struct ttm_backend_func bochs_tt_backend_func = {
 
 static struct ttm_tt *bochs_ttm_tt_create(struct ttm_bo_device *bdev,
  unsigned long size,
- uint32_t page_flags,
- struct page *dummy_read_page)
+ uint32_t page_flags)
 {
struct ttm_tt *tt;
 
@@ -187,7 +186,7 @@ static struct ttm_tt *bochs_ttm_tt_create(struct 
ttm_bo_device *bdev,
if (tt == NULL)
return NULL;
tt->func = _tt_backend_func;
-   if (ttm_tt_init(tt, bdev, size, page_flags, dummy_read_page)) {
+   if (ttm_tt_init(tt, bdev, size, page_flags)) {
kfree(tt);
return NULL;
}
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 33798c76a64b..3413389c0fbe 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -200,8 +200,7 @@ static struct ttm_backend_func cirrus_tt_backend_func = {
 
 
 static struct ttm_tt *cirrus_ttm_tt_create(struct ttm_bo_device *bdev,
-unsigned long size, uint32_t page_flags,
-struct page *dummy_read_page)
+unsigned long size, uint32_t page_flags)
 {
struct ttm_tt *tt;
 
@@ -209,7 +208,7 @@ static struct ttm_tt *cirrus_ttm_tt_create(struct 
ttm_bo_device *bdev,
if (tt == NULL)

[PATCH 1/6] drm/ttm: drop bo->glob

[Christian König]

The pointer is available as bo->bdev->glob as well.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/qxl/qxl_release.c  |  2 +-
 drivers/gpu/drm/ttm/ttm_bo.c   | 23 ---
 drivers/gpu/drm/ttm/ttm_bo_util.c  |  2 +-
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  6 +++---
 include/drm/ttm/ttm_bo_api.h   |  3 ++-
 include/drm/ttm/ttm_bo_driver.h|  4 ++--
 6 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index b223c8d0a491..5d84a66fed36 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -458,7 +458,7 @@ void qxl_release_fence_buffer_objects(struct qxl_release 
*release)
trace_dma_fence_emit(>base);
 
driver = bdev->driver;
-   glob = bo->glob;
+   glob = bdev->glob;
 
spin_lock(>lru_lock);
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2bde37291e3e..fe4aef6b1a7a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -149,7 +149,7 @@ static void ttm_bo_release_list(struct kref *list_kref)
BUG_ON(!list_empty(>lru));
BUG_ON(!list_empty(>ddestroy));
ttm_tt_destroy(bo->ttm);
-   atomic_dec(>glob->bo_count);
+   atomic_dec(>bdev->glob->bo_count);
dma_fence_put(bo->moving);
reservation_object_fini(>ttm_resv);
mutex_destroy(>wu_mutex);
@@ -174,7 +174,7 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
if (bo->ttm && !(bo->ttm->page_flags &
 (TTM_PAGE_FLAG_SG | TTM_PAGE_FLAG_SWAPPED))) {
list_add_tail(>swap,
- >glob->swap_lru[bo->priority]);
+ >glob->swap_lru[bo->priority]);
kref_get(>list_kref);
}
}
@@ -205,9 +205,11 @@ void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
 
 void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
 {
-   spin_lock(>glob->lru_lock);
+   struct ttm_bo_global *glob = bo->bdev->glob;
+
+   spin_lock(>lru_lock);
ttm_bo_del_from_lru(bo);
-   spin_unlock(>glob->lru_lock);
+   spin_unlock(>lru_lock);
 }
 EXPORT_SYMBOL(ttm_bo_del_sub_from_lru);
 
@@ -226,7 +228,7 @@ EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
 static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
 {
struct ttm_bo_device *bdev = bo->bdev;
-   struct ttm_bo_global *glob = bo->glob;
+   struct ttm_bo_global *glob = bdev->glob;
int ret = 0;
uint32_t page_flags = 0;
 
@@ -429,7 +431,7 @@ static void ttm_bo_flush_all_fences(struct 
ttm_buffer_object *bo)
 static void ttm_bo_cleanup_refs_or_queue(struct ttm_buffer_object *bo)
 {
struct ttm_bo_device *bdev = bo->bdev;
-   struct ttm_bo_global *glob = bo->glob;
+   struct ttm_bo_global *glob = bdev->glob;
int ret;
 
ret = ttm_bo_individualize_resv(bo);
@@ -500,7 +502,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
   bool interruptible, bool no_wait_gpu,
   bool unlock_resv)
 {
-   struct ttm_bo_global *glob = bo->glob;
+   struct ttm_bo_global *glob = bo->bdev->glob;
struct reservation_object *resv;
int ret;
 
@@ -1191,7 +1193,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(>io_reserve_lru);
mutex_init(>wu_mutex);
bo->bdev = bdev;
-   bo->glob = bdev->glob;
bo->type = type;
bo->num_pages = num_pages;
bo->mem.size = num_pages << PAGE_SHIFT;
@@ -1213,7 +1214,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->resv = >ttm_resv;
}
reservation_object_init(>ttm_resv);
-   atomic_inc(>glob->bo_count);
+   atomic_inc(>bdev->glob->bo_count);
drm_vma_node_reset(>vma_node);
bo->priority = 0;
 
@@ -1246,9 +1247,9 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
}
 
if (resv && !(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
-   spin_lock(>glob->lru_lock);
+   spin_lock(>glob->lru_lock);
ttm_bo_add_to_lru(bo);
-   spin_unlock(>glob->lru_lock);
+   spin_unlock(>glob->lru_lock);
}
 
return ret;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 38da6903cae9..6d6a3f46143b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -470,7 +470,7 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
 * TODO: Explicit member copy would probably be better here.
 */
 
-   atomic_inc(>glob->bo_count);
+   atomic_inc(>bdev->glob->bo_count);
INIT_LIST_HEAD(>ddestroy);
INIT_LIST_HEAD(>lru);

[PATCH 4/6] drm/ttm: move ttm_tt_create into ttm_tt.c

[Christian König]

Rename ttm_bo_add_ttm to ttm_tt_create, clean it up and move it into
ttm_tt.c.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c| 50 ++---
 drivers/gpu/drm/ttm/ttm_tt.c| 43 +++
 include/drm/ttm/ttm_bo_driver.h | 11 +
 3 files changed, 56 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 55028745214b..3fb58ba1df51 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -222,52 +222,6 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
 }
 EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
 
-/*
- * Call bo->mutex locked.
- */
-static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
-{
-   struct ttm_bo_device *bdev = bo->bdev;
-   int ret = 0;
-   uint32_t page_flags = 0;
-
-   reservation_object_assert_held(bo->resv);
-   bo->ttm = NULL;
-
-   if (bdev->need_dma32)
-   page_flags |= TTM_PAGE_FLAG_DMA32;
-
-   if (bdev->no_retry)
-   page_flags |= TTM_PAGE_FLAG_NO_RETRY;
-
-   switch (bo->type) {
-   case ttm_bo_type_device:
-   if (zero_alloc)
-   page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
-   case ttm_bo_type_kernel:
-   bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << 
PAGE_SHIFT,
- page_flags);
-   if (unlikely(bo->ttm == NULL))
-   ret = -ENOMEM;
-   break;
-   case ttm_bo_type_sg:
-   bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << 
PAGE_SHIFT,
- page_flags | 
TTM_PAGE_FLAG_SG);
-   if (unlikely(bo->ttm == NULL)) {
-   ret = -ENOMEM;
-   break;
-   }
-   bo->ttm->sg = bo->sg;
-   break;
-   default:
-   pr_err("Illegal buffer object type\n");
-   ret = -EINVAL;
-   break;
-   }
-
-   return ret;
-}
-
 static int ttm_bo_handle_move_mem(struct ttm_buffer_object *bo,
  struct ttm_mem_reg *mem, bool evict,
  struct ttm_operation_ctx *ctx)
@@ -295,7 +249,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
if (bo->ttm == NULL) {
bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
-   ret = ttm_bo_add_ttm(bo, zero);
+   ret = ttm_tt_create(bo, zero);
if (ret)
goto out_err;
}
@@ -1134,7 +1088,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
 * We might need to add a TTM.
 */
if (bo->mem.mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
-   ret = ttm_bo_add_ttm(bo, true);
+   ret = ttm_tt_create(bo, true);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index f93cd108b19d..0ee3b8f11605 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -47,6 +47,49 @@
 #include 
 #endif
 
+/**
+ * Allocates a ttm structure for the given BO.
+ */
+int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc)
+{
+   struct ttm_bo_device *bdev = bo->bdev;
+   uint32_t page_flags = 0;
+
+   reservation_object_assert_held(bo->resv);
+
+   if (bdev->need_dma32)
+   page_flags |= TTM_PAGE_FLAG_DMA32;
+
+   if (bdev->no_retry)
+   page_flags |= TTM_PAGE_FLAG_NO_RETRY;
+
+   switch (bo->type) {
+   case ttm_bo_type_device:
+   if (zero_alloc)
+   page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
+   break;
+   case ttm_bo_type_kernel:
+   break;
+   case ttm_bo_type_sg:
+   page_flags |= TTM_PAGE_FLAG_SG;
+   break;
+   default:
+   bo->ttm = NULL;
+   pr_err("Illegal buffer object type\n");
+   return -EINVAL;
+   }
+
+   bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << PAGE_SHIFT,
+ page_flags);
+   if (unlikely(bo->ttm == NULL))
+   return -ENOMEM;
+
+   if (bo->type == ttm_bo_type_sg)
+   bo->ttm->sg = bo->sg;
+
+   return 0;
+}
+
 /**
  * Allocates storage for pointers to the pages that back the ttm.
  */
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index b338dd0ea038..4312b5326f0b 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -610,6 +610,17 @@ ttm_flag_masked(uint32_t *old, 

Re: [PATCH v3 7/8] drm/sun4i: Add support for plane alpha

[Chen-Yu Tsai]

On Thu, Feb 22, 2018 at 10:34 PM, Maxime Ripard
 wrote:
> On Thu, Feb 22, 2018 at 10:17:38PM +0800, Chen-Yu Tsai wrote:
>> On Sat, Feb 17, 2018 at 1:39 AM, Maxime Ripard
>>  wrote:
>> > Our backend supports a per-plane alpha property. Support it through our new
>> > helper.
>> >
>> > Signed-off-by: Maxime Ripard 
>>
>> Reviewed-by: Chen-Yu Tsai 
>>
>> Though, not having a graphics background, does alpha = 255 mean fully
>> transparent and thus can be skipped? Or no alpha at all?
>
> It means that it's fully opaque, and therefore we are in the same
> situation than if we had no alpha channel at all.

Right. Then the code makes sense. Thanks for the explanation.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103371] glxinfo -l shows GL_INVALID_ENUM

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103371

--- Comment #6 from Marc Dietrich  ---
... or mesa should not expose ARB_uniform_buffer_object in compat (GL 3.0)
context. I'm not an expert on this...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 7/8] drm/sun4i: Add support for plane alpha

[Maxime Ripard]

On Thu, Feb 22, 2018 at 10:17:38PM +0800, Chen-Yu Tsai wrote:
> On Sat, Feb 17, 2018 at 1:39 AM, Maxime Ripard
>  wrote:
> > Our backend supports a per-plane alpha property. Support it through our new
> > helper.
> >
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Chen-Yu Tsai 
> 
> Though, not having a graphics background, does alpha = 255 mean fully
> transparent and thus can be skipped? Or no alpha at all?

It means that it's fully opaque, and therefore we are in the same
situation than if we had no alpha channel at all.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/5] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings

[Laurent Pinchart]

Hi Hyun,

Thank you for the patch.

On Wednesday, 7 February 2018 03:36:37 EET Hyun Kwon wrote:
> This add a dt binding for ZynqMP DP subsystem.
> 
> Signed-off-by: Hyun Kwon 
> Reviewed-by: Rob Herring 
> ---
> v4
> - Specify phy related descriptions
> - Specify dma related descriptions
> - Remove ports
> - Remove child nodes for layers
> - Update the example accordingly
> v2
> - Group multiple ports under 'ports'
> - Replace linux specific terms with generic hardware descriptions
> ---
> ---
>  .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 67 +++
>  1 file changed, 67 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
> 
> diff --git
> a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
> b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt new
> file mode 100644
> index 000..f4a2e6d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
> @@ -0,0 +1,67 @@
> +Xilinx ZynqMP DisplayPort subsystem
> +---

A short description of the hardware would be useful. You can also link to the 
documentation. I have found v1.0, v2.0 and v2.1 of the PG199 document, which 
seem to correspond to the "dp" register map (and confusingly documented as the 
"DisplayPort TX Subsystem"), but no document that describes the full 
DisplayPort subsystem as defined by these bindings.

> +Required properties:
> +
> +- compatible: Must be "xlnx,zynqmp-dpsub-1.7".
> +
> +- reg: Physical base address and length of the registers set for the
> device.
> +- reg-names: Must be "dp", "blend", "av_buf", and "aud" to map logical
> register
> +  partitions.
> +
> +- interrupts: Interrupt number.
> +- interrupts-parent: phandle for interrupt controller.
> +
> +- clocks: phandles for axi, audio, non-live video, and live video clocks.
> +  axi clock is required. Audio clock is optional. If not present, audio
> will
> +  be disabled. One of non-live or live video clock should be present.
> +- clock-names: The identification strings are required. "aclk" for axi
> clock.
> +  "dp_aud_clk" for audio clock. "dp_vtc_pixel_clk_in" for non-live video
> clock.
> +  "dp_live_video_in_clk" for live video clock (clock from programmable
> logic).
> +
> +- phys: phandles for phy specifier. The number of lanes is configurable
> +  between 1 and 2. The number of phandles should be 1 or 2.
> +- phy-names: The identifier strings. "dp-phy" followed by index, 0 or 1.
> +  For single lane, only "dp-phy0" is required. For dual lane, both
> "dp-phy0"
> +  and "dp-phy1" are required where "dp-phy0" is the primary lane.
> +
> +- power-domains: phandle for the corresponding power domain
> +
> +- dmas: phandles for DMA channels as defined in
> +  Documentation/devicetree/bindings/dma/dma.txt.
> +- dma-names: The identifier strings are required. "gfx0" for graphics layer
> +  dma channel. "vid" followed by index (0 - 2) for video layer dma
> channels.
> +
> +Optional child node
> +
> +- The driver populates any child device node in this node. This can be
> used,
> +  for example, to populate the sound device from the DisplayPort subsystem
> +  driver.

DT bindings should describe the hardware, not the OS software. You should not 
mention drivers.

Furthermore the above paragraph doesn't seem very clear to me, and the example 
doesn't include any child node, so I'm left wondering what you meant.

> +Example:
> + zynqmp-display-subsystem@fd4a {
> + compatible = "xlnx,zynqmp-dpsub-1.7";
> + reg = <0x0 0xfd4a 0x0 0x1000>,
> +   <0x0 0xfd4aa000 0x0 0x1000>,
> +   <0x0 0xfd4ab000 0x0 0x1000>,
> +   <0x0 0xfd4ac000 0x0 0x1000>;
> + reg-names = "dp", "blend", "av_buf", "aud";

Without seeing the documentation it's a bit hard to tell, but it looks to me 
like this "subsystem" aggregates four separate IP cores that can be used 
individually. The "dp" registers in particular make me think that the 
DisplayPort transmitter is a separate IP core corresponding to PG199. If 
that's the case, I think the IP cores should be modeled as individual DT 
nodes, and connected through the OF graph bindings.

> + interrupts = <0 119 4>;
> + interrupt-parent = <>;
> +
> + clock-names = "dp_apb_clk", "dp_aud_clk", 
> "dp_live_video_in_clk";
> + clocks = <_aclk>, < 17>, <_1>;
> +
> + phys = <>, <>;
> + phy-names = "dp-phy0", "dp-phy1";
> +
> + power-domains = <_dp>;
> +
> + dma-names = "vid0", "vid1", "vid2", "gfx0";
> + dmas = <_dpdma 0>,
> +<_dpdma 1>,
> +<_dpdma 2>,
> +<_dpdma 3>;
> + };
> +};

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list

Re: [PATCH v3 7/8] drm/sun4i: Add support for plane alpha

[Chen-Yu Tsai]

On Sat, Feb 17, 2018 at 1:39 AM, Maxime Ripard
 wrote:
> Our backend supports a per-plane alpha property. Support it through our new
> helper.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 

Though, not having a graphics background, does alpha = 255 mean fully
transparent and thus can be skipped? Or no alpha at all?

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 8/8] drm/sun4i: backend: Remove ARGB spoofing

[Chen-Yu Tsai]

On Sat, Feb 17, 2018 at 1:39 AM, Maxime Ripard
 wrote:
> We've had some code for quite some time to prevent the alpha bug from
> happening on the lowest primary plane. Since we now check for this in our
> atomic_check, we can simply remove it.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/8] drm/sun4i: Remove the plane description structure

[Chen-Yu Tsai]

On Sat, Feb 17, 2018 at 1:39 AM, Maxime Ripard
 wrote:
> The plane description structure was mostly needed to differentiate the
> formats usable on the primary plane (because of its lowest position), and
> assign the pipes. Now that both are dynamically checked and assigned, we
> can remove the static definition.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/8] drm/sun4i: backend: Assign the pipes automatically

[Chen-Yu Tsai]

On Sat, Feb 17, 2018 at 1:39 AM, Maxime Ripard
 wrote:
> Since we now have a way to enforce the zpos, check for the number of alpha
> planes, the only missing part is to assign our pipe automatically instead
> of hardcoding it.
>
> The algorithm is quite simple, but requires two iterations over the list of
> planes.
>
> In the first one (which is the same one that we've had to check for alpha,
> the frontend usage, and so on), we order the planes by their zpos.
>
> We can then do a second iteration over that array by ascending zpos
> starting with the pipe 0. When and if we encounter our alpha plane, we put
> it and all the other subsequent planes in the second pipe.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Tomasz Figa]

On Thu, Feb 22, 2018 at 10:45 PM, Robin Murphy  wrote:
> [sorry, I had intended to reply sooner but clearly forgot]
>
>
> On 16/02/18 00:13, Tomasz Figa wrote:
>>
>> On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy 
>> wrote:
>>>
>>> On 15/02/18 04:17, Tomasz Figa wrote:
>>> [...]
>
>
> Could you elaborate on what kind of locking you are concerned about?
> As I explained before, the normally happening fast path would lock
> dev->power_lock only for the brief moment of incrementing the runtime
> PM usage counter.



 My bad, that's not even it.

 The atomic usage counter is incremented beforehands, without any
 locking [1] and the spinlock is acquired only for the sake of
 validating that device's runtime PM state remained valid indeed [2],
 which would be the case in the fast path of the same driver doing two
 mappings in parallel, with the master powered on (and so the SMMU,
 through device links; if master was not powered on already, powering
 on the SMMU is unavoidable anyway and it would add much more latency
 than the spinlock itself).
>>>
>>>
>>>
>>> We now have no locking at all in the map path, and only a per-domain lock
>>> around TLB sync in unmap which is unfortunately necessary for
>>> correctness;
>>> the latter isn't too terrible, since in "serious" hardware it should only
>>> be
>>> serialising a few cpus serving the same device against each other (e.g.
>>> for
>>> multiple queues on a single NIC).
>>>
>>> Putting in a global lock which serialises *all* concurrent map and unmap
>>> calls for *all* unrelated devices makes things worse. Period. Even if the
>>> lock itself were held for the minimum possible time, i.e. trivially
>>> "spin_lock(); spin_unlock()", the cost of repeatedly bouncing
>>> that
>>> one cache line around between 96 CPUs across two sockets is not
>>> negligible.
>>
>>
>> Fair enough. Note that we're in a quite interesting situation now:
>>   a) We need to have runtime PM enabled on Qualcomm SoC to have power
>> properly managed,
>>   b) We need to have lock-free map/unmap on such distributed systems,
>>   c) If runtime PM is enabled, we need to call into runtime PM from any
>> code that does hardware accesses, otherwise the IOMMU API (and so DMA
>> API and then any V4L2 driver) becomes unusable.
>>
>> I can see one more way that could potentially let us have all the
>> three. How about enabling runtime PM only on selected implementations
>> (e.g. qcom,smmu) and then having all the runtime PM calls surrounded
>> with if (pm_runtime_enabled()), which is lockless?
>
>
> Yes, that's the kind of thing I was gravitating towards - my vague thought
> was adding some flag to the smmu_domain, but pm_runtime_enabled() does look
> conceptually a lot cleaner.

Great, thanks. Looks like we're in agreement now. \o/

Vivek, does this sound reasonable to you?

Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

[Alex Deucher]

On Thu, Feb 22, 2018 at 6:43 AM, He, Roger  wrote:
>
>
> -Original Message-
> From: Koenig, Christian
> Sent: Thursday, February 22, 2018 7:28 PM
> To: He, Roger ; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] drm/ttm: check if free mem space is under the lower limit
>
> Am 22.02.2018 um 11:10 schrieb Roger He:
>> the free mem space and the lower limit both include two parts:
>> system memory and swap space.
>>
>> For the OOM triggered by TTM, that is the case as below:
>> first swap space is full of swapped out pages and soon system memory
>> also is filled up with ttm pages. and then any memory allocation
>> request will run into OOM.
>>
>> to cover two cases:
>> a. if no swap disk at all or free swap space is under swap mem
>> limit but available system mem is bigger than sys mem limit,
>> allow TTM allocation;
>>
>> b. if the available system mem is less than sys mem limit but
>> free swap space is bigger than swap mem limit, allow TTM
>> allocation.
>>
>> v2: merge two memory limit(swap and system) into one
>> v3: keep original behavior except ttm_opt_ctx->flags with
>>  TTM_OPT_FLAG_FORCE_ALLOC
>> v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
>> v5: add an attribute for lower_mem_limit
>>
>> Signed-off-by: Roger He 
>> ---
>>   drivers/gpu/drm/ttm/ttm_memory.c | 94 
>> 
>>   drivers/gpu/drm/ttm/ttm_page_alloc.c |  3 +
>>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +
>>   include/drm/ttm/ttm_memory.h |  5 ++
>>   4 files changed, 105 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>> b/drivers/gpu/drm/ttm/ttm_memory.c
>> index aa0c381..d015e39 100644
>> --- a/drivers/gpu/drm/ttm/ttm_memory.c
>> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
>> @@ -36,6 +36,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>
>>   #define TTM_MEMORY_ALLOC_RETRIES 4
>>
>> @@ -166,6 +167,52 @@ static struct kobj_type ttm_mem_zone_kobj_type = {
>>   .default_attrs = ttm_mem_zone_attrs,
>>   };
>>
>> +static struct attribute ttm_mem_global_lower_mem_limit = {
>> + .name = "lower_mem_limit",
>> + .mode = S_IRUGO | S_IWUSR
>> +};
>> +
>> +static ssize_t ttm_mem_global_show(struct kobject *kobj,
>> +  struct attribute *attr,
>> +  char *buffer)
>> +{
>> + struct ttm_mem_global *glob =
>> + container_of(kobj, struct ttm_mem_global, kobj);
>> + uint64_t val = 0;
>> +
>> + spin_lock(>lock);
>> + val = glob->lower_mem_limit;
>> + spin_unlock(>lock);
>> +
>> + return snprintf(buffer, PAGE_SIZE, "%llu\n",
>> + (unsigned long long) val << 2);
>
> What is that shift good for?
>
> Because the unit of lower_mem_limit is 4KB, so (val << 2) can get KB for 
> consistent with other parameters as below(all are showed with KB bytes.):

Might want to add a comment or use a define for the shift so others
doen't get confused in the future.

Alex

>
> static struct attribute *ttm_mem_zone_attrs[] = {
> _mem_sys,
> _mem_emer,
> _mem_max,
> _mem_swap,
> _mem_used,
> NULL
> };
>
>> +}
>> +
>> +static ssize_t ttm_mem_global_store(struct kobject *kobj,
>> +   struct attribute *attr,
>> +   const char *buffer,
>> +   size_t size)
>> +{
>> + int chars;
>> + uint64_t val64;
>> + unsigned long val;
>> + struct ttm_mem_global *glob =
>> + container_of(kobj, struct ttm_mem_global, kobj);
>> +
>> + chars = sscanf(buffer, "%lu", );
>> + if (chars == 0)
>> + return size;
>> +
>> + val64 = val;
>> + val64 >>= 2;
>
> Dito?
> Covert from KB to 4K page size here.
>
>> +
>> + spin_lock(>lock);
>> + glob->lower_mem_limit = val64;
>> + spin_unlock(>lock);
>> +
>> + return size;
>> +}
>> +
>>   static void ttm_mem_global_kobj_release(struct kobject *kobj)
>>   {
>>   struct ttm_mem_global *glob =
>> @@ -174,8 +221,20 @@ static void ttm_mem_global_kobj_release(struct kobject 
>> *kobj)
>>   kfree(glob);
>>   }
>>
>> +static struct attribute *ttm_mem_global_attrs[] = {
>> + _mem_global_lower_mem_limit,
>> + NULL
>> +};
>> +
>> +static const struct sysfs_ops ttm_mem_global_ops = {
>> + .show = _mem_global_show,
>> + .store = _mem_global_store,
>> +};
>> +
>>   static struct kobj_type ttm_mem_glob_kobj_type = {
>>   .release = _mem_global_kobj_release,
>> + .sysfs_ops = _mem_global_ops,
>> + .default_attrs = ttm_mem_global_attrs,
>>   };
>>
>>   static bool ttm_zones_above_swap_target(struct ttm_mem_global *glob,
>> @@ -375,6 +434,11 @@ int ttm_mem_global_init(struct ttm_mem_global
>> *glob)
>>
>>   si_meminfo();
>>
>> + /* lower limit of swap space and 256MB is enough */
>> + 

[PATCH] staging: vboxvideo: remove ttm_pool_* wrappers

[Christian König]

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/staging/vboxvideo/vbox_ttm.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_ttm.c 
b/drivers/staging/vboxvideo/vbox_ttm.c
index 2ea31589d773..c4b7a6b9abd5 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -213,21 +213,8 @@ static struct ttm_tt *vbox_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
 }
 
-static int vbox_ttm_tt_populate(struct ttm_tt *ttm,
-   struct ttm_operation_ctx *ctx)
-{
-   return ttm_pool_populate(ttm, ctx);
-}
-
-static void vbox_ttm_tt_unpopulate(struct ttm_tt *ttm)
-{
-   ttm_pool_unpopulate(ttm);
-}
-
 static struct ttm_bo_driver vbox_bo_driver = {
.ttm_tt_create = vbox_ttm_tt_create,
-   .ttm_tt_populate = vbox_ttm_tt_populate,
-   .ttm_tt_unpopulate = vbox_ttm_tt_unpopulate,
.init_mem_type = vbox_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = vbox_bo_evict_flags,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103371] glxinfo -l shows GL_INVALID_ENUM

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103371

Marc Dietrich  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #5 from Marc Dietrich  ---
ok, seems to be a false alarm. The (likely) valid error is only produces in
debug builds (either meson or autotools). maybe glxinfo should not ask for
these limits in compat context.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Robin Murphy]

[sorry, I had intended to reply sooner but clearly forgot]

On 16/02/18 00:13, Tomasz Figa wrote:

On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy  wrote:

On 15/02/18 04:17, Tomasz Figa wrote:
[...]


Could you elaborate on what kind of locking you are concerned about?
As I explained before, the normally happening fast path would lock
dev->power_lock only for the brief moment of incrementing the runtime
PM usage counter.



My bad, that's not even it.

The atomic usage counter is incremented beforehands, without any
locking [1] and the spinlock is acquired only for the sake of
validating that device's runtime PM state remained valid indeed [2],
which would be the case in the fast path of the same driver doing two
mappings in parallel, with the master powered on (and so the SMMU,
through device links; if master was not powered on already, powering
on the SMMU is unavoidable anyway and it would add much more latency
than the spinlock itself).



We now have no locking at all in the map path, and only a per-domain lock
around TLB sync in unmap which is unfortunately necessary for correctness;
the latter isn't too terrible, since in "serious" hardware it should only be
serialising a few cpus serving the same device against each other (e.g. for
multiple queues on a single NIC).

Putting in a global lock which serialises *all* concurrent map and unmap
calls for *all* unrelated devices makes things worse. Period. Even if the
lock itself were held for the minimum possible time, i.e. trivially
"spin_lock(); spin_unlock()", the cost of repeatedly bouncing that
one cache line around between 96 CPUs across two sockets is not negligible.


Fair enough. Note that we're in a quite interesting situation now:
  a) We need to have runtime PM enabled on Qualcomm SoC to have power
properly managed,
  b) We need to have lock-free map/unmap on such distributed systems,
  c) If runtime PM is enabled, we need to call into runtime PM from any
code that does hardware accesses, otherwise the IOMMU API (and so DMA
API and then any V4L2 driver) becomes unusable.

I can see one more way that could potentially let us have all the
three. How about enabling runtime PM only on selected implementations
(e.g. qcom,smmu) and then having all the runtime PM calls surrounded
with if (pm_runtime_enabled()), which is lockless?


Yes, that's the kind of thing I was gravitating towards - my vague 
thought was adding some flag to the smmu_domain, but 
pm_runtime_enabled() does look conceptually a lot cleaner.





[1]
http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L1028
[2]
http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L613

In any case, I can't imagine this working with V4L2 or anything else
relying on any memory management more generic than calling IOMMU API
directly from the driver, with the IOMMU device having runtime PM
enabled, but without managing the runtime PM from the IOMMU driver's
callbacks that need access to the hardware. As I mentioned before,
only the IOMMU driver knows when exactly the real hardware access
needs to be done (e.g. Rockchip/Exynos don't need to do that for
map/unmap if the power is down, but some implementations of SMMU with
TLB powered separately might need to do so).



It's worth noting that Exynos and Rockchip are relatively small
self-contained IP blocks integrated closely with the interfaces of their
relevant master devices; SMMU is an architecture, implementations of which
may be large, distributed, and have complex and wildly differing internal
topologies. As such, it's a lot harder to make hardware-specific assumptions
and/or be correct for all possible cases.

Don't get me wrong, I do ultimately agree that the IOMMU driver is the only
agent who ultimately knows what calls are going to be necessary for whatever
operation it's performing on its own hardware*; it's just that for SMMU it
needs to be implemented in a way that has zero impact on the cases where it
doesn't matter, because it's not viable to specialise that driver for any
particular IP implementation/use-case.


Still, exactly the same holds for the low power embedded use cases,
where we strive for the lowest possible power consumption, while
maintaining performance levels high as well. And so the SMMU code is
expected to also work with our use cases, such as V4L2 or DRM drivers.
Since these points don't hold for current SMMU code, I could say that
the it has been already specialized for large, distributed
implementations.


Heh, really it's specialised for ease of maintenance in terms of doing 
as little as we can get away with, but for what we have implemented, 
fast code does save CPU cycles and power on embedded systems too ;)


Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/5] drm: xlnx: Xilinx DRM KMS module

[Laurent Pinchart]

Hi Hyun,

On Thursday, 22 February 2018 04:50:42 EET Hyun Kwon wrote:
> On Wed, 2018-02-21 at 15:17:25 -0800, Laurent Pinchart wrote:
> > On Wednesday, 7 February 2018 03:36:36 EET Hyun Kwon wrote:
> >> Xilinx has various platforms for display, where users can create
> >> using multiple IPs in the programmable FPGA fabric, or where
> >> some hardened piepline is available on the chip. Furthermore,
> > 
> > s/piepline/pipeline/
> > 
> >> hardened pipeline can also interact with soft logics in FPGA.
> >> 
> >> The Xilinx DRM KMS module is to integrate multiple subdevices and
> >> to represent the entire pipeline as a single DRM device. The module
> >> includes helper (ex, framebuffer and gem helpers) and
> >> glue logic (ex, crtc interface) functions.
> >> 
> >> Signed-off-by: Hyun Kwon 
> >> Acked-by: Daniel Vetter 
> >> ---
> >> v5
> >> - Redefine xlnx_pipeline_init()
> >> v4
> >> - Fix a bug in of graph binding handling
> >> - Remove vblank callbacks from xlnx_crtc
> >> - Remove the dt binding. This module becomes more like a library.
> >> - Rephrase the commit message
> >> v3
> >> - Add Laurent as a maintainer
> >> - Fix multiple-reference on gem objects
> >> v2
> >> - Change the SPDX identifier format
> >> - Merge patches(crtc, gem, fb) into single one
> >> v2 of xlnx_drv
> >> - Rename kms to display in xlnx_drv
> >> - Replace some xlnx specific fb helper with common helpers in xlnx_drv
> >> - Don't set the commit tail callback in xlnx_drv
> >> - Support 'ports' graph binding in xlnx_drv
> >> v2 of xlnx_fb
> >> - Remove wrappers in xlnx_fb
> >> - Replace some functions with drm core helpers in xlnx_fb
> >> ---
> >> ---
> >> 
> >>  MAINTAINERS  |   9 +
> >>  drivers/gpu/drm/Kconfig  |   2 +
> >>  drivers/gpu/drm/Makefile |   1 +
> >>  drivers/gpu/drm/xlnx/Kconfig |  12 +
> >>  drivers/gpu/drm/xlnx/Makefile|   2 +
> >>  drivers/gpu/drm/xlnx/xlnx_crtc.c | 177 ++
> >>  drivers/gpu/drm/xlnx/xlnx_crtc.h |  70 ++
> >>  drivers/gpu/drm/xlnx/xlnx_drv.c  | 501 +
> >>  drivers/gpu/drm/xlnx/xlnx_drv.h  |  33 +++
> >>  drivers/gpu/drm/xlnx/xlnx_fb.c   | 298 +++
> >>  drivers/gpu/drm/xlnx/xlnx_fb.h   |  33 +++
> >>  drivers/gpu/drm/xlnx/xlnx_gem.c  |  47 
> >>  drivers/gpu/drm/xlnx/xlnx_gem.h  |  26 ++
> >>  13 files changed, 1211 insertions(+)
> >>  create mode 100644 drivers/gpu/drm/xlnx/Kconfig
> >>  create mode 100644 drivers/gpu/drm/xlnx/Makefile
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c
> >>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h

[snip]

> >> diff --git a/drivers/gpu/drm/xlnx/xlnx_crtc.c
> >> b/drivers/gpu/drm/xlnx/xlnx_crtc.c new file mode 100644
> >> index 000..de83905
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c

[snip]

> >> +uint32_t xlnx_crtc_helper_get_format(struct xlnx_crtc_helper *helper)
> > 
> > You can use the u32 type within the kernel.
> > 
> >> +{
> >> +  struct xlnx_crtc *crtc;
> >> +  u32 format = 0, tmp;
> >> +
> >> +  list_for_each_entry(crtc, >xlnx_crtcs, list) {
> >> +  if (crtc->get_format) {
> >> +  tmp = crtc->get_format(crtc);
> >> +  if (format && format != tmp)
> >> +  return 0;
> >> +  format = tmp;
> > 
> > Same comments regarding the tmp variable and the list locking issue.
> > 
> >> +  }
> >> +  }
> >> +
> >> +  return format;
> > 
> > Does this mean that your CRTCs support a single format each only ?

Does it ? :-)
 
> >> +}

[snip]

> >> diff --git a/drivers/gpu/drm/xlnx/xlnx_drv.c
> >> b/drivers/gpu/drm/xlnx/xlnx_drv.c new file mode 100644
> >> index 000..8f0e357
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/xlnx/xlnx_drv.c

[snip]

> >> +static int xlnx_of_component_probe(struct device *master_dev,
> >> + int (*compare_of)(struct device *, void *),
> >> + const struct component_master_ops *m_ops)
> > 
> > As there's a single user of this function, do you need to pass compare_of
> > as a parameter ? Couldn't you move xlnx_compare_of() above and use it
> > directly ?
> > 
> >> +{
> >> +  struct device *dev = master_dev->parent;
> >> +  struct device_node *ep, *port, *remote, *parent;
> >> +  struct component_match *match = NULL;
> >> +  int i;
> > 
> > i is never negative, you can make it unsigned.
> > 
> >> +  if (!dev->of_node)
> >> +  return -EINVAL;
> >> +
> >> +  component_match_add(master_dev, , compare_of, dev->of_node);
> >> +
> >> +  for (i = 0; ; i++) {
> >> +  

Re: [Freedreno] [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Rob Clark]

On Thu, Feb 22, 2018 at 3:13 AM, Tomasz Figa  wrote:
> On Fri, Feb 16, 2018 at 9:13 AM, Tomasz Figa  wrote:
>> On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy  wrote:
>>> On 15/02/18 04:17, Tomasz Figa wrote:
>>> [...]
>
> Could you elaborate on what kind of locking you are concerned about?
> As I explained before, the normally happening fast path would lock
> dev->power_lock only for the brief moment of incrementing the runtime
> PM usage counter.


 My bad, that's not even it.

 The atomic usage counter is incremented beforehands, without any
 locking [1] and the spinlock is acquired only for the sake of
 validating that device's runtime PM state remained valid indeed [2],
 which would be the case in the fast path of the same driver doing two
 mappings in parallel, with the master powered on (and so the SMMU,
 through device links; if master was not powered on already, powering
 on the SMMU is unavoidable anyway and it would add much more latency
 than the spinlock itself).
>>>
>>>
>>> We now have no locking at all in the map path, and only a per-domain lock
>>> around TLB sync in unmap which is unfortunately necessary for correctness;
>>> the latter isn't too terrible, since in "serious" hardware it should only be
>>> serialising a few cpus serving the same device against each other (e.g. for
>>> multiple queues on a single NIC).
>>>
>>> Putting in a global lock which serialises *all* concurrent map and unmap
>>> calls for *all* unrelated devices makes things worse. Period. Even if the
>>> lock itself were held for the minimum possible time, i.e. trivially
>>> "spin_lock(); spin_unlock()", the cost of repeatedly bouncing that
>>> one cache line around between 96 CPUs across two sockets is not negligible.
>>
>> Fair enough. Note that we're in a quite interesting situation now:
>>  a) We need to have runtime PM enabled on Qualcomm SoC to have power
>> properly managed,
>>  b) We need to have lock-free map/unmap on such distributed systems,
>>  c) If runtime PM is enabled, we need to call into runtime PM from any
>> code that does hardware accesses, otherwise the IOMMU API (and so DMA
>> API and then any V4L2 driver) becomes unusable.
>>
>> I can see one more way that could potentially let us have all the
>> three. How about enabling runtime PM only on selected implementations
>> (e.g. qcom,smmu) and then having all the runtime PM calls surrounded
>> with if (pm_runtime_enabled()), which is lockless?
>>
>
> Sorry for pinging, but any opinion on this kind of approach?
>

It is ok by me, for whatever that is worth

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 4/4] drm: rcar-du: Convert LVDS encoder code to bridge driver

[Laurent Pinchart]

The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched live to move to the new bindings.

Signed-off-by: Laurent Pinchart 
---
Changes since v1:

- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig   |   4 +-
 drivers/gpu/drm/rcar-du/Makefile  |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  93 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  24 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |  64 
 drivers/gpu/drm/rcar-du/rcar_lvds.c   | 524 ++
 12 files changed, 561 insertions(+), 616 deletions(-)
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 3f83352a7313..edde8d4b87a3 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -19,8 +19,8 @@ config DRM_RCAR_DW_HDMI
  Enable support for R-Car Gen3 internal HDMI encoder.
 
 config DRM_RCAR_LVDS
-   bool "R-Car DU LVDS Encoder Support"
-   depends on DRM_RCAR_DU
+   tristate "R-Car DU LVDS Encoder Support"
+   depends on DRM && DRM_BRIDGE && OF
select DRM_PANEL
select OF_FLATTREE
select OF_OVERLAY
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 86b337b4be5d..3e58ed93d5b1 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,10 +4,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_encoder.o \
 rcar_du_group.o \
 rcar_du_kms.o \
-rcar_du_lvdscon.o \
 rcar_du_plane.o
 
-rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
   rcar_du_of_lvds_r8a7790.dtb.o \
   rcar_du_of_lvds_r8a7791.dtb.o \
@@ -18,3 +16,4 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP)+= rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
 obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
+obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 6e02c762a557..06a3fbdd728a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -29,6 +29,7 @@
 
 #include "rcar_du_drv.h"
 #include "rcar_du_kms.h"
+#include "rcar_du_of.h"
 #include "rcar_du_regs.h"
 
 /* 
-
@@ -74,7 +75,6 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info 
= {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7779_info = {
@@ -95,14 +95,13 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
-   .quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B,
.num_crtcs = 3,
.routes = {
/*
@@ -164,7 +163,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7792_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -186,7 +184,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7794_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -434,7 +431,19 @@ static struct platform_driver rcar_du_platform_driver = {
},
 };
 
-module_platform_driver(rcar_du_platform_driver);
+static int __init rcar_du_init(void)
+{
+   

[PATCH v6 1/4] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
Changes since v1:

- Move the SoC name before the IP name in compatible strings
- Rename parallel input to parallel RGB input
- Fixed "renesas,r8a7743-lvds" description
- Document the resets property
- Fixed typo
---
 .../bindings/display/bridge/renesas,lvds.txt   | 56 ++
 MAINTAINERS|  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
new file mode 100644
index ..2b19ce51ec07
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -0,0 +1,56 @@
+Renesas R-Car LVDS Encoder
+==
+
+These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
+Gen2, R-Car Gen3 and RZ/G SoCs.
+
+Required properties:
+
+- compatible : Shall contain one of
+  - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
+  - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
+  - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
+  - "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible LVDS encoders
+  - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
+  - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
+
+- reg: Base address and length for the memory-mapped registers
+- clocks: A phandle + clock-specifier pair for the functional clock
+- resets: A phandle + reset specifier for the module reset
+
+Required nodes:
+
+The LVDS encoder has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 corresponds to the parallel RGB input
+- Video port 1 corresponds to the LVDS output
+
+Each port shall have a single endpoint.
+
+
+Example:
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7790-lvds";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   resets = < 726>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2afba909724c..13c8ec11135a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4744,6 +4744,7 @@ F:drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
 F: include/linux/platform_data/shmob_drm.h
 F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt
 
 DRM DRIVERS FOR ROCKCHIP
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 2/4] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
Changes since v1:

- Remove the LVDS reg range from the example
- Remove the reg-names property
---
 .../devicetree/bindings/display/renesas,du.txt | 31 --
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index cd48aba3bc8c..e79cf9b0ad38 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -14,12 +14,7 @@ Required Properties:
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
 - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
 
-  - reg: A list of base address and length of each memory resource, one for
-each entry in the reg-names property.
-  - reg-names: Name of the memory resources. The DU requires one memory
-resource for the DU core (named "du") and one memory resource for each
-LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical
-index).
+  - reg: the memory-mapped I/O registers base address and length
 
   - interrupt-parent: phandle of the parent interrupt controller.
   - interrupts: Interrupt specifiers for the DU interrupts.
@@ -29,14 +24,13 @@ Required Properties:
   - clock-names: Name of the clocks. This property is model-dependent.
 - R8A7779 uses a single functional clock. The clock doesn't need to be
   named.
-- All other DU instances use one functional clock per channel and one
-  clock per LVDS encoder (if available). The functional clocks must be
-  named "du.x" with "x" being the channel numerical index. The LVDS clocks
-  must be named "lvds.x" with "x" being the LVDS encoder numerical index.
-- In addition to the functional and encoder clocks, all DU versions also
-  support externally supplied pixel clocks. Those clocks are optional.
-  When supplied they must be named "dclkin.x" with "x" being the input
-  clock numerical index.
+- All other DU instances use one functional clock per channel The
+  functional clocks must be named "du.x" with "x" being the channel
+  numerical index.
+- In addition to the functional clocks, all DU versions also support
+  externally supplied pixel clocks. Those clocks are optional. When
+  supplied they must be named "dclkin.x" with "x" being the input clock
+  numerical index.
 
   - vsps: A list of phandle and channel index tuples to the VSPs that handle
 the memory interfaces for the DU channels. The phandle identifies the VSP
@@ -69,9 +63,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
 
du: display@feb0 {
compatible = "renesas,du-r8a7795";
-   reg = <0 0xfeb0 0 0x8>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x8>;
interrupts = ,
 ,
 ,
@@ -79,9 +71,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0>, < 0>, < 0>, < 1>;
 
ports {
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198885] New: amdgpu.dc=1 on CIK (R4 Mullins APU) brightness impossible to change. by Fn or "echo".

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198885

Bug ID: 198885
   Summary: amdgpu.dc=1 on CIK (R4 Mullins APU) brightness
impossible to change. by Fn or "echo".
   Product: Drivers
   Version: 2.5
Kernel Version: 4.15.4
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: sop...@gmail.com
Regression: No

Created attachment 274359
  --> https://bugzilla.kernel.org/attachment.cgi?id=274359=edit
dmesg with "amdgpu.dc=1"

I am using gentoo ~amd64, kernel 4.15.4, amdgpu with amdgpu.dc=1 on CIK A6 APU
- R4 Mullins.

There is no possibility to change brightness level both with Fn keys or
directly by an "echo" command, even as root when "amdgpu.dc=1" is set:

ls -l /sys/class/backlight/amdgpu_bl0/
razem 0
-r--r--r-- 1 root root 4096 02-22 13:41 actual_brightness
-rw-r--r-- 1 root root 4096 02-22 13:41 bl_power
-rw-r--r-- 1 root root 4096 02-22 13:41 brightness
lrwxrwxrwx 1 root root0 02-22 13:41 device -> ../../../:00:01.0
-r--r--r-- 1 root root 4096 02-22 13:40 max_brightness
drwxr-xr-x 2 root root0 02-22 13:41 power
lrwxrwxrwx 1 root root0 02-22 13:40 subsystem ->
../../../../../class/backlight
-r--r--r-- 1 root root 4096 02-22 13:40 type
-rw-r--r-- 1 root root 4096 02-22 13:39 uevent


"/sys/class/backlight/amdgpu_bl0 # echo 22 > actual_brightness
bash: actual_brightness: permission denied"

and 

"/sys/class/backlight/amdgpu_bl0 # echo 128 > brightness
bash: echo: błąd zapisu: Bad argument"

Without "amdgpu.dc=1" in kernel command line changing brightness level is
working as expected, both Fn keys, and echoing directly to a file.

I know that there are plans enabling amdgpu.dc by default, so impossibility to
change brightness level IMHO is a big "no go".

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.

Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.

Signed-off-by: Laurent Pinchart 
---
Changes since v5:

- Use a private copy of rcar_du_of_changeset_add_property()

Changes since v3:

- Use the OF changeset API
- Use of_graph_get_endpoint_by_regs()
- Replace hardcoded constants by sizeof()

Changes since v2:

- Update the SPDX headers to use C-style comments in header files
- Removed the manually created __local_fixups__ node
- Perform manual fixups on live DT instead of overlay

Changes since v1:

- Select OF_FLATTREE
- Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
- Pass void begin and end pointers to rcar_du_of_get_overlay()
- Use of_get_parent() instead of accessing the parent pointer directly
- Find the LVDS endpoints nodes based on the LVDS node instead of the
  root of the overlay
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig|   2 +
 drivers/gpu/drm/rcar-du/Makefile   |   7 +-
 drivers/gpu/drm/rcar-du/rcar_du_of.c   | 342 +
 drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 +
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 
 9 files changed, 661 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 5d0b4b7119af..3f83352a7313 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -22,6 +22,8 @@ config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
select DRM_PANEL
+   select OF_FLATTREE
+   select OF_OVERLAY
help
  Enable support for the R-Car Display Unit embedded LVDS encoders.
 
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 0cf5c11030e8..86b337b4be5d 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -8,7 +8,12 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_plane.o
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
-
+rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
+  rcar_du_of_lvds_r8a7790.dtb.o \
+  rcar_du_of_lvds_r8a7791.dtb.o \
+  rcar_du_of_lvds_r8a7793.dtb.o \
+  rcar_du_of_lvds_r8a7795.dtb.o \
+  rcar_du_of_lvds_r8a7796.dtb.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
new file mode 100644
index ..ac442ddfed16
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rcar_du_of.c - Legacy DT bindings compatibility
+ *
+ * Copyright (C) 2018 Laurent Pinchart 
+ *
+ * Based on work from Jyri Sarha 
+ * Copyright (C) 2015 Texas Instruments
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rcar_du_crtc.h"
+#include "rcar_du_drv.h"
+
+/* 
-
+ * Generic Overlay Handling
+ */
+
+struct rcar_du_of_overlay {
+   const char *compatible;
+   void *begin;
+   void *end;
+};
+
+#define RCAR_DU_OF_DTB(type, soc)  \
+   extern char __dtb_rcar_du_of_##type##_##soc##_begin[];  \
+   extern char __dtb_rcar_du_of_##type##_##soc##_end[]
+
+#define RCAR_DU_OF_OVERLAY(type, soc)  \
+   {   \
+   .compatible = 

[PATCH v6 0/4] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hello,

This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.

To fix the, patches 1/4 and 2/4 define new DT bindings for the LVDS
encoders, and deprecate their description inside the DU bindings. To retain
backward compatibility with existing DT, patch 3/4 then patch the device tree
at runtime to convert the legacy bindings to the new ones.

With the DT side addressed, patch 4/4 converts the LVDS support code to a
separate bridge driver.

I decided to go for live DT patching in patch 3/4 because implementing
support for both the legacy and new bindings in the driver would have been
very intrusive, and prevented further cleanups. This version relies more
heavily on overlays to avoid touching the internals of the OF core compared to
v2, even if manual fixes to the device tree are still needed.

As all the patches but the last one have been acked, I plan to send a pull
request by the end of the week if no new issue is discovered.

Compared to v5, I've dropped the OF changeset halpers series as Frank raised
concerns about hidding it in the middle of a driver patch series. I've thus
copied the implementation of of_changeset_add_property_copy() in the driver to
avoid blocking this series. The function arguments are identical, so when the
OF changeset helpers will land it will be very easy to drop the private copy
and use the of_changeset_add_property_copy() helper.

Compared to v4, the patch "of: changeset: Add of_changeset_node_move method"
has been dropped as it's not needed. The patches that update the DT sources to
the new DU and LVDS bindings have been dropped as well to avoid spamming the
lists as they depend on the driver changes going in first to avoid
regressions and haven't been changed.

Compared to v3, this series uses the OF changeset API to update properties
instead of accessing the internals of the property structure. This removes the
local implementation of functions to look up nodes by path and update
properties. In order to do this, I pulled in Pantelis' patch series titled
"[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's request, and
rebased it while taking two small review comments into account.

Rob, I'd like this series to be merged in v4.17. As the changeset helpers are
now a dependency, I'd need you to merge them early (ideally on top of
v4.16-rc1) and provide a stable branch, or get your ack to merge them through
Dave's tree if they don't conflict with what you have and will queue for
v4.17.

This version also drops the small fix to the Porter board device tree that has
been queued for v4.17 already.

Compared to v2, the biggest change is in patch 3/4. Following Rob's and
Frank's reviews it was clear that modifying the unflattened DT structure of
the overlay before applying it wasn't popular. I have thus decided to use one
overlay source per SoC to move as much of the DT changes to the overlay as
possible, and only perform manual modifications (that are still needed as some
of the information is board-specific) on the system DT after applying the
overlay. As a result the overlay is parsed and applied without being modified.

Compared to v1, this series update the r8a7792 and r8a7794 device tree sources
and incorporate review feedback as described by the changelogs of individual
patches.

Laurent Pinchart (4):
  dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
  dt-bindings: display: renesas: Deprecate LVDS support in the DU
bindings
  drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
  drm: rcar-du: Convert LVDS encoder code to bridge driver

 .../bindings/display/bridge/renesas,lvds.txt   |  56 +++
 .../devicetree/bindings/display/renesas,du.txt |  31 +-
 MAINTAINERS|   1 +
 drivers/gpu/drm/rcar-du/Kconfig|   6 +-
 drivers/gpu/drm/rcar-du/Makefile   |  10 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 175 +--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  93 
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h  |  24 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c  | 238 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h  |  64 ---
 drivers/gpu/drm/rcar-du/rcar_du_of.c   | 342 ++
 drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 +
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 +++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 +++
 

Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

[Christian König]

Am 22.02.2018 um 12:43 schrieb He, Roger:


-Original Message-
From: Koenig, Christian
Sent: Thursday, February 22, 2018 7:28 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

Am 22.02.2018 um 11:10 schrieb Roger He:

the free mem space and the lower limit both include two parts:
system memory and swap space.

For the OOM triggered by TTM, that is the case as below:
first swap space is full of swapped out pages and soon system memory
also is filled up with ttm pages. and then any memory allocation
request will run into OOM.

to cover two cases:
a. if no swap disk at all or free swap space is under swap mem
 limit but available system mem is bigger than sys mem limit,
 allow TTM allocation;

b. if the available system mem is less than sys mem limit but
 free swap space is bigger than swap mem limit, allow TTM
 allocation.

v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
  TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
v5: add an attribute for lower_mem_limit

Signed-off-by: Roger He 
---
   drivers/gpu/drm/ttm/ttm_memory.c | 94 

   drivers/gpu/drm/ttm/ttm_page_alloc.c |  3 +
   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +
   include/drm/ttm/ttm_memory.h |  5 ++
   4 files changed, 105 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..d015e39 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
   #include 
   #include 
   #include 
+#include 
   
   #define TTM_MEMORY_ALLOC_RETRIES 4
   
@@ -166,6 +167,52 @@ static struct kobj_type ttm_mem_zone_kobj_type = {

.default_attrs = ttm_mem_zone_attrs,
   };
   
+static struct attribute ttm_mem_global_lower_mem_limit = {

+   .name = "lower_mem_limit",
+   .mode = S_IRUGO | S_IWUSR
+};
+
+static ssize_t ttm_mem_global_show(struct kobject *kobj,
+struct attribute *attr,
+char *buffer)
+{
+   struct ttm_mem_global *glob =
+   container_of(kobj, struct ttm_mem_global, kobj);
+   uint64_t val = 0;
+
+   spin_lock(>lock);
+   val = glob->lower_mem_limit;
+   spin_unlock(>lock);
+
+   return snprintf(buffer, PAGE_SIZE, "%llu\n",
+   (unsigned long long) val << 2);

What is that shift good for?

Because the unit of lower_mem_limit is 4KB, so (val << 2) can get KB for 
consistent with other parameters as below(all are showed with KB bytes.):


Ok that makes sense.



static struct attribute *ttm_mem_zone_attrs[] = {
_mem_sys,
_mem_emer,
_mem_max,
_mem_swap,
_mem_used,
NULL
};
  

+}
+
+static ssize_t ttm_mem_global_store(struct kobject *kobj,
+ struct attribute *attr,
+ const char *buffer,
+ size_t size)
+{
+   int chars;
+   uint64_t val64;
+   unsigned long val;
+   struct ttm_mem_global *glob =
+   container_of(kobj, struct ttm_mem_global, kobj);
+
+   chars = sscanf(buffer, "%lu", );
+   if (chars == 0)
+   return size;
+
+   val64 = val;
+   val64 >>= 2;

Dito?
Covert from KB to 4K page size here.


+
+   spin_lock(>lock);
+   glob->lower_mem_limit = val64;
+   spin_unlock(>lock);
+
+   return size;
+}
+
   static void ttm_mem_global_kobj_release(struct kobject *kobj)
   {
struct ttm_mem_global *glob =
@@ -174,8 +221,20 @@ static void ttm_mem_global_kobj_release(struct kobject 
*kobj)
kfree(glob);
   }
   
+static struct attribute *ttm_mem_global_attrs[] = {

+   _mem_global_lower_mem_limit,
+   NULL
+};
+
+static const struct sysfs_ops ttm_mem_global_ops = {
+   .show = _mem_global_show,
+   .store = _mem_global_store,
+};
+
   static struct kobj_type ttm_mem_glob_kobj_type = {
.release = _mem_global_kobj_release,
+   .sysfs_ops = _mem_global_ops,
+   .default_attrs = ttm_mem_global_attrs,
   };
   
   static bool ttm_zones_above_swap_target(struct ttm_mem_global *glob,

@@ -375,6 +434,11 @@ int ttm_mem_global_init(struct ttm_mem_global
*glob)
   
   	si_meminfo();
   
+	/* lower limit of swap space and 256MB is enough */

+   glob->lower_mem_limit = 256 << 8;
+   /* lower limit of ram and keep consistent with each zone->emer_mem */
+   glob->lower_mem_limit += si.totalram >> 2;
+

Mhm, I fear we need to set this to zero by default.

Do you mean:  glob->lower_mem_limit = 0  ?
I don't get your point here. Then how amdgpu set it with above value to prevent 
OOM?


We can't activate that by default because most use cases 

[Bug 103371] glxinfo -l shows GL_INVALID_ENUM

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103371

--- Comment #4 from Marc Dietrich  ---
happens only in compat context - digging deeper ...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Update Boris Brezillon email address

[Boris Brezillon]

On Fri, 16 Feb 2018 11:44:49 +0100
Boris Brezillon  wrote:

> Free Electrons is now Bootlin.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Note that I'm planning to take this patch through the MTD tree.

Applied to the nand/next branch of the MTD tree.

> ---
>  .mailmap|  7 ---
>  MAINTAINERS | 10 +-
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/.mailmap b/.mailmap
> index e18cab73e209..50c1d6bf36b2 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -33,9 +33,10 @@ Axel Lin 
>  Ben Gardner 
>  Ben M Cahill 
>  Björn Steinbrink 
> -Boris Brezillon 
> -Boris Brezillon  
> 
> -Boris Brezillon  
> 
> +Boris Brezillon 
> +Boris Brezillon  
> 
> +Boris Brezillon  
> +Boris Brezillon  
>  Brian Avery 
>  Brian King 
>  Christoph Hellwig 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 34b2e9ed6d3d..38fcbabbc55b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1232,7 +1232,7 @@ F:  arch/arm/boot/dts/aspeed-*
>  F:   drivers/*/*aspeed*
>  
>  ARM/ATMEL AT91 Clock Support
> -M:   Boris Brezillon 
> +M:   Boris Brezillon 
>  S:   Maintained
>  F:   drivers/clk/at91
>  
> @@ -4644,7 +4644,7 @@ F:  Documentation/gpu/meson.rst
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
>  
>  DRM DRIVERS FOR ATMEL HLCDC
> -M:   Boris Brezillon 
> +M:   Boris Brezillon 
>  L:   dri-devel@lists.freedesktop.org
>  S:   Supported
>  F:   drivers/gpu/drm/atmel-hlcdc/
> @@ -8412,7 +8412,7 @@ F:  include/uapi/drm/armada_drm.h
>  F:   Documentation/devicetree/bindings/display/armada/
>  
>  MARVELL CRYPTO DRIVER
> -M:   Boris Brezillon 
> +M:   Boris Brezillon 
>  M:   Arnaud Ebalard 
>  F:   drivers/crypto/marvell/
>  S:   Maintained
> @@ -9034,7 +9034,7 @@ F:  mm/
>  MEMORY TECHNOLOGY DEVICES (MTD)
>  M:   David Woodhouse 
>  M:   Brian Norris 
> -M:   Boris Brezillon 
> +M:   Boris Brezillon 
>  M:   Marek Vasut 
>  M:   Richard Weinberger 
>  M:   Cyrille Pitchen 
> @@ -9452,7 +9452,7 @@ S:  Supported
>  F:   drivers/net/ethernet/myricom/myri10ge/
>  
>  NAND FLASH SUBSYSTEM
> -M:   Boris Brezillon 
> +M:   Boris Brezillon 
>  R:   Richard Weinberger 
>  L:   linux-...@lists.infradead.org
>  W:   http://www.linux-mtd.infradead.org/



-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Daniel Thompson]

On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
> were adapted to this change.
> 
> Signed-off-by: Claudiu Beznea 
> ---
>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>  drivers/bus/ts-nbus.c|  2 +-
>  drivers/clk/clk-pwm.c|  3 ++-
>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>  drivers/hwmon/pwm-fan.c  |  2 +-
>  drivers/input/misc/max77693-haptic.c |  2 +-
>  drivers/input/misc/max8997_haptic.c  |  6 +-
>  drivers/leds/leds-pwm.c  |  5 -
>  drivers/media/rc/ir-rx51.c   |  5 -
>  drivers/media/rc/pwm-ir-tx.c |  5 -
>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>  drivers/video/backlight/lp8788_bl.c  |  5 -
>  drivers/video/backlight/pwm_bl.c | 11 +--
>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>  include/linux/pwm.h  |  6 --
>  16 files changed, 70 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/video/backlight/lm3630a_bl.c 
> b/drivers/video/backlight/lm3630a_bl.c
> index 2030a6b77a09..696fa25dafd2 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip *pchip, 
> int br, int br_max)
>  {
>   unsigned int period = pchip->pdata->pwm_period;
>   unsigned int duty = br * period / br_max;
> + struct pwm_caps caps = { };
>  
> - pwm_config(pchip->pwmd, duty, period);
> + pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, );
> + pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));

Well... I admit I've only really looked at the patches that impact 
backlight but dispersing this really odd looking bit twiddling 
throughout the kernel doesn't strike me a great API design.

IMHO callers should not be required to find the first set bit in
some specially crafted set of capability bits simply to get sane 
default behaviour.


Daniel.




>   if (duty)
>   pwm_enable(pchip->pwmd);
>   else
> diff --git a/drivers/video/backlight/lp855x_bl.c 
> b/drivers/video/backlight/lp855x_bl.c
> index 939f057836e1..3d274c604862 100644
> --- a/drivers/video/backlight/lp855x_bl.c
> +++ b/drivers/video/backlight/lp855x_bl.c
> @@ -240,6 +240,7 @@ static void lp855x_pwm_ctrl(struct lp855x *lp, int br, 
> int max_br)
>   unsigned int period = lp->pdata->period_ns;
>   unsigned int duty = br * period / max_br;
>   struct pwm_device *pwm;
> + struct pwm_caps caps = { };
>  
>   /* request pwm device with the consumer name */
>   if (!lp->pwm) {
> @@ -256,7 +257,8 @@ static void lp855x_pwm_ctrl(struct lp855x *lp, int br, 
> int max_br)
>   pwm_apply_args(pwm);
>   }
>  
> - pwm_config(lp->pwm, duty, period);
> + pwm_get_caps(lp->pwm->chip, lp->pwm, );
> + pwm_config(lp->pwm, duty, period, BIT(ffs(caps.modes) - 1));
>   if (duty)
>   pwm_enable(lp->pwm);
>   else
> diff --git a/drivers/video/backlight/lp8788_bl.c 
> b/drivers/video/backlight/lp8788_bl.c
> index cf869ec90cce..06de3163650d 100644
> --- a/drivers/video/backlight/lp8788_bl.c
> +++ b/drivers/video/backlight/lp8788_bl.c
> @@ -128,6 +128,7 @@ static void lp8788_pwm_ctrl(struct lp8788_bl *bl, int br, 
> int max_br)
>   unsigned int duty;
>   struct device *dev;
>   struct pwm_device *pwm;
> + struct pwm_caps caps = { };
>  
>   if (!bl->pdata)
>   return;
> @@ -153,7 +154,9 @@ static void lp8788_pwm_ctrl(struct lp8788_bl *bl, int br, 
> int max_br)
>   pwm_apply_args(pwm);
>   }
>  
> - pwm_config(bl->pwm, duty, period);
> + pwm_get_caps(bl->pwm->chip, bl->pwm, );
> +
> + pwm_config(bl->pwm, duty, period, BIT(ffs(caps.modes) - 1));
>   if (duty)
>   pwm_enable(bl->pwm);
>   else
> diff --git a/drivers/video/backlight/pwm_bl.c 
> b/drivers/video/backlight/pwm_bl.c
> index 1c2289ddd555..706a9ab053a7 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -63,10 +63,14 @@ static void pwm_backlight_power_on(struct pwm_bl_data 
> *pb, int brightness)
>  
>  static void pwm_backlight_power_off(struct pwm_bl_data *pb)
>  {
> + struct pwm_caps caps = { };
> +
>   if (!pb->enabled)
>   return;
>  
> - pwm_config(pb->pwm, 0, pb->period);
> + pwm_get_caps(pb->pwm->chip, pb->pwm, );
> +
> + pwm_config(pb->pwm, 0, pb->period, BIT(ffs(caps.modes) - 1));
>   pwm_disable(pb->pwm);
>  
>   if (pb->enable_gpio)
> @@ -96,6 +100,7 @@ static int pwm_backlight_update_status(struct 
> backlight_device *bl)
>  {
>   struct pwm_bl_data *pb = bl_get_data(bl);
>   int brightness = bl->props.brightness;
> + struct pwm_caps caps = { };
>   int duty_cycle;
>  
>   if 

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

[Stefan Schake]

Hey Robert,

On Thu, Feb 22, 2018 at 11:04 AM, Robert Foss  wrote:
> Hey Stefan,
>
> On 02/22/2018 04:54 AM, Stefan Schake wrote:
>>
>> Android assumes an implicit black background layer is always present
>> behind all layers it specifies for composition. drm_hwcomposer currently
>> punts responsibility for this to the kernel/DRM platform and puts layers
>> with per-pixel alpha content on the primary plane when requested.
>
>
> I wasn't aware of this assumption, but given that it is the case,
> the patch looks like a good fix for the problem.
>
> Unfortunately I don't have a hardware platform up and running to test the
> patch with at the moment.
>

HWC1 has this ominous comment:

* IMPORTANT NOTE: There is an implicit layer containing opaque black
* pixels behind all the layers in the list. It is the responsibility of
* the hwcomposer module to make sure black pixels are output (or blended
* from).

It's not repeated in the HWC2 docs, but I think the assumption carried over
given that Android prefers all things RGBA. Admittedly it's rare that you
don't have a full-size opaque layer in the composition like a background
picture, so the cases where this causes corrupted rendering on VC4 are limited
to some time during boot after the animation finishes but the launcher isn't
up yet.

Thanks,
Stefan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] ipu-v3 fixes and grayscale support

[Philipp Zabel]

Hi Dave,

please consider merging this tag, which reduces code size a bit by
making constant interrupt register tables static, fixes a device node
leak in the PRE/PRG drivers' phandle lookups, and adds some preparations
for grayscale capture support in the imx-media driver.

regards
Philipp

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the Git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2018-02-22

for you to fetch changes up to 50b0f0aee839b5a9995fe7964a678634f75a0518:

  gpu: ipu-csi: add 10/12-bit grayscale support to mbus_code_to_bus_cfg 
(2018-02-19 15:13:05 +0100)


drm/imx: ipu-v3 fixups and grayscale support

- Make const interrupt register arrays static, reduces object size.
- Fix device_node leaks in PRE/PRG phandle lookup functions.
- Add 8-bit and 16-bit grayscale buffer support to ipu_cpmem_set_image,
- add 10-bit and 12-bit grayscale media bus support to ipu-csi,
  to be used by the imx-media driver.


Colin Ian King (1):
  gpu: ipu-v3: make const arrays int_reg static, shrinks object size

Jan Luebbe (1):
  gpu: ipu-csi: add 10/12-bit grayscale support to mbus_code_to_bus_cfg

Philipp Zabel (2):
  gpu: ipu-cpmem: add 8-bit grayscale support to ipu_cpmem_set_image
  gpu: ipu-cpmem: add 16-bit grayscale support to ipu_cpmem_set_image

Tobias Jordan (2):
  gpu: ipu-v3: pre: fix device node leak in ipu_pre_lookup_by_phandle
  gpu: ipu-v3: prg: fix device node leak in ipu_prg_lookup_by_phandle

 drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
 drivers/gpu/ipu-v3/ipu-cpmem.c  | 2 ++
 drivers/gpu/ipu-v3/ipu-csi.c| 2 ++
 drivers/gpu/ipu-v3/ipu-pre.c| 3 +++
 drivers/gpu/ipu-v3/ipu-prg.c| 3 +++
 5 files changed, 12 insertions(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/amd: Remove inclusion of non-existing include directories

[Corentin Labbe]

This patch fix the following build warnings:
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o
cc1: warning: ../display/: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../display/include: No such file or directory 
[-Wmissing-include-dirs]
  CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
cc1: warning: ../display/: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../display/include: No such file or directory 
[-Wmissing-include-dirs]
[...]
This warning is shown for each file in amdgpu directory, so it spams a lot.

Signed-off-by: Corentin Labbe 
---
 drivers/gpu/drm/amd/display/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Makefile 
b/drivers/gpu/drm/amd/display/Makefile
index c27c81cdeed3..22c72dffdf98 100644
--- a/drivers/gpu/drm/amd/display/Makefile
+++ b/drivers/gpu/drm/amd/display/Makefile
@@ -26,8 +26,6 @@
 
 AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
 
-subdir-ccflags-y += -I$(AMDDALPATH)/ -I$(AMDDALPATH)/include
-
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
 subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/modules/inc
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/amd: remove inclusion of non-existing scheduler directory

[Corentin Labbe]

The scheduler directory was removed via commit 1b1f42d8fde4 ("drm: move 
amd_gpu_scheduler into common location")
Remove it from include path.

Signed-off-by: Corentin Labbe 
---
 drivers/gpu/drm/amd/amdgpu/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index d6e5b7273853..8408aeeaf6c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -30,7 +30,6 @@ FULL_AMD_DISPLAY_PATH = 
$(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
 ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \
-I$(FULL_AMD_PATH)/include \
-I$(FULL_AMD_PATH)/amdgpu \
-   -I$(FULL_AMD_PATH)/scheduler \
-I$(FULL_AMD_PATH)/powerplay/inc \
-I$(FULL_AMD_PATH)/acp/include \
-I$(FULL_AMD_DISPLAY_PATH) \
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: fix drm_get_max_iomem type mismatch

[Arnd Bergmann]

When comparing two variables with min()/max(), they should be the same type:

drivers/gpu/drm/drm_memory.c: In function 'drm_get_max_iomem':
include/linux/kernel.h:821:16: error: comparison of distinct pointer types 
lacks a cast [-Werror]
  (void) ( == );

This makes the local variable in drm_get_max_iomem make the type
from resource->end.

Fixes: 82626363a217 ("drm: add func to get max iomem address v2")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/drm_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index 7ca500b8c399..3c54044214db 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -153,7 +153,7 @@ EXPORT_SYMBOL(drm_legacy_ioremapfree);
 u64 drm_get_max_iomem(void)
 {
struct resource *tmp;
-   u64 max_iomem = 0;
+   resource_size_t max_iomem = 0;
 
for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
max_iomem = max(max_iomem,  tmp->end);
-- 
2.9.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/ttm: check if free mem space is under the lower limit

[He, Roger]

-Original Message-
From: Koenig, Christian 
Sent: Thursday, February 22, 2018 7:28 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

Am 22.02.2018 um 11:10 schrieb Roger He:
> the free mem space and the lower limit both include two parts:
> system memory and swap space.
>
> For the OOM triggered by TTM, that is the case as below:
> first swap space is full of swapped out pages and soon system memory 
> also is filled up with ttm pages. and then any memory allocation 
> request will run into OOM.
>
> to cover two cases:
> a. if no swap disk at all or free swap space is under swap mem
> limit but available system mem is bigger than sys mem limit,
> allow TTM allocation;
>
> b. if the available system mem is less than sys mem limit but
> free swap space is bigger than swap mem limit, allow TTM
> allocation.
>
> v2: merge two memory limit(swap and system) into one
> v3: keep original behavior except ttm_opt_ctx->flags with
>  TTM_OPT_FLAG_FORCE_ALLOC
> v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
> v5: add an attribute for lower_mem_limit
>
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/ttm/ttm_memory.c | 94 
> 
>   drivers/gpu/drm/ttm/ttm_page_alloc.c |  3 +
>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +
>   include/drm/ttm/ttm_memory.h |  5 ++
>   4 files changed, 105 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c 
> b/drivers/gpu/drm/ttm/ttm_memory.c
> index aa0c381..d015e39 100644
> --- a/drivers/gpu/drm/ttm/ttm_memory.c
> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> @@ -36,6 +36,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #define TTM_MEMORY_ALLOC_RETRIES 4
>   
> @@ -166,6 +167,52 @@ static struct kobj_type ttm_mem_zone_kobj_type = {
>   .default_attrs = ttm_mem_zone_attrs,
>   };
>   
> +static struct attribute ttm_mem_global_lower_mem_limit = {
> + .name = "lower_mem_limit",
> + .mode = S_IRUGO | S_IWUSR
> +};
> +
> +static ssize_t ttm_mem_global_show(struct kobject *kobj,
> +  struct attribute *attr,
> +  char *buffer)
> +{
> + struct ttm_mem_global *glob =
> + container_of(kobj, struct ttm_mem_global, kobj);
> + uint64_t val = 0;
> +
> + spin_lock(>lock);
> + val = glob->lower_mem_limit;
> + spin_unlock(>lock);
> +
> + return snprintf(buffer, PAGE_SIZE, "%llu\n",
> + (unsigned long long) val << 2);

What is that shift good for?

Because the unit of lower_mem_limit is 4KB, so (val << 2) can get KB for 
consistent with other parameters as below(all are showed with KB bytes.):

static struct attribute *ttm_mem_zone_attrs[] = {
_mem_sys,
_mem_emer,
_mem_max,
_mem_swap,
_mem_used,
NULL
};
 
> +}
> +
> +static ssize_t ttm_mem_global_store(struct kobject *kobj,
> +   struct attribute *attr,
> +   const char *buffer,
> +   size_t size)
> +{
> + int chars;
> + uint64_t val64;
> + unsigned long val;
> + struct ttm_mem_global *glob =
> + container_of(kobj, struct ttm_mem_global, kobj);
> +
> + chars = sscanf(buffer, "%lu", );
> + if (chars == 0)
> + return size;
> +
> + val64 = val;
> + val64 >>= 2;

Dito?
Covert from KB to 4K page size here.

> +
> + spin_lock(>lock);
> + glob->lower_mem_limit = val64;
> + spin_unlock(>lock);
> +
> + return size;
> +}
> +
>   static void ttm_mem_global_kobj_release(struct kobject *kobj)
>   {
>   struct ttm_mem_global *glob =
> @@ -174,8 +221,20 @@ static void ttm_mem_global_kobj_release(struct kobject 
> *kobj)
>   kfree(glob);
>   }
>   
> +static struct attribute *ttm_mem_global_attrs[] = {
> + _mem_global_lower_mem_limit,
> + NULL
> +};
> +
> +static const struct sysfs_ops ttm_mem_global_ops = {
> + .show = _mem_global_show,
> + .store = _mem_global_store,
> +};
> +
>   static struct kobj_type ttm_mem_glob_kobj_type = {
>   .release = _mem_global_kobj_release,
> + .sysfs_ops = _mem_global_ops,
> + .default_attrs = ttm_mem_global_attrs,
>   };
>   
>   static bool ttm_zones_above_swap_target(struct ttm_mem_global *glob, 
> @@ -375,6 +434,11 @@ int ttm_mem_global_init(struct ttm_mem_global 
> *glob)
>   
>   si_meminfo();
>   
> + /* lower limit of swap space and 256MB is enough */
> + glob->lower_mem_limit = 256 << 8;
> + /* lower limit of ram and keep consistent with each zone->emer_mem */
> + glob->lower_mem_limit += si.totalram >> 2;
> +

Mhm, I fear we need to set this to zero by default.

Do you mean:  glob->lower_mem_limit = 0  ?
I don't get your point here. Then how amdgpu set it with above value 

Re: [PATCH] drm/ttm: check if free mem space is under the lower limit

[Christian König]

Am 22.02.2018 um 11:10 schrieb Roger He:

the free mem space and the lower limit both include two parts:
system memory and swap space.

For the OOM triggered by TTM, that is the case as below:
first swap space is full of swapped out pages and soon
system memory also is filled up with ttm pages. and then
any memory allocation request will run into OOM.

to cover two cases:
a. if no swap disk at all or free swap space is under swap mem
limit but available system mem is bigger than sys mem limit,
allow TTM allocation;

b. if the available system mem is less than sys mem limit but
free swap space is bigger than swap mem limit, allow TTM
allocation.

v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
 TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
v5: add an attribute for lower_mem_limit

Signed-off-by: Roger He 
---
  drivers/gpu/drm/ttm/ttm_memory.c | 94 
  drivers/gpu/drm/ttm/ttm_page_alloc.c |  3 +
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +
  include/drm/ttm/ttm_memory.h |  5 ++
  4 files changed, 105 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..d015e39 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define TTM_MEMORY_ALLOC_RETRIES 4
  
@@ -166,6 +167,52 @@ static struct kobj_type ttm_mem_zone_kobj_type = {

.default_attrs = ttm_mem_zone_attrs,
  };
  
+static struct attribute ttm_mem_global_lower_mem_limit = {

+   .name = "lower_mem_limit",
+   .mode = S_IRUGO | S_IWUSR
+};
+
+static ssize_t ttm_mem_global_show(struct kobject *kobj,
+struct attribute *attr,
+char *buffer)
+{
+   struct ttm_mem_global *glob =
+   container_of(kobj, struct ttm_mem_global, kobj);
+   uint64_t val = 0;
+
+   spin_lock(>lock);
+   val = glob->lower_mem_limit;
+   spin_unlock(>lock);
+
+   return snprintf(buffer, PAGE_SIZE, "%llu\n",
+   (unsigned long long) val << 2);


What is that shift good for?


+}
+
+static ssize_t ttm_mem_global_store(struct kobject *kobj,
+ struct attribute *attr,
+ const char *buffer,
+ size_t size)
+{
+   int chars;
+   uint64_t val64;
+   unsigned long val;
+   struct ttm_mem_global *glob =
+   container_of(kobj, struct ttm_mem_global, kobj);
+
+   chars = sscanf(buffer, "%lu", );
+   if (chars == 0)
+   return size;
+
+   val64 = val;
+   val64 >>= 2;


Dito?


+
+   spin_lock(>lock);
+   glob->lower_mem_limit = val64;
+   spin_unlock(>lock);
+
+   return size;
+}
+
  static void ttm_mem_global_kobj_release(struct kobject *kobj)
  {
struct ttm_mem_global *glob =
@@ -174,8 +221,20 @@ static void ttm_mem_global_kobj_release(struct kobject 
*kobj)
kfree(glob);
  }
  
+static struct attribute *ttm_mem_global_attrs[] = {

+   _mem_global_lower_mem_limit,
+   NULL
+};
+
+static const struct sysfs_ops ttm_mem_global_ops = {
+   .show = _mem_global_show,
+   .store = _mem_global_store,
+};
+
  static struct kobj_type ttm_mem_glob_kobj_type = {
.release = _mem_global_kobj_release,
+   .sysfs_ops = _mem_global_ops,
+   .default_attrs = ttm_mem_global_attrs,
  };
  
  static bool ttm_zones_above_swap_target(struct ttm_mem_global *glob,

@@ -375,6 +434,11 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
  
  	si_meminfo();
  
+	/* lower limit of swap space and 256MB is enough */

+   glob->lower_mem_limit = 256 << 8;
+   /* lower limit of ram and keep consistent with each zone->emer_mem */
+   glob->lower_mem_limit += si.totalram >> 2;
+


Mhm, I fear we need to set this to zero by default.


ret = ttm_mem_init_kernel_zone(glob, );
if (unlikely(ret != 0))
goto out_no_zone;
@@ -469,6 +533,36 @@ void ttm_mem_global_free(struct ttm_mem_global *glob,
  }
  EXPORT_SYMBOL(ttm_mem_global_free);
  
+/*

+ * check if the available mem is under lower memory limit
+ *
+ * a. if no swap disk at all or free swap space is under swap_mem_limit
+ * but available system mem is bigger than sys_mem_limit, allow TTM
+ * allocation;
+ *
+ * b. if the available system mem is less than sys_mem_limit but free
+ * swap disk is bigger than swap_mem_limit, allow TTM allocation.
+ */
+bool
+ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
+   uint64_t num_pages,
+   struct ttm_operation_ctx *ctx)
+{
+   bool ret = false;
+   int64_t available;
+
+   if (ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC)
+   

[PATCH 8/8] drm/bochs: remove the default ttm_tt_populate callbacks

[Christian König]

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/bochs/bochs_mm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 704e879711e4..5525b6660340 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -196,8 +196,6 @@ static struct ttm_tt *bochs_ttm_tt_create(struct 
ttm_bo_device *bdev,
 
 struct ttm_bo_driver bochs_bo_driver = {
.ttm_tt_create = bochs_ttm_tt_create,
-   .ttm_tt_populate = ttm_pool_populate,
-   .ttm_tt_unpopulate = ttm_pool_unpopulate,
.init_mem_type = bochs_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = bochs_bo_evict_flags,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] drm/hisilicon: remove ttm_pool_* wrappers

[Christian König]

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 8516e005643f..0c93349fbacf 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -223,21 +223,8 @@ static struct ttm_tt *hibmc_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
 }
 
-static int hibmc_ttm_tt_populate(struct ttm_tt *ttm,
-   struct ttm_operation_ctx *ctx)
-{
-   return ttm_pool_populate(ttm, ctx);
-}
-
-static void hibmc_ttm_tt_unpopulate(struct ttm_tt *ttm)
-{
-   ttm_pool_unpopulate(ttm);
-}
-
 struct ttm_bo_driver hibmc_bo_driver = {
.ttm_tt_create  = hibmc_ttm_tt_create,
-   .ttm_tt_populate= hibmc_ttm_tt_populate,
-   .ttm_tt_unpopulate  = hibmc_ttm_tt_unpopulate,
.init_mem_type  = hibmc_bo_init_mem_type,
.evict_flags= hibmc_bo_evict_flags,
.move   = NULL,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/8] drm/virtio: remove ttm_pool_* wrappers

[Christian König]

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/virtio/virtgpu_ttm.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c 
b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index 36655b709eb2..1cde060602aa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -324,20 +324,6 @@ static struct ttm_backend_func virtio_gpu_backend_func = {
.destroy = _gpu_ttm_backend_destroy,
 };
 
-static int virtio_gpu_ttm_tt_populate(struct ttm_tt *ttm,
-   struct ttm_operation_ctx *ctx)
-{
-   if (ttm->state != tt_unpopulated)
-   return 0;
-
-   return ttm_pool_populate(ttm, ctx);
-}
-
-static void virtio_gpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
-{
-   ttm_pool_unpopulate(ttm);
-}
-
 static struct ttm_tt *virtio_gpu_ttm_tt_create(struct ttm_bo_device *bdev,
   unsigned long size,
   uint32_t page_flags,
@@ -421,8 +407,6 @@ static void virtio_gpu_bo_swap_notify(struct 
ttm_buffer_object *tbo)
 
 static struct ttm_bo_driver virtio_gpu_bo_driver = {
.ttm_tt_create = _gpu_ttm_tt_create,
-   .ttm_tt_populate = _gpu_ttm_tt_populate,
-   .ttm_tt_unpopulate = _gpu_ttm_tt_unpopulate,
.invalidate_caches = _gpu_invalidate_caches,
.init_mem_type = _gpu_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/8] drm/cirrus: remove ttm_pool_* wrappers

[Christian König]

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/cirrus/cirrus_ttm.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index a8e31ea07382..33798c76a64b 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -216,21 +216,8 @@ static struct ttm_tt *cirrus_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
 }
 
-static int cirrus_ttm_tt_populate(struct ttm_tt *ttm,
-   struct ttm_operation_ctx *ctx)
-{
-   return ttm_pool_populate(ttm, ctx);
-}
-
-static void cirrus_ttm_tt_unpopulate(struct ttm_tt *ttm)
-{
-   ttm_pool_unpopulate(ttm);
-}
-
 struct ttm_bo_driver cirrus_bo_driver = {
.ttm_tt_create = cirrus_ttm_tt_create,
-   .ttm_tt_populate = cirrus_ttm_tt_populate,
-   .ttm_tt_unpopulate = cirrus_ttm_tt_unpopulate,
.init_mem_type = cirrus_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = cirrus_bo_evict_flags,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/8] drm/mgag200: remove ttm_pool_* wrappers

[Christian König]

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/mgag200/mgag200_ttm.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index c97009bb77dd..26e5f14645c5 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -216,21 +216,8 @@ static struct ttm_tt *mgag200_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
 }
 
-static int mgag200_ttm_tt_populate(struct ttm_tt *ttm,
-   struct ttm_operation_ctx *ctx)
-{
-   return ttm_pool_populate(ttm, ctx);
-}
-
-static void mgag200_ttm_tt_unpopulate(struct ttm_tt *ttm)
-{
-   ttm_pool_unpopulate(ttm);
-}
-
 struct ttm_bo_driver mgag200_bo_driver = {
.ttm_tt_create = mgag200_ttm_tt_create,
-   .ttm_tt_populate = mgag200_ttm_tt_populate,
-   .ttm_tt_unpopulate = mgag200_ttm_tt_unpopulate,
.init_mem_type = mgag200_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = mgag200_bo_evict_flags,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/8] drm/ast: remove ttm_pool_* wrappers

[Christian König]

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ast/ast_ttm.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 7b784d91e258..68b9c5522eaa 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -216,21 +216,8 @@ static struct ttm_tt *ast_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
 }
 
-static int ast_ttm_tt_populate(struct ttm_tt *ttm,
-   struct ttm_operation_ctx *ctx)
-{
-   return ttm_pool_populate(ttm, ctx);
-}
-
-static void ast_ttm_tt_unpopulate(struct ttm_tt *ttm)
-{
-   ttm_pool_unpopulate(ttm);
-}
-
 struct ttm_bo_driver ast_bo_driver = {
.ttm_tt_create = ast_ttm_tt_create,
-   .ttm_tt_populate = ast_ttm_tt_populate,
-   .ttm_tt_unpopulate = ast_ttm_tt_unpopulate,
.init_mem_type = ast_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = ast_bo_evict_flags,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/8] drm/qxl: remove ttm_pool_* wrappers

[Christian König]

TTM calls the default implementation now.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/qxl/qxl_ttm.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 59cd74c3f3af..07d4f3fde6c1 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -291,26 +291,6 @@ static struct ttm_backend_func qxl_backend_func = {
.destroy = _ttm_backend_destroy,
 };
 
-static int qxl_ttm_tt_populate(struct ttm_tt *ttm,
-   struct ttm_operation_ctx *ctx)
-{
-   int r;
-
-   if (ttm->state != tt_unpopulated)
-   return 0;
-
-   r = ttm_pool_populate(ttm, ctx);
-   if (r)
-   return r;
-
-   return 0;
-}
-
-static void qxl_ttm_tt_unpopulate(struct ttm_tt *ttm)
-{
-   ttm_pool_unpopulate(ttm);
-}
-
 static struct ttm_tt *qxl_ttm_tt_create(struct ttm_bo_device *bdev,
unsigned long size, uint32_t page_flags,
struct page *dummy_read_page)
@@ -379,8 +359,6 @@ static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
 
 static struct ttm_bo_driver qxl_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
-   .ttm_tt_populate = _ttm_tt_populate,
-   .ttm_tt_unpopulate = _ttm_tt_unpopulate,
.invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/8] drm/ttm: add default implementations for ttm_tt_(un)populate

[Christian König]

Use ttm_pool_populate/ttm_pool_unpopulate if the driver doesn't provide
a function.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 9fd7115a013a..65bf4eac184b 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -410,7 +410,10 @@ int ttm_tt_populate(struct ttm_tt *ttm, struct 
ttm_operation_ctx *ctx)
if (ttm->state != tt_unpopulated)
return 0;
 
-   ret = ttm->bdev->driver->ttm_tt_populate(ttm, ctx);
+   if (ttm->bdev->driver->ttm_tt_populate)
+   ret = ttm->bdev->driver->ttm_tt_populate(ttm, ctx);
+   else
+   ret = ttm_pool_populate(ttm, ctx);
if (!ret)
ttm_tt_add_mapping(ttm);
return ret;
@@ -436,5 +439,8 @@ void ttm_tt_unpopulate(struct ttm_tt *ttm)
return;
 
ttm_tt_clear_mapping(ttm);
-   ttm->bdev->driver->ttm_tt_unpopulate(ttm);
+   if (ttm->bdev->driver->ttm_tt_unpopulate)
+   ttm->bdev->driver->ttm_tt_unpopulate(ttm);
+   else
+   ttm_pool_unpopulate(ttm);
 }
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105171] performance regression (3x slower) running glamor with PutImage workload (radeonsi)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105171

Clemens Eisserer  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
Summary|Performance regression  |performance regression (3x
   |running glamor with |slower) running glamor with
   |PutImage workload   |PutImage workload
   ||(radeonsi)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 6/8] i2c: demux: Use changeset helpers for clarity

[Wolfram Sang]

> > Why? ePAPR says "okay", "disabled", "fail", or "fail-sss".
> > 
> > Sorry for missing this in the previous round.
> 
> That was per Wolfram's request, and because the existing code uses "ok". I'm 
> personally fine with any.

I did? Well, today I don't have a strong preference. Any is fine with
me, too.



signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103371] glxinfo -l shows GL_INVALID_ENUM

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103371

--- Comment #3 from Marc Dietrich  ---
what do you mean by texture-float flag? in the meson configuration? I set
"-Dtexture-float=true" at least. driconf isn't working anymore for me. meson
config: 

--buildtype=debug \
-Db_ndebug=false \
-Dgallium-drivers=r600,swrast \
-Dplatforms=drm,x11,wayland \
-Dvulkan-drivers= \
-Dtexture-float=true \
-Dgles1=true -Dgles2=true \
-Dgallium-nine=true \
-Dglvnd=true \
-Ddri-drivers= \
-Dosmesa=gallium \
-Dshared-glapi=true \

hw is rs880 (ati hd2000 series).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 151341] AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=151341

--- Comment #7 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
This seems to be (very) related to
https://bugzilla.kernel.org/show_bug.cgi?id=198883

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198883

--- Comment #2 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 274355
  --> https://bugzilla.kernel.org/attachment.cgi?id=274355=edit
xorg log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198883

--- Comment #1 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 274353
  --> https://bugzilla.kernel.org/attachment.cgi?id=274353=edit
dmesg

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198883

--- Comment #3 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 274357
  --> https://bugzilla.kernel.org/attachment.cgi?id=274357=edit
xorg.conf

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198881] New: amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198881

Bug ID: 198881
   Summary: amdgpu: carrizo: Screen stalls after starting X
   Product: Drivers
   Version: 2.5
Kernel Version: 4.15.0
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: ricardo.riba...@gmail.com
Regression: No

Created attachment 274351
  --> https://bugzilla.kernel.org/attachment.cgi?id=274351=edit
dmesg

The screen freezes completely and does not even respond to commands like
Alt+Ctrl+F1.

I can still ssh the device.

Seems to happen more often when the system is cold :S.

Similar (maybe same as #151341)

Relevant dmesg:

[  246.751055] INFO: task amdgpu_cs:0:530 blocked for more than 120 seconds.
[  246.751067]   Tainted: G   O 4.15.0-qtec-standard #3
[  246.751070] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[  246.751074] amdgpu_cs:0 D0   530518 0x0008
[  246.751079] Call Trace:
[  246.751107]  ? __schedule+0x25c/0x860
[  246.751113]  ? dma_fence_default_wait+0x10b/0x280
[  246.751115]  ? dma_fence_default_wait+0x1c7/0x280
[  246.751118]  schedule+0x2f/0x90
[  246.751122]  schedule_timeout+0x1e0/0x430
[  246.751237]  ? amdgpu_vm_update_directories+0x2d/0x5d0 [amdgpu]
[  246.751241]  ? dma_fence_default_wait+0x10b/0x280
[  246.751243]  ? dma_fence_default_wait+0x1c7/0x280
[  246.751246]  dma_fence_default_wait+0x1f3/0x280
[  246.751251]  ? __kfifo_in+0x2e/0x40
[  246.751254]  ? dma_fence_default_wait+0x280/0x280
[  246.751256]  dma_fence_wait_timeout+0x2e/0x100
[  246.751319]  amdgpu_ctx_wait_prev_fence+0x49/0x80 [amdgpu]
[  246.751378]  amdgpu_cs_ioctl+0x26e/0x1a90 [amdgpu]
[  246.751403]  ? radix_tree_node_alloc.constprop.13+0x3d/0xc0
[  246.751461]  ? amdgpu_cs_find_mapping+0xc0/0xc0 [amdgpu]
[  246.751493]  drm_ioctl_kernel+0x59/0xb0 [drm]
[  246.751514]  drm_ioctl+0x29f/0x340 [drm]
[  246.751572]  ? amdgpu_cs_find_mapping+0xc0/0xc0 [amdgpu]
[  246.751620]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[  246.751626]  do_vfs_ioctl+0x8e/0x680
[  246.751632]  ? SyS_futex+0x11d/0x150
[  246.751635]  SyS_ioctl+0x74/0x80
[  246.751638]  ? get_vtime_delta+0xe/0x40
[  246.751642]  do_syscall_64+0x6f/0x1c0
[  246.751645]  entry_SYSCALL64_slow_path+0x25/0x25
[  246.751649] RIP: 0033:0x3c768e57e7
[  246.751651] RSP: 002b:7fd1220d0ba8 EFLAGS: 0246 ORIG_RAX:
0010
[  246.751655] RAX: ffda RBX: 7fd1220d0c88 RCX:
003c768e57e7
[  246.751656] RDX: 7fd1220d0c10 RSI: c0186444 RDI:
000c
[  246.751658] RBP: 7fd1220d0c10 R08: 7fd1220d0cb0 R09:
7fd1220d0c88
[  246.751659] R10: 7fd1220d0cb0 R11: 0246 R12:
c0186444
[  246.751661] R13: 000c R14: 0008 R15:


-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] New: amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198883

Bug ID: 198883
   Summary: amdgpu: carrizo: Screen stalls after starting X
   Product: Drivers
   Version: 2.5
Kernel Version: 4.15.0
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: ricardo.riba...@gmail.com
Regression: No

The screen freezes completely and does not even respond to commands like
Alt+Ctrl+F1.

I can still ssh the device.

Seems to happen more often when the system is cold :S.

Similar (maybe same as #151341)

Relevant dmesg:

[  246.751055] INFO: task amdgpu_cs:0:530 blocked for more than 120 seconds.
[  246.751067]   Tainted: G   O 4.15.0-qtec-standard #3
[  246.751070] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[  246.751074] amdgpu_cs:0 D0   530518 0x0008
[  246.751079] Call Trace:
[  246.751107]  ? __schedule+0x25c/0x860
[  246.751113]  ? dma_fence_default_wait+0x10b/0x280
[  246.751115]  ? dma_fence_default_wait+0x1c7/0x280
[  246.751118]  schedule+0x2f/0x90
[  246.751122]  schedule_timeout+0x1e0/0x430
[  246.751237]  ? amdgpu_vm_update_directories+0x2d/0x5d0 [amdgpu]
[  246.751241]  ? dma_fence_default_wait+0x10b/0x280
[  246.751243]  ? dma_fence_default_wait+0x1c7/0x280
[  246.751246]  dma_fence_default_wait+0x1f3/0x280
[  246.751251]  ? __kfifo_in+0x2e/0x40
[  246.751254]  ? dma_fence_default_wait+0x280/0x280
[  246.751256]  dma_fence_wait_timeout+0x2e/0x100
[  246.751319]  amdgpu_ctx_wait_prev_fence+0x49/0x80 [amdgpu]
[  246.751378]  amdgpu_cs_ioctl+0x26e/0x1a90 [amdgpu]
[  246.751403]  ? radix_tree_node_alloc.constprop.13+0x3d/0xc0
[  246.751461]  ? amdgpu_cs_find_mapping+0xc0/0xc0 [amdgpu]
[  246.751493]  drm_ioctl_kernel+0x59/0xb0 [drm]
[  246.751514]  drm_ioctl+0x29f/0x340 [drm]
[  246.751572]  ? amdgpu_cs_find_mapping+0xc0/0xc0 [amdgpu]
[  246.751620]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[  246.751626]  do_vfs_ioctl+0x8e/0x680
[  246.751632]  ? SyS_futex+0x11d/0x150
[  246.751635]  SyS_ioctl+0x74/0x80
[  246.751638]  ? get_vtime_delta+0xe/0x40
[  246.751642]  do_syscall_64+0x6f/0x1c0
[  246.751645]  entry_SYSCALL64_slow_path+0x25/0x25
[  246.751649] RIP: 0033:0x3c768e57e7
[  246.751651] RSP: 002b:7fd1220d0ba8 EFLAGS: 0246 ORIG_RAX:
0010
[  246.751655] RAX: ffda RBX: 7fd1220d0c88 RCX:
003c768e57e7
[  246.751656] RDX: 7fd1220d0c10 RSI: c0186444 RDI:
000c
[  246.751658] RBP: 7fd1220d0c10 R08: 7fd1220d0cb0 R09:
7fd1220d0c88
[  246.751659] R10: 7fd1220d0cb0 R11: 0246 R12:
c0186444
[  246.751661] R13: 000c R14: 0008 R15:


-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103371] glxinfo -l shows GL_INVALID_ENUM

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103371

Emil Velikov  changed:

   What|Removed |Added

 CC||baker.dyla...@gmail.com

--- Comment #2 from Emil Velikov  ---
glGetIntegerv throwing an GL_INVALID_ENUM indicates a more serious problem
lurking in the shadows.

Did you set the texture-float toggle appropriately? It that doesn't help,
please provide a complete configure line (both autotools and meson) so that
people can investigate easier.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103371] glxinfo -l shows GL_INVALID_ENUM

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103371

--- Comment #1 from Marc Dietrich  ---
additional info: this only happens on meson builds.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hi Frank,

On Thursday, 22 February 2018 08:07:14 EET Frank Rowand wrote:
> On 02/20/18 15:10, Laurent Pinchart wrote:
> > Hello,
> > 
> > This patch series addresses a design mistake that dates back from the
> > initial DU support. Support for the LVDS encoders, which are IP cores
> > separate from the DU, was bundled in the DU driver. Worse, both the DU
> > and LVDS were described through a single DT node.
> > 
> > To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS
> > encoders, and deprecate their description inside the DU bindings. To
> > retain backward compatibility with existing DT, patches 03/16 to 08/16
> > then patch the device tree at runtime to convert the legacy bindings to
> > the new ones.
> > 
> > With the DT side addressed, patch 09/16 converts the LVDS support code to
> > a separate bridge driver. Patches 11/16 to 16/16 then update all the
> > device tree sources to the new DU and LVDS encoders bindings.
> > 
> > I decided to go for live DT patching in patch 08/16 because implementing
> > support for both the legacy and new bindings in the driver would have been
> > very intrusive, and prevented further cleanups. This version relies more
> > heavily on overlays to avoid touching the internals of the OF core
> > compared to v2, even if manual fixes to the device tree are still needed.
> > 
> > Compared to v3, this series uses the OF changeset API to update properties
> > instead of accessing the internals of the property structure. This removes
> > the local implementation of functions to look up nodes by path and update
> > properties. In order to do this, I pulled in Pantelis' patch series
> > titled "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's
> > request, and rebased it while taking two small review comments into
> > account.
> 
> Wait a minute!  Why are you putting a patch set to modify core devicetree
> in the middle of a driver series.  Please pull it out to a separate series.

Because Rob asked for the driver-local implementation of the property add 
function to be replaced by Pantelis' series. I want to get the LVDS changes in 
v4.17 and asked Rob whether I could then take the OF changeset patches merged 
through the DRM tree, and he didn't object. If that causes an issue I'll 
switch back to the driver-local implementation to get the driver changes 
merged, split the OF changeset series out, and then move to the OF changeset 
API once merged. Would you prefer that ?

> I'll try to look at the patches, as they are in this series, sometime
> tomorrow.  I have a vague memory of unresolved issues from the last
> time they were proposed.
> 
> > Rob, I'd like this series to be merged in v4.17. As the changeset helpers
> > are now a dependency, I'd need you to merge them early (ideally on top of
> > v4.16-rc1) and provide a stable branch, or get your ack to merge them
> > through Dave's tree if they don't conflict with what you have and will
> > queue for v4.17.
> > 
> > This version also drops the small fix to the Porter board device tree that
> > has been queued for v4.17 already.
> > 
> > Compared to v2, the biggest change is in patch 03/16. Following Rob's and
> > Frank's reviews it was clear that modifying the unflattened DT structure
> > of the overlay before applying it wasn't popular. I have thus decided to
> > use one overlay source per SoC to move as much of the DT changes to the
> > overlay as possible, and only perform manual modifications (that are
> > still needed as some of the information is board-specific) on the system
> > DT after applying the overlay. As a result the overlay is parsed and
> > applied without being modified.
> > 
> > Compared to v1, this series update the r8a7792 and r8a7794 device tree
> > sources and incorporate review feedback as described by the changelogs of
> > individual patches.
> > 
> > Laurent Pinchart (11):
> >   dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
> >   dt-bindings: display: renesas: Deprecate LVDS support in the DU
> > bindings
> >   drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
> >   drm: rcar-du: Convert LVDS encoder code to bridge driver
> >   ARM: dts: r8a7790: Convert to new LVDS DT bindings
> >   ARM: dts: r8a7791: Convert to new LVDS DT bindings
> >   ARM: dts: r8a7792: Convert to new DU DT bindings
> >   ARM: dts: r8a7793: Convert to new LVDS DT bindings
> >   ARM: dts: r8a7794: Convert to new DU DT bindings
> >   arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
> >   arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings
> > 
> > Pantelis Antoniou (5):
> >   of: dynamic: Add __of_node_dupv()
> >   of: changesets: Introduce changeset helper methods
> >   of: changeset: Add of_changeset_node_move method
> >   of: unittest: changeset helpers
> >   i2c: demux: Use changeset helpers for clarity
> >  
> >  .../bindings/display/bridge/renesas,lvds.txt   |  56 +++
> >  .../devicetree/bindings/display/renesas,du.txt |  31 +-

Re: [PATCH v5 6/8] i2c: demux: Use changeset helpers for clarity

[Laurent Pinchart]

Hi Geert,

On Thursday, 22 February 2018 11:26:44 EET Geert Uytterhoeven wrote:
> On Thu, Feb 22, 2018 at 1:05 AM, Laurent Pinchart wrote:
> > From: Pantelis Antoniou 
> > 
> > The changeset helpers are easier to use, use them instead of
> > using the static property.
> > 
> > Signed-off-by: Pantelis Antoniou 
> > Acked-by: Wolfram Sang 
> > ["okay" -> "ok"]
> 
> Why? ePAPR says "okay", "disabled", "fail", or "fail-sss".
> 
> Sorry for missing this in the previous round.

That was per Wolfram's request, and because the existing code uses "ok". I'm 
personally fine with any.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/ttm: check if free mem space is under the lower limit

[Roger He]

the free mem space and the lower limit both include two parts:
system memory and swap space.

For the OOM triggered by TTM, that is the case as below:
first swap space is full of swapped out pages and soon
system memory also is filled up with ttm pages. and then
any memory allocation request will run into OOM.

to cover two cases:
a. if no swap disk at all or free swap space is under swap mem
   limit but available system mem is bigger than sys mem limit,
   allow TTM allocation;

b. if the available system mem is less than sys mem limit but
   free swap space is bigger than swap mem limit, allow TTM
   allocation.

v2: merge two memory limit(swap and system) into one
v3: keep original behavior except ttm_opt_ctx->flags with
TTM_OPT_FLAG_FORCE_ALLOC
v4: always set force_alloc as tx->flags & TTM_OPT_FLAG_FORCE_ALLOC
v5: add an attribute for lower_mem_limit

Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_memory.c | 94 
 drivers/gpu/drm/ttm/ttm_page_alloc.c |  3 +
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |  3 +
 include/drm/ttm/ttm_memory.h |  5 ++
 4 files changed, 105 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index aa0c381..d015e39 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TTM_MEMORY_ALLOC_RETRIES 4
 
@@ -166,6 +167,52 @@ static struct kobj_type ttm_mem_zone_kobj_type = {
.default_attrs = ttm_mem_zone_attrs,
 };
 
+static struct attribute ttm_mem_global_lower_mem_limit = {
+   .name = "lower_mem_limit",
+   .mode = S_IRUGO | S_IWUSR
+};
+
+static ssize_t ttm_mem_global_show(struct kobject *kobj,
+struct attribute *attr,
+char *buffer)
+{
+   struct ttm_mem_global *glob =
+   container_of(kobj, struct ttm_mem_global, kobj);
+   uint64_t val = 0;
+
+   spin_lock(>lock);
+   val = glob->lower_mem_limit;
+   spin_unlock(>lock);
+
+   return snprintf(buffer, PAGE_SIZE, "%llu\n",
+   (unsigned long long) val << 2);
+}
+
+static ssize_t ttm_mem_global_store(struct kobject *kobj,
+ struct attribute *attr,
+ const char *buffer,
+ size_t size)
+{
+   int chars;
+   uint64_t val64;
+   unsigned long val;
+   struct ttm_mem_global *glob =
+   container_of(kobj, struct ttm_mem_global, kobj);
+
+   chars = sscanf(buffer, "%lu", );
+   if (chars == 0)
+   return size;
+
+   val64 = val;
+   val64 >>= 2;
+
+   spin_lock(>lock);
+   glob->lower_mem_limit = val64;
+   spin_unlock(>lock);
+
+   return size;
+}
+
 static void ttm_mem_global_kobj_release(struct kobject *kobj)
 {
struct ttm_mem_global *glob =
@@ -174,8 +221,20 @@ static void ttm_mem_global_kobj_release(struct kobject 
*kobj)
kfree(glob);
 }
 
+static struct attribute *ttm_mem_global_attrs[] = {
+   _mem_global_lower_mem_limit,
+   NULL
+};
+
+static const struct sysfs_ops ttm_mem_global_ops = {
+   .show = _mem_global_show,
+   .store = _mem_global_store,
+};
+
 static struct kobj_type ttm_mem_glob_kobj_type = {
.release = _mem_global_kobj_release,
+   .sysfs_ops = _mem_global_ops,
+   .default_attrs = ttm_mem_global_attrs,
 };
 
 static bool ttm_zones_above_swap_target(struct ttm_mem_global *glob,
@@ -375,6 +434,11 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
 
si_meminfo();
 
+   /* lower limit of swap space and 256MB is enough */
+   glob->lower_mem_limit = 256 << 8;
+   /* lower limit of ram and keep consistent with each zone->emer_mem */
+   glob->lower_mem_limit += si.totalram >> 2;
+
ret = ttm_mem_init_kernel_zone(glob, );
if (unlikely(ret != 0))
goto out_no_zone;
@@ -469,6 +533,36 @@ void ttm_mem_global_free(struct ttm_mem_global *glob,
 }
 EXPORT_SYMBOL(ttm_mem_global_free);
 
+/*
+ * check if the available mem is under lower memory limit
+ *
+ * a. if no swap disk at all or free swap space is under swap_mem_limit
+ * but available system mem is bigger than sys_mem_limit, allow TTM
+ * allocation;
+ *
+ * b. if the available system mem is less than sys_mem_limit but free
+ * swap disk is bigger than swap_mem_limit, allow TTM allocation.
+ */
+bool
+ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
+   uint64_t num_pages,
+   struct ttm_operation_ctx *ctx)
+{
+   bool ret = false;
+   int64_t available;
+
+   if (ctx->flags & TTM_OPT_FLAG_FORCE_ALLOC)
+   return false;
+
+   available = get_nr_swap_pages() + si_mem_available();
+   available -= num_pages;
+   if (available < glob->lower_mem_limit)
+

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

[Robert Foss]

Hey Stefan,

On 02/22/2018 04:54 AM, Stefan Schake wrote:

Android assumes an implicit black background layer is always present
behind all layers it specifies for composition. drm_hwcomposer currently
punts responsibility for this to the kernel/DRM platform and puts layers
with per-pixel alpha content on the primary plane when requested.


I wasn't aware of this assumption, but given that it is the case,
the patch looks like a good fix for the problem.

Unfortunately I don't have a hardware platform up and running to test the patch 
with at the moment.




On some platforms (e.g. VC4) a background color fill has a cycle cost for
the hardware composer and is not enabled by default. Instead, userland can
request a background color through a CRTC property. Use this property to
specify the implicit black background Android expects.

Signed-off-by: Stefan Schake 
---
Kernel changes for this (background_color) are available here:

https://github.com/stschake/linux/commits/background-upstream

Sending as RFC because I'm not entirely clear on whose responsibility
this should be, on most DRM drivers it seems to be implicit. I think
a case could also be made that VC4 should not accept alpha formats on
the lowest layer or enable background color fill when given one anyway.
On the other hand, userland control over background color seems desirable
regardless and is a feature of multiple hardware composers (i915, vc4, omap).

  drmcrtc.cpp  | 11 +++
  drmcrtc.h|  2 ++
  drmdisplaycompositor.cpp | 15 +++
  3 files changed, 28 insertions(+)

diff --git a/drmcrtc.cpp b/drmcrtc.cpp
index 1b354fe..d7bcd7a 100644
--- a/drmcrtc.cpp
+++ b/drmcrtc.cpp
@@ -52,6 +52,13 @@ int DrmCrtc::Init() {
  ALOGE("Failed to get OUT_FENCE_PTR property");
  return ret;
}
+
+  ret = drm_->GetCrtcProperty(*this, "background_color",
+  _color_property_);
+  if (ret) {
+ALOGI("Failed to get background_color property");
+// This is an optional property
+  }
return 0;
  }
  
@@ -86,4 +93,8 @@ const DrmProperty ::mode_property() const {

  const DrmProperty ::out_fence_ptr_property() const {
return out_fence_ptr_property_;
  }
+
+const DrmProperty ::background_color_property() const {
+  return background_color_property_;
+}
  }
diff --git a/drmcrtc.h b/drmcrtc.h
index c5a5599..704573a 100644
--- a/drmcrtc.h
+++ b/drmcrtc.h
@@ -46,6 +46,7 @@ class DrmCrtc {
const DrmProperty _property() const;
const DrmProperty _property() const;
const DrmProperty _fence_ptr_property() const;
+  const DrmProperty _color_property() const;
  
   private:

DrmResources *drm_;
@@ -59,6 +60,7 @@ class DrmCrtc {
DrmProperty active_property_;
DrmProperty mode_property_;
DrmProperty out_fence_ptr_property_;
+  DrmProperty background_color_property_;
  };
  }
  
diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp

index e556e86..69c52dd 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -527,6 +527,21 @@ int 
DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
return ret;
  }
  
+if (crtc->background_color_property().id() != 0) {

+  // Background color is specified as a 16 bit per channel RGBA value.
+  // Set a fully opaque black background as Android HWC expects.
+  const uint64_t background_color = 0x;
+
+  ret = drmModeAtomicAddProperty(pset, crtc->id(),
+ crtc->background_color_property().id(),
+ background_color) < 0;
+  if (ret) {
+ALOGE("Failed to add CRTC background_color to pset: %d", ret);
+drmModeAtomicFree(pset);
+return ret;
+  }
+}
+
  ret = drmModeAtomicAddProperty(pset, crtc->id(), 
crtc->mode_property().id(),
 mode_.blob_id) < 0 ||
drmModeAtomicAddProperty(pset, connector->id(),


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 6/8] i2c: demux: Use changeset helpers for clarity

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Feb 22, 2018 at 1:05 AM, Laurent Pinchart
 wrote:
> From: Pantelis Antoniou 
>
> The changeset helpers are easier to use, use them instead of
> using the static property.
>
> Signed-off-by: Pantelis Antoniou 
> Acked-by: Wolfram Sang 
> ["okay" -> "ok"]

Why? ePAPR says "okay", "disabled", "fail", or "fail-sss".

Sorry for missing this in the previous round.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fix double ;;s in code

[Shawn Guo]

Hi Pavel,

On Sat, Feb 17, 2018 at 10:19:55PM +0100, Pavel Machek wrote:
...
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 53f7275..cfb42f5 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -348,7 +348,7 @@ static int imx_gpc_old_dt_init(struct device *dev, struct 
> regmap *regmap,
>   if (i == 1) {
>   domain->supply = devm_regulator_get(dev, "pu");
>   if (IS_ERR(domain->supply))
> - return PTR_ERR(domain->supply);;
> + return PTR_ERR(domain->supply);
>  
>   ret = imx_pgc_get_clocks(dev, domain);
>   if (ret)
> 

Considering the controversy how the changes should be merged, I'm going
to send a separate patch just for IMX GPC driver with a reported-by-you
tag.  Thanks for catching this.

Shawn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd: Remove inclusion of non-existing include directories

[Christian König]

Am 22.02.2018 um 09:21 schrieb Corentin Labbe:

This patch fix the following build warnings:
   CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o
cc1: warning: ../display/: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../display/include: No such file or directory 
[-Wmissing-include-dirs]
   CC [M]  drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
cc1: warning: ../display/: No such file or directory [-Wmissing-include-dirs]
cc1: warning: ../display/include: No such file or directory 
[-Wmissing-include-dirs]
[...]
This warning is shown for each file in amdgpu directory, so it spams a lot.

Signed-off-by: Corentin Labbe 


Acked-by: Christian König 


---
  drivers/gpu/drm/amd/display/Makefile | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Makefile 
b/drivers/gpu/drm/amd/display/Makefile
index c27c81cdeed3..22c72dffdf98 100644
--- a/drivers/gpu/drm/amd/display/Makefile
+++ b/drivers/gpu/drm/amd/display/Makefile
@@ -26,8 +26,6 @@
  
  AMDDALPATH = $(RELATIVE_AMD_DISPLAY_PATH)
  
-subdir-ccflags-y += -I$(AMDDALPATH)/ -I$(AMDDALPATH)/include

-
  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/
  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/dc/inc/hw
  subdir-ccflags-y += -I$(FULL_AMD_DISPLAY_PATH)/modules/inc


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/amd: remove inclusion of non-existing scheduler directory

[Christian König]

Am 22.02.2018 um 09:21 schrieb Corentin Labbe:

The scheduler directory was removed via commit 1b1f42d8fde4 ("drm: move 
amd_gpu_scheduler into common location")
Remove it from include path.

Signed-off-by: Corentin Labbe 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/Makefile | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index d6e5b7273853..8408aeeaf6c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -30,7 +30,6 @@ FULL_AMD_DISPLAY_PATH = 
$(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
  ccflags-y := -I$(FULL_AMD_PATH)/include/asic_reg \
-I$(FULL_AMD_PATH)/include \
-I$(FULL_AMD_PATH)/amdgpu \
-   -I$(FULL_AMD_PATH)/scheduler \
-I$(FULL_AMD_PATH)/powerplay/inc \
-I$(FULL_AMD_PATH)/acp/include \
-I$(FULL_AMD_DISPLAY_PATH) \


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/9] drm/xen-front: Implement Xen bus state handling

[Juergen Gross]

On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Initial handling for Xen bus states: implement
> Xen bus state machine for the frontend driver according to
> the state diagram and recovery flow from display para-virtualized
> protocol: xen/interface/io/displif.h.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/gpu/drm/xen/xen_drm_front.c | 124 
> +++-
>  drivers/gpu/drm/xen/xen_drm_front.h |  26 
>  2 files changed, 149 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/xen/xen_drm_front.h
> 
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
> b/drivers/gpu/drm/xen/xen_drm_front.c
> index fd372fb464a1..d0306f9d660d 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -24,19 +24,141 @@
>  
>  #include 
>  
> +#include "xen_drm_front.h"
> +
> +static void xen_drv_remove_internal(struct xen_drm_front_info *front_info)
> +{
> +}
> +
> +static int backend_on_initwait(struct xen_drm_front_info *front_info)
> +{
> + return 0;
> +}
> +
> +static int backend_on_connected(struct xen_drm_front_info *front_info)
> +{
> + return 0;
> +}
> +
> +static void backend_on_disconnected(struct xen_drm_front_info *front_info)
> +{
> + xenbus_switch_state(front_info->xb_dev, XenbusStateInitialising);
> +}
> +
>  static void backend_on_changed(struct xenbus_device *xb_dev,
>   enum xenbus_state backend_state)
>  {
> + struct xen_drm_front_info *front_info = dev_get_drvdata(_dev->dev);
> + int ret;
> +
> + DRM_DEBUG("Backend state is %s, front is %s\n",
> + xenbus_strstate(backend_state),
> + xenbus_strstate(xb_dev->state));
> +
> + switch (backend_state) {
> + case XenbusStateReconfiguring:
> + /* fall through */
> + case XenbusStateReconfigured:
> + /* fall through */
> + case XenbusStateInitialised:
> + break;
> +
> + case XenbusStateInitialising:
> + /* recovering after backend unexpected closure */
> + backend_on_disconnected(front_info);
> + break;
> +
> + case XenbusStateInitWait:
> + /* recovering after backend unexpected closure */
> + backend_on_disconnected(front_info);
> + if (xb_dev->state != XenbusStateInitialising)
> + break;
> +
> + ret = backend_on_initwait(front_info);
> + if (ret < 0)
> + xenbus_dev_fatal(xb_dev, ret, "initializing frontend");
> + else
> + xenbus_switch_state(xb_dev, XenbusStateInitialised);
> + break;
> +
> + case XenbusStateConnected:
> + if (xb_dev->state != XenbusStateInitialised)
> + break;
> +
> + ret = backend_on_connected(front_info);
> + if (ret < 0)
> + xenbus_dev_fatal(xb_dev, ret, "initializing DRM 
> driver");
> + else
> + xenbus_switch_state(xb_dev, XenbusStateConnected);
> + break;
> +
> + case XenbusStateClosing:
> + /*
> +  * in this state backend starts freeing resources,
> +  * so let it go into closed state, so we can also
> +  * remove ours
> +  */
> + break;
> +
> + case XenbusStateUnknown:
> + /* fall through */
> + case XenbusStateClosed:
> + if (xb_dev->state == XenbusStateClosed)
> + break;
> +
> + backend_on_disconnected(front_info);
> + break;
> + }
>  }
>  
>  static int xen_drv_probe(struct xenbus_device *xb_dev,
>   const struct xenbus_device_id *id)
>  {
> - return 0;
> + struct xen_drm_front_info *front_info;
> +
> + front_info = devm_kzalloc(_dev->dev,
> + sizeof(*front_info), GFP_KERNEL);
> + if (!front_info) {
> + xenbus_dev_fatal(xb_dev, -ENOMEM, "allocating device memory");

No need for message in case of allocation failure: this is
handled in memory allocation already.


Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/9] drm/xen-front: Implement Xen bus state handling

[Oleksandr Andrushchenko]

On 02/21/2018 10:23 AM, Juergen Gross wrote:

On 21/02/18 09:03, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Initial handling for Xen bus states: implement
Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.

Signed-off-by: Oleksandr Andrushchenko 
---
  drivers/gpu/drm/xen/xen_drm_front.c | 124 +++-
  drivers/gpu/drm/xen/xen_drm_front.h |  26 
  2 files changed, 149 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/xen/xen_drm_front.h

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index fd372fb464a1..d0306f9d660d 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -24,19 +24,141 @@
  
  #include 
  
+#include "xen_drm_front.h"

+
+static void xen_drv_remove_internal(struct xen_drm_front_info *front_info)
+{
+}
+
+static int backend_on_initwait(struct xen_drm_front_info *front_info)
+{
+   return 0;
+}
+
+static int backend_on_connected(struct xen_drm_front_info *front_info)
+{
+   return 0;
+}
+
+static void backend_on_disconnected(struct xen_drm_front_info *front_info)
+{
+   xenbus_switch_state(front_info->xb_dev, XenbusStateInitialising);
+}
+
  static void backend_on_changed(struct xenbus_device *xb_dev,
enum xenbus_state backend_state)
  {
+   struct xen_drm_front_info *front_info = dev_get_drvdata(_dev->dev);
+   int ret;
+
+   DRM_DEBUG("Backend state is %s, front is %s\n",
+   xenbus_strstate(backend_state),
+   xenbus_strstate(xb_dev->state));
+
+   switch (backend_state) {
+   case XenbusStateReconfiguring:
+   /* fall through */
+   case XenbusStateReconfigured:
+   /* fall through */
+   case XenbusStateInitialised:
+   break;
+
+   case XenbusStateInitialising:
+   /* recovering after backend unexpected closure */
+   backend_on_disconnected(front_info);
+   break;
+
+   case XenbusStateInitWait:
+   /* recovering after backend unexpected closure */
+   backend_on_disconnected(front_info);
+   if (xb_dev->state != XenbusStateInitialising)
+   break;
+
+   ret = backend_on_initwait(front_info);
+   if (ret < 0)
+   xenbus_dev_fatal(xb_dev, ret, "initializing frontend");
+   else
+   xenbus_switch_state(xb_dev, XenbusStateInitialised);
+   break;
+
+   case XenbusStateConnected:
+   if (xb_dev->state != XenbusStateInitialised)
+   break;
+
+   ret = backend_on_connected(front_info);
+   if (ret < 0)
+   xenbus_dev_fatal(xb_dev, ret, "initializing DRM 
driver");
+   else
+   xenbus_switch_state(xb_dev, XenbusStateConnected);
+   break;
+
+   case XenbusStateClosing:
+   /*
+* in this state backend starts freeing resources,
+* so let it go into closed state, so we can also
+* remove ours
+*/
+   break;
+
+   case XenbusStateUnknown:
+   /* fall through */
+   case XenbusStateClosed:
+   if (xb_dev->state == XenbusStateClosed)
+   break;
+
+   backend_on_disconnected(front_info);
+   break;
+   }
  }
  
  static int xen_drv_probe(struct xenbus_device *xb_dev,

const struct xenbus_device_id *id)
  {
-   return 0;
+   struct xen_drm_front_info *front_info;
+
+   front_info = devm_kzalloc(_dev->dev,
+   sizeof(*front_info), GFP_KERNEL);
+   if (!front_info) {
+   xenbus_dev_fatal(xb_dev, -ENOMEM, "allocating device memory");

No need for message in case of allocation failure: this is
handled in memory allocation already.

Will remove, thank you


Juergen


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Frank Rowand]

On 02/20/18 15:10, Laurent Pinchart wrote:
> Hello,
> 
> This patch series addresses a design mistake that dates back from the initial
> DU support. Support for the LVDS encoders, which are IP cores separate from
> the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
> described through a single DT node.
> 
> To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS
> encoders, and deprecate their description inside the DU bindings. To retain
> backward compatibility with existing DT, patches 03/16 to 08/16 then patch the
> device tree at runtime to convert the legacy bindings to the new ones.
> 
> With the DT side addressed, patch 09/16 converts the LVDS support code to a
> separate bridge driver. Patches 11/16 to 16/16 then update all the device tree
> sources to the new DU and LVDS encoders bindings.
> 
> I decided to go for live DT patching in patch 08/16 because implementing
> support for both the legacy and new bindings in the driver would have been
> very intrusive, and prevented further cleanups. This version relies more
> heavily on overlays to avoid touching the internals of the OF core compared to
> v2, even if manual fixes to the device tree are still needed.
> 
> Compared to v3, this series uses the OF changeset API to update properties
> instead of accessing the internals of the property structure. This removes the
> local implementation of functions to look up nodes by path and update
> properties. In order to do this, I pulled in Pantelis' patch series titled
> "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's request, and
> rebased it while taking two small review comments into account.

Wait a minute!  Why are you putting a patch set to modify core devicetree
in the middle of a driver series.  Please pull it out to a separate series.

I'll try to look at the patches, as they are in this series, sometime
tomorrow.  I have a vague memory of unresolved issues from the last
time they were proposed.

Thanks,

Frank


> 
> Rob, I'd like this series to be merged in v4.17. As the changeset helpers are
> now a dependency, I'd need you to merge them early (ideally on top of
> v4.16-rc1) and provide a stable branch, or get your ack to merge them through
> Dave's tree if they don't conflict with what you have and will queue for
> v4.17.
> 
> This version also drops the small fix to the Porter board device tree that has
> been queued for v4.17 already.
> 
> Compared to v2, the biggest change is in patch 03/16. Following Rob's and
> Frank's reviews it was clear that modifying the unflattened DT structure of
> the overlay before applying it wasn't popular. I have thus decided to use one
> overlay source per SoC to move as much of the DT changes to the overlay as
> possible, and only perform manual modifications (that are still needed as some
> of the information is board-specific) on the system DT after applying the
> overlay. As a result the overlay is parsed and applied without being modified.
> 
> Compared to v1, this series update the r8a7792 and r8a7794 device tree sources
> and incorporate review feedback as described by the changelogs of individual
> patches.
> 
> 
> Laurent Pinchart (11):
>   dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
>   dt-bindings: display: renesas: Deprecate LVDS support in the DU
> bindings
>   drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
>   drm: rcar-du: Convert LVDS encoder code to bridge driver
>   ARM: dts: r8a7790: Convert to new LVDS DT bindings
>   ARM: dts: r8a7791: Convert to new LVDS DT bindings
>   ARM: dts: r8a7792: Convert to new DU DT bindings
>   ARM: dts: r8a7793: Convert to new LVDS DT bindings
>   ARM: dts: r8a7794: Convert to new DU DT bindings
>   arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
>   arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings
> 
> Pantelis Antoniou (5):
>   of: dynamic: Add __of_node_dupv()
>   of: changesets: Introduce changeset helper methods
>   of: changeset: Add of_changeset_node_move method
>   of: unittest: changeset helpers
>   i2c: demux: Use changeset helpers for clarity
> 
>  .../bindings/display/bridge/renesas,lvds.txt   |  56 +++
>  .../devicetree/bindings/display/renesas,du.txt |  31 +-
>  MAINTAINERS|   1 +
>  arch/arm/boot/dts/r8a7790-lager.dts|  22 +-
>  arch/arm/boot/dts/r8a7790.dtsi |  64 ++-
>  arch/arm/boot/dts/r8a7791-koelsch.dts  |  10 +-
>  arch/arm/boot/dts/r8a7791-porter.dts   |  16 +-
>  arch/arm/boot/dts/r8a7791.dtsi |  36 +-
>  arch/arm/boot/dts/r8a7792.dtsi |   1 -
>  arch/arm/boot/dts/r8a7793-gose.dts |  10 +-
>  arch/arm/boot/dts/r8a7793.dtsi |  37 +-
>  arch/arm/boot/dts/r8a7794.dtsi |   1 -
>  .../boot/dts/renesas/r8a7795-es1-salvator-x.dts|   3 +-
>  

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

[Roger Pau Monné]

On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Introduce skeleton of the para-virtualized Xen display
> frontend driver. This patch only adds required
> essential stubs.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/gpu/drm/Kconfig |  2 +
>  drivers/gpu/drm/Makefile|  1 +
>  drivers/gpu/drm/xen/Kconfig | 17 
>  drivers/gpu/drm/xen/Makefile|  5 +++
>  drivers/gpu/drm/xen/xen_drm_front.c | 83 
> +
>  5 files changed, 108 insertions(+)
>  create mode 100644 drivers/gpu/drm/xen/Kconfig
>  create mode 100644 drivers/gpu/drm/xen/Makefile
>  create mode 100644 drivers/gpu/drm/xen/xen_drm_front.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index deeefa7a1773..757825ac60df 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
>  
>  source "drivers/gpu/drm/tve200/Kconfig"
>  
> +source "drivers/gpu/drm/xen/Kconfig"
> +
>  # Keep legacy drivers last
>  
>  menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 50093ff4479b..9d66657ea117 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB)   += mxsfb/
>  obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
>  obj-$(CONFIG_DRM_PL111) += pl111/
>  obj-$(CONFIG_DRM_TVE200) += tve200/
> +obj-$(CONFIG_DRM_XEN) += xen/
> diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
> new file mode 100644
> index ..4cca160782ab
> --- /dev/null
> +++ b/drivers/gpu/drm/xen/Kconfig
> @@ -0,0 +1,17 @@
> +config DRM_XEN
> + bool "DRM Support for Xen guest OS"
> + depends on XEN
> + help
> +   Choose this option if you want to enable DRM support
> +   for Xen.
> +
> +config DRM_XEN_FRONTEND
> + tristate "Para-virtualized frontend driver for Xen guest OS"
> + depends on DRM_XEN
> + depends on DRM
> + select DRM_KMS_HELPER
> + select VIDEOMODE_HELPERS
> + select XEN_XENBUS_FRONTEND
> + help
> +   Choose this option if you want to enable a para-virtualized
> +   frontend DRM/KMS driver for Xen guest OSes.
> diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
> new file mode 100644
> index ..967074d348f6
> --- /dev/null
> +++ b/drivers/gpu/drm/xen/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +drm_xen_front-objs := xen_drm_front.o
> +
> +obj-$(CONFIG_DRM_XEN_FRONTEND) += drm_xen_front.o
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
> b/drivers/gpu/drm/xen/xen_drm_front.c
> new file mode 100644
> index ..fd372fb464a1
> --- /dev/null
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -0,0 +1,83 @@
> +/*
> + *  Xen para-virtual DRM device
> + *
> + *   This program is free software; you can redistribute it and/or modify
> + *   it under the terms of the GNU General Public License as published by
> + *   the Free Software Foundation; either version 2 of the License, or
> + *   (at your option) any later version.
> + *
> + *   This program is distributed in the hope that it will be useful,
> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *   GNU General Public License for more details.

Most Xen drivers in Linux use a dual GPL/BSD license, so that they can
be imported into other non GPL OSes:

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License version 2
as published by the Free Software Foundation; or, when distributed
separately from the Linux kernel or incorporated into other
software packages, subject to the following license:

Permission is hereby granted, free of charge, to any person obtaining a copy
of this source file (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.

IMO it would be good to release this driver under 

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Simon Horman]

On Wed, Feb 21, 2018 at 01:10:30AM +0200, Laurent Pinchart wrote:
> Hello,
> 
> This patch series addresses a design mistake that dates back from the initial
> DU support. Support for the LVDS encoders, which are IP cores separate from
> the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
> described through a single DT node.
> 
> To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS
> encoders, and deprecate their description inside the DU bindings. To retain
> backward compatibility with existing DT, patches 03/16 to 08/16 then patch the
> device tree at runtime to convert the legacy bindings to the new ones.
> 
> With the DT side addressed, patch 09/16 converts the LVDS support code to a
> separate bridge driver. Patches 11/16 to 16/16 then update all the device tree
> sources to the new DU and LVDS encoders bindings.
> 
> I decided to go for live DT patching in patch 08/16 because implementing
> support for both the legacy and new bindings in the driver would have been
> very intrusive, and prevented further cleanups. This version relies more
> heavily on overlays to avoid touching the internals of the OF core compared to
> v2, even if manual fixes to the device tree are still needed.
> 
> Compared to v3, this series uses the OF changeset API to update properties
> instead of accessing the internals of the property structure. This removes the
> local implementation of functions to look up nodes by path and update
> properties. In order to do this, I pulled in Pantelis' patch series titled
> "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's request, and
> rebased it while taking two small review comments into account.
> 
> Rob, I'd like this series to be merged in v4.17. As the changeset helpers are
> now a dependency, I'd need you to merge them early (ideally on top of
> v4.16-rc1) and provide a stable branch, or get your ack to merge them through
> Dave's tree if they don't conflict with what you have and will queue for
> v4.17.
> 
> This version also drops the small fix to the Porter board device tree that has
> been queued for v4.17 already.
> 
> Compared to v2, the biggest change is in patch 03/16. Following Rob's and
> Frank's reviews it was clear that modifying the unflattened DT structure of
> the overlay before applying it wasn't popular. I have thus decided to use one
> overlay source per SoC to move as much of the DT changes to the overlay as
> possible, and only perform manual modifications (that are still needed as some
> of the information is board-specific) on the system DT after applying the
> overlay. As a result the overlay is parsed and applied without being modified.
> 
> Compared to v1, this series update the r8a7792 and r8a7794 device tree sources
> and incorporate review feedback as described by the changelogs of individual
> patches.
> 
> 
> Laurent Pinchart (11):
>   dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
>   dt-bindings: display: renesas: Deprecate LVDS support in the DU
> bindings
>   drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
>   drm: rcar-du: Convert LVDS encoder code to bridge driver
>   ARM: dts: r8a7790: Convert to new LVDS DT bindings
>   ARM: dts: r8a7791: Convert to new LVDS DT bindings
>   ARM: dts: r8a7792: Convert to new DU DT bindings
>   ARM: dts: r8a7793: Convert to new LVDS DT bindings
>   ARM: dts: r8a7794: Convert to new DU DT bindings
>   arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
>   arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

I have marked the dts patches above as deferred as they depend
on the driver changes not to cause a regression. Please repost them
or otherwise ping me once the driver dependencies are present in an rc
release.

I am assuming that the other patches in this series are not targeted
at the renesas tree.

> 
> Pantelis Antoniou (5):
>   of: dynamic: Add __of_node_dupv()
>   of: changesets: Introduce changeset helper methods
>   of: changeset: Add of_changeset_node_move method
>   of: unittest: changeset helpers
>   i2c: demux: Use changeset helpers for clarity

...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

[Maarten Lankhorst]

Op 21-02-18 om 00:56 schreef Daniel Vetter:
> On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote:
>> On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote:
>>> Am 20.02.2018 um 15:54 schrieb Peter Zijlstra:
 On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:
>> OK, but neither case would in fact need the !ctx case right? That's just
>> there for completeness sake?
> Unfortunately not. TTM uses trylock to lock BOs which are about to be
> evicted to make room for all the BOs locked with a ctx.
>
> I need to be able to distinct between the BOs which are trylocked and 
> those
> which are locked with a ctx.
>
> Writing this I actually noticed the current version is buggy, cause even
> when we check the mutex owner we still need to make sure that the ctx in 
> the
> lock is NULL.
 Hurm... I can't remember why trylocks behave like that, and it seems
 rather unfortunate / inconsistent.
>>> Actually for me that is rather fortunate, cause I need to distinct between
>>> the locks acquired through trylock and lock.
>> I suppose that would always be possible using:
>> ww_mutex_trylock(.ctx=NULL), and it could be that there simply weren't
>> any immediate uses for a !NULL trylock and it was thus not implemented.
>>
>> But that is all very long ago..
> I think we simple never had a use-case for interleaving ww_mutex_lock(ctx)
> and ww_mutex_trylock(ctx). Nesting multiple trylocks in ctx-locks happens
> plenty, but not further:
>
> The common use-case for that is locking a bunch of buffers you need (for
> command submission or whatever), and then trylocking other buffers to make
> space for the buffers you need to move into VRAM. I guess if only
> trylocking buffers doesn't succeed in freeing up enough VRAM then we could
> go into blocking ww_mutex_locks which need the ctx (and which would need
> all the trylock-acquired buffers to be annotated with the ctx too). TTM
> currently tries to be far enough away from that corner case (using a
> defensive "never use more than 50% of all memory for gfx" approach) that
> it doesn't seem to need that.
>
> Once we get there it should indeed be simply to add a ctx parameter to
> ww_mutex_trylock to fix this case. The TTM side rework is definitely going
> to be the much bigger issue here ...
> -Daniel

Yes, I think fixing trylock to take a ctx parameter would be a better fix than 
ww_mutex_is_owned_by..

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC

[Oleksandr Andrushchenko]

On 02/22/2018 08:09 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

It is possible that drm_simple_kms_plane_atomic_check called
with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID
to 0 before doing any actual drawing. This leads to NULL pointer
dereference because in this case new CRTC state is NULL and must be
checked before accessing.

Signed-off-by: Oleksandr Andrushchenko 
Reviewed-by: Daniel Vetter 

---
Changes since initial:
- re-worked checks for null CRTC as suggested by Daniel Vetter
---
  drivers/gpu/drm/drm_simple_kms_helper.c | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 9ca8a4a59b74..4a1dbd88b1ec 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -121,12 +121,6 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
pipe = container_of(plane, struct drm_simple_display_pipe, plane);
crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
   >crtc);
-   if (!crtc_state->enable)
-   return 0; /* nothing to check when disabling or disabled */
-
-   if (crtc_state->enable)
-   drm_mode_get_hv_timing(_state->mode,
-  , );
  
  	ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,

  ,
@@ -137,7 +131,9 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
return ret;
  
  	if (!plane_state->visible)

-   return -EINVAL;

Daniel, I have put your R-b tag, but I had removed suggested
"WARN_ON(crtc_state && crtc_state->enable);"
here as it fires each time when crtc_state is not NULL.
Please let me know if this is not ok and you want me to remove
your R-b tag.

+   return 0;
+
+   drm_mode_get_hv_timing(_state->mode, , );
  
  	if (!pipe->funcs || !pipe->funcs->check)

return 0;

Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

[Juergen Gross]

On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Introduce skeleton of the para-virtualized Xen display
> frontend driver. This patch only adds required
> essential stubs.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/gpu/drm/Kconfig |  2 +
>  drivers/gpu/drm/Makefile|  1 +
>  drivers/gpu/drm/xen/Kconfig | 17 
>  drivers/gpu/drm/xen/Makefile|  5 +++
>  drivers/gpu/drm/xen/xen_drm_front.c | 83 
> +
>  5 files changed, 108 insertions(+)
>  create mode 100644 drivers/gpu/drm/xen/Kconfig
>  create mode 100644 drivers/gpu/drm/xen/Makefile
>  create mode 100644 drivers/gpu/drm/xen/xen_drm_front.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index deeefa7a1773..757825ac60df 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
>  
>  source "drivers/gpu/drm/tve200/Kconfig"
>  
> +source "drivers/gpu/drm/xen/Kconfig"
> +
>  # Keep legacy drivers last
>  
>  menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 50093ff4479b..9d66657ea117 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB)   += mxsfb/
>  obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
>  obj-$(CONFIG_DRM_PL111) += pl111/
>  obj-$(CONFIG_DRM_TVE200) += tve200/
> +obj-$(CONFIG_DRM_XEN) += xen/
> diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
> new file mode 100644
> index ..4cca160782ab
> --- /dev/null
> +++ b/drivers/gpu/drm/xen/Kconfig
> @@ -0,0 +1,17 @@
> +config DRM_XEN
> + bool "DRM Support for Xen guest OS"
> + depends on XEN
> + help
> +   Choose this option if you want to enable DRM support
> +   for Xen.
> +
> +config DRM_XEN_FRONTEND
> + tristate "Para-virtualized frontend driver for Xen guest OS"
> + depends on DRM_XEN
> + depends on DRM
> + select DRM_KMS_HELPER
> + select VIDEOMODE_HELPERS
> + select XEN_XENBUS_FRONTEND
> + help
> +   Choose this option if you want to enable a para-virtualized
> +   frontend DRM/KMS driver for Xen guest OSes.
> diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
> new file mode 100644
> index ..967074d348f6
> --- /dev/null
> +++ b/drivers/gpu/drm/xen/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +drm_xen_front-objs := xen_drm_front.o
> +
> +obj-$(CONFIG_DRM_XEN_FRONTEND) += drm_xen_front.o
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
> b/drivers/gpu/drm/xen/xen_drm_front.c
> new file mode 100644
> index ..fd372fb464a1
> --- /dev/null
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -0,0 +1,83 @@
> +/*
> + *  Xen para-virtual DRM device
> + *
> + *   This program is free software; you can redistribute it and/or modify
> + *   it under the terms of the GNU General Public License as published by
> + *   the Free Software Foundation; either version 2 of the License, or
> + *   (at your option) any later version.
> + *
> + *   This program is distributed in the hope that it will be useful,
> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *   GNU General Public License for more details.

Use SPDX identifier instead (same applies for all other new
sources):

// SPDX-License-Identifier: GPL-2.0

> + *
> + * Copyright (C) 2016-2018 EPAM Systems Inc.
> + *
> + * Author: Oleksandr Andrushchenko 
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +static void backend_on_changed(struct xenbus_device *xb_dev,
> + enum xenbus_state backend_state)
> +{
> +}
> +
> +static int xen_drv_probe(struct xenbus_device *xb_dev,
> + const struct xenbus_device_id *id)
> +{
> + return 0;
> +}
> +
> +static int xen_drv_remove(struct xenbus_device *dev)
> +{
> + return 0;
> +}
> +
> +static const struct xenbus_device_id xen_drv_ids[] = {
> + { XENDISPL_DRIVER_NAME },
> + { "" }
> +};
> +
> +static struct xenbus_driver xen_driver = {
> + .ids = xen_drv_ids,
> + .probe = xen_drv_probe,
> + .remove = xen_drv_remove,
> + .otherend_changed = backend_on_changed,
> +};
> +
> +static int __init xen_drv_init(void)
> +{
> + if (!xen_domain())
> + return -ENODEV;
> +
> + if (xen_initial_domain()) {
> + DRM_ERROR(XENDISPL_DRIVER_NAME " cannot run in initial 
> domain\n");
> + return -ENODEV;
> + }

Why not? Wouldn't that be possible in case of the backend living in a
driver domain?


Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

[Juergen Gross]

On 21/02/18 09:47, Oleksandr Andrushchenko wrote:
> On 02/21/2018 10:19 AM, Juergen Gross wrote:
>> On 21/02/18 09:03, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko 
>>>
>>> Introduce skeleton of the para-virtualized Xen display
>>> frontend driver. This patch only adds required
>>> essential stubs.
>>>
>>> Signed-off-by: Oleksandr Andrushchenko
>>> 
>>> ---
>>>   drivers/gpu/drm/Kconfig |  2 +
>>>   drivers/gpu/drm/Makefile    |  1 +
>>>   drivers/gpu/drm/xen/Kconfig | 17 
>>>   drivers/gpu/drm/xen/Makefile    |  5 +++
>>>   drivers/gpu/drm/xen/xen_drm_front.c | 83
>>> +
>>>   5 files changed, 108 insertions(+)
>>>   create mode 100644 drivers/gpu/drm/xen/Kconfig
>>>   create mode 100644 drivers/gpu/drm/xen/Makefile
>>>   create mode 100644 drivers/gpu/drm/xen/xen_drm_front.c
>>>
>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>> index deeefa7a1773..757825ac60df 100644
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
>>>     source "drivers/gpu/drm/tve200/Kconfig"
>>>   +source "drivers/gpu/drm/xen/Kconfig"
>>> +
>>>   # Keep legacy drivers last
>>>     menuconfig DRM_LEGACY
>>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>>> index 50093ff4479b..9d66657ea117 100644
>>> --- a/drivers/gpu/drm/Makefile
>>> +++ b/drivers/gpu/drm/Makefile
>>> @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB)    += mxsfb/
>>>   obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
>>>   obj-$(CONFIG_DRM_PL111) += pl111/
>>>   obj-$(CONFIG_DRM_TVE200) += tve200/
>>> +obj-$(CONFIG_DRM_XEN) += xen/
>>> diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
>>> new file mode 100644
>>> index ..4cca160782ab
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/xen/Kconfig
>>> @@ -0,0 +1,17 @@
>>> +config DRM_XEN
>>> +    bool "DRM Support for Xen guest OS"
>>> +    depends on XEN
>>> +    help
>>> +  Choose this option if you want to enable DRM support
>>> +  for Xen.
>>> +
>>> +config DRM_XEN_FRONTEND
>>> +    tristate "Para-virtualized frontend driver for Xen guest OS"
>>> +    depends on DRM_XEN
>>> +    depends on DRM
>>> +    select DRM_KMS_HELPER
>>> +    select VIDEOMODE_HELPERS
>>> +    select XEN_XENBUS_FRONTEND
>>> +    help
>>> +  Choose this option if you want to enable a para-virtualized
>>> +  frontend DRM/KMS driver for Xen guest OSes.
>>> diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
>>> new file mode 100644
>>> index ..967074d348f6
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/xen/Makefile
>>> @@ -0,0 +1,5 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +
>>> +drm_xen_front-objs := xen_drm_front.o
>>> +
>>> +obj-$(CONFIG_DRM_XEN_FRONTEND) += drm_xen_front.o
>>> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
>>> b/drivers/gpu/drm/xen/xen_drm_front.c
>>> new file mode 100644
>>> index ..fd372fb464a1
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
>>> @@ -0,0 +1,83 @@
>>> +/*
>>> + *  Xen para-virtual DRM device
>>> + *
>>> + *   This program is free software; you can redistribute it and/or
>>> modify
>>> + *   it under the terms of the GNU General Public License as
>>> published by
>>> + *   the Free Software Foundation; either version 2 of the License, or
>>> + *   (at your option) any later version.
>>> + *
>>> + *   This program is distributed in the hope that it will be useful,
>>> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + *   GNU General Public License for more details.
>> Use SPDX identifier instead (same applies for all other new
>> sources):
>>
>> // SPDX-License-Identifier: GPL-2.0
> Will update, thank you
>>> + *
>>> + * Copyright (C) 2016-2018 EPAM Systems Inc.
>>> + *
>>> + * Author: Oleksandr Andrushchenko 
>>> + */
>>> +
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +static void backend_on_changed(struct xenbus_device *xb_dev,
>>> +    enum xenbus_state backend_state)
>>> +{
>>> +}
>>> +
>>> +static int xen_drv_probe(struct xenbus_device *xb_dev,
>>> +    const struct xenbus_device_id *id)
>>> +{
>>> +    return 0;
>>> +}
>>> +
>>> +static int xen_drv_remove(struct xenbus_device *dev)
>>> +{
>>> +    return 0;
>>> +}
>>> +
>>> +static const struct xenbus_device_id xen_drv_ids[] = {
>>> +    { XENDISPL_DRIVER_NAME },
>>> +    { "" }
>>> +};
>>> +
>>> +static struct xenbus_driver xen_driver = {
>>> +    .ids = xen_drv_ids,
>>> +    .probe = xen_drv_probe,
>>> +    .remove = xen_drv_remove,
>>> +    .otherend_changed = backend_on_changed,
>>> +};
>>> +
>>> +static int __init xen_drv_init(void)
>>> +{
>>> +    if (!xen_domain())
>>> +    return 

Re: [Xen-devel] [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

[Roger Pau Monné]

On Wed, Feb 21, 2018 at 11:42:23AM +0200, Oleksandr Andrushchenko wrote:
> On 02/21/2018 11:17 AM, Roger Pau Monné wrote:
> > On Wed, Feb 21, 2018 at 10:03:34AM +0200, Oleksandr Andrushchenko wrote:
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> > > @@ -0,0 +1,83 @@
> > > +/*
> > > + *  Xen para-virtual DRM device
> > > + *
> > > + *   This program is free software; you can redistribute it and/or modify
> > > + *   it under the terms of the GNU General Public License as published by
> > > + *   the Free Software Foundation; either version 2 of the License, or
> > > + *   (at your option) any later version.
> > > + *
> > > + *   This program is distributed in the hope that it will be useful,
> > > + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + *   GNU General Public License for more details.
> > Most Xen drivers in Linux use a dual GPL/BSD license, so that they can
> > be imported into other non GPL OSes:
> > 
> > This program is free software; you can redistribute it and/or
> > modify it under the terms of the GNU General Public License version 2
> > as published by the Free Software Foundation; or, when distributed
> > separately from the Linux kernel or incorporated into other
> > software packages, subject to the following license:
> > 
> > Permission is hereby granted, free of charge, to any person obtaining a copy
> > of this source file (the "Software"), to deal in the Software without
> > restriction, including without limitation the rights to use, copy, modify,
> > merge, publish, distribute, sublicense, and/or sell copies of the Software,
> > and to permit persons to whom the Software is furnished to do so, subject to
> > the following conditions:
> > 
> > The above copyright notice and this permission notice shall be included in
> > all copies or substantial portions of the Software.
> > 
> > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> > AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> > IN THE SOFTWARE.
> > 
> > IMO it would be good to release this driver under the same license, so
> > it can be incorporated into other OSes.
> I am in any way expert in licensing, but the above seems to be
> /* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
> At least this is what I see at [1] for MIT.
> Could you please tell which license(s) as listed at [1]
> would be appropriate for Xen drivers in terms of how it is
> expected to appear in the kernel code, e.g. expected
> SPDX-License-Identifier?

I would be fine with anything MIT/BSD-*/Apache-* like. In the Xen
community we have generally done dual GPL-2.0 MIT, so your proposed
tag looks fine IMO (I would also personally be fine with
MIT/BSD-*/Apache-* only).

The point is that it would be good to have the code under a more
permissive license so it can be integrated into non GPL OSes in the
future if needed, and that your code could be used as a reference for
that.

Thanks, Roger.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers

[Tomasz Figa]

On Fri, Feb 16, 2018 at 9:13 AM, Tomasz Figa  wrote:
> On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy  wrote:
>> On 15/02/18 04:17, Tomasz Figa wrote:
>> [...]

 Could you elaborate on what kind of locking you are concerned about?
 As I explained before, the normally happening fast path would lock
 dev->power_lock only for the brief moment of incrementing the runtime
 PM usage counter.
>>>
>>>
>>> My bad, that's not even it.
>>>
>>> The atomic usage counter is incremented beforehands, without any
>>> locking [1] and the spinlock is acquired only for the sake of
>>> validating that device's runtime PM state remained valid indeed [2],
>>> which would be the case in the fast path of the same driver doing two
>>> mappings in parallel, with the master powered on (and so the SMMU,
>>> through device links; if master was not powered on already, powering
>>> on the SMMU is unavoidable anyway and it would add much more latency
>>> than the spinlock itself).
>>
>>
>> We now have no locking at all in the map path, and only a per-domain lock
>> around TLB sync in unmap which is unfortunately necessary for correctness;
>> the latter isn't too terrible, since in "serious" hardware it should only be
>> serialising a few cpus serving the same device against each other (e.g. for
>> multiple queues on a single NIC).
>>
>> Putting in a global lock which serialises *all* concurrent map and unmap
>> calls for *all* unrelated devices makes things worse. Period. Even if the
>> lock itself were held for the minimum possible time, i.e. trivially
>> "spin_lock(); spin_unlock()", the cost of repeatedly bouncing that
>> one cache line around between 96 CPUs across two sockets is not negligible.
>
> Fair enough. Note that we're in a quite interesting situation now:
>  a) We need to have runtime PM enabled on Qualcomm SoC to have power
> properly managed,
>  b) We need to have lock-free map/unmap on such distributed systems,
>  c) If runtime PM is enabled, we need to call into runtime PM from any
> code that does hardware accesses, otherwise the IOMMU API (and so DMA
> API and then any V4L2 driver) becomes unusable.
>
> I can see one more way that could potentially let us have all the
> three. How about enabling runtime PM only on selected implementations
> (e.g. qcom,smmu) and then having all the runtime PM calls surrounded
> with if (pm_runtime_enabled()), which is lockless?
>

Sorry for pinging, but any opinion on this kind of approach?

Best regards,
Tomasz

>>
>>> [1]
>>> http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L1028
>>> [2]
>>> http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L613
>>>
>>> In any case, I can't imagine this working with V4L2 or anything else
>>> relying on any memory management more generic than calling IOMMU API
>>> directly from the driver, with the IOMMU device having runtime PM
>>> enabled, but without managing the runtime PM from the IOMMU driver's
>>> callbacks that need access to the hardware. As I mentioned before,
>>> only the IOMMU driver knows when exactly the real hardware access
>>> needs to be done (e.g. Rockchip/Exynos don't need to do that for
>>> map/unmap if the power is down, but some implementations of SMMU with
>>> TLB powered separately might need to do so).
>>
>>
>> It's worth noting that Exynos and Rockchip are relatively small
>> self-contained IP blocks integrated closely with the interfaces of their
>> relevant master devices; SMMU is an architecture, implementations of which
>> may be large, distributed, and have complex and wildly differing internal
>> topologies. As such, it's a lot harder to make hardware-specific assumptions
>> and/or be correct for all possible cases.
>>
>> Don't get me wrong, I do ultimately agree that the IOMMU driver is the only
>> agent who ultimately knows what calls are going to be necessary for whatever
>> operation it's performing on its own hardware*; it's just that for SMMU it
>> needs to be implemented in a way that has zero impact on the cases where it
>> doesn't matter, because it's not viable to specialise that driver for any
>> particular IP implementation/use-case.
>
> Still, exactly the same holds for the low power embedded use cases,
> where we strive for the lowest possible power consumption, while
> maintaining performance levels high as well. And so the SMMU code is
> expected to also work with our use cases, such as V4L2 or DRM drivers.
> Since these points don't hold for current SMMU code, I could say that
> the it has been already specialized for large, distributed
> implementations.
>
> Best regards,
> Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel