[PATCH] drm/i915/pmu: Fix sleep under atomic in RC6 readout

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We are not allowed to call intel_runtime_pm_get from the PMU counter read
callback since the former can sleep, and the latter is running under IRQ
context.

To workaround this, we start our timer when we detect that we have failed
to obtain a runtime PM reference during read, and approximate the growing
RC6 counter from the timer.

Once the timer manages to obtain the runtime PM reference, we stop the
timer and go back to the above described behaviour.

We have to be careful not to overshoot the RC6 estimate, so once resumed
after a period of approximation, we only update the counter once it
catches up. With the observation that RC6 is increasing while the device
is suspended, this should not pose a problem and can only cause
slight inaccuracies due clock base differences.

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104943
Fixes: 6060b6aec03c ("drm/i915/pmu: Add RC6 residency metrics")
Testcase: igt/perf_pmu/rc6-runtime-pm
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Imre Deak 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_pmu.c | 149 ++--
 drivers/gpu/drm/i915/i915_pmu.h |   1 +
 2 files changed, 114 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c440460255d..dca41c072a7c 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -90,23 +90,16 @@ static unsigned int event_enabled_bit(struct perf_event 
*event)
return config_enabled_bit(event->attr.config);
 }
 
-static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
+static bool
+__pmu_needs_timer(struct drm_i915_private *i915, u64 enable, bool gpu_active)
 {
-   u64 enable;
-
-   /*
-* Only some counters need the sampling timer.
-*
-* We start with a bitmask of all currently enabled events.
-*/
-   enable = i915->pmu.enable;
-
/*
-* Mask out all the ones which do not need the timer, or in
+* Mask out all events which do not need the timer, or in
 * other words keep all the ones that could need the timer.
 */
enable &= config_enabled_mask(I915_PMU_ACTUAL_FREQUENCY) |
  config_enabled_mask(I915_PMU_REQUESTED_FREQUENCY) |
+ config_enabled_mask(I915_PMU_RC6_RESIDENCY) |
  ENGINE_SAMPLE_MASK;
 
/*
@@ -130,6 +123,11 @@ static bool pmu_needs_timer(struct drm_i915_private *i915, 
bool gpu_active)
return enable;
 }
 
+static bool pmu_needs_timer(struct drm_i915_private *i915, bool gpu_active)
+{
+   return __pmu_needs_timer(i915, i915->pmu.enable, gpu_active);
+}
+
 void i915_pmu_gt_parked(struct drm_i915_private *i915)
 {
if (!i915->pmu.base.event_init)
@@ -181,20 +179,20 @@ update_sample(struct i915_pmu_sample *sample, u32 unit, 
u32 val)
sample->cur += mul_u32_u32(val, unit);
 }
 
-static void engines_sample(struct drm_i915_private *dev_priv)
+static bool engines_sample(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
enum intel_engine_id id;
bool fw = false;
 
if ((dev_priv->pmu.enable & ENGINE_SAMPLE_MASK) == 0)
-   return;
+   return false;
 
if (!dev_priv->gt.awake)
-   return;
+   return false;
 
if (!intel_runtime_pm_get_if_in_use(dev_priv))
-   return;
+   return false;
 
for_each_engine(engine, dev_priv, id) {
u32 current_seqno = intel_engine_get_seqno(engine);
@@ -225,10 +223,51 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
if (fw)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 
-   intel_runtime_pm_put(dev_priv);
+   return true;
+}
+
+static u64 read_rc6_residency(struct drm_i915_private *i915)
+{
+   u64 val;
+
+   val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
+  VLV_GT_RENDER_RC6 : GEN6_GT_GFX_RC6);
+   if (HAS_RC6p(i915))
+   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
+   if (HAS_RC6pp(i915))
+   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
+
+   return val;
+}
+
+static void
+update_rc6_sample(struct drm_i915_private *i915, u64 val, bool locked)
+{
+   unsigned long flags;
+
+   if (!locked)
+   spin_lock_irqsave(>pmu.lock, flags);
+
+   /*
+* Update stored RC6 counter only if it is greater than the current
+* value. This 

[PATCH] video: fbdev: vermilion: use 64-bit arithmetic instead of 32-bit

[Gustavo A. R. Silva]

Cast _pitch_ to u64 in order to give the compiler complete information
about the proper arithmetic to use. Notice that this variable is
being used in a context that expects an expression of type u64
(64 bits, unsigned).

The expression pitch * var->yres_virtual is currently being evaluated
using 32-bit arithmetic and the result of the operation is being stored
into variable mem, which is a variable of type u64. Based on that,
chances are there is a potential integer overflow as a result of the
operation.

Addresses-Coverity-ID: 200655 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/vermilion/vermilion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/vermilion/vermilion.c 
b/drivers/video/fbdev/vermilion/vermilion.c
index 6f8d444..5172fa5 100644
--- a/drivers/video/fbdev/vermilion/vermilion.c
+++ b/drivers/video/fbdev/vermilion/vermilion.c
@@ -651,7 +651,7 @@ static int vmlfb_check_var_locked(struct fb_var_screeninfo 
*var,
}
 
pitch = ALIGN((var->xres * var->bits_per_pixel) >> 3, 0x40);
-   mem = pitch * var->yres_virtual;
+   mem = (u64)pitch * var->yres_virtual;
if (mem > vinfo->vram_contig_size) {
return -ENOMEM;
}
-- 
2.7.4

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

Re: [PATCH v3 03/20] kconfig: Remove leftover references to AVR32 symbol

[Ulf Magnusson]

On Tue, Feb 6, 2018 at 1:08 PM, Mark Brown  wrote:
> On Mon, Feb 05, 2018 at 08:05:39PM +0100, Ulf Magnusson wrote:
>> The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
>> support for AVR32 architecture"). Remove the remaining references to it
>> from the Kconfig files.
>
>>  drivers/spi/Kconfig   | 2 +-
>>  drivers/video/console/Kconfig | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> It'd probably be easier to just submit these as separate patches to the
> individual subsystems, that'd make it more likely that reviewers will
> see them.  As I've no context for this I can't tell if there's any
> dependencies, I'm guessing not but just in case
>
> Acked-by: Mark Brown 

Done

https://lkml.org/lkml/2018/2/6/805
https://lkml.org/lkml/2018/2/6/808

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

[PATCH v4 2/3] drm/i915: Free memdup-ed DSI VBT data structures on driver_unload

[Hans de Goede]

Make intel_bios_cleanup function free the DSI VBT data structures which
are memdup-ed by parse_mipi_config() and parse_mipi_sequence().

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_bios.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index f9550507bb9f..18110bbd9ee2 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1629,6 +1629,12 @@ void intel_bios_cleanup(struct drm_i915_private 
*dev_priv)
dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+   kfree(dev_priv->vbt.dsi.data);
+   dev_priv->vbt.dsi.data = NULL;
+   kfree(dev_priv->vbt.dsi.pps);
+   dev_priv->vbt.dsi.pps = NULL;
+   kfree(dev_priv->vbt.dsi.config);
+   dev_priv->vbt.dsi.config = NULL;
 }
 
 /**
-- 
2.14.3

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

[PATCH] spi: kconfig: Remove AVR32 dep. from SPI_ATMEL

[Ulf Magnusson]

The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
support for AVR32 architecture").

Signed-off-by: Ulf Magnusson 
---
 drivers/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 603783976b81..c1e455d46c7f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -72,7 +72,7 @@ config SPI_ARMADA_3700
 config SPI_ATMEL
tristate "Atmel SPI Controller"
depends on HAS_DMA
-   depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
+   depends on (ARCH_AT91 || COMPILE_TEST)
help
  This selects a driver for the Atmel SPI Controller, present on
  many AT32 (AVR32) and AT91 (ARM) chips.
-- 
2.14.1

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

[PATCH v4 3/3] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v3

[Hans de Goede]

So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
index = 3, one of which has been kindly provided to me by Jan Brummer,
where not working with the i915 driver, giving a black screen on the
first modeset.

The problem with at least these Dells is that their VBT defines a MIPI
ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
reset in their INIT_OTP sequence, but the deassert must be done before
calling intel_dsi_device_ready(), so that is too late.

Simply doing the INIT_OTP sequence earlier is not enough to fix this,
because the INIT_OTP sequence also sends various MIPI packets to the
panel, which can only happen after calling intel_dsi_device_ready().

This commit fixes this by splitting the INIT_OTP sequence into everything
before the first DSI packet and everything else, including the first DSI
packet. The first part (everything before the first DSI packet) is then
used as deassert sequence.

Changed in v2:
-Split the init OTP sequence into a deassert reset and the actual init
 OTP sequence, instead of calling it earlier and then having the first
 mipi_exec_send_packet() call call intel_dsi_device_ready().

Changes in v3:
-Move the whole shebang to intel_bios.c

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82880
References: https://bugs.freedesktop.org/show_bug.cgi?id=101205
Cc: Jan-Michael Brummer 
Reported-by: Jan-Michael Brummer 
Tested-by: Hans de Goede 
Reviewed-by: Ville Syrjälä 
Acked-by: Jani Nikula 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c | 84 +++
 2 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1cccea1b87bc..b3c4fde600eb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1356,6 +1356,7 @@ struct intel_vbt_data {
u32 size;
u8 *data;
const u8 *sequence[MIPI_SEQ_MAX];
+   u8 *deassert_seq; /* Used by fixup_mipi_sequences() */
} dsi;
 
int crt_ddc_pin;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 18110bbd9ee2..797d1aecda03 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -947,6 +947,86 @@ static int goto_next_sequence_v3(const u8 *data, int 
index, int total)
return 0;
 }
 
+/*
+ * Get len of pre-fixed deassert fragment from a v1 init OTP sequence,
+ * skip all delay + gpio operands and stop at the first DSI packet op.
+ */
+static int get_init_otp_deassert_fragment_len(struct drm_i915_private 
*dev_priv)
+{
+   const u8 *data = dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP];
+   int index, len;
+
+   if (WARN_ON(!data || dev_priv->vbt.dsi.seq_version != 1))
+   return 0;
+
+   /* index = 1 to skip sequence byte */
+   for (index = 1; data[index] != MIPI_SEQ_ELEM_END; index += len) {
+   switch (data[index]) {
+   case MIPI_SEQ_ELEM_SEND_PKT:
+   return index == 1 ? 0 : index;
+   case MIPI_SEQ_ELEM_DELAY:
+   len = 5; /* 1 byte for operand + uint32 */
+   break;
+   case MIPI_SEQ_ELEM_GPIO:
+   len = 3; /* 1 byte for op, 1 for gpio_nr, 1 for value */
+   break;
+   default:
+   return 0;
+   }
+   }
+
+   return 0;
+}
+
+/*
+ * Some v1 VBT MIPI sequences do the deassert in the init OTP sequence.
+ * The deassert must be done before calling intel_dsi_device_ready, so for
+ * these devices we split the init OTP sequence into a deassert sequence and
+ * the actual init OTP part.
+ */
+static void fixup_mipi_sequences(struct drm_i915_private *dev_priv)
+{
+   u8 *init_otp;
+   int len;
+
+   /* Limit this to VLV for now. */
+   if (!IS_VALLEYVIEW(dev_priv))
+   return;
+
+   /* Limit this to v1 vid-mode sequences */
+   if (dev_priv->vbt.dsi.config->is_cmd_mode ||
+   dev_priv->vbt.dsi.seq_version != 1)
+   return;
+
+   /* Only do this if there are otp and assert seqs and no deassert seq */
+   if (!dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP] ||
+   !dev_priv->vbt.dsi.sequence[MIPI_SEQ_ASSERT_RESET] ||
+   dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET])
+   return;
+
+   /* The deassert-sequence ends at the first DSI packet */
+   len = get_init_otp_deassert_fragment_len(dev_priv);
+   if (!len)
+   return;
+
+   DRM_DEBUG_KMS("Using init OTP fragment to deassert reset\n");
+
+   /* Copy the fragment, update seq byte and terminate it */
+   init_otp = (u8 

[PATCH v4 1/3] drm/i915: Add intel_bios_cleanup() function

[Hans de Goede]

Add an intel_bios_cleanup() function to act as counterpart of
intel_bios_init() and move the cleanup of vbt related resources there,
putting it in the same file as the allocation.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_drv.c   | 14 +-
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c | 21 +
 3 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e9f1daf258fe..7f094bbc2a7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1446,19 +1446,7 @@ void i915_driver_unload(struct drm_device *dev)
 
intel_modeset_cleanup(dev);
 
-   /*
-* free the memory space allocated for the child device
-* config parsed from VBT
-*/
-   if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
-   kfree(dev_priv->vbt.child_dev);
-   dev_priv->vbt.child_dev = NULL;
-   dev_priv->vbt.child_dev_num = 0;
-   }
-   kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
-   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
-   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
-   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+   intel_bios_cleanup(dev_priv);
 
vga_switcheroo_unregister_client(pdev);
vga_client_register(pdev, NULL, NULL, NULL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d6b5ac2a563d..1cccea1b87bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3675,6 +3675,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
*dev_priv);
 
 /* intel_bios.c */
 void intel_bios_init(struct drm_i915_private *dev_priv);
+void intel_bios_cleanup(struct drm_i915_private *dev_priv);
 bool intel_bios_is_valid_vbt(const void *buf, size_t size);
 bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
 bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
*i2c_pin);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 4e74aa2f16bc..f9550507bb9f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1610,6 +1610,27 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
pci_unmap_rom(pdev, bios);
 }
 
+/**
+ * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
+ * @dev_priv: i915 device instance
+ */
+void intel_bios_cleanup(struct drm_i915_private *dev_priv)
+{
+   /*
+* free the memory space allocated for the child device
+* config parsed from VBT
+*/
+   if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
+   kfree(dev_priv->vbt.child_dev);
+   dev_priv->vbt.child_dev = NULL;
+   dev_priv->vbt.child_dev_num = 0;
+   }
+   kfree(dev_priv->vbt.sdvo_lvds_vbt_mode);
+   dev_priv->vbt.sdvo_lvds_vbt_mode = NULL;
+   kfree(dev_priv->vbt.lfp_lvds_vbt_mode);
+   dev_priv->vbt.lfp_lvds_vbt_mode = NULL;
+}
+
 /**
  * intel_bios_is_tv_present - is integrated TV present in VBT
  * @dev_priv:  i915 device instance
-- 
2.14.3

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

Re: [PATCH v3 03/20] kconfig: Remove leftover references to AVR32 symbol

[Ulf Magnusson]

On Mon, Feb 5, 2018 at 8:05 PM, Ulf Magnusson  wrote:
> The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
> support for AVR32 architecture"). Remove the remaining references to it
> from the Kconfig files.
>
> Signed-off-by: Ulf Magnusson 
> ---
> Changes in v3:
> Removal of the AVR32 dependency in PWM_ATMEL is already pending:
> https://lkml.org/lkml/2018/1/18/699
>
> Changes in v2:
> Removal of AVR32_AT32AP_CPUFREQ is already pending in
> https://marc.info/?i=20180118200202.11883-1-clabbe.montjoie%40gmail.com (which
> also does it properly -- I forgot to search for related files here). Just
> remove the other references.
>
>  drivers/spi/Kconfig   | 2 +-
>  drivers/video/console/Kconfig | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 603783976b81..c1e455d46c7f 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -72,7 +72,7 @@ config SPI_ARMADA_3700
>  config SPI_ATMEL
> tristate "Atmel SPI Controller"
> depends on HAS_DMA
> -   depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
> +   depends on (ARCH_AT91 || COMPILE_TEST)
> help
>   This selects a driver for the Atmel SPI Controller, present on
>   many AT32 (AVR32) and AT91 (ARM) chips.
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index 7f1f1fbcef9e..be63759b6027 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -7,7 +7,7 @@ menu "Console display driver support"
>  config VGA_CONSOLE
> bool "VGA text console" if EXPERT || !X86
> depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
> -   !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
> +   !SUPERH && !BLACKFIN && !MN10300 && !CRIS && \
> (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || 
> ARCH_NETWINDER) && \
> !ARM64 && !ARC && !MICROBLAZE && !OPENRISC
> default y
> --
> 2.14.1
>

Superseded by two patches, split up per subsystem:

https://lkml.org/lkml/2018/2/6/805
https://lkml.org/lkml/2018/2/6/808

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

[PATCH v2] drm/i915/pmu: Fix sleep under atomic in RC6 readout

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We are not allowed to call intel_runtime_pm_get from the PMU counter read
callback since the former can sleep, and the latter is running under IRQ
context.

To workaround this, we record the last known RC6 and while runtime
suspended estimate its increase by querying the runtime PM core
timestamps.

Downside of this approach is that we can temporarily lose a chunk of RC6
time, from the last PMU read-out to runtime suspend entry, but that will
eventually catch up, once device comes back online and in the presence of
PMU queries.

Also, we have to be careful not to overshoot the RC6 estimate, so once
resumed after a period of approximation, we only update the counter once
it catches up. With the observation that RC6 is increasing while the
device is suspended, this should not pose a problem and can only cause
slight inaccuracies due clock base differences.

v2: Simplify by estimating on top of PM core counters. (Imre)

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104943
Fixes: 6060b6aec03c ("drm/i915/pmu: Add RC6 residency metrics")
Testcase: igt/perf_pmu/rc6-runtime-pm
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Imre Deak 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_pmu.c | 93 ++---
 drivers/gpu/drm/i915/i915_pmu.h |  6 +++
 2 files changed, 84 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 1c440460255d..bfc402d47609 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -415,7 +415,81 @@ static int i915_pmu_event_init(struct perf_event *event)
return 0;
 }
 
-static u64 __i915_pmu_event_read(struct perf_event *event)
+static u64 get_rc6(struct drm_i915_private *i915, bool locked)
+{
+   unsigned long flags;
+   u64 val;
+
+   if (intel_runtime_pm_get_if_in_use(i915)) {
+   val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
+  VLV_GT_RENDER_RC6 :
+  GEN6_GT_GFX_RC6);
+
+   if (HAS_RC6p(i915))
+   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
+
+   if (HAS_RC6pp(i915))
+   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
+
+   intel_runtime_pm_put(i915);
+
+   /*
+* If we are coming back from being runtime suspended we must
+* be careful not to report a larger value than returned
+* previously.
+*/
+
+   if (!locked)
+   spin_lock_irqsave(>pmu.lock, flags);
+
+   if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
+   i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
+   i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
+   } else {
+   val = i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
+   }
+
+   if (!locked)
+   spin_unlock_irqrestore(>pmu.lock, flags);
+   } else {
+   struct pci_dev *pdev = i915->drm.pdev;
+   struct device *kdev = >dev;
+   unsigned long flags2;
+
+   /*
+* We are runtime suspended.
+*
+* Report the delta from when the device was suspended to now,
+* on top of the last known real value, as the approximated RC6
+* counter value.
+*/
+   if (!locked)
+   spin_lock_irqsave(>pmu.lock, flags);
+
+   spin_lock_irqsave(>power.lock, flags2);
+
+   if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
+   i915->pmu.suspended_jiffies_last =
+   kdev->power.suspended_jiffies;
+
+   val = kdev->power.suspended_jiffies -
+ i915->pmu.suspended_jiffies_last;
+   val += jiffies - kdev->power.accounting_timestamp;
+
+   spin_unlock_irqrestore(>power.lock, flags2);
+
+   val = jiffies_to_nsecs(val);
+   val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
+   i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
+
+   if (!locked)
+   spin_unlock_irqrestore(>pmu.lock, flags);
+   }
+
+   return val;
+}
+
+static u64 __i915_pmu_event_read(struct perf_event *event, bool locked)
 {

[PATCH v2] Documentation/ABI: add sysfs interface for s6e63m0 lcd driver

[Aishwarya Pant]

Document sysfs attributes of s6e63m0 lcd panel driver by looking through
git logs and reading code.

Signed-off-by: Aishwarya Pant 
---
Changes in v2:
- Update contact information

 Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-lcd-s6e63m0

diff --git a/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 
b/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0
new file mode 100644
index ..ae0a2d3dcc07
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0
@@ -0,0 +1,27 @@
+sysfs interface for the S6E63M0 AMOLED LCD panel driver
+---
+
+What:  /sys/class/lcd//gamma_mode
+Date:  May, 2010
+KernelVersion: v2.6.35
+Contact:   dri-devel@lists.freedesktop.org
+Description:
+   (RW) Read or write the gamma mode. Following three modes are
+   supported:
+   0 - gamma value 2.2,
+   1 - gamma value 1.9 and
+   2 - gamma value 1.7.
+
+
+What:  /sys/class/lcd//gamma_table
+Date:  May, 2010
+KernelVersion: v2.6.35
+Contact:   dri-devel@lists.freedesktop.org
+Description:
+   (RO) Displays the size of the gamma table i.e. the number of
+   gamma modes available.
+
+This is a backlight lcd driver. These interfaces are an extension to the API
+documented in Documentation/ABI/testing/sysfs-class-lcd and in
+Documentation/ABI/stable/sysfs-class-backlight (under
+/sys/class/backlight//).
-- 
2.16.1

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Tomeu Vizoso]

On 02/07/2018 02:09 AM, Michael S. Tsirkin wrote:

On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:

Creation of shareable buffer by guest
-

1. Client requests virtio driver to create a buffer suitable for sharing
with host (DRM_VIRTGPU_RESOURCE_CREATE)


client or guest proxy?


4. QEMU maps that buffer to the guest's address space
(KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver


That part is problematic.  The host can't simply allocate something in
the physical address space, because most physical address space
management is done by the guest.  All pci bars are mapped by the guest
firmware for example (or by the guest OS in case of hotplug).


4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
resource, sends data + FDs to the compositor with SCM_RIGHTS


If you squint hard, this sounds a bit like a use-case for vhost-user-gpu, does 
it not?


Can you extend on what makes you think that?

As an aside, crosvm runs the virtio-gpu device in a separate, jailed
process, among other virtual devices.

https://chromium.googlesource.com/chromiumos/platform/crosvm/

Regards,

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

[PATCH] video: console: kconfig: Remove AVR32 dep. from VGA_CONSOLE

[Ulf Magnusson]

The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
support for AVR32 architecture").

Signed-off-by: Ulf Magnusson 
---
 drivers/video/console/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 7f1f1fbcef9e..be63759b6027 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -7,7 +7,7 @@ menu "Console display driver support"
 config VGA_CONSOLE
bool "VGA text console" if EXPERT || !X86
depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
-   !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
+   !SUPERH && !BLACKFIN && !MN10300 && !CRIS && \
(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) 
&& \
!ARM64 && !ARC && !MICROBLAZE && !OPENRISC
default y
-- 
2.14.1

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

Re: [PATCH 0/5] prevent OOM triggered by TTM

[Thomas Hellstrom]

Hi, Roger,

On 02/06/2018 10:04 AM, Roger He wrote:

currently ttm code has no any allocation limit. So it allows pages
allocatation unlimited until OOM. Because if swap space is full
of swapped pages and then system memory will be filled up with ttm
pages. and then any memory allocation request will trigger OOM.



I'm a bit curious, isn't this the way things are supposed to work on a 
linux system?
If all memory resources are used up, the OOM killer will kill the most 
memory hungry (perhaps rogue) process
rather than processes being nice and try to find out themselves whether 
allocations will succeed?
Why should TTM be different in that aspect? It would be good to know 
your reasoning WRT this?


Admittedly, graphics process OOM memory accounting doesn't work very 
well, due to not all BOs not being

CPU mapped, but it looks like there is recent work towards fixing this?

One thing I looked at at one point was to have TTM do the swapping 
itself instead of handing it off to the
shmem system. That way we could pre-allocate swap entries for all 
swappable (BO) memory, making sure that
we wouldn't run out of swap space when, for example, hibernating and 
that would also limit the pinned
non-swappable memory (from TTM driver kernel allocations for example) to 
half the system memory resources.


Thanks,
Thomas

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

[radeon-alex:amd-staging-drm-next 85/381] sound/soc//amd/raven/acp3x-pcm-dma.c:246:10: error: implicit declaration of function 'page_to_phys'; did you mean 'page_to_pfn'?

[kbuild test robot]

Hi Maruthi,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   987aae1f47ba0fe5a320d013d2bf97b5f9922761
commit: 4ab7d004f9ff2e877caa267887360e1804b4edcf [85/381] ASoC: AMD: enable 
ACP3x drivers build
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4ab7d004f9ff2e877caa267887360e1804b4edcf
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   In file included from sound/soc//amd/raven/acp3x-pcm-dma.c:26:0:
   sound/soc//amd/raven/acp3x.h: In function 'rv_readl':
   sound/soc//amd/raven/acp3x.h:28:9: error: implicit declaration of function 
'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
 return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
   sound/soc//amd/raven/acp3x.h: In function 'rv_writel':
   sound/soc//amd/raven/acp3x.h:33:2: error: implicit declaration of function 
'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
 writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
 ^~
 vwrite
   sound/soc//amd/raven/acp3x-pcm-dma.c: In function 'config_acp3x_dma':
>> sound/soc//amd/raven/acp3x-pcm-dma.c:246:10: error: implicit declaration of 
>> function 'page_to_phys'; did you mean 'page_to_pfn'? 
>> [-Werror=implicit-function-declaration]
  addr = page_to_phys(pg);
 ^~~~
 page_to_pfn
   sound/soc//amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
   sound/soc//amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of 
function 'devm_ioremap'; did you mean 'devm_kmemdup'? 
[-Werror=implicit-function-declaration]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
 ^~~~
 devm_kmemdup
   sound/soc//amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
 adata->acp3x_base = devm_ioremap(>dev, res->start,
   ^
   cc1: some warnings being treated as errors

vim +246 sound/soc//amd/raven/acp3x-pcm-dma.c

090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  222  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  223  static void 
config_acp3x_dma(struct i2s_stream_instance *rtd, int direction)
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  224  {
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  225   u16 page_idx;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  226   u64 addr;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  227   u32 low, high, val, 
acp_fifo_addr;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  228   struct page *pg = 
rtd->pg;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  229  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  230   /* 8 scratch registers 
used to map one 64 bit address.
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  231* For 2 pages (4096 * 
2 bytes), it will be 16 registers.
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  232*/
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  233   if (direction == 
SNDRV_PCM_STREAM_PLAYBACK)
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  234   val = 0;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  235   else
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  236   val = 16;
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  237  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  238   /* Group Enable */
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  239   
rv_writel(ACP_SRAM_PTE_OFFSET | BIT(31), rtd->acp3x_base +
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  240   
mmACPAXI2AXI_ATU_BASE_ADDR_GRP_1);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  241   
rv_writel(PAGE_SIZE_4K_ENABLE, rtd->acp3x_base +
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  242   
mmACPAXI2AXI_ATU_PAGE_SIZE_GRP_1);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  243  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  244   for (page_idx = 0; 
page_idx < rtd->num_pages; page_idx++) {
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  245   /* Load the low 
address of page int ACP SRAM through SRBM */
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29 @246   addr = 
page_to_phys(pg);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  247   low = 
lower_32_bits(addr);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  248   high = 
upper_32_bits(addr);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  249  
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  250   rv_writel(low, 
rtd->acp3x_base + mmACP_SCRATCH_REG_0 + val);
41456703 Maruthi Srinivas Bayyavarapu 2017-03-29  251   high |= 

Re: [Intel-gfx] [PATCH 06/10] drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()

[Pandiyan, Dhinakaran]

On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pandiyan wrote:
> 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> return type for drm_crtc_vblank_count() to u64. This could cause
> potential problems if the return value is used in arithmetic operations
> with a 32-bit reference HW vblank count. Explicitly typecasting this
> down to u32 either fixes a potential problem or serves to add clarity in
> case the implicit typecasting was already correct.
> 
> Cc: Keith Packard 
> Cc: Thierry Reding 


Thierry, 

Can I get an Ack on this please? 

> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/tegra/dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index b8403ed48285..49df2db2ad46 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -1359,7 +1359,7 @@ static u32 tegra_dc_get_vblank_counter(struct drm_crtc 
> *crtc)
>   return host1x_syncpt_read(dc->syncpt);
>  
>   /* fallback to software emulated VBLANK counter */
> - return drm_crtc_vblank_count(>base);
> + return (u32)drm_crtc_vblank_count(>base);
>  }
>  
>  static int tegra_dc_enable_vblank(struct drm_crtc *crtc)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 4/5] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort

[Hyun Kwon]

This driver creates DRM encoder and connector for ZynqMP DisplayPort.

Signed-off-by: Hyun Kwon 
Acked-by: Daniel Vetter 
---
v2
- Change the SPDX identifier format
- Split drm properties into a separate patch
---
---
 drivers/gpu/drm/xlnx/zynqmp_dp.c | 1738 ++
 drivers/gpu/drm/xlnx/zynqmp_dp.h |   37 +
 2 files changed, 1775 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h

diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
new file mode 100644
index 000..9c9f4df
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -0,0 +1,1738 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP DisplayPort Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "zynqmp_disp.h"
+#include "zynqmp_dpsub.h"
+
+static uint zynqmp_dp_aux_timeout_ms = 50;
+module_param_named(aux_timeout_ms, zynqmp_dp_aux_timeout_ms, uint, 0444);
+MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in msec (default: 50)");
+
+/*
+ * Some sink requires a delay after power on request
+ */
+static uint zynqmp_dp_power_on_delay_ms = 4;
+module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint, 0444);
+MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
+
+/* Link configuration registers */
+#define ZYNQMP_DP_TX_LINK_BW_SET   0x0
+#define ZYNQMP_DP_TX_LANE_CNT_SET  0x4
+#define ZYNQMP_DP_TX_ENHANCED_FRAME_EN 0x8
+#define ZYNQMP_DP_TX_TRAINING_PATTERN_SET  0xc
+#define ZYNQMP_DP_TX_SCRAMBLING_DISABLE0x14
+#define ZYNQMP_DP_TX_DOWNSPREAD_CTL0x18
+#define ZYNQMP_DP_TX_SW_RESET  0x1c
+#define ZYNQMP_DP_TX_SW_RESET_STREAM1  BIT(0)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM2  BIT(1)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM3  BIT(2)
+#define ZYNQMP_DP_TX_SW_RESET_STREAM4  BIT(3)
+#define ZYNQMP_DP_TX_SW_RESET_AUX  BIT(7)
+#define ZYNQMP_DP_TX_SW_RESET_ALL  
(ZYNQMP_DP_TX_SW_RESET_STREAM1 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM2 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM3 | \
+
ZYNQMP_DP_TX_SW_RESET_STREAM4 | \
+
ZYNQMP_DP_TX_SW_RESET_AUX)
+
+/* Core enable registers */
+#define ZYNQMP_DP_TX_ENABLE0x80
+#define ZYNQMP_DP_TX_ENABLE_MAIN_STREAM0x84
+#define ZYNQMP_DP_TX_FORCE_SCRAMBLER_RESET 0xc0
+#define ZYNQMP_DP_TX_VERSION   0xf8
+#define ZYNQMP_DP_TX_VERSION_MAJOR_MASKGENMASK(31, 24)
+#define ZYNQMP_DP_TX_VERSION_MAJOR_SHIFT   24
+#define ZYNQMP_DP_TX_VERSION_MINOR_MASKGENMASK(23, 16)
+#define ZYNQMP_DP_TX_VERSION_MINOR_SHIFT   16
+#define ZYNQMP_DP_TX_VERSION_REVISION_MASK GENMASK(15, 12)
+#define ZYNQMP_DP_TX_VERSION_REVISION_SHIFT12
+#define ZYNQMP_DP_TX_VERSION_PATCH_MASKGENMASK(11, 8)
+#define ZYNQMP_DP_TX_VERSION_PATCH_SHIFT   8
+#define ZYNQMP_DP_TX_VERSION_INTERNAL_MASK GENMASK(7, 0)
+#define ZYNQMP_DP_TX_VERSION_INTERNAL_SHIFT0
+
+/* Core ID registers */
+#define ZYNQMP_DP_TX_CORE_ID   0xfc
+#define ZYNQMP_DP_TX_CORE_ID_MAJOR_MASKGENMASK(31, 24)
+#define ZYNQMP_DP_TX_CORE_ID_MAJOR_SHIFT   24
+#define ZYNQMP_DP_TX_CORE_ID_MINOR_MASKGENMASK(23, 16)
+#define ZYNQMP_DP_TX_CORE_ID_MINOR_SHIFT   16
+#define ZYNQMP_DP_TX_CORE_ID_REVISION_MASK GENMASK(15, 8)
+#define ZYNQMP_DP_TX_CORE_ID_REVISION_SHIFT8
+#define ZYNQMP_DP_TX_CORE_ID_DIRECTION GENMASK(1)
+
+/* AUX channel interface registers */
+#define ZYNQMP_DP_TX_AUX_COMMAND   0x100
+#define ZYNQMP_DP_TX_AUX_COMMAND_CMD_SHIFT 8
+#define 

[PATCH v5 3/5] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DP subsystem display

[Hyun Kwon]

Xilinx ZynqMP has a hardened display pipeline. The pipeline can
be logically partitioned into 2 parts: display controller and
DisplayPort encoder / transmitter. This driver handles the display
controller part of the pipeline that handles buffer management and
blending.

Signed-off-by: Hyun Kwon 
Acked-by: Daniel Vetter 
---
v4
- Use drm_crtc_funcs for vblank
- Remove child nodes for layer
v3
- Fix a small typo
v2
- Use drm_fb_cma_get_gem_addr()
- Use drm_crtc_arm_vblank_event()
- Split drm properties into a separate patch
- Remove dummy funcs
- Don't add offset as it's already done by a new helper
- Change the SPDX identifier format
- Minor change of a commit message
---
---
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 2676 
 drivers/gpu/drm/xlnx/zynqmp_disp.h |   36 +
 2 files changed, 2712 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.h

diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
new file mode 100644
index 000..e47d77d
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -0,0 +1,2676 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP Display Controller Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xlnx_crtc.h"
+#include "xlnx_fb.h"
+#include "zynqmp_disp.h"
+#include "zynqmp_dp.h"
+#include "zynqmp_dpsub.h"
+
+/*
+ * Overview
+ * 
+ *
+ * The display part of ZynqMP DP subsystem. Internally, the device
+ * is partitioned into 3 blocks: AV buffer manager, Blender, Audio.
+ * The driver creates the DRM crtc and plane objectes and maps the DRM
+ * interface into those 3 blocks. In high level, the driver is layered
+ * in the following way:
+ *
+ * zynqmp_disp_crtc & zynqmp_disp_plane
+ * |->zynqmp_disp
+ * |->zynqmp_disp_aud
+ * |->zynqmp_disp_blend
+ * |->zynqmp_disp_av_buf
+ *
+ * The driver APIs are used externally by
+ * - zynqmp_dpsub: Top level ZynqMP DP subsystem driver
+ * - zynqmp_dp: ZynqMP DP driver
+ * - xlnx_crtc: Xilinx DRM specific crtc functions
+ */
+
+/* Blender registers */
+#define ZYNQMP_DISP_V_BLEND_BG_CLR_0   0x0
+#define ZYNQMP_DISP_V_BLEND_BG_CLR_1   0x4
+#define ZYNQMP_DISP_V_BLEND_BG_CLR_2   0x8
+#define ZYNQMP_DISP_V_BLEND_BG_MAX 0xfff
+#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA   0xc
+#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA_MASK  0x1fe
+#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA_MAX   0xff
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT 0x14
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_RGB 0x0
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YCBCR4440x1
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YCBCR4220x2
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YONLY   0x3
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_XVYCC   0x4
+#define ZYNQMP_DISP_V_BLEND_OUTPUT_EN_DOWNSAMPLE   BIT(4)
+#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL  0x18
+#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_EN_USBIT(0)
+#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_RGB  BIT(1)
+#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_BYPASS   BIT(8)
+#define ZYNQMP_DISP_V_BLEND_NUM_COEFF  9
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF0   0x20
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF1   0x24
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF2   0x28
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF3   0x2c
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF4   0x30
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF5   0x34
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF6   0x38
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF7   0x3c
+#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF8   0x40
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF0  0x44
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF1  0x48
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF2  0x4c
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF3  0x50
+#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF4  0x54
+#define 

[PATCH v5 5/5] drm: xlnx: ZynqMP DP subsystem DRM KMS driver

[Hyun Kwon]

This is a wrapper around the ZynqMP Display and DisplayPort drivers.

Signed-off-by: Hyun Kwon 
Acked-by: Daniel Vetter 
---
v4
- Use the newly added xlnx pipeline calls to initialize drm device
v2
- Change the SPDX identifier format
---
---
 drivers/gpu/drm/xlnx/Kconfig|  11 +++
 drivers/gpu/drm/xlnx/Makefile   |   3 +
 drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 155 
 drivers/gpu/drm/xlnx/zynqmp_dpsub.h |  28 +++
 4 files changed, 197 insertions(+)
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.c
 create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.h

diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
index 19fd7cd..7c5529c 100644
--- a/drivers/gpu/drm/xlnx/Kconfig
+++ b/drivers/gpu/drm/xlnx/Kconfig
@@ -10,3 +10,14 @@ config DRM_XLNX
  display pipeline using Xilinx IPs in FPGA. This module
  provides the kernel mode setting functionalities
  for Xilinx display drivers.
+
+config DRM_ZYNQMP_DPSUB
+   tristate "ZynqMP DP Subsystem Driver"
+   depends on ARCH_ZYNQMP && OF && DRM_XLNX && COMMON_CLK
+   select DMA_ENGINE
+   select GENERIC_PHY
+   help
+ DRM KMS driver for ZynqMP DP Subsystem controller. Choose
+ this option if you have a Xilinx ZynqMP SoC with DisplayPort
+ subsystem. The driver provides the kernel mode setting
+ functionlaities for ZynqMP DP subsystem.
diff --git a/drivers/gpu/drm/xlnx/Makefile b/drivers/gpu/drm/xlnx/Makefile
index c60a281..064a05a 100644
--- a/drivers/gpu/drm/xlnx/Makefile
+++ b/drivers/gpu/drm/xlnx/Makefile
@@ -1,2 +1,5 @@
 xlnx_drm-objs += xlnx_crtc.o xlnx_drv.o xlnx_fb.o xlnx_gem.o
 obj-$(CONFIG_DRM_XLNX) += xlnx_drm.o
+
+zynqmp-dpsub-objs += zynqmp_disp.o zynqmp_dpsub.o zynqmp_dp.o
+obj-$(CONFIG_DRM_ZYNQMP_DPSUB) += zynqmp-dpsub.o
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c 
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
new file mode 100644
index 000..5aaf9fb
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP DP Subsystem Driver
+ *
+ *  Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ *  Author: Hyun Woo Kwon 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xlnx_drv.h"
+
+#include "zynqmp_disp.h"
+#include "zynqmp_dp.h"
+#include "zynqmp_dpsub.h"
+
+static int
+zynqmp_dpsub_bind(struct device *dev, struct device *master, void *data)
+{
+   int ret;
+
+   ret = zynqmp_disp_bind(dev, master, data);
+   if (ret)
+   return ret;
+
+   /* zynqmp_disp should bind first, so zynqmp_dp encoder can find crtc */
+   ret = zynqmp_dp_bind(dev, master, data);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static void
+zynqmp_dpsub_unbind(struct device *dev, struct device *master, void *data)
+{
+   zynqmp_dp_unbind(dev, master, data);
+   zynqmp_disp_unbind(dev, master, data);
+}
+
+static const struct component_ops zynqmp_dpsub_component_ops = {
+   .bind   = zynqmp_dpsub_bind,
+   .unbind = zynqmp_dpsub_unbind,
+};
+
+static int zynqmp_dpsub_probe(struct platform_device *pdev)
+{
+   struct zynqmp_dpsub *dpsub;
+   int ret;
+
+   dpsub = devm_kzalloc(>dev, sizeof(*dpsub), GFP_KERNEL);
+   if (!dpsub)
+   return -ENOMEM;
+
+   /* Sub-driver will access dpsub from drvdata */
+   platform_set_drvdata(pdev, dpsub);
+   pm_runtime_enable(>dev);
+
+   /*
+* DP should be probed first so that the zynqmp_disp can set the output
+* format accordingly.
+*/
+   ret = zynqmp_dp_probe(pdev);
+   if (ret)
+   goto err_pm;
+
+   ret = zynqmp_disp_probe(pdev);
+   if (ret)
+   goto err_dp;
+
+   ret = component_add(>dev, _dpsub_component_ops);
+   if (ret)
+   goto err_disp;
+
+   /* Populate the sound child nodes */
+   ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, >dev);
+   if (ret) {
+   dev_err(>dev, "failed to populate child nodes\n");
+   goto err_component;
+   }
+
+   dev_info(>dev, "ZynqMP DisplayPort Subsystem driver probed");
+
+   dpsub->master = xlnx_drm_pipeline_init(pdev);
+
+   return 0;
+
+err_component:
+   component_del(>dev, _dpsub_component_ops);
+err_disp:
+   zynqmp_disp_remove(pdev);
+err_dp:
+   zynqmp_dp_remove(pdev);
+err_pm:

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

[Hyun Kwon]

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
+---
+
+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.
+
+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";
+   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>;
+   };
+};
+
-- 
2.7.4

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

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

[Hyun Kwon]

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,
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

diff --git a/MAINTAINERS b/MAINTAINERS
index 5bc088f..07c0e73 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4789,6 +4789,15 @@ F:   drivers/gpu/drm/etnaviv/
 F: include/uapi/drm/etnaviv_drm.h
 F: Documentation/devicetree/bindings/display/etnaviv/
 
+DRM DRIVERS FOR XILINX
+M: Hyun Kwon 
+M: Laurent Pinchart 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/xlnx/
+F: Documentation/devicetree/bindings/display/xlnx/
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DRM DRIVERS FOR ZTE ZX
 M: Shawn Guo 
 L: dri-devel@lists.freedesktop.org
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index deeefa7..5a3ec66 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/xlnx/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff..f93557e 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_XLNX) += xlnx/
diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
new file mode 100644
index 000..19fd7cd
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/Kconfig
@@ -0,0 +1,12 @@
+config DRM_XLNX
+   tristate "Xilinx DRM KMS Driver"
+   depends on DRM && OF
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   help
+ Xilinx DRM KMS driver. Choose this option if you have
+ a Xilinx SoCs with hardened display pipeline or soft
+ display pipeline using Xilinx IPs in FPGA. This module
+ provides the kernel mode setting functionalities
+ for Xilinx display drivers.
diff --git a/drivers/gpu/drm/xlnx/Makefile b/drivers/gpu/drm/xlnx/Makefile
new file mode 100644
index 000..c60a281
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/Makefile
@@ -0,0 +1,2 @@
+xlnx_drm-objs += xlnx_crtc.o xlnx_drv.o xlnx_fb.o xlnx_gem.o
+obj-$(CONFIG_DRM_XLNX) += xlnx_drm.o
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
+++ 

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Michael S. Tsirkin]

On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote:
> > Creation of shareable buffer by guest
> > -
> > 
> > 1. Client requests virtio driver to create a buffer suitable for sharing
> > with host (DRM_VIRTGPU_RESOURCE_CREATE)
> 
> client or guest proxy?
> 
> > 4. QEMU maps that buffer to the guest's address space
> > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver
> 
> That part is problematic.  The host can't simply allocate something in
> the physical address space, because most physical address space
> management is done by the guest.  All pci bars are mapped by the guest
> firmware for example (or by the guest OS in case of hotplug).
> 
> > 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
> > resource, sends data + FDs to the compositor with SCM_RIGHTS

If you squint hard, this sounds a bit like a use-case for vhost-user-gpu, does 
it not?

> BTW: Is there a 1:1 relationship between buffers and shmem blocks?  Or
> does the wayland protocol allow for offsets in buffer meta data, so you
> can place multiple buffers in a single shmem block?
> 
> cheers,
>   Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-drm-next 1/3] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:3: error: 'const struct pp_hwmgr_func' has no member named 'set_mmhub_powergating_by_smu'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   987aae1f47ba0fe5a320d013d2bf97b5f9922761
commit: 6bea4fd090e45704decd1abf47431ad1c1e56977 [1/3] drm/amd/powerplay: 
implement set_mmhub_powergating_by_smu for Raven
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 6bea4fd090e45704decd1abf47431ad1c1e56977
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: the radeon-alex/amd-staging-drm-next HEAD 
987aae1f47ba0fe5a320d013d2bf97b5f9922761 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:3: error: 
>> 'const struct pp_hwmgr_func' has no member named 
>> 'set_mmhub_powergating_by_smu'
 .set_mmhub_powergating_by_smu = rv_set_mmhub_powergating_by_smu,
  ^~~~
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:34: error: 
>> initialization from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 .set_mmhub_powergating_by_smu = rv_set_mmhub_powergating_by_smu,
 ^~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c:1067:34: note: 
(near initialization for 'rv_hwmgr_funcs.patch_boot_state')
   cc1: some warnings being treated as errors

vim +1067 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/rv_hwmgr.c

  1033  
  1034  static const struct pp_hwmgr_func rv_hwmgr_funcs = {
  1035  .backend_init = rv_hwmgr_backend_init,
  1036  .backend_fini = rv_hwmgr_backend_fini,
  1037  .asic_setup = NULL,
  1038  .apply_state_adjust_rules = rv_apply_state_adjust_rules,
  1039  .force_dpm_level = rv_dpm_force_dpm_level,
  1040  .get_power_state_size = rv_get_power_state_size,
  1041  .powerdown_uvd = NULL,
  1042  .powergate_uvd = NULL,
  1043  .powergate_vce = NULL,
  1044  .get_mclk = rv_dpm_get_mclk,
  1045  .get_sclk = rv_dpm_get_sclk,
  1046  .patch_boot_state = rv_dpm_patch_boot_state,
  1047  .get_pp_table_entry = rv_dpm_get_pp_table_entry,
  1048  .get_num_of_pp_table_entries = 
rv_dpm_get_num_of_pp_table_entries,
  1049  .set_cpu_power_state = rv_set_cpu_power_state,
  1050  .store_cc6_data = rv_store_cc6_data,
  1051  .force_clock_level = rv_force_clock_level,
  1052  .print_clock_levels = rv_print_clock_levels,
  1053  .get_dal_power_level = rv_get_dal_power_level,
  1054  .get_performance_level = rv_get_performance_level,
  1055  .get_current_shallow_sleep_clocks = 
rv_get_current_shallow_sleep_clocks,
  1056  .get_clock_by_type_with_latency = 
rv_get_clock_by_type_with_latency,
  1057  .get_clock_by_type_with_voltage = 
rv_get_clock_by_type_with_voltage,
  1058  .get_max_high_clocks = rv_get_max_high_clocks,
  1059  .read_sensor = rv_read_sensor,
  1060  .set_active_display_count = rv_set_active_display_count,
  1061  .set_deep_sleep_dcefclk = rv_set_deep_sleep_dcefclk,
  1062  .dynamic_state_management_enable = rv_enable_dpm_tasks,
  1063  .power_off_asic = rv_power_off_asic,
  1064  .asic_setup = rv_setup_asic_task,
  1065  .power_state_set = rv_set_power_state_tasks,
  1066  .dynamic_state_management_disable = rv_disable_dpm_tasks,
> 1067  .set_mmhub_powergating_by_smu = rv_set_mmhub_powergating_by_smu,
  1068  };
  1069  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104216] Firefox quirks (black and/or white squares)

[bugzilla-daemon]

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

--- Comment #15 from Germano Massullo  ---
I am trying to build Mesa 17.0.5 but I had no success, even passing the older
llvm to the old compiler. I had not the time to go deeper and check what
happened to the build
https://copr.fedorainfracloud.org/coprs/germano/mesa_test_regression/builds/

but meanwhile I manage to record a video of the bug
https://youtu.be/Tt44jJ1KDdI

-- 
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 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

[bugzilla-daemon]

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

--- Comment #12 from Przemek  ---
The valid mailing list post, when it comes to messages "swiotlb buffer is full"
and "swiotlb: coherent allocation failed", is:
https://lkml.org/lkml/2018/1/10/132. Thanks to Alex Deucher correcting me in
another bug report.

-- 
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 v2] drm/i915/pmu: Fix sleep under atomic in RC6 readout

[Imre Deak]

Hi Rafael,

On Tue, Feb 06, 2018 at 09:11:02PM +, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-02-06 18:33:11)
> > From: Tvrtko Ursulin 
> > 
> > We are not allowed to call intel_runtime_pm_get from the PMU counter read
> > callback since the former can sleep, and the latter is running under IRQ
> > context.
> > 
> > To workaround this, we record the last known RC6 and while runtime
> > suspended estimate its increase by querying the runtime PM core
> > timestamps.
> > 
> > Downside of this approach is that we can temporarily lose a chunk of RC6
> > time, from the last PMU read-out to runtime suspend entry, but that will
> > eventually catch up, once device comes back online and in the presence of
> > PMU queries.
> > 
> > Also, we have to be careful not to overshoot the RC6 estimate, so once
> > resumed after a period of approximation, we only update the counter once
> > it catches up. With the observation that RC6 is increasing while the
> > device is suspended, this should not pose a problem and can only cause
> > slight inaccuracies due clock base differences.
> > 
> > v2: Simplify by estimating on top of PM core counters. (Imre)
> > 
> > Signed-off-by: Tvrtko Ursulin 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104943
> > Fixes: 6060b6aec03c ("drm/i915/pmu: Add RC6 residency metrics")
> > Testcase: igt/perf_pmu/rc6-runtime-pm
> > Cc: Tvrtko Ursulin 
> > Cc: Chris Wilson 
> > Cc: Imre Deak 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Rodrigo Vivi 
> > Cc: David Airlie 
> > Cc: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > ---
> >  drivers/gpu/drm/i915/i915_pmu.c | 93 
> > ++---
> >  drivers/gpu/drm/i915/i915_pmu.h |  6 +++
> >  2 files changed, 84 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c 
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index 1c440460255d..bfc402d47609 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -415,7 +415,81 @@ static int i915_pmu_event_init(struct perf_event 
> > *event)
> > return 0;
> >  }
> >  
> > -static u64 __i915_pmu_event_read(struct perf_event *event)
> > +static u64 get_rc6(struct drm_i915_private *i915, bool locked)
> > +{
> > +   unsigned long flags;
> > +   u64 val;
> > +
> > +   if (intel_runtime_pm_get_if_in_use(i915)) {
> > +   val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
> > +  VLV_GT_RENDER_RC6 :
> > +  GEN6_GT_GFX_RC6);
> > +
> > +   if (HAS_RC6p(i915))
> > +   val += intel_rc6_residency_ns(i915, 
> > GEN6_GT_GFX_RC6p);
> > +
> > +   if (HAS_RC6pp(i915))
> > +   val += intel_rc6_residency_ns(i915, 
> > GEN6_GT_GFX_RC6pp);
> > +
> > +   intel_runtime_pm_put(i915);
> > +
> > +   /*
> > +* If we are coming back from being runtime suspended we 
> > must
> > +* be careful not to report a larger value than returned
> > +* previously.
> > +*/
> > +
> > +   if (!locked)
> > +   spin_lock_irqsave(>pmu.lock, flags);
> > +
> > +   if (val >= 
> > i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
> > +   i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 
> > 0;
> > +   i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
> > +   } else {
> > +   val = 
> > i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
> > +   }
> > +
> > +   if (!locked)
> > +   spin_unlock_irqrestore(>pmu.lock, flags);
> > +   } else {
> > +   struct pci_dev *pdev = i915->drm.pdev;
> > +   struct device *kdev = >dev;
> > +   unsigned long flags2;
> > +
> > +   /*
> > +* We are runtime suspended.
> > +*
> > +* Report the delta from when the device was suspended to 
> > now,
> > +* on top of the last known real value, as the approximated 
> > RC6
> > +* counter value.
> > +*/
> > +   if (!locked)
> > +   spin_lock_irqsave(>pmu.lock, flags);
> > +
> > +   spin_lock_irqsave(>power.lock, flags2);
> > +
> > +   if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> > +   i915->pmu.suspended_jiffies_last =
> > +   
> > kdev->power.suspended_jiffies;
> > +
> > +   val = 

Re: [PATCH 1/3] drm/panel: simple: Add ability to override typical timing

[Sean Paul]

On Tue, Feb 06, 2018 at 02:19:34PM -0600, Rob Herring wrote:
> On Tue, Feb 6, 2018 at 10:56 AM, Sean Paul  wrote:
> > This patch adds the ability to override the typical display timing for a
> > given panel. This is useful for devices which have timing constraints
> > that do not apply across the entire display driver (eg: to avoid
> > crosstalk between panel and digitizer on certain laptops). The rules are
> > as follows:
> >
> > - panel must not specify fixed mode (since the override mode will
> >   either be the same as the fixed mode, or we'll be unable to
> >   check the bounds of the overried)
> > - panel must specify at least one display_timing range which will be
> >   used to ensure the override mode fits within its bounds
> >
> > Cc: Doug Anderson 
> > Cc: Heiko Stuebner 
> > Cc: Jeffy Chen 
> > Cc: Rob Herring 
> > Cc: Stéphane Marchesin 
> > Cc: Thierry Reding 
> > Cc: devicet...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-rockc...@lists.infradead.org
> > Signed-off-by: Sean Paul 
> > ---
> >  .../bindings/display/panel/simple-panel.txt| 20 +++
> 
> The binding should be a separate patch.
> 

Ack, will split.


> >  drivers/gpu/drm/panel/panel-simple.c   | 69 
> > +-
> >  2 files changed, 88 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
> > b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > index 16d8ff088b7d..590bbff6fc90 100644
> > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > @@ -7,6 +7,14 @@ Optional properties:
> >  - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> >  - enable-gpios: GPIO pin to enable or disable the panel
> >  - backlight: phandle of the backlight device attached to the panel
> > +- override-mode: For devices which require a mode which differs from the
> 
> This is not a property, but a node so it needs its own section.
> 
> Also, it's not real clear from display-timing.txt, but the modes
> should be grouped under a display-timings node. Looks like we haven't
> been good at enforcing that as "panel-timing" is also common when
> there's a single mode. I'd rather not have another way. With a
> standard node name, we can validate the node more easily.
> 
> We'd lose the fact that this is explicitly an override, but I'd doubt
> Thierry is going to start letting in panels with no timings.
> 

Yeah, I noticed that the timing subnode was specified as nestled in
display-timings. I figured since there can only be one override mode, and the
of_get_display_timing function was exported, it would be Ok to just reuse the
format of the subnode. I'll respin with the full thing.


> Finally, since this is an override, is it valid to only override the
> parameters that need overriding? I don't really have an opinion either
> way. It just needs to be explicitly documented.

I'll pimp the documentation. My gut reaction is to specify everything, since
this should be a very conscious decision, and having to fully specify the mode
seems like the right thing to do.

Thanks for your review!

Sean

> 
> > +display_timing's "typical" mode, and whose restrictions 
> > cannot
> > +be applied across the entire platform. The mode must fall
> > +within the bounds of the panel's specified display_timing, 
> > and
> > +cannot be used if the panel already specifies a single 
> > fixed
> > +mode. The format is specified under "timing subnode" in
> > +display-timing.txt
> > +
> >
> >  Example:
> >
> > @@ -18,4 +26,16 @@ Example:
> > enable-gpios = < 90 0>;
> >
> > backlight = <>;
> > +
> > +   override-mode {
> > +   clock-frequency = <266604720>;
> > +   hactive = <2400>;
> > +   hfront-porch = <48>;
> > +   hback-porch = <84>;
> > +   hsync-len = <32>;
> > +   vactive = <1600>;
> > +   vfront-porch = <3>;
> > +   vback-porch = <120>;
> > +   vsync-len = <10>;
> > +   }
> > };

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

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

--- Comment #9 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) 
---
I think we have to agree to differ on this one. You seem to be focussing on the
software interface between the GPU and the driver.

What follows is my personal opinion.

The most likely cause of this kind of mechanical issue is the signal path
between the video interface hardware and the outside world, either a dry joint
or a mechanical fault in the cable or cable connectors. I can only reiterate
what I said in my previous post. The driver has sufficient information to
determine that a hard failure has occured, and that failure is probably not in
the gpu itself. I would like to see the driver doing a hard reset of the card
with rigorous error checking. If it cannot reset the GPU in graphical mode it
should try to set the display hardware into a basic console mode.

-- 
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 2/2] drm/tilcdc: panel: Use common error handling code in of_get_panel_info()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 6 Feb 2018 22:10:11 +0100

Add a jump target so that a bit of exception handling can be better reused
at the end of this function.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 0b6aa95aec89..cf9ca16fee81 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -289,10 +289,8 @@ static struct tilcdc_panel_info *of_get_panel_info(struct 
device_node *np)
}
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
-   if (!info) {
-   of_node_put(info_np);
-   return NULL;
-   }
+   if (!info)
+   goto put_node;
 
ret |= of_property_read_u32(info_np, "ac-bias", >ac_bias);
ret |= of_property_read_u32(info_np, "ac-bias-intrpt", 
>ac_bias_intrpt);
@@ -311,11 +309,11 @@ static struct tilcdc_panel_info *of_get_panel_info(struct 
device_node *np)
if (ret) {
pr_err("%s: error reading panel-info properties\n", __func__);
kfree(info);
-   of_node_put(info_np);
-   return NULL;
+   info = NULL;
}
-   of_node_put(info_np);
 
+put_node:
+   of_node_put(info_np);
return info;
 }
 
-- 
2.16.1

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

[PATCH 1/2] drm/tilcdc: Delete an error message for a failed memory allocation in seven functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 6 Feb 2018 21:51:15 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 4 +---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 4 +---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 9 ++---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 8 ++--
 4 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 8bf6bb93dc79..1b278a22c8b7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -994,10 +994,8 @@ int tilcdc_crtc_create(struct drm_device *dev)
int ret;
 
tilcdc_crtc = devm_kzalloc(dev->dev, sizeof(*tilcdc_crtc), GFP_KERNEL);
-   if (!tilcdc_crtc) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!tilcdc_crtc)
return -ENOMEM;
-   }
 
init_completion(_crtc->palette_loaded);
tilcdc_crtc->palette_base = dmam_alloc_coherent(dev->dev,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 1afde61f1247..b8a5e4ed22e6 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -233,10 +233,8 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
int ret;
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
-   if (!priv) {
-   dev_err(dev, "failed to allocate private data\n");
+   if (!priv)
return -ENOMEM;
-   }
 
ddev = drm_dev_alloc(ddrv, dev);
if (IS_ERR(ddev))
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 8eebb5f826a6..0b6aa95aec89 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -101,10 +101,8 @@ static struct drm_encoder *panel_encoder_create(struct 
drm_device *dev,
 
panel_encoder = devm_kzalloc(dev->dev, sizeof(*panel_encoder),
 GFP_KERNEL);
-   if (!panel_encoder) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!panel_encoder)
return NULL;
-   }
 
panel_encoder->mod = mod;
 
@@ -210,10 +208,8 @@ static struct drm_connector *panel_connector_create(struct 
drm_device *dev,
 
panel_connector = devm_kzalloc(dev->dev, sizeof(*panel_connector),
   GFP_KERNEL);
-   if (!panel_connector) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!panel_connector)
return NULL;
-   }
 
panel_connector->encoder = encoder;
panel_connector->mod = mod;
@@ -294,7 +290,6 @@ static struct tilcdc_panel_info *of_get_panel_info(struct 
device_node *np)
 
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info) {
-   pr_err("%s: allocation failed\n", __func__);
of_node_put(info_np);
return NULL;
}
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 7e3643462a08..c45cabb38db0 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -111,10 +111,8 @@ static struct drm_encoder *tfp410_encoder_create(struct 
drm_device *dev,
 
tfp410_encoder = devm_kzalloc(dev->dev, sizeof(*tfp410_encoder),
  GFP_KERNEL);
-   if (!tfp410_encoder) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!tfp410_encoder)
return NULL;
-   }
 
tfp410_encoder->dpms = DRM_MODE_DPMS_OFF;
tfp410_encoder->mod = mod;
@@ -224,10 +222,8 @@ static struct drm_connector 
*tfp410_connector_create(struct drm_device *dev,
 
tfp410_connector = devm_kzalloc(dev->dev, sizeof(*tfp410_connector),
GFP_KERNEL);
-   if (!tfp410_connector) {
-   dev_err(dev->dev, "allocation failed\n");
+   if (!tfp410_connector)
return NULL;
-   }
 
tfp410_connector->encoder = encoder;
tfp410_connector->mod = mod;
-- 
2.16.1

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

[PATCH 0/2] GPU-DRM-TILCDC: Adjustments for seven function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 6 Feb 2018 22:17:44 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation in seven functions
  Use common error handling code in of_get_panel_info()

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  4 +---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  4 +---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 21 +++--
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  8 ++--
 4 files changed, 11 insertions(+), 26 deletions(-)

-- 
2.16.1

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

[PATCH] configure/Makefile.am: use pkg-config to discover libatomic_ops

[Peter Seiderer]

From: Thomas Petazzoni 

The configure script currently tests the availability of libatomic_ops
by checking the presence of atomic_ops.h. While this is good enough as
an availability test, it is not sufficient as on some platforms,
libatomic_ops provides an actual shared library against which we
should be linked to access libatomic_ops functionality.

Therefore, we instead use PKG_CHECK_MODULES() to test the availability
of libatomic_ops. Besides testing its availability, this also fills in
the ATOMIC_OPS_LIBS variable with the list of libraries we need to
link with to use libatomic_ops.

All Mesa drivers that include xf86atomic.h have been updated to link
against ATOMIC_OPS_LIBS.

Of course, if we're not using libatomic_ops, ATOMIC_OPS_LIBS is empty,
and we don't link against it.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Peter Seiderer 
[Bernd: PKG_CHECK_MODULES should not fail when libatomic_ops is missing]
Signed-off-by: Bernd Kuhls 
---
 amdgpu/Makefile.am| 2 +-
 configure.ac  | 2 +-
 etnaviv/Makefile.am   | 3 ++-
 freedreno/Makefile.am | 3 ++-
 intel/Makefile.am | 3 ++-
 nouveau/Makefile.am   | 2 +-
 omap/Makefile.am  | 2 +-
 radeon/Makefile.am| 2 +-
 tegra/Makefile.am | 2 +-
 9 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
index a1b0d05c..b2bcceff 100644
--- a/amdgpu/Makefile.am
+++ b/amdgpu/Makefile.am
@@ -36,7 +36,7 @@ AM_CPPFLAGS = 
-DAMDGPU_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\"
 libdrm_amdgpu_la_LTLIBRARIES = libdrm_amdgpu.la
 libdrm_amdgpu_ladir = $(libdir)
 libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libdrm_amdgpu_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
+libdrm_amdgpu_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@ @ATOMIC_OPS_LIBS@
 
 libdrm_amdgpu_la_SOURCES = $(LIBDRM_AMDGPU_FILES)
 amdgpu_asic_id.lo: $(top_srcdir)/data/amdgpu.ids
diff --git a/configure.ac b/configure.ac
index 321ab2c0..1386d15c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -247,7 +247,7 @@ AC_CACHE_CHECK([for native atomic primitives], 
drm_cv_atomic_primitives, [
  ]],[[]])], 
[drm_cv_atomic_primitives="Intel"],[])
 
if test "x$drm_cv_atomic_primitives" = "xnone"; then
-   AC_CHECK_HEADER([atomic_ops.h], 
drm_cv_atomic_primitives="libatomic-ops")
+   PKG_CHECK_MODULES(ATOMIC_OPS, [atomic_ops], 
drm_cv_atomic_primitives="libatomic-ops", true)
fi
 
# atomic functions defined in  & libc on Solaris
diff --git a/etnaviv/Makefile.am b/etnaviv/Makefile.am
index be96ba86..669cf14f 100644
--- a/etnaviv/Makefile.am
+++ b/etnaviv/Makefile.am
@@ -12,7 +12,8 @@ libdrm_etnaviv_la_LDFLAGS = -version-number 1:0:0 
-no-undefined
 libdrm_etnaviv_la_LIBADD = \
../libdrm.la \
@PTHREADSTUBS_LIBS@ \
-   @CLOCK_LIB@
+   @CLOCK_LIB@ \
+   @ATOMIC_OPS_LIBS@
 
 libdrm_etnaviv_la_SOURCES = $(LIBDRM_ETNAVIV_FILES)
 
diff --git a/freedreno/Makefile.am b/freedreno/Makefile.am
index cbb0d031..238407e3 100644
--- a/freedreno/Makefile.am
+++ b/freedreno/Makefile.am
@@ -14,7 +14,8 @@ libdrm_freedreno_la_LDFLAGS = -version-number 1:0:0 
-no-undefined
 libdrm_freedreno_la_LIBADD = \
../libdrm.la \
@PTHREADSTUBS_LIBS@ \
-   @CLOCK_LIB@
+   @CLOCK_LIB@ \
+   @ATOMIC_OPS_LIBS@
 
 libdrm_freedreno_la_SOURCES = $(LIBDRM_FREEDRENO_FILES)
 if HAVE_FREEDRENO_KGSL
diff --git a/intel/Makefile.am b/intel/Makefile.am
index c52e8c08..f3635a64 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -38,7 +38,8 @@ libdrm_intel_la_LDFLAGS = -version-number 1:0:0 -no-undefined
 libdrm_intel_la_LIBADD = ../libdrm.la \
@PTHREADSTUBS_LIBS@ \
@PCIACCESS_LIBS@ \
-   @CLOCK_LIB@
+   @CLOCK_LIB@ \
+   @ATOMIC_OPS_LIBS@
 
 libdrm_intel_la_SOURCES = $(LIBDRM_INTEL_FILES)
 
diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
index 344a8445..a4e6a78b 100644
--- a/nouveau/Makefile.am
+++ b/nouveau/Makefile.am
@@ -10,7 +10,7 @@ AM_CFLAGS = \
 libdrm_nouveau_la_LTLIBRARIES = libdrm_nouveau.la
 libdrm_nouveau_ladir = $(libdir)
 libdrm_nouveau_la_LDFLAGS = -version-number 2:0:0 -no-undefined
-libdrm_nouveau_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
+libdrm_nouveau_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@ @ATOMIC_OPS_LIBS@
 
 libdrm_nouveau_la_SOURCES = $(LIBDRM_NOUVEAU_FILES)
 
diff --git a/omap/Makefile.am b/omap/Makefile.am
index 599bb9de..524afee3 100644
--- a/omap/Makefile.am
+++ b/omap/Makefile.am
@@ -7,7 +7,7 @@ AM_CFLAGS = \
 libdrm_omap_la_LTLIBRARIES = libdrm_omap.la
 libdrm_omap_ladir = $(libdir)
 libdrm_omap_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libdrm_omap_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
+libdrm_omap_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@ @ATOMIC_OPS_LIBS@
 
 libdrm_omap_la_SOURCES = omap_drm.c
 
diff --git a/radeon/Makefile.am 

Re: [PATCH] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Jyri Sarha]

I have not been following the subject for half a year now. Just let me
know if I can do something to help land this patch, e.g. rebase and
resend it.


On 02/06/18 20:08, Hans Verkuil wrote:
> On 02/06/2018 06:58 PM, Ville Syrjälä wrote:
>> On Mon, Jun 12, 2017 at 12:10:04AM +0300, Jyri Sarha wrote:
>>> Add a standard optional properties to support different non RGB color
>>> encodings in DRM planes. COLOR_ENCODING select the supported non RGB
>>> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
>>> the value ranges within the selected color encoding. The properties
>>> are stored to drm_plane object to allow different set of supported
>>> encoding for different planes on the device.
>>>
>>> Signed-off-by: Jyri Sarha 
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c |  8 
>>>  drivers/gpu/drm/drm_color_mgmt.c | 91 
>>> 
>>>  include/drm/drm_color_mgmt.h | 19 +
>>>  include/drm/drm_plane.h  |  8 
>>>  4 files changed, 126 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index 77dcef0..8067681 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -786,6 +786,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
>>> *plane,
>>> state->rotation = val;
>>> } else if (property == plane->zpos_property) {
>>> state->zpos = val;
>>> +   } else if (property == plane->color_encoding_property) {
>>> +   state->color_encoding = val;
>>> +   } else if (property == plane->color_range_property) {
>>> +   state->color_range = val;
>>> } else if (plane->funcs->atomic_set_property) {
>>> return plane->funcs->atomic_set_property(plane, state,
>>> property, val);
>>> @@ -846,6 +850,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
>>> *plane,
>>> *val = state->rotation;
>>> } else if (property == plane->zpos_property) {
>>> *val = state->zpos;
>>> +   } else if (property == plane->color_encoding_property) {
>>> +   *val = state->color_encoding;
>>> +   } else if (property == plane->color_range_property) {
>>> +   *val = state->color_range;
>>> } else if (plane->funcs->atomic_get_property) {
>>> return plane->funcs->atomic_get_property(plane, state, 
>>> property, val);
>>> } else {
>>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
>>> b/drivers/gpu/drm/drm_color_mgmt.c
>>> index 3eda500..9077bf6 100644
>>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>>> @@ -88,6 +88,19 @@
>>>   * drm_mode_crtc_set_gamma_size(). Drivers which support both should use
>>>   * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp 
>>> with the
>>>   * "GAMMA_LUT" property above.
>>> + *
>>> + * Support for different non RGB color encodings is controlled through
>>> + * _plane specific COLOR_ENCODING and COLOR_RANGE properties:
>>> + *
>>> + * "COLOR_ENCODING"
>>> + * Optional plane enum property to support different non RGB
>>> + * color encodings. The driver can provide a subset of standard
>>> + * enum values supported by the DRM plane.
>>> + *
>>> + * "COLOR_RANGE"
>>> + * Optional plane enum property to support different non RGB
>>> + * color parameter ranges. The driver can provide a subset of
>>> + * standard enum values supported by the DRM plane.
>>>   */
>>>  
>>>  /**
>>> @@ -336,3 +349,81 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
>>> drm_modeset_unlock(>mutex);
>>> return ret;
>>>  }
>>> +
>>> +static const char * const color_encoding_name[] = {
>>> +   [DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
>>> +   [DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
>>> +   [DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
>>
>> I was just looking at this again (in the hopes of landing it finally),
>> and then I realized we probably need to split this BT.2020 into
>> constant and non-constant luminance variants.
>>
>> ..._BT2020_CL and ..._BT2020_NCL maybe?
> 
> This is what V4L2 uses:
> 
> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html
> 
> V4L2_YCBCR_ENC_BT2020 and V4L2_YCBCR_ENC_BT2020_CONST_LUM.
> 
> I've never seen V4L2_YCBCR_ENC_BT2020_CONST_LUM in the wild. Non-constant
> Bt.2020 is what is normally used, so I'd keep the define just as-is:
> DRM_COLOR_YCBCR_BT2020. And add a DRM_COLOR_YCBCR_BT2020_CONST_LUM if
> you think you need it. I've never seen anyone use this.
> 
> And in case you wonder why: this is the BT.2020 OpenGL Y'CbCr to R'G'B'
> conversion:
> 
>   float r = y + 1.4719 * v;
> float g = y - 0.1646 * u - 0.5703 * v;
> float b = y + 1.8814 * u;
> 
> And this for BT.2020 constant luminance:
> 
>   float b = u <= 0.0 ? y + 1.9404 * u : y + 1.5816 * u;
>   float r = v <= 0.0 ? y + 1.7184 * v : y + 0.9936 * v;
>  

Re: [PATCH v2] drm/i915/pmu: Fix sleep under atomic in RC6 readout

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-06 18:33:11)
> From: Tvrtko Ursulin 
> 
> We are not allowed to call intel_runtime_pm_get from the PMU counter read
> callback since the former can sleep, and the latter is running under IRQ
> context.
> 
> To workaround this, we record the last known RC6 and while runtime
> suspended estimate its increase by querying the runtime PM core
> timestamps.
> 
> Downside of this approach is that we can temporarily lose a chunk of RC6
> time, from the last PMU read-out to runtime suspend entry, but that will
> eventually catch up, once device comes back online and in the presence of
> PMU queries.
> 
> Also, we have to be careful not to overshoot the RC6 estimate, so once
> resumed after a period of approximation, we only update the counter once
> it catches up. With the observation that RC6 is increasing while the
> device is suspended, this should not pose a problem and can only cause
> slight inaccuracies due clock base differences.
> 
> v2: Simplify by estimating on top of PM core counters. (Imre)
> 
> Signed-off-by: Tvrtko Ursulin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104943
> Fixes: 6060b6aec03c ("drm/i915/pmu: Add RC6 residency metrics")
> Testcase: igt/perf_pmu/rc6-runtime-pm
> Cc: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Cc: Imre Deak 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/i915_pmu.c | 93 
> ++---
>  drivers/gpu/drm/i915/i915_pmu.h |  6 +++
>  2 files changed, 84 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 1c440460255d..bfc402d47609 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -415,7 +415,81 @@ static int i915_pmu_event_init(struct perf_event *event)
> return 0;
>  }
>  
> -static u64 __i915_pmu_event_read(struct perf_event *event)
> +static u64 get_rc6(struct drm_i915_private *i915, bool locked)
> +{
> +   unsigned long flags;
> +   u64 val;
> +
> +   if (intel_runtime_pm_get_if_in_use(i915)) {
> +   val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
> +  VLV_GT_RENDER_RC6 :
> +  GEN6_GT_GFX_RC6);
> +
> +   if (HAS_RC6p(i915))
> +   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
> +
> +   if (HAS_RC6pp(i915))
> +   val += intel_rc6_residency_ns(i915, 
> GEN6_GT_GFX_RC6pp);
> +
> +   intel_runtime_pm_put(i915);
> +
> +   /*
> +* If we are coming back from being runtime suspended we must
> +* be careful not to report a larger value than returned
> +* previously.
> +*/
> +
> +   if (!locked)
> +   spin_lock_irqsave(>pmu.lock, flags);
> +
> +   if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) 
> {
> +   i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
> +   i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
> +   } else {
> +   val = 
> i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
> +   }
> +
> +   if (!locked)
> +   spin_unlock_irqrestore(>pmu.lock, flags);
> +   } else {
> +   struct pci_dev *pdev = i915->drm.pdev;
> +   struct device *kdev = >dev;
> +   unsigned long flags2;
> +
> +   /*
> +* We are runtime suspended.
> +*
> +* Report the delta from when the device was suspended to now,
> +* on top of the last known real value, as the approximated 
> RC6
> +* counter value.
> +*/
> +   if (!locked)
> +   spin_lock_irqsave(>pmu.lock, flags);
> +
> +   spin_lock_irqsave(>power.lock, flags2);
> +
> +   if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> +   i915->pmu.suspended_jiffies_last =
> +   kdev->power.suspended_jiffies;
> +
> +   val = kdev->power.suspended_jiffies -
> + i915->pmu.suspended_jiffies_last;
> +   val += jiffies - kdev->power.accounting_timestamp;
> +
> +   spin_unlock_irqrestore(>power.lock, flags2);
> +
> +   val = jiffies_to_nsecs(val);
> +   val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
> 

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #14 from Przemek  ---
Yes, sorry, my bad. Wrong copy-paste action here. Thanks Alex.

-- 
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 1/3] drm/panel: simple: Add ability to override typical timing

[Rob Herring]

On Tue, Feb 6, 2018 at 10:56 AM, Sean Paul  wrote:
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
>
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
>
> Cc: Doug Anderson 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  .../bindings/display/panel/simple-panel.txt| 20 +++

The binding should be a separate patch.

>  drivers/gpu/drm/panel/panel-simple.c   | 69 
> +-
>  2 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
> b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> index 16d8ff088b7d..590bbff6fc90 100644
> --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> @@ -7,6 +7,14 @@ Optional properties:
>  - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
>  - enable-gpios: GPIO pin to enable or disable the panel
>  - backlight: phandle of the backlight device attached to the panel
> +- override-mode: For devices which require a mode which differs from the

This is not a property, but a node so it needs its own section.

Also, it's not real clear from display-timing.txt, but the modes
should be grouped under a display-timings node. Looks like we haven't
been good at enforcing that as "panel-timing" is also common when
there's a single mode. I'd rather not have another way. With a
standard node name, we can validate the node more easily.

We'd lose the fact that this is explicitly an override, but I'd doubt
Thierry is going to start letting in panels with no timings.

Finally, since this is an override, is it valid to only override the
parameters that need overriding? I don't really have an opinion either
way. It just needs to be explicitly documented.

> +display_timing's "typical" mode, and whose restrictions 
> cannot
> +be applied across the entire platform. The mode must fall
> +within the bounds of the panel's specified display_timing, 
> and
> +cannot be used if the panel already specifies a single fixed
> +mode. The format is specified under "timing subnode" in
> +display-timing.txt
> +
>
>  Example:
>
> @@ -18,4 +26,16 @@ Example:
> enable-gpios = < 90 0>;
>
> backlight = <>;
> +
> +   override-mode {
> +   clock-frequency = <266604720>;
> +   hactive = <2400>;
> +   hfront-porch = <48>;
> +   hback-porch = <84>;
> +   hsync-len = <32>;
> +   vactive = <1600>;
> +   vfront-porch = <3>;
> +   vback-porch = <120>;
> +   vsync-len = <10>;
> +   }
> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #13 from Alex Deucher  ---
https://lkml.org/lkml/2018/1/10/132

-- 
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/amd/powerplay: delete some dead code

[Alex Deucher]

On Tue, Feb 6, 2018 at 7:35 AM, Dan Carpenter  wrote:
> We deleted some code in e154162ef75d ("drm/amd/powerplay: refine pp code
> for raven") but there were a few related bits that were missed.  Let's
> delete them as well.
>
> Signed-off-by: Dan Carpenter 

Applied.  Thanks!

Alex

>
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
> b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> index 565fe0832f41..0b0fbb228edf 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
> @@ -608,7 +608,6 @@ struct phm_dynamic_state_info {
> struct phm_ppm_table  *ppm_parameter_table;
> struct phm_cac_tdp_table  *cac_dtp_table;
> struct phm_clock_voltage_dependency_table   
> *vdd_gfx_dependency_on_sclk;
> -   struct phm_vq_budgeting_table   
> *vq_budgeting_table;
>  };
>
>  struct pp_fan_info {
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> index c3e7e34535e8..7545776a774d 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> @@ -1697,9 +1697,6 @@ static int pp_tables_uninitialize(struct pp_hwmgr 
> *hwmgr)
> kfree(hwmgr->dyn_state.vdd_gfx_dependency_on_sclk);
> hwmgr->dyn_state.vdd_gfx_dependency_on_sclk = NULL;
>
> -   kfree(hwmgr->dyn_state.vq_budgeting_table);
> -   hwmgr->dyn_state.vq_budgeting_table = NULL;
> -
> return 0;
>  }
>
> ___
> 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

[Bug 104194] HDMI with RX460 not working on linux 4.15-rc2 with DC enabled and linux-amd-staging-drm-next

[bugzilla-daemon]

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

--- Comment #4 from saunders...@wright.edu ---
Unplugging and replugging the cable on the GPU side causes the monitor to be
detected without DC enabled. (Haven't checked with DC.)

-- 
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 104194] HDMI with RX460 not working on linux 4.15-rc2 with DC enabled and linux-amd-staging-drm-next

[bugzilla-daemon]

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

--- Comment #3 from saunders...@wright.edu ---
I am having this issue as well on 4.15.1 without DC enabled (as well as DC
enabled) on a RX 460. Will try the cable replug on GPU side (didn't work on
monitor side.)

-- 
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 102423] kwin segfaults when Alt+Tabbing with windows thumbnails on AMDGPU

[bugzilla-daemon]

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

--- Comment #6 from pmarget...@gmail.com ---
Plasma updated to 5.12 today, and I no longer can reproduce this bug. I guess
this was on their end afterall.

-- 
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 100105] Make Theano OpenCL support work on Clover and RadeonSI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100105
Bug 100105 depends on bug 100212, which changed state.

Bug 100212 Summary: Implement vload_* and vstore_* to make Theano/libgpuarray 
working
https://bugs.freedesktop.org/show_bug.cgi?id=100212

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
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 100212] Implement vload_* and vstore_* to make Theano/libgpuarray working

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from Jan Vesely  ---
vstore_half_rtn was added in libclc r324374.

-- 
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 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 100212, which changed state.

Bug 100212 Summary: Implement vload_* and vstore_* to make Theano/libgpuarray 
working
https://bugs.freedesktop.org/show_bug.cgi?id=100212

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
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: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Ville Syrjälä]

On Tue, Feb 06, 2018 at 07:08:34PM +0100, Hans Verkuil wrote:
> On 02/06/2018 06:58 PM, Ville Syrjälä wrote:
> > On Mon, Jun 12, 2017 at 12:10:04AM +0300, Jyri Sarha wrote:
> >> Add a standard optional properties to support different non RGB color
> >> encodings in DRM planes. COLOR_ENCODING select the supported non RGB
> >> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
> >> the value ranges within the selected color encoding. The properties
> >> are stored to drm_plane object to allow different set of supported
> >> encoding for different planes on the device.
> >>
> >> Signed-off-by: Jyri Sarha 
> >> ---
> >>  drivers/gpu/drm/drm_atomic.c |  8 
> >>  drivers/gpu/drm/drm_color_mgmt.c | 91 
> >> 
> >>  include/drm/drm_color_mgmt.h | 19 +
> >>  include/drm/drm_plane.h  |  8 
> >>  4 files changed, 126 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index 77dcef0..8067681 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -786,6 +786,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
> >> *plane,
> >>state->rotation = val;
> >>} else if (property == plane->zpos_property) {
> >>state->zpos = val;
> >> +  } else if (property == plane->color_encoding_property) {
> >> +  state->color_encoding = val;
> >> +  } else if (property == plane->color_range_property) {
> >> +  state->color_range = val;
> >>} else if (plane->funcs->atomic_set_property) {
> >>return plane->funcs->atomic_set_property(plane, state,
> >>property, val);
> >> @@ -846,6 +850,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
> >> *plane,
> >>*val = state->rotation;
> >>} else if (property == plane->zpos_property) {
> >>*val = state->zpos;
> >> +  } else if (property == plane->color_encoding_property) {
> >> +  *val = state->color_encoding;
> >> +  } else if (property == plane->color_range_property) {
> >> +  *val = state->color_range;
> >>} else if (plane->funcs->atomic_get_property) {
> >>return plane->funcs->atomic_get_property(plane, state, 
> >> property, val);
> >>} else {
> >> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> >> b/drivers/gpu/drm/drm_color_mgmt.c
> >> index 3eda500..9077bf6 100644
> >> --- a/drivers/gpu/drm/drm_color_mgmt.c
> >> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> >> @@ -88,6 +88,19 @@
> >>   * drm_mode_crtc_set_gamma_size(). Drivers which support both should use
> >>   * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp 
> >> with the
> >>   * "GAMMA_LUT" property above.
> >> + *
> >> + * Support for different non RGB color encodings is controlled through
> >> + * _plane specific COLOR_ENCODING and COLOR_RANGE properties:
> >> + *
> >> + * "COLOR_ENCODING"
> >> + *Optional plane enum property to support different non RGB
> >> + *color encodings. The driver can provide a subset of standard
> >> + *enum values supported by the DRM plane.
> >> + *
> >> + * "COLOR_RANGE"
> >> + *Optional plane enum property to support different non RGB
> >> + *color parameter ranges. The driver can provide a subset of
> >> + *standard enum values supported by the DRM plane.
> >>   */
> >>  
> >>  /**
> >> @@ -336,3 +349,81 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> >>drm_modeset_unlock(>mutex);
> >>return ret;
> >>  }
> >> +
> >> +static const char * const color_encoding_name[] = {
> >> +  [DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
> >> +  [DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
> >> +  [DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
> > 
> > I was just looking at this again (in the hopes of landing it finally),
> > and then I realized we probably need to split this BT.2020 into
> > constant and non-constant luminance variants.
> > 
> > ..._BT2020_CL and ..._BT2020_NCL maybe?
> 
> This is what V4L2 uses:
> 
> https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html
> 
> V4L2_YCBCR_ENC_BT2020 and V4L2_YCBCR_ENC_BT2020_CONST_LUM.
> 
> I've never seen V4L2_YCBCR_ENC_BT2020_CONST_LUM in the wild. Non-constant
> Bt.2020 is what is normally used, so I'd keep the define just as-is:
> DRM_COLOR_YCBCR_BT2020. And add a DRM_COLOR_YCBCR_BT2020_CONST_LUM if
> you think you need it. I've never seen anyone use this.

Hmm. I suppose that's a reasonable apporach. As long as we document that
the the plain BT2020 enum value is in fact the non-const luminance
variant.

> 
> And in case you wonder why: this is the BT.2020 OpenGL Y'CbCr to R'G'B'
> conversion:
> 
>   float r = y + 1.4719 * v;
> float g = y - 0.1646 * u - 0.5703 * v;
> float b = y + 1.8814 * u;
> 
> And this for BT.2020 constant luminance:
> 
>   float b = u <= 0.0 ? y + 1.9404 * u : y + 

Re: [PATCH] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Ville Syrjälä]

On Tue, Feb 06, 2018 at 08:16:56PM +0200, Jyri Sarha wrote:
> 
> I have not been following the subject for half a year now. Just let me
> know if I can do something to help land this patch, e.g. rebase and
> resend it.

I guess I can just pick it up and repost along with my i915 stuff. I can
just toss in the const luminance thing on top I suppose.

> 
> 
> On 02/06/18 20:08, Hans Verkuil wrote:
> > On 02/06/2018 06:58 PM, Ville Syrjälä wrote:
> >> On Mon, Jun 12, 2017 at 12:10:04AM +0300, Jyri Sarha wrote:
> >>> Add a standard optional properties to support different non RGB color
> >>> encodings in DRM planes. COLOR_ENCODING select the supported non RGB
> >>> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
> >>> the value ranges within the selected color encoding. The properties
> >>> are stored to drm_plane object to allow different set of supported
> >>> encoding for different planes on the device.
> >>>
> >>> Signed-off-by: Jyri Sarha 
> >>> ---
> >>>  drivers/gpu/drm/drm_atomic.c |  8 
> >>>  drivers/gpu/drm/drm_color_mgmt.c | 91 
> >>> 
> >>>  include/drm/drm_color_mgmt.h | 19 +
> >>>  include/drm/drm_plane.h  |  8 
> >>>  4 files changed, 126 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>> index 77dcef0..8067681 100644
> >>> --- a/drivers/gpu/drm/drm_atomic.c
> >>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> @@ -786,6 +786,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
> >>> *plane,
> >>>   state->rotation = val;
> >>>   } else if (property == plane->zpos_property) {
> >>>   state->zpos = val;
> >>> + } else if (property == plane->color_encoding_property) {
> >>> + state->color_encoding = val;
> >>> + } else if (property == plane->color_range_property) {
> >>> + state->color_range = val;
> >>>   } else if (plane->funcs->atomic_set_property) {
> >>>   return plane->funcs->atomic_set_property(plane, state,
> >>>   property, val);
> >>> @@ -846,6 +850,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
> >>> *plane,
> >>>   *val = state->rotation;
> >>>   } else if (property == plane->zpos_property) {
> >>>   *val = state->zpos;
> >>> + } else if (property == plane->color_encoding_property) {
> >>> + *val = state->color_encoding;
> >>> + } else if (property == plane->color_range_property) {
> >>> + *val = state->color_range;
> >>>   } else if (plane->funcs->atomic_get_property) {
> >>>   return plane->funcs->atomic_get_property(plane, state, 
> >>> property, val);
> >>>   } else {
> >>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> >>> b/drivers/gpu/drm/drm_color_mgmt.c
> >>> index 3eda500..9077bf6 100644
> >>> --- a/drivers/gpu/drm/drm_color_mgmt.c
> >>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> >>> @@ -88,6 +88,19 @@
> >>>   * drm_mode_crtc_set_gamma_size(). Drivers which support both should use
> >>>   * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp 
> >>> with the
> >>>   * "GAMMA_LUT" property above.
> >>> + *
> >>> + * Support for different non RGB color encodings is controlled through
> >>> + * _plane specific COLOR_ENCODING and COLOR_RANGE properties:
> >>> + *
> >>> + * "COLOR_ENCODING"
> >>> + *   Optional plane enum property to support different non RGB
> >>> + *   color encodings. The driver can provide a subset of standard
> >>> + *   enum values supported by the DRM plane.
> >>> + *
> >>> + * "COLOR_RANGE"
> >>> + *   Optional plane enum property to support different non RGB
> >>> + *   color parameter ranges. The driver can provide a subset of
> >>> + *   standard enum values supported by the DRM plane.
> >>>   */
> >>>  
> >>>  /**
> >>> @@ -336,3 +349,81 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> >>>   drm_modeset_unlock(>mutex);
> >>>   return ret;
> >>>  }
> >>> +
> >>> +static const char * const color_encoding_name[] = {
> >>> + [DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
> >>> + [DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
> >>> + [DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
> >>
> >> I was just looking at this again (in the hopes of landing it finally),
> >> and then I realized we probably need to split this BT.2020 into
> >> constant and non-constant luminance variants.
> >>
> >> ..._BT2020_CL and ..._BT2020_NCL maybe?
> > 
> > This is what V4L2 uses:
> > 
> > https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html
> > 
> > V4L2_YCBCR_ENC_BT2020 and V4L2_YCBCR_ENC_BT2020_CONST_LUM.
> > 
> > I've never seen V4L2_YCBCR_ENC_BT2020_CONST_LUM in the wild. Non-constant
> > Bt.2020 is what is normally used, so I'd keep the define just as-is:
> > DRM_COLOR_YCBCR_BT2020. And add a DRM_COLOR_YCBCR_BT2020_CONST_LUM if
> > you think you need it. I've never seen anyone use this.
> > 
> > And in case you wonder why: this is the 

Re: [PATCH] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Hans Verkuil]

On 02/06/2018 06:58 PM, Ville Syrjälä wrote:
> On Mon, Jun 12, 2017 at 12:10:04AM +0300, Jyri Sarha wrote:
>> Add a standard optional properties to support different non RGB color
>> encodings in DRM planes. COLOR_ENCODING select the supported non RGB
>> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
>> the value ranges within the selected color encoding. The properties
>> are stored to drm_plane object to allow different set of supported
>> encoding for different planes on the device.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
>>  drivers/gpu/drm/drm_atomic.c |  8 
>>  drivers/gpu/drm/drm_color_mgmt.c | 91 
>> 
>>  include/drm/drm_color_mgmt.h | 19 +
>>  include/drm/drm_plane.h  |  8 
>>  4 files changed, 126 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 77dcef0..8067681 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -786,6 +786,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
>> *plane,
>>  state->rotation = val;
>>  } else if (property == plane->zpos_property) {
>>  state->zpos = val;
>> +} else if (property == plane->color_encoding_property) {
>> +state->color_encoding = val;
>> +} else if (property == plane->color_range_property) {
>> +state->color_range = val;
>>  } else if (plane->funcs->atomic_set_property) {
>>  return plane->funcs->atomic_set_property(plane, state,
>>  property, val);
>> @@ -846,6 +850,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
>> *plane,
>>  *val = state->rotation;
>>  } else if (property == plane->zpos_property) {
>>  *val = state->zpos;
>> +} else if (property == plane->color_encoding_property) {
>> +*val = state->color_encoding;
>> +} else if (property == plane->color_range_property) {
>> +*val = state->color_range;
>>  } else if (plane->funcs->atomic_get_property) {
>>  return plane->funcs->atomic_get_property(plane, state, 
>> property, val);
>>  } else {
>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
>> b/drivers/gpu/drm/drm_color_mgmt.c
>> index 3eda500..9077bf6 100644
>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>> @@ -88,6 +88,19 @@
>>   * drm_mode_crtc_set_gamma_size(). Drivers which support both should use
>>   * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp with 
>> the
>>   * "GAMMA_LUT" property above.
>> + *
>> + * Support for different non RGB color encodings is controlled through
>> + * _plane specific COLOR_ENCODING and COLOR_RANGE properties:
>> + *
>> + * "COLOR_ENCODING"
>> + *  Optional plane enum property to support different non RGB
>> + *  color encodings. The driver can provide a subset of standard
>> + *  enum values supported by the DRM plane.
>> + *
>> + * "COLOR_RANGE"
>> + *  Optional plane enum property to support different non RGB
>> + *  color parameter ranges. The driver can provide a subset of
>> + *  standard enum values supported by the DRM plane.
>>   */
>>  
>>  /**
>> @@ -336,3 +349,81 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
>>  drm_modeset_unlock(>mutex);
>>  return ret;
>>  }
>> +
>> +static const char * const color_encoding_name[] = {
>> +[DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
>> +[DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
>> +[DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",
> 
> I was just looking at this again (in the hopes of landing it finally),
> and then I realized we probably need to split this BT.2020 into
> constant and non-constant luminance variants.
> 
> ..._BT2020_CL and ..._BT2020_NCL maybe?

This is what V4L2 uses:

https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html

V4L2_YCBCR_ENC_BT2020 and V4L2_YCBCR_ENC_BT2020_CONST_LUM.

I've never seen V4L2_YCBCR_ENC_BT2020_CONST_LUM in the wild. Non-constant
Bt.2020 is what is normally used, so I'd keep the define just as-is:
DRM_COLOR_YCBCR_BT2020. And add a DRM_COLOR_YCBCR_BT2020_CONST_LUM if
you think you need it. I've never seen anyone use this.

And in case you wonder why: this is the BT.2020 OpenGL Y'CbCr to R'G'B'
conversion:

float r = y + 1.4719 * v;
float g = y - 0.1646 * u - 0.5703 * v;
float b = y + 1.8814 * u;

And this for BT.2020 constant luminance:

float b = u <= 0.0 ? y + 1.9404 * u : y + 1.5816 * u;
float r = v <= 0.0 ? y + 1.7184 * v : y + 0.9936 * v;
float lin_r = (r < 0.081) ? r / 4.5 : pow((r + 0.099) / 1.099, 1.0 / 
0.45);
float lin_b = (b < 0.081) ? b / 4.5 : pow((b + 0.099) / 1.099, 1.0 / 
0.45);
float lin_y = (y < 0.081) ? y / 4.5 : pow((y + 0.099) / 1.099, 1.0 / 
0.45);
float lin_g = lin_y / 0.6780 - lin_r * 0.2627 / 0.6780 - lin_b * 0.0593 
/ 

Re: [PATCH] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane

[Ville Syrjälä]

On Mon, Jun 12, 2017 at 12:10:04AM +0300, Jyri Sarha wrote:
> Add a standard optional properties to support different non RGB color
> encodings in DRM planes. COLOR_ENCODING select the supported non RGB
> color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects
> the value ranges within the selected color encoding. The properties
> are stored to drm_plane object to allow different set of supported
> encoding for different planes on the device.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/drm_atomic.c |  8 
>  drivers/gpu/drm/drm_color_mgmt.c | 91 
> 
>  include/drm/drm_color_mgmt.h | 19 +
>  include/drm/drm_plane.h  |  8 
>  4 files changed, 126 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 77dcef0..8067681 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -786,6 +786,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   state->rotation = val;
>   } else if (property == plane->zpos_property) {
>   state->zpos = val;
> + } else if (property == plane->color_encoding_property) {
> + state->color_encoding = val;
> + } else if (property == plane->color_range_property) {
> + state->color_range = val;
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -846,6 +850,10 @@ int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
>   *val = state->zpos;
> + } else if (property == plane->color_encoding_property) {
> + *val = state->color_encoding;
> + } else if (property == plane->color_range_property) {
> + *val = state->color_range;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 3eda500..9077bf6 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -88,6 +88,19 @@
>   * drm_mode_crtc_set_gamma_size(). Drivers which support both should use
>   * drm_atomic_helper_legacy_gamma_set() to alias the legacy gamma ramp with 
> the
>   * "GAMMA_LUT" property above.
> + *
> + * Support for different non RGB color encodings is controlled through
> + * _plane specific COLOR_ENCODING and COLOR_RANGE properties:
> + *
> + * "COLOR_ENCODING"
> + *   Optional plane enum property to support different non RGB
> + *   color encodings. The driver can provide a subset of standard
> + *   enum values supported by the DRM plane.
> + *
> + * "COLOR_RANGE"
> + *   Optional plane enum property to support different non RGB
> + *   color parameter ranges. The driver can provide a subset of
> + *   standard enum values supported by the DRM plane.
>   */
>  
>  /**
> @@ -336,3 +349,81 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
>   drm_modeset_unlock(>mutex);
>   return ret;
>  }
> +
> +static const char * const color_encoding_name[] = {
> + [DRM_COLOR_YCBCR_BT601] = "ITU-R BT.601 YCbCr",
> + [DRM_COLOR_YCBCR_BT709] = "ITU-R BT.709 YCbCr",
> + [DRM_COLOR_YCBCR_BT2020] = "ITU-R BT.2020 YCbCr",

I was just looking at this again (in the hopes of landing it finally),
and then I realized we probably need to split this BT.2020 into
constant and non-constant luminance variants.

..._BT2020_CL and ..._BT2020_NCL maybe?

> +};
> +
> +static const char * const color_range_name[] = {
> + [DRM_COLOR_YCBCR_FULL_RANGE] = "YCbCr full range",
> + [DRM_COLOR_YCBCR_LIMITED_RANGE] = "YCbCr limited range",
> +};
> +
> +/**
> + * drm_plane_create_color_properties - color encoding related plane 
> properties
> + * @supported_encodings: bitfield indicating supported color encodings
> + * @supported_ranges: bitfileld indicating supported color ranges
> + * @default_encoding: default color encoding
> + * @default_range: default color range
> + *
> + * Create and attach plane specific COLOR_ENCODING and COLOR_RANGE
> + * properties to to the drm_plane object. The supported encodings and
> + * ranges should be provided in supported_encodings and
> + * supported_ranges bitmasks. Each bit set in the bitmask indicates
> + * the its number as enum value being supported.
> + */
> +int drm_plane_create_color_properties(struct drm_plane *plane,
> +   u32 supported_encodings,
> +   u32 supported_ranges,
> +   enum drm_color_encoding default_encoding,
> +   enum drm_color_range default_range)
> +{
> + struct drm_device *dev = 

[Bug 104963] MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba HD7560D) Boot loop without radeon.dpm=0

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
Does booting with radeon.bapm=0 or radeon.bapm=1 on the kernel command line in
grub help?

-- 
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: [Intel-gfx] [PATCH] drm/i915/pmu: Fix sleep under atomic in RC6 readout

[Tvrtko Ursulin]

On 06/02/2018 16:10, Imre Deak wrote:

On Tue, Feb 06, 2018 at 04:04:10PM +, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-02-06 14:31:07)

+static u64 read_rc6_residency(struct drm_i915_private *i915)
+{
+   u64 val;
+
+   val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
+  VLV_GT_RENDER_RC6 : GEN6_GT_GFX_RC6);
+   if (HAS_RC6p(i915))
+   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
+   if (HAS_RC6pp(i915))
+   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);


We really should mention that these may produce interesting results
every 53 minutes. Switching to a timer will allow us to notice the
wraparound in each counter.


+
+   return val;
+}
+
+static void
+update_rc6_sample(struct drm_i915_private *i915, u64 val, bool locked)
+{
+   unsigned long flags;
+
+   if (!locked)
+   spin_lock_irqsave(>pmu.lock, flags);
+
+   /*
+* Update stored RC6 counter only if it is greater than the current
+* value. This deals with periods of runtime suspend during which we are
+* estimating the RC6 residency, so do not want to overshoot the real
+* value read once the device is woken up.
+*/
+   if (val > i915->pmu.sample[__I915_SAMPLE_RC6].cur)
+   i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;


64b wraparound? Maybe not today, maybe not tomorrow... ;)


But in 585 years we're in trouble? :))




+
+   /* We don't need to sample RC6 from the timer any more. */
+   i915->pmu.timer_enabled =
+   __pmu_needs_timer(i915,
+ i915->pmu.enable & 
~config_enabled_mask(I915_PMU_RC6_RESIDENCY),
+ READ_ONCE(i915->gt.awake));


But we do... :)
One thing I had in mind was to hook into runtime suspend/resume to read
the counters there and compensate, but the more I think about it, we may
as well solve the lack of resolution in the rc6 counters whilst we are
here. https://bugs.freedesktop.org/show_bug.cgi?id=94852.


How about using dev->power.suspended_jiffies?


This sounds promising and I hope it ends up with a much nicer fix so 
I'll give it a go.


RC6 wraparound issue I hope we can leave for a different patch. I hope 
it will be possible without a timer, as long as someone is not taking 
samples every 54 minutes only. (Don't mention VLV.) :)


Regards,

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

[PATCH 3/3] arm64: dts: rockchip: Specify override mode for kevin panel

[Sean Paul]

This patch adds an override mode for kevin devices. The mode increases
both back porches to allow a pixel clock of 2kHz as opposed to the
'typical' value of 252750kHz. This is needed to avoid interference with
the touch digitizer on these laptops.

Cc: Doug Anderson 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 191a6bcb1704..24430e689bcf 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -98,6 +98,20 @@
backlight = <>;
power-supply = <_disp>;
 
+   override-mode {
+   clock-frequency = <266604720>;
+   hactive = <2400>;
+   hfront-porch = <48>;
+   hback-porch = <84>;
+   hsync-len = <32>;
+   hsync-active = <0>;
+   vactive = <1600>;
+   vfront-porch = <3>;
+   vback-porch = <120>;
+   vsync-len = <10>;
+   vsync-active = <0>;
+   };
+
ports {
panel_in_edp: endpoint {
remote-endpoint = <_out_panel>;
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH 1/3] drm/panel: simple: Add ability to override typical timing

[Sean Paul]

This patch adds the ability to override the typical display timing for a
given panel. This is useful for devices which have timing constraints
that do not apply across the entire display driver (eg: to avoid
crosstalk between panel and digitizer on certain laptops). The rules are
as follows:

- panel must not specify fixed mode (since the override mode will
  either be the same as the fixed mode, or we'll be unable to
  check the bounds of the overried)
- panel must specify at least one display_timing range which will be
  used to ensure the override mode fits within its bounds

Cc: Doug Anderson 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 .../bindings/display/panel/simple-panel.txt| 20 +++
 drivers/gpu/drm/panel/panel-simple.c   | 69 +-
 2 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 16d8ff088b7d..590bbff6fc90 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -7,6 +7,14 @@ Optional properties:
 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
 - enable-gpios: GPIO pin to enable or disable the panel
 - backlight: phandle of the backlight device attached to the panel
+- override-mode: For devices which require a mode which differs from the
+display_timing's "typical" mode, and whose restrictions cannot
+be applied across the entire platform. The mode must fall
+within the bounds of the panel's specified display_timing, and
+cannot be used if the panel already specifies a single fixed
+mode. The format is specified under "timing subnode" in
+display-timing.txt
+
 
 Example:
 
@@ -18,4 +26,16 @@ Example:
enable-gpios = < 90 0>;
 
backlight = <>;
+
+   override-mode {
+   clock-frequency = <266604720>;
+   hactive = <2400>;
+   hfront-porch = <48>;
+   hback-porch = <84>;
+   hsync-len = <32>;
+   vactive = <1600>;
+   vfront-porch = <3>;
+   vback-porch = <120>;
+   vsync-len = <10>;
+   }
};
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..b774365f3635 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 struct panel_desc {
@@ -87,6 +88,8 @@ struct panel_simple {
struct i2c_adapter *ddc;
 
struct gpio_desc *enable_gpio;
+
+   struct drm_display_mode override_mode;
 };
 
 static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
@@ -99,11 +102,22 @@ static int panel_simple_get_fixed_modes(struct 
panel_simple *panel)
struct drm_connector *connector = panel->base.connector;
struct drm_device *drm = panel->base.drm;
struct drm_display_mode *mode;
+   bool has_override = panel->override_mode.type;
unsigned int i, num = 0;
 
if (!panel->desc)
return 0;
 
+   if (has_override) {
+   mode = drm_mode_duplicate(drm, >override_mode);
+   if (mode) {
+   drm_mode_probed_add(connector, mode);
+   num++;
+   } else {
+   dev_err(drm->dev, "failed to add override mode\n");
+   }
+   }
+
for (i = 0; i < panel->desc->num_timings; i++) {
const struct display_timing *dt = >desc->timings[i];
struct videomode vm;
@@ -120,7 +134,7 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
 
mode->type |= DRM_MODE_TYPE_DRIVER;
 
-   if (panel->desc->num_timings == 1)
+   if (panel->desc->num_timings == 1 && !has_override)
mode->type |= DRM_MODE_TYPE_PREFERRED;
 
drm_mode_probed_add(connector, mode);
@@ -291,10 +305,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
.get_timings = panel_simple_get_timings,
 };
 
+#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
+   (to_check->field.typ >= bounds->field.min && \
+to_check->field.typ <= bounds->field.max)
+static void 

[PATCH 2/3] drm/panel: simple: Use display_timing for lq123p1jx31

[Sean Paul]

Convert the sharp lq123p1jx31 from using a fixed mode to specifying a
display timing with min/typ/max values. This allows us to capture the
timings set forth in the datasheet as well as the additional values that
we've cleared with the display vendor to avoid interference with the
digitizer on the Samsung Chromebook Plus (kevin).

A follow-on patch will specify the override mode for kevin devices.

Cc: Doug Anderson 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index b774365f3635..2619b24d7e3b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1808,23 +1808,22 @@ static const struct panel_desc sharp_lq101k1ly04 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
 };
 
-static const struct drm_display_mode sharp_lq123p1jx31_mode = {
-   .clock = 252750,
-   .hdisplay = 2400,
-   .hsync_start = 2400 + 48,
-   .hsync_end = 2400 + 48 + 32,
-   .htotal = 2400 + 48 + 32 + 80,
-   .vdisplay = 1600,
-   .vsync_start = 1600 + 3,
-   .vsync_end = 1600 + 3 + 10,
-   .vtotal = 1600 + 3 + 10 + 33,
-   .vrefresh = 60,
-   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+static const struct display_timing sharp_lq123p1jx31_timing = {
+   .pixelclock = { 25275, 25275, 266604720 },
+   .hactive = { 2400, 2400, 2400 },
+   .hfront_porch = { 48, 48, 48 },
+   .hback_porch = { 80, 80, 84 },
+   .hsync_len = { 32, 32, 32 },
+   .vactive = { 1600, 1600, 1600 },
+   .vfront_porch = { 3, 3, 3 },
+   .vback_porch = { 33, 33, 120 },
+   .vsync_len = { 10, 10, 10 },
+   .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
 };
 
 static const struct panel_desc sharp_lq123p1jx31 = {
-   .modes = _lq123p1jx31_mode,
-   .num_modes = 1,
+   .timings = _lq123p1jx31_timing,
+   .num_timings = 1,
.bpc = 8,
.size = {
.width = 259,
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH 0/3] drm/panel: simple: Add mode support to devicetree

[Sean Paul]

Hey all,
Here's a set which allows us to add an "override" mode to the simple
panel dt node. The override mode can be used for devices for which the
typical display timing is not sufficient, yet the overriding mode should
not be applied across the entire platform. 

An example of this (and the motivation) is the Chromebook Plus (kevin).
If the sharp panel on this laptop is run at the mode advertised in the
datasheet (and what is currently in mainline), it creates interference
with the touch digitizer. To fix this, we need to run the pixel clock at
a slightly higher rate (which we can do by increasing the back porches).
This "fix" should not be used on other rockchip devices using this panel
since they might not encounter the same interference.

If an override mode is present, it will be checked against the panel's
display_timing range. When validated, it will be exposed as the
preferred mode along with the 'typical' modes generated from the panel's
display_timing.

This set is based on Linus' master to pick up the edp support in
rk3399-gru-kevin.dts.

Thanks,

Sean

Cc: Doug Anderson 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org



Sean Paul (3):
  drm/panel: simple: Add ability to override typical timing
  drm/panel: simple: Use display_timing for lq123p1jx31
  arm64: dts: rockchip: Specify override mode for kevin panel

 .../bindings/display/panel/simple-panel.txt| 20 +
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  | 14 
 drivers/gpu/drm/panel/panel-simple.c   | 96 ++
 3 files changed, 115 insertions(+), 15 deletions(-)

-- 
2.16.0.rc1.238.g530d649a79-goog

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

Re: [PATCH] drm/i915/pmu: Fix sleep under atomic in RC6 readout

[Imre Deak]

On Tue, Feb 06, 2018 at 04:04:10PM +, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-02-06 14:31:07)
> > +static u64 read_rc6_residency(struct drm_i915_private *i915)
> > +{
> > +   u64 val;
> > +
> > +   val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
> > +  VLV_GT_RENDER_RC6 : 
> > GEN6_GT_GFX_RC6);
> > +   if (HAS_RC6p(i915))
> > +   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
> > +   if (HAS_RC6pp(i915))
> > +   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);
> 
> We really should mention that these may produce interesting results
> every 53 minutes. Switching to a timer will allow us to notice the
> wraparound in each counter.
> 
> > +
> > +   return val;
> > +}
> > +
> > +static void
> > +update_rc6_sample(struct drm_i915_private *i915, u64 val, bool locked)
> > +{
> > +   unsigned long flags;
> > +
> > +   if (!locked)
> > +   spin_lock_irqsave(>pmu.lock, flags);
> > +
> > +   /*
> > +* Update stored RC6 counter only if it is greater than the current
> > +* value. This deals with periods of runtime suspend during which 
> > we are
> > +* estimating the RC6 residency, so do not want to overshoot the 
> > real
> > +* value read once the device is woken up.
> > +*/
> > +   if (val > i915->pmu.sample[__I915_SAMPLE_RC6].cur)
> > +   i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
> 
> 64b wraparound? Maybe not today, maybe not tomorrow... ;)
> 
> > +
> > +   /* We don't need to sample RC6 from the timer any more. */
> > +   i915->pmu.timer_enabled =
> > +   __pmu_needs_timer(i915,
> > + i915->pmu.enable & 
> > ~config_enabled_mask(I915_PMU_RC6_RESIDENCY),
> > + READ_ONCE(i915->gt.awake));
> 
> But we do... :)
> One thing I had in mind was to hook into runtime suspend/resume to read
> the counters there and compensate, but the more I think about it, we may
> as well solve the lack of resolution in the rc6 counters whilst we are
> here. https://bugs.freedesktop.org/show_bug.cgi?id=94852.

How about using dev->power.suspended_jiffies?

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

Re: Questions on page flips and atomic modeset

[Ville Syrjälä]

On Tue, Feb 06, 2018 at 11:59:37AM +0200, Oleksandr Andrushchenko wrote:
> Hello, Ville!
> 
> Thank you very much for such a comprehensive answer.
> 
> Please see inline
> 
> 
> On 02/05/2018 06:47 PM, Ville Syrjälä wrote:
> > On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:
> >> Hello,
> >>
> >>
> >> I have a DRM driver which implements display protocol for Xen [1]
> >> and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
> >> tells the other end that some display buffer needs to be displayed,
> >> e.g. it is issued by the frontend DRM driver to the corresponding
> >> backend when the former wants to display a buffer.
> >> Two notes:
> >> 1. Communication between two remote parties can obviously fail.
> >> 2. At the moment only primary plane is supported, so we can think of
> >> the display buffer as of CRTC's primary fb.
> >>
> >> There are two APIs available for user-space to initiate a page-flip
> >> (please correct me if I am wrong here): legacy via DRM_IOCTL_MODE_PAGE_FLIP
> >> and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
> >> (which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
> >> XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
> >> I can return an error code, so the DRM core knows that page flip
> >> cannot be done.
> >>
> >> But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC for
> >> which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via .atomic_check 
> >> +
> >> .atomic_flush callbacks.
> >>
> >> The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP request
> >> to the .atomic_flush callback which seems to be the right place to serve
> >> both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).
> >>
> >> The questions I have with this are:
> >>
> >> 1. What is the framebuffer I can send to the backend?
> >> I assume I can use crtc->primary->fb from
> >> drm_crtc_helper_funcs.atomic_flush,
> >> is this assumption correct?
> > Planes are explicit in the atomic world, so you should just deal with
> > the plane if and when it's part of the drm_atomic_state. Look at eg.
> > drm_atomic_helper_commit_planes() how to figure out what's in the
> > state.
> Yes, this is clear. The question was about the frame buffer
> I get in drm_crtc_helper_funcs.atomic_flush which only has
> old_crtc_state, so I assumed I can use crtc->primary->fb there.
> Or you mean I have to dig into old_crtc_state->state to find
> out if there is a plane and if it has a frambuffer and if so
> use it instead of crtc->primary->fb?

You will get the plane explicitly as part of the drm_atomic_state.
Normally you shouldn't need to go find it via other means.

Oh, and never use the plane->fb etc. pointers in an atomic driver.
Those are for legacy purposes only. Atomic drivers should only ever
deal with proper state objects.

> >   And I guess you're already planning on using that helper since
> > you mention .atomic_flush().
> Not directly, but via drm_mode_config_funcs.atomic_commit

.atomic_commit() is a hook the driver has to provide. Most drivers use
the helper for it, which in turn requires the driver to provide other
hooks such as .atomic_flush(). That is what you appear to be doing.

> >
> > One should really think of the drm_atomic_state as more of a transaction
> > rather than as a state (since not all objects need be part of it).
> Thank you
> >> 2. Is the check (either to send or not) for crtc->primary->fb != NULL
> >> enough?
> >> I assume there are other cases when .atomic_flush gets called,
> >> so is there a way I can filter out unneeded cases? E.g. those which
> >> are not for page flipping?
> > Each object taking part in the transaction will have an associated
> > new state and old state.
> As I replied above I only have old state in .atomic_flush

Oh right. That way of passing the old state only dates back to earlier
days of atomic. To find the new state what you should do these days
is something like:

foo(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
{
struct drm_atomic_state *state = old_state->state;
struct drm_crtc_state *new_state =
drm_atomic_get_new_crtc_state(state, crtc);
...

The old way was to use the crtc->state pointer as either the old
or new state depending on where you are in the commit sequence.
But that wasn't very good so Maarten changed things so that we
now have explicit old and new states for each object tracked in
the drm_atomic_state.

I think what we should really do is change most of the hooks to
pass crtc+drm_atomic_state instead, and let each function grab
the old and/or new crtc state from the drm_atomic_state as needed.
I believe that would avoid confusing people with just the old or
new state.

> >   You can compare the two to figure out what
> > changed, and in addition there may already some flags in the base
> > class for the state that indicate what may have changed (eg.
> > 

Re: [PATCH] drm/i915/pmu: Fix sleep under atomic in RC6 readout

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-02-06 14:31:07)
> +static u64 read_rc6_residency(struct drm_i915_private *i915)
> +{
> +   u64 val;
> +
> +   val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
> +  VLV_GT_RENDER_RC6 : 
> GEN6_GT_GFX_RC6);
> +   if (HAS_RC6p(i915))
> +   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6p);
> +   if (HAS_RC6pp(i915))
> +   val += intel_rc6_residency_ns(i915, GEN6_GT_GFX_RC6pp);

We really should mention that these may produce interesting results
every 53 minutes. Switching to a timer will allow us to notice the
wraparound in each counter.

> +
> +   return val;
> +}
> +
> +static void
> +update_rc6_sample(struct drm_i915_private *i915, u64 val, bool locked)
> +{
> +   unsigned long flags;
> +
> +   if (!locked)
> +   spin_lock_irqsave(>pmu.lock, flags);
> +
> +   /*
> +* Update stored RC6 counter only if it is greater than the current
> +* value. This deals with periods of runtime suspend during which we 
> are
> +* estimating the RC6 residency, so do not want to overshoot the real
> +* value read once the device is woken up.
> +*/
> +   if (val > i915->pmu.sample[__I915_SAMPLE_RC6].cur)
> +   i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;

64b wraparound? Maybe not today, maybe not tomorrow... ;)

> +
> +   /* We don't need to sample RC6 from the timer any more. */
> +   i915->pmu.timer_enabled =
> +   __pmu_needs_timer(i915,
> + i915->pmu.enable & 
> ~config_enabled_mask(I915_PMU_RC6_RESIDENCY),
> + READ_ONCE(i915->gt.awake));

But we do... :)
One thing I had in mind was to hook into runtime suspend/resume to read
the counters there and compensate, but the more I think about it, we may
as well solve the lack of resolution in the rc6 counters whilst we are
here. https://bugs.freedesktop.org/show_bug.cgi?id=94852.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

--- Comment #8 from Christian König (christian.koe...@amd.com) ---
(In reply to ro...@beardandsandals.co.uk from comment #7)
> The original point I made in the bug report was that this bug is not about
> the mechanical hardware glitch. It as about the driver being in what is
> obviously a failure mode and attempting a recovery that fails and leaves the
> system in unusable state.

You are missing the point. The driver fails to recover because the hardware is
buggy and not because there is any problem with the recovery routine.

In other words we read back an impossible value from the hardware and that is
why the system is failing.

I mean I can handle this impossible value at this code location, but as you
actually figured out by yourself it then fails at the next best location.

There are simply hundreds or even thousands of locations where the assumption
is that the hardware works correctly and we don't handle the case to get
nonsense values.

-- 
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

Re: Atomic driver and old remove FB behavior

[Maarten Lankhorst]

Op 06-02-18 om 15:43 schreef Oleksandr Andrushchenko:
> Hello, Maarten!
>
>
> On 02/01/2018 12:13 PM, Oleksandr Andrushchenko wrote:
>> On 02/01/2018 12:04 PM, Maarten Lankhorst wrote:
>>> Op 01-02-18 om 08:08 schreef Oleksandr Andrushchenko:
 Hi, all!

 I am working on a para-virtualized frontend DRM driver for Xen [1]
 which implements display device I/O interface for Xen guest OSes [2].

 At the moment I am rebasing the existing implementation from 4.9 kernel
 to recent and found that when user-space DRM application exits then CRTC's
 .set_config callback is not called to reset CRTC's mode to NULL.

 I tracked the change down to commit 
 846c7dfc1193eb2f9866fe2fa0ae7d45c72f95b9
 "drm/atomic: Try to preserve the crtc enabled state in 
 drm_atomic_remove_fb, v2.

  This introduces a slight behavioral change to rmfb. Instead of
  disabling a crtc when the primary plane is disabled, we try to
  preserve it.
 
  If the atomic commit is rejected by the driver then we will still
  fall back to the old behavior and turn off the crtc.
 "
 which per my understanding is ok for real hardware, but in my case I still
 need .set_config to be called with NULL: this way I can tell the backend

 driver that it can release resources for this connection on its end.


 I tried to implement drm_mode_config_funcs's .atomic_commit returning 
 -EINVAL
 on tear down, but at best it made CRTC's atomic state change to NOCRTC, but
 still no .set_config callback seen.

 Can anyone please tell me the right sequence to implement old remove FB
 behavior for atomic drivers? Or what could be the problem on my side?
>>> rmfb was never meant to mean that the crtc will be disabled as well. vmwgfx 
>>> relied on that
>>> behavior as well for old userspace support because userspace never called 
>>> set_config.
>>>
>>> If you're an atomic driver, the driver core will never call set_config any 
>>> more, even if the
>>> first attempt to disable returns -EINVAL. Even the fbcon helpers now 
>>> perform direct
>>> calls to atomic_commit().
>> understood, thank you for clarification
> I started to re-implement the existing code in my driver to comply to the
> new atomic behavior in terms of "the driver core will never call set_config 
> any more"
> and the question now is what would be the right place to put a check for mode 
> change?
> Basically, I would like to know where I can get "struct drm_mode_set" as
> I used to have in drm_crtc_funcs.set_config callback? Or some other source of
> information I can derive (x,y), (width,height), pixel format for the mode
> when it changes.

Any validation check needs to be in atomic_check(), the other check
depends on what kind of check you are looking at. atomic_begin() and
atomic_flush() are usually for plane updates.

If you have special needs for atomic updates, you could always implement
your own implementation for commit_tail(), the original is something like this:

{
drm_atomic_helper_commit_modeset_disables() -> can always put all 
disables here, including when mode is changed. If you replace this, make sure 
you put drm_atomic_helper_update_legacy_modeset_state() after all disables..

Next 2 calls can be swapped, depending on whether planes need to be 
programmed before crtc enabling or after:
{
drm_atomic_helper_commit_modeset_enables() -> putting enables 
here..
drm_atomic_helper_commit_planes()
}

drm_atomic_helper_commit_hw_done()
drm_atomic_helper_wait_for_flip_done()
drm_atomic_helper_wait_for_vblanks()
drm_atomic_helper_cleanup_planes()
}

You can always trace the flow and see if there's a function call that's useful 
for you in there.

I would just call set_config if required in 2 places, once in crtc disable, 
once in crtc enable.

> Candidates I am playing with are:
> 1. drm_crtc_helper_funcs.atomic_flush
> 2. drm_mode_config_funcs.atomic_commit
>
> During experiments with the above I see that during "on" phase in the
> drm_crtc_state I can see that mode, enable and active fields of the state
> are changed to 1, but during the "off" phase they remain at 1.
> Then I added the primary plane check from drm_simple_kms_crtc_check
> and at "off" those started to change to 0.
>
> Do you think drm_mode_config_funcs.atomic_commit with the above changes/checks
> will be the right way to get knowledge to emulate old ".set_config"?
> I am trying to be a new atomic driver, but due to the protocol [2] 
> requirements
> I still need a way to send .set_config request to the backend. 

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

Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size

[Pali Rohár]

Hi! I'm periodically getting following message in dmesg on Lenovo
Thinkpad X1 Carbon 3rd generation:

[drm] Reducing the compressed framebuffer size. This may lead to less power 
savings than a non-reduced-size. Try to increase stolen memory size if 
available in BIOS.

In BIOS I already set GPU size to 512M, but this did not help. Also
update to last BIOS version did not help.

So why this message is periodically print in dmesg? And what can I do
with this problem?

And why cannot Linux kernel allocate itself more memory for GPU (if BIOS
can/could do that)? Is not 512MB for GPU enough?

-- 
Pali Rohár
pali.ro...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

--- Comment #7 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) 
---
The original point I made in the bug report was that this bug is not about the
mechanical hardware glitch. It as about the driver being in what is obviously a
failure mode and attempting a recovery that fails and leaves the system in
unusable state. The error recovery paths of any driver should be its most
resilient components. Especially when the driver is controlling a part of the
primary user interface to it.

To pose another question. Why, when the driver has the information to tell it
that the GPU is irrevocably stalled, does it attempt a soft restart and leave
the system in an unusable state.

-- 
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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Pekka Paalanen]

On Mon, 5 Feb 2018 17:03:22 +0100
Gerd Hoffmann  wrote:

> On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
> > On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:  
> > >Hi,
> > >   
> 
> Hmm.  I allways assumed the wayland client allocates the buffers, not
> the server.  Is that wrong?

Hi Gerd,

a fly-by comment here:

The standard operation mode on Wayland indeed is that the client
allocates any pixel buffers. It is not the whole story though.

Server allocated buffers passed to a client also exist:
- core protocol uses this to pass keymaps to clients
- people are not forbidden from writing Wayland extensions that do this
  for whatever reason

The latter server-allocated case could probably be overlooked, but the
keymap case not really. Furthermore, copy and drag protocol
pass pipe file descriptors via Wayland to establish client-to-client
pipes.


Thanks,
pq


pgpQxF06nhdFw.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Atomic driver and old remove FB behavior

[Oleksandr Andrushchenko]

Hello, Maarten!


On 02/01/2018 12:13 PM, Oleksandr Andrushchenko wrote:

On 02/01/2018 12:04 PM, Maarten Lankhorst wrote:

Op 01-02-18 om 08:08 schreef Oleksandr Andrushchenko:

Hi, all!

I am working on a para-virtualized frontend DRM driver for Xen [1]
which implements display device I/O interface for Xen guest OSes [2].

At the moment I am rebasing the existing implementation from 4.9 kernel
to recent and found that when user-space DRM application exits then 
CRTC's

.set_config callback is not called to reset CRTC's mode to NULL.

I tracked the change down to commit 
846c7dfc1193eb2f9866fe2fa0ae7d45c72f95b9
"drm/atomic: Try to preserve the crtc enabled state in 
drm_atomic_remove_fb, v2.


 This introduces a slight behavioral change to rmfb. Instead of
 disabling a crtc when the primary plane is disabled, we try to
 preserve it.

 If the atomic commit is rejected by the driver then we will still
 fall back to the old behavior and turn off the crtc.
"
which per my understanding is ok for real hardware, but in my case I 
still
need .set_config to be called with NULL: this way I can tell the 
backend


driver that it can release resources for this connection on its end.


I tried to implement drm_mode_config_funcs's .atomic_commit 
returning -EINVAL
on tear down, but at best it made CRTC's atomic state change to 
NOCRTC, but

still no .set_config callback seen.

Can anyone please tell me the right sequence to implement old remove FB
behavior for atomic drivers? Or what could be the problem on my side?
rmfb was never meant to mean that the crtc will be disabled as well. 
vmwgfx relied on that
behavior as well for old userspace support because userspace never 
called set_config.


If you're an atomic driver, the driver core will never call 
set_config any more, even if the
first attempt to disable returns -EINVAL. Even the fbcon helpers now 
perform direct

calls to atomic_commit().

understood, thank you for clarification

I started to re-implement the existing code in my driver to comply to the
new atomic behavior in terms of "the driver core will never call 
set_config any more"
and the question now is what would be the right place to put a check for 
mode change?

Basically, I would like to know where I can get "struct drm_mode_set" as
I used to have in drm_crtc_funcs.set_config callback? Or some other 
source of

information I can derive (x,y), (width,height), pixel format for the mode
when it changes.

Candidates I am playing with are:
1. drm_crtc_helper_funcs.atomic_flush
2. drm_mode_config_funcs.atomic_commit

During experiments with the above I see that during "on" phase in the
drm_crtc_state I can see that mode, enable and active fields of the state
are changed to 1, but during the "off" phase they remain at 1.
Then I added the primary plane check from drm_simple_kms_crtc_check
and at "off" those started to change to 0.

Do you think drm_mode_config_funcs.atomic_commit with the above 
changes/checks

will be the right way to get knowledge to emulate old ".set_config"?
I am trying to be a new atomic driver, but due to the protocol [2] 
requirements

I still need a way to send .set_config request to the backend.

If you then still want to revert to old behavior and it doesn't make 
sense to have the
crtc enabled without primary plane enabled, you can copy the check 
from drm_simple_kms_crtc_check().
will try that, but at the moment this is not a strict requirement 
anymore,

just wanted to make sure I understand the flow correctly


~Maarten


Thank you,
Oleksandr

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Gerd Hoffmann]

  Hi,

> > Hmm?  I'm assuming the wayland client (in the guest) talks to the
> > wayland proxy, using the wayland protocol, like it would talk to a
> > wayland display server.  Buffers must be passed from client to
> > server/proxy somehow, probably using fd passing, so where is the
> > problem?
> > 
> > Or did I misunderstand the role of the proxy?
> 
> Hi Gerd,
> 
> it's starting to look to me that we're talking a bit past the other, so I
> have pasted below a few words describing my current plan regarding the 3 key
> scenarios that I'm addressing.

You are describing the details, but I'm missing the big picture ...

So, virtualization aside, how do buffers work in wayland?  As far I know
it goes like this:

  (a) software rendering: client allocates shared memory buffer, renders
  into it, then passes a file handle for that shmem block together
  with some meta data (size, format, ...) to the wayland server.

  (b) gpu rendering: client opens a render node, allocates a buffer,
  asks the cpu to renders into it, exports the buffer as dma-buf
  (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
  (again including meta data of course).

Is that correct?

Now, with virtualization added to the mix it becomes a bit more
complicated.  Client and server are unmodified.  The client talks to the
guest proxy (wayland protocol).  The guest proxy talks to the host proxy
(protocol to be defined). The host proxy talks to the server (wayland
protocol).

Buffers must be managed along the way, and we want avoid copying around
the buffers.  The host proxy could be implemented directly in qemu, or
as separate process which cooperates with qemu for buffer management.

Fine so far?

> I really think that whatever we come up with needs to support 3D clients as
> well.

Lets start with 3d clients, I think these are easier.  They simply use
virtio-gpu for 3d rendering as usual.  When they are done the rendered
buffer already lives in a host drm buffer (because virgl runs the actual
rendering on the host gpu).  So the client passes the dma-buf to the
guest proxy, the guest proxy imports it to look up the resource-id,
passes the resource-id to the host proxy, the host proxy looks up the
drm buffer and exports it as dma-buf, then passes it to the server.
Done, without any extra data copies.

> Creation of shareable buffer by guest
> -
> 
> 1. Client requests virtio driver to create a buffer suitable for sharing
> with host (DRM_VIRTGPU_RESOURCE_CREATE)

client or guest proxy?

> 4. QEMU maps that buffer to the guest's address space
> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver

That part is problematic.  The host can't simply allocate something in
the physical address space, because most physical address space
management is done by the guest.  All pci bars are mapped by the guest
firmware for example (or by the guest OS in case of hotplug).

> 4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each
> resource, sends data + FDs to the compositor with SCM_RIGHTS

BTW: Is there a 1:1 relationship between buffers and shmem blocks?  Or
does the wayland protocol allow for offsets in buffer meta data, so you
can place multiple buffers in a single shmem block?

cheers,
  Gerd

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

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

--- Comment #6 from Christian König (christian.koe...@amd.com) ---
Well the issue is triggered by the driver reading nonsense values from the
hardware.

E.g. we ask the hardware what the last good position on a 16k ring buffer is
and get 0x as result (or something like this) which obviously can't be
correct.

My patch mitigated that by clamping the value to a valid range, but if you read
nonsense values from the hardware because the hardware has a loose connection
and acts strange on vibrations then I basically can't guarantee for anything.

-- 
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

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Julia Lawall]

On Tue, 6 Feb 2018, Dan Carpenter wrote:

> That found 4 that I think Wolfram's grep missed.
>
>  arch/um/drivers/vector_user.h |2 --
>  drivers/gpu/drm/mxsfb/mxsfb_regs.h|2 --
>  drivers/video/fbdev/mxsfb.c   |2 --
>  include/drm/drm_scdc_helper.h |3 ---
>
> But it didn't find the two bugs that Geert found where the right side
> wasn't a number literal.
>
> drivers/net/can/m_can/m_can.c:#define RXFC_FWM_MASK (0x7f < 
> RXFC_FWM_SHIFT)

OK, I can easily add this in - I've got rules to protect against reporting
it at the moment.  It may end up with false positives.

> drivers/usb/gadget/udc/goku_udc.h:#define INT_EPnNAK(n) (0x00100 < (n))   
>   /* 0 < n < 4 */

This is indeed harder, because one has to look at the usage site.

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

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

--- Comment #5 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) 
---
My best guess is the error came from 

r600.c:2848:DRM_ERROR("radeon: ring %d test failed
(scratch(0x%04X)=0x%08X)\n",


I cannot reproduce the mechanical hardware failure. I don't want to clobber the
system any harder and risk damaging a disk.

I assume this is being called from the GPU reset path.

-- 
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

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Dan Carpenter]

That found 4 that I think Wolfram's grep missed.

 arch/um/drivers/vector_user.h |2 --
 drivers/gpu/drm/mxsfb/mxsfb_regs.h|2 --
 drivers/video/fbdev/mxsfb.c   |2 --
 include/drm/drm_scdc_helper.h |3 ---

But it didn't find the two bugs that Geert found where the right side
wasn't a number literal.

drivers/net/can/m_can/m_can.c:#define RXFC_FWM_MASK (0x7f < RXFC_FWM_SHIFT)
drivers/usb/gadget/udc/goku_udc.h:#define INT_EPnNAK(n) (0x00100 < (n)) 
/* 0 < n < 4 */

regards,
dan carpenter

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

Re: [PATCH v2 3/3] backlight: adp8860: document sysfs attributes

[Daniel Thompson]

On Tue, Feb 06, 2018 at 01:11:12PM +0530, Aishwarya Pant wrote:
> Add documentation for sysfs interface of adp8860 series backlight
> devices by reading through code and git commits.
> 
> Signed-off-by: Aishwarya Pant 
> Acked-by: Michael Hennerich 

Acked-by: Daniel Thompson 

> ---
>  .../ABI/testing/sysfs-class-backlight-adp8860  | 54 
> ++
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp8860
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp8860 
> b/Documentation/ABI/testing/sysfs-class-backlight-adp8860
> new file mode 100644
> index ..54d61c788b1b
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-backlight-adp8860
> @@ -0,0 +1,54 @@
> +sysfs interface for analog devices adp8860 backlight driver
> +---
> +
> +The backlight brightness control operates at three different levels for the
> +adp8860, adp8861 and adp8863 devices: daylight (level 1), office (level 2) 
> and
> +dark (level 3). By default the brightness operates at the daylight brightness
> +level.
> +
> +What:/sys/class/backlight//ambient_light_level
> +Date:Apr, 2010
> +KernelVersion:   v2.6.35
> +Contact: Michael Hennerich 
> +Description:
> + (RO) 13-bit conversion value for the first light sensor—high
> + byte (Bit 12 to Bit 8). The value is updated every 80 ms (when
> + the light sensor is enabled).
> +
> +
> +What:/sys/class/backlight//ambient_light_zone
> +Date:Apr, 2010
> +KernelVersion:   v2.6.35
> +Contact: Michael Hennerich 
> +Description:
> + (RW) Read or write the specific level at which the backlight
> + operates. Value "0" enables automatic ambient light sensing, and
> + values "1", "2" or "3" set the control to daylight, office or
> + dark respectively.
> +
> +
> +What:/sys/class/backlight//l1_daylight_max
> +What:/sys/class/backlight//l2_office_max
> +What:/sys/class/backlight//l3_dark_max
> +Date:Apr, 2010
> +KernelVersion:   v2.6.35
> +Contact: Michael Hennerich 
> +Description:
> + (RW) Maximum current setting for the backlight when brightness
> + is at one of the three levels (daylight, office or dark). This
> + is an input code between 0 and 127, which is transformed to a
> + value between 0 mA and 30 mA using linear or non-linear
> + algorithms.
> +
> +
> +What:/sys/class/backlight//l1_daylight_dim
> +What:/sys/class/backlight//l2_office_dim
> +What:/sys/class/backlight//l3_dark_dim
> +Date:Apr, 2010
> +KernelVersion:   v2.6.35
> +Contact: Michael Hennerich 
> +Description:
> + (RW) Dim current setting for the backlight when brightness is at
> + one of the three levels (daylight, office or dark). This is an
> + input code between 0 and 127, which is transformed to a value
> + between 0 mA and 30 mA using linear or non-linear algorithms.
> -- 
> 2.16.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Wolfram Sang]

> I did that too but got no results.  Perhaps right shifting constants is
> pretty uncommon.  I can put that in the complete rule though.

Please do. Even if rare, we would want this bug pointed out, right? :)



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

Re: [PATCH v2 2/3] backlight: adp5520: document sysfs attributes

[Daniel Thompson]

On Tue, Feb 06, 2018 at 01:10:26PM +0530, Aishwarya Pant wrote:
> Add documentation for sysfs interface of adp5520/adp5501 analog devices
> backlight driver by reading code and looking through git commit logs.
> 
> Signed-off-by: Aishwarya Pant 
> Acked-by: Michael Hennerich 

Acked-by: Daniel Thompson 

> ---
>  .../ABI/testing/sysfs-class-backlight-adp5520  | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-backlight-adp5520
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-adp5520 
> b/Documentation/ABI/testing/sysfs-class-backlight-adp5520
> new file mode 100644
> index ..34b6ebafa210
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-backlight-adp5520
> @@ -0,0 +1,31 @@
> +sysfs interface for analog devices adp5520(01) backlight driver
> +---
> +
> +The backlight brightness control operates at three different levels for the
> +adp5520 and adp5501 devices: daylight (level 1), office (level 2) and dark
> +(level 3). By default the brightness operates at the daylight brightness 
> level.
> +
> +What:/sys/class/backlight//daylight_max
> +What:/sys/class/backlight//office_max
> +What:/sys/class/backlight//dark_max
> +Date:Sep, 2009
> +KernelVersion:   v2.6.32
> +Contact: Michael Hennerich 
> +Description:
> + (RW) Maximum current setting for the backlight when brightness
> + is at one of the three levels (daylight, office or dark). This
> + is an input code between 0 and 127, which is transformed to a
> + value between 0 mA and 30 mA using linear or non-linear
> + algorithms.
> +
> +What:/sys/class/backlight//daylight_dim
> +What:/sys/class/backlight//office_dim
> +What:/sys/class/backlight//dark_dim
> +Date:Sep, 2009
> +KernelVersion:   v2.6.32
> +Contact: Michael Hennerich 
> +Description:
> + (RW) Dim current setting for the backlight when brightness is at
> + one of the three levels (daylight, office or dark). This is an
> + input code between 0 and 127, which is transformed to a value
> + between 0 mA and 30 mA using linear or non-linear algorithms.
> -- 
> 2.16.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Julia Lawall]

On Tue, 6 Feb 2018, Wolfram Sang wrote:

> Hi Julia,
>
> > and got the results below.  I can make a version for the kernel shortly.
>
> It should probably take care of right-shifting, too?

I did that too but got no results.  Perhaps right shifting constants is
pretty uncommon.  I can put that in the complete rule though.

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

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Wolfram Sang]

Hi Julia,

> and got the results below.  I can make a version for the kernel shortly.

It should probably take care of right-shifting, too?

Thanks,

   Wolfram



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

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Julia Lawall]

On Tue, 6 Feb 2018, Dan Carpenter wrote:

> On Tue, Feb 06, 2018 at 02:15:51PM +0100, Julia Lawall wrote:
> >
> >
> > On Tue, 6 Feb 2018, Dan Carpenter wrote:
> >
> > > On Mon, Feb 05, 2018 at 09:09:57PM +0100, Wolfram Sang wrote:
> > > > In one Renesas driver, I found a typo which turned an intended bit 
> > > > shift ('<<')
> > > > into a comparison ('<'). Because this is a subtle issue, I looked tree 
> > > > wide for
> > > > similar patterns. This small patch series is the outcome.
> > > >
> > > > Buildbot and checkpatch are happy. Only compile-tested. To be applied
> > > > individually per sub-system, I think. I'd think only the net: amd: 
> > > > patch needs
> > > > to be conisdered for stable, but I leave this to people who actually 
> > > > know this
> > > > driver.
> > > >
> > > > CCing Dan. Maybe he has an idea how to add a test to smatch? In my 
> > > > setup, only
> > > > cppcheck reported a 'coding style' issue with a low prio.
> > > >
> > >
> > > Most of these are inside macros so it makes it complicated for Smatch
> > > to warn about them.  It might be easier in Coccinelle.  Julia the bugs
> > > look like this:
> > >
> > > - reissue_mask |= 0x < 4;
> > > + reissue_mask |= 0x << 4;
> >
> > Thanks.  I'll take a look.  Do you have an example of the macro issue
> > handy?
> >
>
> It's the same:
>
> #define EXYNOS_CIIMGEFF_PAT_CBCR_MASK  ((0xff < 13) | (0xff < 0))
>
> Smatch only sees the outside of the macro (where it is used in the code)
> and the pre-processed code.

I wrote the following rule:

@@
constant int x,y;
identifier i;
type T;
@@

(
i < x
|
x < i
|
 (T)i < x
|
x < (T)i
|
* x < y
)

and got the results below.  I can make a version for the kernel shortly.

julia

diff -u -p /run/shm/linux-next/drivers/gpu/drm/exynos/regs-fimc.h 
/tmp/nothing/drivers/gpu/drm/exynos/regs-fimc.h
--- /run/shm/linux-next/drivers/gpu/drm/exynos/regs-fimc.h
+++ /tmp/nothing/drivers/gpu/drm/exynos/regs-fimc.h
@@ -569,7 +569,6 @@
 #define EXYNOS_CIIMGEFF_FIN_EMBOSSING  (4 << 26)
 #define EXYNOS_CIIMGEFF_FIN_SILHOUETTE (5 << 26)
 #define EXYNOS_CIIMGEFF_FIN_MASK   (7 << 26)
-#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK  ((0xff < 13) | (0xff < 0))

 /* Real input DMA size register */
 #define EXYNOS_CIREAL_ISIZE_AUTOLOAD_ENABLE(1 << 31)
diff -u -p /run/shm/linux-next/drivers/net/ethernet/amd/xgbe/xgbe-drv.c 
/tmp/nothing/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
--- /run/shm/linux-next/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ /tmp/nothing/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -595,7 +595,6 @@ isr_done:

reissue_mask = 1 << 0;
if (!pdata->per_channel_irq)
-   reissue_mask |= 0x < 4;

XP_IOWRITE(pdata, XP_INT_REISSUE_EN, reissue_mask);
}
diff -u -p /run/shm/linux-next/drivers/video/fbdev/mxsfb.c 
/tmp/nothing/drivers/video/fbdev/mxsfb.c
--- /run/shm/linux-next/drivers/video/fbdev/mxsfb.c
+++ /tmp/nothing/drivers/video/fbdev/mxsfb.c
@@ -133,8 +133,6 @@
 #define VDCTRL4_SYNC_SIGNALS_ON(1 << 18)
 #define SET_DOTCLK_H_VALID_DATA_CNT(x) ((x) & 0x3)

-#define DEBUG0_HSYNC   (1 < 26)
-#define DEBUG0_VSYNC   (1 < 25)

 #define MIN_XRES   120
 #define MIN_YRES   120
diff -u -p /run/shm/linux-next/include/drm/drm_scdc_helper.h 
/tmp/nothing/include/drm/drm_scdc_helper.h
--- /run/shm/linux-next/include/drm/drm_scdc_helper.h
+++ /tmp/nothing/include/drm/drm_scdc_helper.h
@@ -50,9 +50,6 @@
 #define  SCDC_READ_REQUEST_ENABLE (1 << 0)

 #define SCDC_STATUS_FLAGS_0 0x40
-#define  SCDC_CH2_LOCK (1 < 3)
-#define  SCDC_CH1_LOCK (1 < 2)
-#define  SCDC_CH0_LOCK (1 < 1)
 #define  SCDC_CH_LOCK_MASK (SCDC_CH2_LOCK | SCDC_CH1_LOCK | SCDC_CH0_LOCK)
 #define  SCDC_CLOCK_DETECT (1 << 0)

diff -u -p /run/shm/linux-next/arch/um/drivers/vector_user.h 
/tmp/nothing/arch/um/drivers/vector_user.h
--- /run/shm/linux-next/arch/um/drivers/vector_user.h
+++ /tmp/nothing/arch/um/drivers/vector_user.h
@@ -61,8 +61,6 @@ struct vector_fds {
 };

 #define VECTOR_READ1
-#define VECTOR_WRITE   (1 < 1)
-#define VECTOR_HEADERS (1 < 2)

 extern struct arglist *uml_parse_vector_ifspec(char *arg);

diff -u -p /run/shm/linux-next/drivers/gpu/drm/mxsfb/mxsfb_regs.h 
/tmp/nothing/drivers/gpu/drm/mxsfb/mxsfb_regs.h
--- /run/shm/linux-next/drivers/gpu/drm/mxsfb/mxsfb_regs.h
+++ /tmp/nothing/drivers/gpu/drm/mxsfb/mxsfb_regs.h
@@ -91,8 +91,6 @@
 #define VDCTRL4_SYNC_SIGNALS_ON(1 << 18)
 #define SET_DOTCLK_H_VALID_DATA_CNT(x) ((x) & 0x3)

-#define DEBUG0_HSYNC   (1 < 26)
-#define DEBUG0_VSYNC   (1 < 25)

 #define MXSFB_MIN_XRES 120
 #define MXSFB_MIN_YRES 120
diff -u -p /run/shm/linux-next/drivers/media/platform/vsp1/vsp1_regs.h 
/tmp/nothing/drivers/media/platform/vsp1/vsp1_regs.h
--- 

Re: [PATCH 1/2] drm/i915: Free memdup-ed bios data structures on driver_unload

[Hans de Goede]

Hi,

On 02-02-18 17:13, Ville Syrjälä wrote:

On Mon, Jan 29, 2018 at 03:47:34PM +0100, Hans de Goede wrote:

Add a new intel_bios_cleanup function to free memdup-ed bios data
structures and call it from i915_driver_unload().

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/i915_drv.c   |  2 ++
  drivers/gpu/drm/i915/i915_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_bios.c | 11 +++
  3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1ec12add34b2..4ecf41724183 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1437,6 +1437,8 @@ void i915_driver_unload(struct drm_device *dev)
  
  	intel_modeset_cleanup(dev);
  
+	intel_bios_cleanup(dev_priv);

+
/*
 * free the memory space allocated for the child device
 * config parsed from VBT


Looks like there's already a bunch of VBT related cleanup just below.
Maybe that should be sucked into the new cleanup function as well?


Ah, I somehow missed that, yes that is a good idea. I will send a v3 of
the series with that changed.

Regards,

Hans





diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 454d8f937fae..081190da0818 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3663,6 +3663,7 @@ extern void intel_i2c_reset(struct drm_i915_private 
*dev_priv);
  
  /* intel_bios.c */

  void intel_bios_init(struct drm_i915_private *dev_priv);
+void intel_bios_cleanup(struct drm_i915_private *dev_priv);
  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
  bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
  bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
*i2c_pin);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 95f0b310d656..64a0d55df28e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1588,6 +1588,17 @@ void intel_bios_init(struct drm_i915_private *dev_priv)
pci_unmap_rom(pdev, bios);
  }
  
+/**

+ * intel_bios_cleanup - Free any resources allocated by intel_bios_init()
+ * @dev_priv: i915 device instance
+ */
+void intel_bios_cleanup(struct drm_i915_private *dev_priv)
+{
+   kfree(dev_priv->vbt.dsi.data);
+   kfree(dev_priv->vbt.dsi.pps);
+   kfree(dev_priv->vbt.dsi.config);
+}
+
  /**
   * intel_bios_is_tv_present - is integrated TV present in VBT
   * @dev_priv: i915 device instance
--
2.14.3



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

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Dan Carpenter]

On Tue, Feb 06, 2018 at 02:15:51PM +0100, Julia Lawall wrote:
> 
> 
> On Tue, 6 Feb 2018, Dan Carpenter wrote:
> 
> > On Mon, Feb 05, 2018 at 09:09:57PM +0100, Wolfram Sang wrote:
> > > In one Renesas driver, I found a typo which turned an intended bit shift 
> > > ('<<')
> > > into a comparison ('<'). Because this is a subtle issue, I looked tree 
> > > wide for
> > > similar patterns. This small patch series is the outcome.
> > >
> > > Buildbot and checkpatch are happy. Only compile-tested. To be applied
> > > individually per sub-system, I think. I'd think only the net: amd: patch 
> > > needs
> > > to be conisdered for stable, but I leave this to people who actually know 
> > > this
> > > driver.
> > >
> > > CCing Dan. Maybe he has an idea how to add a test to smatch? In my setup, 
> > > only
> > > cppcheck reported a 'coding style' issue with a low prio.
> > >
> >
> > Most of these are inside macros so it makes it complicated for Smatch
> > to warn about them.  It might be easier in Coccinelle.  Julia the bugs
> > look like this:
> >
> > -   reissue_mask |= 0x < 4;
> > +   reissue_mask |= 0x << 4;
> 
> Thanks.  I'll take a look.  Do you have an example of the macro issue
> handy?
> 

It's the same:

#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK  ((0xff < 13) | (0xff < 0)) 

Smatch only sees the outside of the macro (where it is used in the code)
and the pre-processed code.

regards,
dan carpenter

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

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Julia Lawall]

On Tue, 6 Feb 2018, Dan Carpenter wrote:

> On Mon, Feb 05, 2018 at 09:09:57PM +0100, Wolfram Sang wrote:
> > In one Renesas driver, I found a typo which turned an intended bit shift 
> > ('<<')
> > into a comparison ('<'). Because this is a subtle issue, I looked tree wide 
> > for
> > similar patterns. This small patch series is the outcome.
> >
> > Buildbot and checkpatch are happy. Only compile-tested. To be applied
> > individually per sub-system, I think. I'd think only the net: amd: patch 
> > needs
> > to be conisdered for stable, but I leave this to people who actually know 
> > this
> > driver.
> >
> > CCing Dan. Maybe he has an idea how to add a test to smatch? In my setup, 
> > only
> > cppcheck reported a 'coding style' issue with a low prio.
> >
>
> Most of these are inside macros so it makes it complicated for Smatch
> to warn about them.  It might be easier in Coccinelle.  Julia the bugs
> look like this:
>
> - reissue_mask |= 0x < 4;
> + reissue_mask |= 0x << 4;

Thanks.  I'll take a look.  Do you have an example of the macro issue
handy?

julia

>
> regards,
> dan carpenter
>
> > Wolfram Sang (4):
> >   v4l: vsp1: fix mask creation for MULT_ALPHA_RATIO
> >   drm/exynos: fix comparison to bitshift when dealing with a mask
> >   v4l: dvb-frontends: stb0899: fix comparison to bitshift when dealing
> > with a mask
> >   net: amd-xgbe: fix comparison to bitshift when dealing with a mask
> >
> >  drivers/gpu/drm/exynos/regs-fimc.h| 2 +-
> >  drivers/media/dvb-frontends/stb0899_reg.h | 8 
> >  drivers/media/platform/vsp1/vsp1_regs.h   | 2 +-
> >  drivers/net/ethernet/amd/xgbe/xgbe-drv.c  | 2 +-
> >  4 files changed, 7 insertions(+), 7 deletions(-)
> >
> > --
> > 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Dan Carpenter]

On Mon, Feb 05, 2018 at 09:09:57PM +0100, Wolfram Sang wrote:
> In one Renesas driver, I found a typo which turned an intended bit shift 
> ('<<')
> into a comparison ('<'). Because this is a subtle issue, I looked tree wide 
> for
> similar patterns. This small patch series is the outcome.
> 
> Buildbot and checkpatch are happy. Only compile-tested. To be applied
> individually per sub-system, I think. I'd think only the net: amd: patch needs
> to be conisdered for stable, but I leave this to people who actually know this
> driver.
> 
> CCing Dan. Maybe he has an idea how to add a test to smatch? In my setup, only
> cppcheck reported a 'coding style' issue with a low prio.
> 

Most of these are inside macros so it makes it complicated for Smatch
to warn about them.  It might be easier in Coccinelle.  Julia the bugs
look like this:

-   reissue_mask |= 0x < 4;
+   reissue_mask |= 0x << 4;

regards,
dan carpenter

> Wolfram Sang (4):
>   v4l: vsp1: fix mask creation for MULT_ALPHA_RATIO
>   drm/exynos: fix comparison to bitshift when dealing with a mask
>   v4l: dvb-frontends: stb0899: fix comparison to bitshift when dealing
> with a mask
>   net: amd-xgbe: fix comparison to bitshift when dealing with a mask
> 
>  drivers/gpu/drm/exynos/regs-fimc.h| 2 +-
>  drivers/media/dvb-frontends/stb0899_reg.h | 8 
>  drivers/media/platform/vsp1/vsp1_regs.h   | 2 +-
>  drivers/net/ethernet/amd/xgbe/xgbe-drv.c  | 2 +-
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 
> -- 
> 2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/bridge/synopsys: dsi: Add 1.31 version support

[Andrzej Hajda]

On 06.02.2018 09:42, Philippe Cornu wrote:
> Add support for the Synopsys DesignWare MIPI DSI version 1.31
> Two registers need to be updated/added for supporting 1.31:
> * PHY_TMR_CFG 0x9c (updated)
>   1.30 [31:24] phy_hs2lp_time
>[23:16] phy_lp2hs_time
>[14: 0] max_rd_time
>
>   1.31 [25:16] phy_hs2lp_time
>[ 9: 0] phy_lp2hs_time
>
> * PHY_TMR_RD_CFG 0xf4 (new)
>   1.31 [14: 0] max_rd_time
>
> Signed-off-by: Philippe Cornu 

Reviewed-by: Andrzej Hajda 

If there will be no objections I will merge it this week.

 --
Regards
Andrzej

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

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Tomeu Vizoso]

On 02/05/2018 05:03 PM, Gerd Hoffmann wrote:

On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:

On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:

Hi,


Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar functionality in
virtio-gpu.


The reason for abandoning that approach was the type of objects that
could be shared via virtio-vsock would be extremely limited. Besides
that being potentially confusing to users, it would mean from the
implementation side that either virtio-vsock would gain a dependency on
the drm subsystem, or an appropriate abstraction for shareable buffers
would need to be added for little gain.


Well, no.  The idea is that virtio-vsock and virtio-gpu are used largely
as-is, without knowing about each other.  The guest wayland proxy which
does the buffer management talks to both devices.


Note that the proxy won't know anything about buffers if clients opt-in for
zero-copy support (they allocate the buffers in a way that allows for
sharing with the host).


Hmm?  I'm assuming the wayland client (in the guest) talks to the
wayland proxy, using the wayland protocol, like it would talk to a
wayland display server.  Buffers must be passed from client to
server/proxy somehow, probably using fd passing, so where is the
problem?

Or did I misunderstand the role of the proxy?


Hi Gerd,

it's starting to look to me that we're talking a bit past the other, so 
I have pasted below a few words describing my current plan regarding the 
3 key scenarios that I'm addressing.


I mention below KVM_SET_USER_MEMORY_REGION, but I guess we can discuss 
alternatives such as the one you are proposing using PCI BARs at a later 
stage.


I really think that whatever we come up with needs to support 3D clients 
as well.



Creation of shareable buffer by guest
-

1. Client requests virtio driver to create a buffer suitable for sharing 
with host (DRM_VIRTGPU_RESOURCE_CREATE)


2. Virtio driver creates a new resource ID and passes the request to 
QEMU (VIRTIO_GPU_CMD_RESOURCE_CREATE_2D)


3. QEMU creates a shmem file (for example with mkostemp), associates 
that FD with the ID of this resource


4. QEMU maps that buffer to the guest's address space 
(KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver


5. DRM_VIRTGPU_RESOURCE_CREATE returns the resource id just created

6. Client mmaps it with DRM_IOCTL_VIRTGPU_MAP+mmap and can render to it

7. Gets a FD with DRM_IOCTL_PRIME_HANDLE_TO_FD that can be sent around


Send of shareable buffer by guest
-

1. Client sends the host a message that refers to this buffer, passing 
the FD using SCM_RIGHTS


2. Guest proxy passes the message (serialized data + FDs) on to the 
virtio driver responsable for winsrv support


3. virtio driver puts the data and the resource ids corresponding to the 
FDs in a virtqueue, kicks it


4. QEMU pops data+buffers from the virtqueue, looks up shmem FD for each 
resource, sends data + FDs to the compositor with SCM_RIGHTS



Reception of buffer from the compositor
-

1. QEMU reads from the socket and gets a FD via SCM_RIGHTS

2. QEMU mmaps the FD and maps the resulting pointer to the guest via 
KVM_SET_USER_MEMORY_REGION


3. QEMU sends the guest PFN along the presentation data to the virtio 
driver (VIRTIO_GPU_CMD_WINSRV_RX)


4. Virtio driver wraps a FD around that PFN, puts it in a queue

5. Guest proxy calls DRM_IOCTL_VIRTGPU_WINSRV_RX and gets data plus that FD

6. Guest proxy sends that data + FD to the client via SCM_RIGHTS

7. Client gets FD, mmaps it and reads the data from the compositor



Thanks,

Tomeu



If you have a guest proxy anyway using virtio-sock for the protocol
stream and virtio-gpu for buffer sharing (and some day 3d rendering
too) should work fine I think.


If I understand correctly your proposal, virtio-gpu would be used for
creating buffers that could be shared across domains, but something
equivalent to SCM_RIGHTS would still be needed in virtio-vsock?


Yes, the proxy would send a reference to the buffer over virtio-vsock.
I was more thinking about a struct specifying something like
"ressource-id 42 on virtio-gpu-pci device in slot 1:23.0" instead of
using SCM_RIGHTS.


Can you extend on this? I'm having trouble figuring out how this could work
in a way that keeps protocol data together with the resources it refers to.


Don't know much about the wayland protocol.  Assuming you are passing
buffers as file handles, together with some information what kind of
buffer this is (sysv shm, dma-buf, ...).

We have a proxy on both ends.  One running in the guest, one on the host
(be it qemu or some external one).  So these two have to agree on how to
pass buffers from one to the other.  One way would be to have them talk
a simple meta protocol to each other, with "here comes a 

[PATCH] drm/amd/powerplay: delete some dead code

[Dan Carpenter]

We deleted some code in e154162ef75d ("drm/amd/powerplay: refine pp code
for raven") but there were a few related bits that were missed.  Let's
delete them as well.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
index 565fe0832f41..0b0fbb228edf 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
@@ -608,7 +608,6 @@ struct phm_dynamic_state_info {
struct phm_ppm_table  *ppm_parameter_table;
struct phm_cac_tdp_table  *cac_dtp_table;
struct phm_clock_voltage_dependency_table   
*vdd_gfx_dependency_on_sclk;
-   struct phm_vq_budgeting_table   
*vq_budgeting_table;
 };
 
 struct pp_fan_info {
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index c3e7e34535e8..7545776a774d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -1697,9 +1697,6 @@ static int pp_tables_uninitialize(struct pp_hwmgr *hwmgr)
kfree(hwmgr->dyn_state.vdd_gfx_dependency_on_sclk);
hwmgr->dyn_state.vdd_gfx_dependency_on_sclk = NULL;
 
-   kfree(hwmgr->dyn_state.vq_budgeting_table);
-   hwmgr->dyn_state.vq_budgeting_table = NULL;
-
return 0;
 }
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 03/20] kconfig: Remove leftover references to AVR32 symbol

[Mark Brown]

On Mon, Feb 05, 2018 at 08:05:39PM +0100, Ulf Magnusson wrote:
> The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
> support for AVR32 architecture"). Remove the remaining references to it
> from the Kconfig files.

>  drivers/spi/Kconfig   | 2 +-
>  drivers/video/console/Kconfig | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

It'd probably be easier to just submit these as separate patches to the
individual subsystems, that'd make it more likely that reviewers will
see them.  As I've no context for this I can't tell if there's any
dependencies, I'm guessing not but just in case

Acked-by: Mark Brown 


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

[PATCH 0/3] Bandwidth limitation on PL111, take 2

[Linus Walleij]

I had to add a hook into the simple KMS helper to be able
to gate off too high bandwidths on the PL111.

Let me know what you think.

This solution is inspired by the OMAPDRM commit a7631c4b9846
"drm/omap: Filter displays mode based on bandwidth limit"
by Peter Ujfalusi.

I'm not super-happy that we don't know or negotiate the
desired pixel format when the CRTC asks the driver whether
the mode is valid, I need to think more about this for the
future.

For now patch 2/2 just hammers that down to 16 or 32 BPP
depending on variant, so we get running code. But the
BPP is not used to negotiate formats wrt bandwidth, we
just fix that variable and work on the resolution
limitation.

Maybe the 16BPP systems are in such a minority that this
hard-coding is reasonable.

Linus Walleij (3):
  drm: simple_kms_helper: Add mode_valid() callback support
  drm/pl111: Make the default BPP a per-variant variable
  drm/pl111: Use max memory bandwidth for resolution

 drivers/gpu/drm/drm_simple_kms_helper.c | 15 +++
 drivers/gpu/drm/pl111/pl111_display.c   | 30 ++
 drivers/gpu/drm/pl111/pl111_drm.h   |  3 +++
 drivers/gpu/drm/pl111/pl111_drv.c   | 10 +-
 drivers/gpu/drm/pl111/pl111_versatile.c |  2 ++
 include/drm/drm_simple_kms_helper.h | 15 +++
 6 files changed, 74 insertions(+), 1 deletion(-)

-- 
2.14.3

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

[PATCH 1/3] drm: simple_kms_helper: Add mode_valid() callback support

[Linus Walleij]

The PL111 needs to filter valid modes based on memory bandwidth.
I guess it is a pretty simple operation, so we can still claim
the DRM KMS helper pipeline is simple after adding this (optional)
vtable callback.

Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 15 +++
 include/drm/drm_simple_kms_helper.h | 15 +++
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index dc9fd109de14..b7840cf34808 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -34,6 +34,20 @@ static const struct drm_encoder_funcs 
drm_simple_kms_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
 
+static enum drm_mode_status
+drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
+  const struct drm_display_mode *mode)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->mode_valid)
+   /* Anything goes */
+   return MODE_OK;
+
+   return pipe->funcs->mode_valid(crtc, mode);
+}
+
 static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
 struct drm_crtc_state *state)
 {
@@ -72,6 +86,7 @@ static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs = {
+   .mode_valid = drm_simple_kms_crtc_mode_valid,
.atomic_check = drm_simple_kms_crtc_check,
.atomic_enable = drm_simple_kms_crtc_enable,
.atomic_disable = drm_simple_kms_crtc_disable,
diff --git a/include/drm/drm_simple_kms_helper.h 
b/include/drm/drm_simple_kms_helper.h
index 6d9adbb46293..ad74cb33c539 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -21,6 +21,21 @@ struct drm_simple_display_pipe;
  *display pipeline
  */
 struct drm_simple_display_pipe_funcs {
+   /**
+* @mode_valid:
+*
+* This function is called to filter out valid modes from the
+* suggestions suggested by the bridge or display. This optional
+* hook is passed in when initializing the pipeline.
+*
+* RETURNS:
+*
+* MODE_OK if the mode is acceptable.
+* MODE_BAD if we need to try something else.
+*/
+   enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
+  const struct drm_display_mode *mode);
+
/**
 * @enable:
 *
-- 
2.14.3

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

[PATCH 2/3] drm/pl111: Make the default BPP a per-variant variable

[Linus Walleij]

The PL110, Integrator and Versatile boards strongly prefer to
use 16 BPP even if other modes are supported, both to keep down
memory consumption and also to easier find a good match to
supported resolutions with consideration taken to the memory
bandwidth of the platforms.

Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/pl111/pl111_drm.h   | 2 ++
 drivers/gpu/drm/pl111/pl111_drv.c   | 4 +++-
 drivers/gpu/drm/pl111/pl111_versatile.c | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index d74076c6b7ef..9f2d30b52e7a 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -43,6 +43,7 @@ struct drm_minor;
  * @broken_vblank: the vblank IRQ is broken on this variant
  * @formats: array of supported pixel formats on this variant
  * @nformats: the length of the array of supported pixel formats
+ * @fb_bpp: desired bits per pixel on the default framebuffer
  */
 struct pl111_variant_data {
const char *name;
@@ -52,6 +53,7 @@ struct pl111_variant_data {
bool broken_vblank;
const u32 *formats;
unsigned int nformats;
+   unsigned int fb_bpp;
 };
 
 struct pl111_drm_dev_private {
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 221f3af02fb4..f5d5aa464ae2 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -191,7 +191,7 @@ static int pl111_modeset_init(struct drm_device *dev)
 
drm_mode_config_reset(dev);
 
-   priv->fbdev = drm_fbdev_cma_init(dev, 32,
+   priv->fbdev = drm_fbdev_cma_init(dev, priv->variant->fb_bpp,
 dev->mode_config.num_connector);
if (IS_ERR(priv->fbdev)) {
dev_err(dev->dev, "Failed to initialize CMA framebuffer\n");
@@ -354,6 +354,7 @@ static const struct pl111_variant_data pl110_variant = {
.is_pl110 = true,
.formats = pl110_pixel_formats,
.nformats = ARRAY_SIZE(pl110_pixel_formats),
+   .fb_bpp = 16,
 };
 
 /* RealView, Versatile Express etc use this modern variant */
@@ -378,6 +379,7 @@ static const struct pl111_variant_data pl111_variant = {
.name = "PL111",
.formats = pl111_pixel_formats,
.nformats = ARRAY_SIZE(pl111_pixel_formats),
+   .fb_bpp = 32,
 };
 
 static const struct amba_id pl111_id_table[] = {
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c 
b/drivers/gpu/drm/pl111/pl111_versatile.c
index 11024ad64181..9825f6d52788 100644
--- a/drivers/gpu/drm/pl111/pl111_versatile.c
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -241,6 +241,7 @@ static const struct pl111_variant_data pl110_integrator = {
.broken_vblank = true,
.formats = pl110_integrator_pixel_formats,
.nformats = ARRAY_SIZE(pl110_integrator_pixel_formats),
+   .fb_bpp = 16,
 };
 
 /*
@@ -253,6 +254,7 @@ static const struct pl111_variant_data pl110_versatile = {
.external_bgr = true,
.formats = pl110_versatile_pixel_formats,
.nformats = ARRAY_SIZE(pl110_versatile_pixel_formats),
+   .fb_bpp = 16,
 };
 
 int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private 
*priv)
-- 
2.14.3

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

[PATCH 3/3] drm/pl111: Use max memory bandwidth for resolution

[Linus Walleij]

We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.

This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.

Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP, Versatile and
Integrator/CP we get a nice console as default with this code.

Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Exploit the new .mode_valid() callback we added to the
  simple KMS helper.
- Use the hardcoded bits per pixel per variant instead of
  trying to be heuristic about this setting for now.
---
 drivers/gpu/drm/pl111/pl111_display.c | 30 ++
 drivers/gpu/drm/pl111/pl111_drm.h |  1 +
 drivers/gpu/drm/pl111/pl111_drv.c |  6 ++
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index d75923896609..a1ca9e1ffe15 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -50,6 +50,35 @@ irqreturn_t pl111_irq(int irq, void *data)
return status;
 }
 
+static enum drm_mode_status
+pl111_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+   struct drm_device *drm = crtc->dev;
+   struct pl111_drm_dev_private *priv = drm->dev_private;
+   u32 cpp = priv->variant->fb_bpp / 8;
+   u64 bw;
+
+   /*
+* We use the pixelclock to also account for interlaced modes, the
+* resulting bandwidth is in bytes per second.
+*/
+   bw = mode->clock * 1000; /* In Hz */
+   bw = bw * mode->hdisplay * mode->vdisplay * cpp;
+   bw = div_u64(bw, mode->htotal * mode->vtotal);
+
+   if (bw > priv->memory_bw) {
+   DRM_DEBUG("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
+ mode->hdisplay, mode->vdisplay, mode->clock, cpp, bw);
+
+   return MODE_BAD;
+   }
+   DRM_DEBUG("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
+ mode->hdisplay, mode->vdisplay, mode->clock, cpp, bw);
+
+   return MODE_OK;
+}
+
 static int pl111_display_check(struct drm_simple_display_pipe *pipe,
   struct drm_plane_state *pstate,
   struct drm_crtc_state *cstate)
@@ -344,6 +373,7 @@ static int pl111_display_prepare_fb(struct 
drm_simple_display_pipe *pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs pl111_display_funcs = {
+   .mode_valid = pl111_mode_valid,
.check = pl111_display_check,
.enable = pl111_display_enable,
.disable = pl111_display_disable,
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index 9f2d30b52e7a..7a3d7af1c8cf 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -66,6 +66,7 @@ struct pl111_drm_dev_private {
struct drm_fbdev_cma *fbdev;
 
void *regs;
+   u32 memory_bw;
u32 ienb;
u32 ctrl;
/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index f5d5aa464ae2..0077059c897f 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -274,6 +274,12 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
drm->dev_private = priv;
priv->variant = variant;
 
+   if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
+>memory_bw)) {
+   dev_info(dev, "no max memory bandwidth specified, assume 
unlimited\n");
+   priv->memory_bw = 0;
+   }
+
/* The two variants swap this register */
if (variant->is_pl110) {
priv->ienb = CLCD_PL110_IENB;
-- 
2.14.3

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

[PATCH v4 6/6] drm/omap: Use normalized zpos for plane placement

[Peter Ujfalusi]

Planes with identical zpos value will result undefined behavior:
disappearing planes, screen flickering and it is not supported by the
hardware.

Use normalized zpos to make sure that we don't encounter invalid
configuration.

Signed-off-by: Peter Ujfalusi 
CC: Tomi Valkeinen 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/omapdrm/omap_drv.c   | 3 +++
 drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index dd68b2556f5b..37ee20c773c7 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -316,6 +316,9 @@ static int omap_modeset_init(struct drm_device *dev)
dev->mode_config.max_width = 2048;
dev->mode_config.max_height = 2048;
 
+   /* We want the zpos to be normalized */
+   dev->mode_config.normalize_zpos = true;
+
dev->mode_config.funcs = _mode_config_funcs;
dev->mode_config.helper_private = _mode_config_helper_funcs;
 
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 7d789d1551a1..2c19d2239bc5 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -65,7 +65,7 @@ static void omap_plane_atomic_update(struct drm_plane *plane,
info.rotation_type = OMAP_DSS_ROT_NONE;
info.rotation = DRM_MODE_ROTATE_0;
info.global_alpha = 0xff;
-   info.zorder = state->zpos;
+   info.zorder = state->normalized_zpos;
 
/* update scanout: */
omap_framebuffer_update_scanout(state->fb, state, );
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 5/6] drm: rcar-du: Let core take care of normalizing the zpos

[Peter Ujfalusi]

Set the drm_mode_config->normalize_zpos and call drm_atomic_helper_check()
from rcar_du_atomic_check() instead of re implementing the function locally.

Signed-off-by: Peter Ujfalusi 
CC: Laurent Pinchart 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 566d1a948c8f..384f98aa4ca3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -234,15 +234,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
struct rcar_du_device *rcdu = dev->dev_private;
int ret;
 
-   ret = drm_atomic_helper_check_modeset(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_normalize_zpos(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_helper_check_planes(dev, state);
+   ret = drm_atomic_helper_check(dev, state);
if (ret)
return ret;
 
@@ -531,6 +523,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
dev->mode_config.min_height = 0;
dev->mode_config.max_width = 4095;
dev->mode_config.max_height = 2047;
+   dev->mode_config.normalize_zpos = true;
dev->mode_config.funcs = _du_mode_config_funcs;
dev->mode_config.helper_private = _du_mode_config_helper;
 
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 4/6] drm/sti: Let core take care of normalizing the zpos

[Peter Ujfalusi]

Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.

Note: the drm_atomic_helper_check() now includes

if (state->legacy_cursor_update)
state->async_update = !drm_atomic_helper_async_check(drm, state);

which was added after the driver moved away from using it
(38d868e41c4b9250d5a115c049dc2d48f4909581 drm: Don't force all planes to
be added to the state due to zpos)

Signed-off-by: Peter Ujfalusi 
CC: Benjamin Gaignard 
CC: Vincent Abriou 
Acked-by: Daniel Vetter 
Acked-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_drv.c | 24 +++-
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 55b6967d27e1..90c46b49c931 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -119,30 +119,10 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
return ret;
 }
 
-static int sti_atomic_check(struct drm_device *dev,
-   struct drm_atomic_state *state)
-{
-   int ret;
-
-   ret = drm_atomic_helper_check_modeset(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_normalize_zpos(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_helper_check_planes(dev, state);
-   if (ret)
-   return ret;
-
-   return ret;
-}
-
 static const struct drm_mode_config_funcs sti_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
-   .atomic_check = sti_atomic_check,
+   .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
 
@@ -160,6 +140,8 @@ static void sti_mode_config_init(struct drm_device *dev)
dev->mode_config.max_height = STI_MAX_FB_HEIGHT;
 
dev->mode_config.funcs = _mode_config_funcs;
+
+   dev->mode_config.normalize_zpos = true;
 }
 
 DEFINE_DRM_GEM_CMA_FOPS(sti_driver_fops);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 0/6] drm: zpos normalization cleanup and omapdrm to use it

[Peter Ujfalusi]

Hi,

Changes since v3:
- Moved the new normalize_zpos bool to be around another bools
- Extended the commit message for sti that the drm_atomic_helper_check() is
  going to ask for async_update due to the legacy cursor usage.

Changes since v2:
- Fixed commit messages (s/drm_device/drm_mode_config)
- Added ack from Benjamin Gaignard to drm/sti patch

Changes since v1:
- normalize_zpos flag moved to drm_mode_config
- Added comment to note the side effect of normalization and updated the comment
  for normalized_zpos in the header file as well.
- Added Acked-by from Daniel to patch 2-6 but not for patch 1 as I'm not sure if
  the comments I have added matches with what is expected to be.

The first patch is adding a flag to drm_device that drivers can set if they want
the zpos to be normalized.

Then convert exynos, tegra, sti and rcar-du to use this flag instead of
re-implementing the drm_atomic_helper_check() locally just to add the call to
drm_atomic_normalize_zpos().

The last patch is moving omapdrm to use the zpos normalization as well to comply
with the UAPI documentation regarding to zpos.

Laurent's note in an earlier thread:
https://marc.info/?l=dri-devel=151567355225029=2

"The problem is that zpos normalization requires accessing the state of all 
enabled planes for a CRTC in order to compute (and store) the normalized zpos 
values. This thus forces all planes to be added to the commit state, even when 
the commit doesn't touch the zpos property. I assume this caused issues 
(possibly performance issues) in drivers that then performed hardware setup of 
all planes as a result."

can be addressed later in the core for all users of drm_atomic_normalize_zpos()

Regards,
Peter
---
Peter Ujfalusi (6):
  drm: Add drm_mode_config->normalize_zpos boolean
  drm/exynos: Let core take care of normalizing the zpos
  drm/tegra: Let core take care of normalizing the zpos
  drm/sti: Let core take care of normalizing the zpos
  drm: rcar-du: Let core take care of normalizing the zpos
  drm/omap: Use normalized zpos for plane placement

 drivers/gpu/drm/drm_atomic_helper.c | 11 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  1 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  4 +++-
 drivers/gpu/drm/omapdrm/omap_drv.c  |  3 +++
 drivers/gpu/drm/omapdrm/omap_plane.c|  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 11 ++-
 drivers/gpu/drm/sti/sti_drv.c   | 24 +++-
 drivers/gpu/drm/tegra/drm.c | 27 +++
 include/drm/drm_mode_config.h   |  8 
 include/drm/drm_plane.h |  4 ++--
 11 files changed, 36 insertions(+), 79 deletions(-)

-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 1/6] drm: Add drm_mode_config->normalize_zpos boolean

[Peter Ujfalusi]

Instead of drivers duplicating the drm_atomic_helper_check() code to be
able to normalize the zpos they can use the normalize_zpos flag to let the
drm core to do it.

Signed-off-by: Peter Ujfalusi 
---
 drivers/gpu/drm/drm_atomic_helper.c | 11 +++
 include/drm/drm_mode_config.h   |  8 
 include/drm/drm_plane.h |  4 ++--
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ab4032167094..0f6a4949e6dc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -873,6 +873,11 @@ EXPORT_SYMBOL(drm_atomic_helper_check_planes);
  * functions depend upon an updated adjusted_mode.clock to e.g. properly 
compute
  * watermarks.
  *
+ * Note that zpos normalization will add all enable planes to the state which
+ * might not desired for some drivers.
+ * For example enable/disable of a cursor plane which have fixed zpos value
+ * would trigger all other enabled planes to be forced to the state change.
+ *
  * RETURNS:
  * Zero for success or -errno
  */
@@ -885,6 +890,12 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
 
+   if (dev->mode_config.normalize_zpos) {
+   ret = drm_atomic_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+   }
+
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
return ret;
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 2cb6f02df64a..0743c01b9f69 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -783,6 +783,14 @@ struct drm_mode_config {
 */
bool allow_fb_modifiers;
 
+   /**
+* @normalize_zpos:
+*
+* If true the drm core will call drm_atomic_normalize_zpos() as part of
+* atomic mode checking from drm_atomic_helper_check()
+*/
+   bool normalize_zpos;
+
/**
 * @modifiers_property: Plane property to list support modifier/format
 * combination.
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 8185e3468a23..2c0adb124e0f 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -50,8 +50,8 @@ struct drm_modeset_acquire_ctx;
  * plane with a lower ID.
  * @normalized_zpos: normalized value of zpos: unique, range from 0 to N-1
  * where N is the number of active planes for given crtc. Note that
- * the driver must call drm_atomic_normalize_zpos() to update this before
- * it can be trusted.
+ * the driver must set drm_mode_config.normalize_zpos or call
+ * drm_atomic_normalize_zpos() to update this before it can be trusted.
  * @src: clipped source coordinates of the plane (in 16.16)
  * @dst: clipped destination coordinates of the plane
  * @state: backpointer to global drm_atomic_state
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 3/6] drm/tegra: Let core take care of normalizing the zpos

[Peter Ujfalusi]

Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.

Signed-off-by: Peter Ujfalusi 
CC: Thierry Reding 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/drm.c | 27 +++
 1 file changed, 3 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d50bddb2e447..037c79d9c6fd 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -33,29 +33,6 @@ struct tegra_drm_file {
struct mutex lock;
 };
 
-static int tegra_atomic_check(struct drm_device *drm,
- struct drm_atomic_state *state)
-{
-   int err;
-
-   err = drm_atomic_helper_check_modeset(drm, state);
-   if (err < 0)
-   return err;
-
-   err = drm_atomic_normalize_zpos(drm, state);
-   if (err < 0)
-   return err;
-
-   err = drm_atomic_helper_check_planes(drm, state);
-   if (err < 0)
-   return err;
-
-   if (state->legacy_cursor_update)
-   state->async_update = !drm_atomic_helper_async_check(drm, 
state);
-
-   return 0;
-}
-
 static struct drm_atomic_state *
 tegra_atomic_state_alloc(struct drm_device *drm)
 {
@@ -90,7 +67,7 @@ static const struct drm_mode_config_funcs 
tegra_drm_mode_config_funcs = {
 #ifdef CONFIG_DRM_FBDEV_EMULATION
.output_poll_changed = drm_fb_helper_output_poll_changed,
 #endif
-   .atomic_check = tegra_atomic_check,
+   .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.atomic_state_alloc = tegra_atomic_state_alloc,
.atomic_state_clear = tegra_atomic_state_clear,
@@ -179,6 +156,8 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
long flags)
 
drm->mode_config.allow_fb_modifiers = true;
 
+   drm->mode_config.normalize_zpos = true;
+
drm->mode_config.funcs = _drm_mode_config_funcs;
drm->mode_config.helper_private = _drm_mode_config_helpers;
 
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 2/6] drm/exynos: Let core take care of normalizing the zpos

[Peter Ujfalusi]

Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.

Signed-off-by: Peter Ujfalusi 
CC: Inki Dae 
CC: Joonyoung Shim 
CC: Seung-Woo Kim 
CC: Kyungmin Park 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  1 -
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  4 +++-
 3 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index a518e9c6d6cc..39284bb7c2c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -37,26 +37,6 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
-int exynos_atomic_check(struct drm_device *dev,
-   struct drm_atomic_state *state)
-{
-   int ret;
-
-   ret = drm_atomic_helper_check_modeset(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_normalize_zpos(dev, state);
-   if (ret)
-   return ret;
-
-   ret = drm_atomic_helper_check_planes(dev, state);
-   if (ret)
-   return ret;
-
-   return ret;
-}
-
 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index df2262f70d91..075957cb6ba1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -275,7 +275,6 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
 
 int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state 
*state,
 bool nonblock);
-int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state 
*state);
 
 
 extern struct platform_driver fimd_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 0faaf829f5bf..2379d732da67 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -206,7 +206,7 @@ static struct drm_mode_config_helper_funcs 
exynos_drm_mode_config_helpers = {
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
-   .atomic_check = exynos_atomic_check,
+   .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
 
@@ -227,4 +227,6 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
dev->mode_config.helper_private = _drm_mode_config_helpers;
 
dev->mode_config.allow_fb_modifiers = true;
+
+   dev->mode_config.normalize_zpos = true;
 }
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH 1/2] fbdev: don't select I2C directly

[Geert Uytterhoeven]

On Fri, Feb 2, 2018 at 12:59 PM, Arnd Bergmann  wrote:
> On Fri, Feb 2, 2018 at 1:21 AM, Randy Dunlap  wrote:
>> b. DRM configuration is a mess. You shouldn't want to follow their model. :)
>
> Right, that should also be fixed, so DRM no longer includes I2C ;-)
>
> At the moment, DRM is the most common cause for circular dependencies
> because it has a number of 'select' statements for symbols that otherwise
> are used with 'depends on'. We should probably address the 'select I2C'
> portion in there, but also some of the others like:
>
> drivers/gpu/drm/Kconfig:select POWER_SUPPLY
> drivers/gpu/drm/Kconfig:select HWMON
> drivers/gpu/drm/Kconfig:select FB
> drivers/gpu/drm/udl/Kconfig: select USB

USB? Seriously?

> drivers/gpu/drm/sti/Kconfig: select OF
> drivers/gpu/drm/sti/Kconfig: select RESET_CONTROLLER
> drivers/gpu/drm/etnaviv/Kconfig:select CMA if HAVE_DMA_CONTIGUOUS
> drivers/gpu/drm/etnaviv/Kconfig:select TMPFS
> drivers/gpu/drm/i915/Kconfig.debug:select DEBUG_FS
> drivers/gpu/drm/i915/Kconfig.debug:select PREEMPT_COUNT
> drivers/gpu/drm/i915/Kconfig.debug: select TRACING
> drivers/gpu/drm/i915/Kconfig.debug: select FAULT_INJECTION
> drivers/gpu/drm/mediatek/Kconfig:   select MEMORY
> drivers/gpu/drm/mediatek/Kconfig:   select GENERIC_PHY
> drivers/gpu/drm/msm/Kconfig:select REGULATOR
>
>> c. If I2C is not enabled in the FB menu, someone could just add something 
>> like this:
>>
>> comment "Enable I2C to see more driver choices"
>> depends on !I2C
>
> I don't think that would address the issue of 'defconfig' builds losing
> I2C support when it's no longer automatically selection. On x86, this
> is not an issue, as X86 always enables I2C. For the rest, we could
> do a hack like this:
>
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -8,6 +8,7 @@ config I2C
> tristate "I2C support"
> select RT_MUTEXES
> select IRQ_DOMAIN
> +   default DRM || FB
> ---help---
>   I2C (pronounce: I-squared-C) is a slow serial bus protocol used in
>   many micro controller applications and developed by Philips.  SMBus,
>
> which would let all 'defconfig' versions keep working. It's a bit ugly, but
> at least wouldn't cause other circular dependencies.

And then we'll have to refresh all defconfigs for machines with FB and
without I2C?

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 libdrm] drm: Fix 32-bit drmSyncobjWait.

[Christian König]

Am 06.02.2018 um 11:23 schrieb Bas Nieuwenhuizen:

Otherwise we get an EFAULT, at least on a 64-bit kernel.

Fixes: 2048a9e7 "drm: add drmSyncobjWait wrapper"


Reviewed-by: Christian König 


---
  xf86drm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 74b4e230..1e87610b 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4271,7 +4271,7 @@ int drmSyncobjWait(int fd, uint32_t *handles, unsigned 
num_handles,
  int ret;
  
  memclear(args);

-args.handles = (intptr_t)handles;
+args.handles = (uintptr_t)handles;
  args.timeout_nsec = timeout_nsec;
  args.count_handles = num_handles;
  args.flags = flags;


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

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

[Wolfram Sang]

> I found two more using "git grep 'define.*0x[0-9a-f]* < '":

I added '[0-9]\+' at the end of the regex to reduce the number of false
positives...

> drivers/net/can/m_can/m_can.c:#define RXFC_FWM_MASK (0x7f < 
> RXFC_FWM_SHIFT)
> drivers/usb/gadget/udc/goku_udc.h:#define INT_EPnNAK(n)
> (0x00100 < (n)) /* 0 < n < 4 */

... but you found those two true positives in there. Nice, thanks!



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

[PATCH libdrm] drm: Fix 32-bit drmSyncobjWait.

[Bas Nieuwenhuizen]

Otherwise we get an EFAULT, at least on a 64-bit kernel.

Fixes: 2048a9e7 "drm: add drmSyncobjWait wrapper"
---
 xf86drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 74b4e230..1e87610b 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4271,7 +4271,7 @@ int drmSyncobjWait(int fd, uint32_t *handles, unsigned 
num_handles,
 int ret;
 
 memclear(args);
-args.handles = (intptr_t)handles;
+args.handles = (uintptr_t)handles;
 args.timeout_nsec = timeout_nsec;
 args.count_handles = num_handles;
 args.flags = flags;
-- 
2.16.1

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

RE: [PATCH 0/5] prevent OOM triggered by TTM

[He, Roger]

Move the new call out of ttm_mem_global_reserve() and into 
ttm_page_alloc.c or ttm_page_alloc_dma.c (but keep it in ttm_memory.c).  
ttm_mem_global_reserve() is called for each page allocated and 
si_mem_available() is a bit to heavy for that.

Good idea! Agree with you completely, because initially I also concern that but 
no better way at that time.
Going to improve the patches. Thanks!

-Original Message-
From: Koenig, Christian 
Sent: Tuesday, February 06, 2018 5:52 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Cc: tho...@shipmail.org
Subject: Re: [PATCH 0/5] prevent OOM triggered by TTM

Nice work, but a few comments.

First of all you need to reorder the patches. Adding the exceptions to the 
restrictions should come first, then the restriction itself. 
Otherwise we might break a setup in between the patches and that is bad for 
bisecting.

Then make all values configurable, e.g. take a closer look at ttm_memory.c. 
Just add attributes directly under the memory_accounting directory (see 
ttm_mem_global_init).

Additional to that you can't put device specific information (the no_retry 
flag) into ttm_mem_global, that is driver unspecific and won't work like this.

Move the new call out of ttm_mem_global_reserve() and into ttm_page_alloc.c or 
ttm_page_alloc_dma.c (but keep it in ttm_memory.c). 
ttm_mem_global_reserve() is called for each page allocated and
si_mem_available() is a bit to heavy for that.

Maybe name TTM_OPT_FLAG_ALLOW_ALLOC_ANYWAY something like _FORCE_ALLOCATION or 
_ALLOW_OOM.

And please also try if a criteria like (si_mem_available() +
get_nr_swap_pages()) < limit works as well. This way we would have only a 
single new limit.

Regards,
Christian.

Am 06.02.2018 um 10:04 schrieb Roger He:
> currently ttm code has no any allocation limit. So it allows pages 
> allocatation unlimited until OOM. Because if swap space is full of 
> swapped pages and then system memory will be filled up with ttm pages. 
> and then any memory allocation request will trigger OOM.
>
>
> the following patches is for prevent OOM triggered by TTM.
> the basic idea is when allocating TTM pages, check the free swap space 
> firt. if it is less than the fixe limit, reject the allocation request.
> but there are two exceptions which should allow it regardless of zone 
> memory account limit.
> a. page fault
> for ttm_mem_global_reserve if serving for page fault routine,
> because page fault routing already grabbed system memory so the
> allowance of this exception is harmless. Otherwise, it will trigger
>  OOM killer.
> b. suspend
> anyway, we should allow suspend success always.
>
>
> at last, if bdev.no_retry is false (by defaut), keep the original 
> behavior no any change.
>
> Roger He (5):
>drm/ttm: check if the free swap space is under limit 256MB
>drm/ttm: keep original behavior except with flag no_retry
>drm/ttm: use bit flag to replace allow_reserved_eviction in
>  ttm_operation_ctx
>drm/ttm: add bit flag TTM_OPT_FLAG_ALLOW_ALLOC_ANYWAY
>drm/ttm: add input parameter allow_allo_anyway for ttm_bo_evict_mm
>
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  4 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  4 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  | 10 +++---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  8 +++--
>   drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
>   drivers/gpu/drm/qxl/qxl_object.c|  4 +--
>   drivers/gpu/drm/radeon/radeon_device.c  |  6 ++--
>   drivers/gpu/drm/radeon/radeon_object.c  |  6 ++--
>   drivers/gpu/drm/radeon/radeon_object.h  |  3 +-
>   drivers/gpu/drm/ttm/ttm_bo.c| 19 +++
>   drivers/gpu/drm/ttm/ttm_bo_vm.c |  6 ++--
>   drivers/gpu/drm/ttm/ttm_memory.c| 51 
> ++---
>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c|  1 -
>   drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  6 ++--
>   include/drm/ttm/ttm_bo_api.h| 14 ++--
>   include/drm/ttm/ttm_memory.h|  6 
>   18 files changed, 111 insertions(+), 43 deletions(-)
>

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

Re: Questions on page flips and atomic modeset

[Oleksandr Andrushchenko]

Hello, Ville!

Thank you very much for such a comprehensive answer.

Please see inline


On 02/05/2018 06:47 PM, Ville Syrjälä wrote:

On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:

Hello,


I have a DRM driver which implements display protocol for Xen [1]
and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
tells the other end that some display buffer needs to be displayed,
e.g. it is issued by the frontend DRM driver to the corresponding
backend when the former wants to display a buffer.
Two notes:
1. Communication between two remote parties can obviously fail.
2. At the moment only primary plane is supported, so we can think of
the display buffer as of CRTC's primary fb.

There are two APIs available for user-space to initiate a page-flip
(please correct me if I am wrong here): legacy via DRM_IOCTL_MODE_PAGE_FLIP
and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
(which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
I can return an error code, so the DRM core knows that page flip
cannot be done.

But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC for
which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via .atomic_check +
.atomic_flush callbacks.

The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP request
to the .atomic_flush callback which seems to be the right place to serve
both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).

The questions I have with this are:

1. What is the framebuffer I can send to the backend?
I assume I can use crtc->primary->fb from
drm_crtc_helper_funcs.atomic_flush,
is this assumption correct?

Planes are explicit in the atomic world, so you should just deal with
the plane if and when it's part of the drm_atomic_state. Look at eg.
drm_atomic_helper_commit_planes() how to figure out what's in the
state.

Yes, this is clear. The question was about the frame buffer
I get in drm_crtc_helper_funcs.atomic_flush which only has
old_crtc_state, so I assumed I can use crtc->primary->fb there.
Or you mean I have to dig into old_crtc_state->state to find
out if there is a plane and if it has a frambuffer and if so
use it instead of crtc->primary->fb?

  And I guess you're already planning on using that helper since
you mention .atomic_flush().

Not directly, but via drm_mode_config_funcs.atomic_commit


One should really think of the drm_atomic_state as more of a transaction
rather than as a state (since not all objects need be part of it).

Thank you

2. Is the check (either to send or not) for crtc->primary->fb != NULL
enough?
I assume there are other cases when .atomic_flush gets called,
so is there a way I can filter out unneeded cases? E.g. those which
are not for page flipping?

Each object taking part in the transaction will have an associated
new state and old state.

As I replied above I only have old state in .atomic_flush

  You can compare the two to figure out what
changed, and in addition there may already some flags in the base
class for the state that indicate what may have changed (eg.
drm_crtc_state::mode_changed etc.). Such flags may be set by the
core to help figure out what needs doing.

Yes, thank you

3. If communication with the backend fails there is no way for me
to tell the DRM core about this as .atomic_flush is called after
"the point of no return". Do you think I can remember the error
code and report it next time .atomic_check is called? So, other page
flips will not run on broken connection, for example.

Do you know when it might fail?

Not really, this is a software protocol to talk from
the frontend para-virtual DRM driver to its backend
in other Xen domain

  If so you should implement the appropriate
checks in .atomic_check() etc. to try and make sure it never happens
(barring a total hardware failure for example).

Generally what we (i915) do is try to check everything up front, but if
an unexpected error does happen later we just muddle through and log an
error.

For us I think the most common late failure is DP link training failure.
That we can't fully check up front since it depends on external factors:
sink, dongles, cabling, etc. For those we added a new connector property
to signal to userspace that the link is having issues, allowing
userspace to reconfigure things such that we lower the link bandwidth
requirements.

I cannot do that this way, because the driver has to run
seamlessly for user-space, no specific utilities  are
expected to run.


The link_status mechanism could perhaps be used to to work around other
"late errors". But in general if you want to somehow fix that error you
have to know what caused it, no?

That is correct, so I will print an error message on
page flip error so user has at list a clue on what's
wrong

  So if you just get a random error for
seemingly no reason there's very little you can do apart from blindly

Re: [PATCH 0/5] prevent OOM triggered by TTM

[Christian König]

Nice work, but a few comments.

First of all you need to reorder the patches. Adding the exceptions to 
the restrictions should come first, then the restriction itself. 
Otherwise we might break a setup in between the patches and that is bad 
for bisecting.


Then make all values configurable, e.g. take a closer look at 
ttm_memory.c. Just add attributes directly under the memory_accounting 
directory (see ttm_mem_global_init).


Additional to that you can't put device specific information (the 
no_retry flag) into ttm_mem_global, that is driver unspecific and won't 
work like this.


Move the new call out of ttm_mem_global_reserve() and into 
ttm_page_alloc.c or ttm_page_alloc_dma.c (but keep it in ttm_memory.c). 
ttm_mem_global_reserve() is called for each page allocated and 
si_mem_available() is a bit to heavy for that.


Maybe name TTM_OPT_FLAG_ALLOW_ALLOC_ANYWAY something like 
_FORCE_ALLOCATION or _ALLOW_OOM.


And please also try if a criteria like (si_mem_available() + 
get_nr_swap_pages()) < limit works as well. This way we would have only 
a single new limit.


Regards,
Christian.

Am 06.02.2018 um 10:04 schrieb Roger He:

currently ttm code has no any allocation limit. So it allows pages
allocatation unlimited until OOM. Because if swap space is full
of swapped pages and then system memory will be filled up with ttm
pages. and then any memory allocation request will trigger OOM.


the following patches is for prevent OOM triggered by TTM.
the basic idea is when allocating TTM pages, check the free swap space
firt. if it is less than the fixe limit, reject the allocation request.
but there are two exceptions which should allow it regardless of zone
memory account limit.
a. page fault
for ttm_mem_global_reserve if serving for page fault routine,
because page fault routing already grabbed system memory so the
allowance of this exception is harmless. Otherwise, it will trigger
 OOM killer.
b. suspend
anyway, we should allow suspend success always.


at last, if bdev.no_retry is false (by defaut), keep the original behavior
no any change.

Roger He (5):
   drm/ttm: check if the free swap space is under limit 256MB
   drm/ttm: keep original behavior except with flag no_retry
   drm/ttm: use bit flag to replace allow_reserved_eviction in
 ttm_operation_ctx
   drm/ttm: add bit flag TTM_OPT_FLAG_ALLOW_ALLOC_ANYWAY
   drm/ttm: add input parameter allow_allo_anyway for ttm_bo_evict_mm

  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  4 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  |  4 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  | 10 +++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h  |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  8 +++--
  drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +-
  drivers/gpu/drm/qxl/qxl_object.c|  4 +--
  drivers/gpu/drm/radeon/radeon_device.c  |  6 ++--
  drivers/gpu/drm/radeon/radeon_object.c  |  6 ++--
  drivers/gpu/drm/radeon/radeon_object.h  |  3 +-
  drivers/gpu/drm/ttm/ttm_bo.c| 19 +++
  drivers/gpu/drm/ttm/ttm_bo_vm.c |  6 ++--
  drivers/gpu/drm/ttm/ttm_memory.c| 51 ++---
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c|  1 -
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  6 ++--
  include/drm/ttm/ttm_bo_api.h| 14 ++--
  include/drm/ttm/ttm_memory.h|  6 
  18 files changed, 111 insertions(+), 43 deletions(-)



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

Re: [PATCH 4/5 v2] drm/pl111: Support variants with broken VBLANK

[Linus Walleij]

On Sun, Feb 4, 2018 at 12:44 AM, Eric Anholt  wrote:
> Linus Walleij  writes:
>
>> The early Integrator CLCD synthesized in the Integrator CP and
>> IM-PD1 FPGAs are broken: their vertical and next base interrupts
>> are not functional. Support these variants by simply disabling
>> the use of the vblank interrupt on these variants.
>
> I do wonder if we just have the vblank interrupt number wrong or
> something for Integrator.  However, let's get to at least functional
> parity with fbdev before we worry too much about the new features that
> DRM can bring us.
>
> The remainder of this series is also:
>
> Reviewed-by: Eric Anholt 

Thanks man, sent it out again with your review tag (I do this
to pick it to the dim-script thing with tags and all). And as a last
checkpoint for everyone else.

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