Re: [PATCH] drm/bridge/synopsys: dsi: Add read feature

[Andrzej Hajda]

On 04.02.2018 22:31, Philippe Cornu wrote:
> This patch adds the DCS/GENERIC DSI read feature.
>
> Signed-off-by: Philippe Cornu 
> ---
Queued to drm-misc-next.
--
Regards
Andrzej
___
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 
Queued to drm-misc-next.
--
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #5 from Dmitry  ---
dc1 + hdmi. The problem remained

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

[git pull] drm for v4.16-rc1 (part 2 - fixes)

[Dave Airlie]

Hi Linus,

Ben missed sending his tree, but he really didn't have much stuff in
it, GP108 acceleration support is enabled by "secure boot" support,
some clockgating work on Kepler, and bunch of fixes. The main bulk is
regenerated firmware files, the change to them really isn't that
large.

Otherwise this contains regular Intel and AMDGPU fixes

Regards,
Dave.

The following changes since commit 24b8ef699e8221d2b7f813adaab13eec053e1507:

  drm/ast: Load lut in crtc_commit (2018-02-01 11:35:46 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.16-part2-fixes

for you to fetch changes up to 94fc27ac487a80daf42f97b1a0503d029f3c1325:

  Merge tag 'drm-intel-next-fixes-2018-02-07' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-02-08
08:21:37 +1000)


nouveau features, i915 + amdgpu fixes


Anusha Srivatsa (1):
  drm/i915/glk: Disable Guc and HuC on GLK

Arnd Bergmann (2):
  drm/nouveau: nouveau: use correct string length
  drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning

Ben Skeggs (8):
  drm/nouveau/secboot/r370: move a bunch of r375 stuff to a new
implementation
  drm/nouveau/secboot/r370: implement support for booting LS SEC2 ucode
  drm/nouveau/secboot/gp108: implement on top of acr_r370
  drm/nouveau/fbcon: add module parameter to select bits-per-pixel
  drm/nouveau/bo: add helper functions for handling pinned+mapped buffers
  drm/nouveau/kms/nv50: prepare for double-buffered LUTs
  drm/nouveau/kms/nv50: use INTERPOLATE_257_UNITY_RANGE LUT on
newer chipsets
  drm/nouveau/kms/nv50: fix handling of gamma since atomic conversion

Changbin Du (1):
  drm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=on

Chris Wilson (5):
  drm/i915/pmu: Reconstruct active state on starting busy-stats
  drm/i915: Only attempt to scan the requested number of shrinker slabs
  drm/i915: Protect WC stash allocation against direct reclaim
  drm/i915: Always run hangcheck while the GPU is busy
  drm/i915/ppgtt: Pin page directories before allocation

Christian König (3):
  drm/amdgpu: fix another potential cause of VM faults
  drm/amdgpu: fix locking in vega10_ih_prescreen_iv
  drm/amdgpu: remove WARN_ON when VM isn't found v2

Christoph Böhmwalder (1):
  drm/nouveau/drm/nouveau/mmu: fix odd_ptr_err.cocci warnings

Dave Airlie (4):
  Merge tag 'drm-intel-next-fixes-2018-02-01' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next
  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-next
  Merge branch 'drm-next-4.16' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'drm-intel-next-fixes-2018-02-07' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next

Hang Yuan (1):
  drm/i915/gvt: validate gfn before set shadow page entry

Huang Rui (1):
  drm/amdgpu: use queue 0 for kiq ring

Ilia Mirkin (1):
  drm/nouveau/kms/nv50: use "low res" lut for indexed mode

Imre Deak (2):
  drm/i915: Fix using BIT_ULL() vs. BIT() for power domain masks
  drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing

Jani Nikula (1):
  drm/i915/bios: add DP max link rate to VBT child device struct

Julia Lawall (1):
  drm/radeon: adjust tested variable

Karol Herbst (1):
  drm/nouveau/pmu/fuc: don't use movw directly anymore

Lionel Landwerlin (1):
  Revert "drm/i915: mark all device info struct with __initconst"

Luis de Bethencourt (1):
  drm/nouveau/mmu: Fix trailing semicolon

Lyude Paul (5):
  drm/nouveau: Add support for basic clockgating on Kepler1
  drm/nouveau: Add support for BLCG on Kepler1
  drm/nouveau: Add support for BLCG on Kepler2
  drm/nouveau: Add support for SLCG for Kepler2
  drm/nouveau: Introduce NvPmEnableGating option

Maarten Lankhorst (1):
  drm/i915: Always call to intel_display_set_init_power() in resume_early.

Manasi Navare (1):
  drm/i915/edp: Do not do link training fallback or prune modes on EDP

Michal Srb (2):
  drm/i915/cmdparser: Check reg_table_count before derefencing.
  drm/i915/cmdparser: Do not check past the cmd length.

Michel Thierry (1):
  drm/i915/gvt: Do not use I915_NUM_ENGINES to iterate over the
mocs regs array

Mika Kahola (1):
  drm/i915: Check for fused or unused pipes

Oscar Mateo (1):
  drm/i915: Stop getting the fault address from RING_FAULT_REG

Pei Zhang (1):
  drm/i915/gvt: add PLANE_KEYMAX regs to mmio track list

Rodrigo Vivi (2):
  drm/i915/cnp: Ignore VBT request for know invalid DDC pin.
  drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

Roger He (1):
  drm/ttm: fix missing parameter change for ttm_bo_cleanup_refs

Sagar Arun Kamble (1):
  drm/i915/guc: Add uc_fini_wq in gem_init 

[PATCH 3/3] drm/radeon: only enable swiotlb path when need

[Chunming Zhou]

swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.

Change-Id: I1802645833155a9cd808913f863981173a82145f
Signed-off-by: Chunming Zhou 
---
 drivers/gpu/drm/radeon/radeon.h| 1 +
 drivers/gpu/drm/radeon/radeon_device.c | 2 ++
 drivers/gpu/drm/radeon/radeon_ttm.c| 6 +++---
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d34887873dea..4a2eb409aacc 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2387,6 +2387,7 @@ struct radeon_device {
struct radeon_dummy_pagedummy_page;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
boolneeds_reset, in_reset;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 8d3e3d2e0090..62d8626e1fe8 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1367,6 +1368,7 @@ int radeon_device_init(struct radeon_device *rdev,
rdev->need_dma32 = true;
 
dma_bits = rdev->need_dma32 ? 32 : 40;
+   rdev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
rdev->need_dma32 = true;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a0a839bc39bf..c1e3862a48a4 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -756,7 +756,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm,
 #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (rdev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, rdev->dev, ctx);
}
 #endif
@@ -788,7 +788,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
 #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (rdev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, rdev->dev);
return;
}
@@ -1155,7 +1155,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
*rdev)
count = ARRAY_SIZE(radeon_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
-   if (!swiotlb_nr_tbl())
+   if (!(rdev->need_swiotlb && swiotlb_nr_tbl()))
--count;
 #endif
 
-- 
2.14.1

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

[PATCH 2/3] drm/amdgpu: only enable swiotlb alloc when need

[Chunming Zhou]

get the max io mapping address of system memory to see if it is over
our card accessing range.

Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c   | 2 ++
 6 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 257424dd8a52..627a06185368 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1437,6 +1437,7 @@ struct amdgpu_device {
const struct amdgpu_asic_funcs  *asic_funcs;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
struct work_struct  reset_work;
struct notifier_block   acpi_nb;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 95f990140f2a..a021de9629ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1018,7 +1018,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
}
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, adev->dev, ctx);
}
 #endif
@@ -1045,7 +1045,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
adev = amdgpu_ttm_adev(ttm->bdev);
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, adev->dev);
return;
}
@@ -2007,7 +2007,7 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
-   if (!swiotlb_nr_tbl())
+   if (!(adev->need_swiotlb && swiotlb_nr_tbl()))
--count;
 #endif
 
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index 5eacc0819b66..63d0720ac21f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v6_0.h"
 #include "amdgpu_ucode.h"
@@ -855,6 +856,7 @@ static int gmc_v6_0_sw_init(void *handle)
 
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index ce7f484f86f9..f70a81fcadec 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "cikd.h"
 #include "cik.h"
@@ -1003,6 +1004,7 @@ static int gmc_v7_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index f53f3936fd4f..21fe9afb6e73 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v8_0.h"
 #include "amdgpu_ucode.h"
@@ -1101,6 +1102,7 @@ static int gmc_v8_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 2c60981d2eec..8730768efd13 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -21,6 +21,7 @@
  *
  */
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v9_0.h"
 #include "amdgpu_atomfirmware.h"
@@ -879,6 +880,7 @@ static int gmc_v9_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 44;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));

[PATCH 1/3] drm: add func to get max iomem address

[Chunming Zhou]

it will be used to check if the driver needs swiotlb

Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou 
---
 include/drm/drm_cache.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0cfb..442c9ba63d03 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -39,6 +39,19 @@ void drm_clflush_pages(struct page *pages[], unsigned long 
num_pages);
 void drm_clflush_sg(struct sg_table *st);
 void drm_clflush_virt_range(void *addr, unsigned long length);
 
+static inline u64 drm_get_max_iomem(void)
+{
+   struct resource *tmp;
+   u64 max_iomem = 0;
+
+   for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
+   max_iomem = max(max_iomem,  tmp->end);
+   }
+
+   return max_iomem;
+}
+
+
 static inline bool drm_arch_can_wc_memory(void)
 {
 #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
-- 
2.14.1

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

Re: [PATCH v3 5/8] drm: Handle aspect ratio info in atomic and legacy modeset paths

[Nautiyal, Ankit K]

Hi Ville,

I still have some queries regarding the handling of aspect ratio flags 
in getblob ioctl.


Please find below my responses inline.


On 2/1/2018 6:24 PM, Ville Syrjälä wrote:

On Thu, Feb 01, 2018 at 04:35:22PM +0530, Nautiyal, Ankit K wrote:

Hi Ville,

Appreciate your time and the suggestions.
Please find my response inline:

On 1/31/2018 6:39 PM, Ville Syrjälä wrote:

On Wed, Jan 31, 2018 at 12:04:52PM +0530, Nautiyal, Ankit K wrote:

On 1/30/2018 12:23 AM, Ville Syrjälä wrote:

On Fri, Jan 12, 2018 at 11:51:33AM +0530, Nautiyal, Ankit K wrote:

From: Ankit Nautiyal 

If the user mode does not support aspect-ratio, and requests for
a modeset, then the flag bits representing aspect ratio in the
given user-mode must be rejected.
Similarly, while preparing a user-mode from kernel mode, the
aspect-ratio info must not be given, if aspect-ratio is not
supported by the user.

This patch:
1. adds a new bit field aspect_ratio_allowed in drm_atomic_state,
which is set only if the aspect-ratio is supported by the user.
2. discards the aspect-ratio info from the user mode while
preparing kernel mode structure, during modeset, if the
user does not support aspect ratio.
3. avoids setting the aspect-ratio info in user-mode, while
converting user-mode from the kernel-mode.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
-Do not corrupt the current crtc state by updating aspect ratio
on the fly.
---
drivers/gpu/drm/drm_atomic.c | 61 
+---
drivers/gpu/drm/drm_crtc.c   | 19 ++
include/drm/drm_atomic.h |  2 ++
3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 69ff763..39313e2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -316,6 +316,35 @@ static s32 __user *get_out_fence_for_crtc(struct 
drm_atomic_state *state,

	return fence_ptr;

}
+/**
+ * drm_atomic_allow_aspect_ratio_for_kmode
+ * @state: the crtc state
+ * @mode: kernel-internal mode, which is used to create a duplicate mode,
+ * with updated picture aspect ratio.
+ *
+ * Allow the aspect ratio info in the kernel mode only if aspect ratio is
+ * supported.
+ *
+ * RETURNS:
+ * kernel-internal mode with updated picture aspect ratio value.
+ */
+
+struct drm_display_mode*
+drm_atomic_allow_aspect_ratio_for_kmode(struct drm_crtc_state *state,
+   const struct drm_display_mode *mode)
+{
+   struct drm_atomic_state *atomic_state = state->state;
+   struct drm_display_mode *ar_kmode;
+
+   ar_kmode = drm_mode_duplicate(state->crtc->dev, mode);
+   /*
+* If aspect ratio is not supported, set the picture aspect ratio as
+* NONE.
+*/
+   if (atomic_state && !atomic_state->allow_aspect_ratio)
+   ar_kmode->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   return ar_kmode;
+}

/**

 * drm_atomic_set_mode_for_crtc - set mode for CRTC
@@ -341,7 +370,10 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
state->mode_blob = NULL;

	if (mode) {

-   drm_mode_convert_to_umode(, mode);
+   struct drm_display_mode *ar_mode;
+
+   ar_mode = drm_atomic_allow_aspect_ratio_for_kmode(state, mode);
+   drm_mode_convert_to_umode(, ar_mode);

This still looks sketchy.

I believe there are just two places where we need to filter out the
aspect ratio flags from the umode, namely the getblob and getcrtc
ioctls.

AFAIK The getblob ioctl can be called for edid blob, gamma, ctm blob,
etc. apart from the mode blob.
Is there any way to check from blob id (or by any other means),
if the data is for the mode, or edid, or gamma etc.

I think we'd have to somehow mark the mode blobs as special. Until we
have more need for cleaning up blobs before returning them to userspace
I think a simple flag should do. If we come up with more uses like this
then it might make sense to introduce some kind of optional filter
function for blobs.

If my understanding is correct,
1. To be able to do this, we need to change in uapi.

We should be fine with an internal flag. Obviously it won't be set
for blobs freshly created by userspace, but that's fine because we
do no other error checking for them either. The error checking will
happen when the user tries to actually use the blob.


I am not sure why getblob ioctl should even come into picture. (Perhaps 
I am missing something).

As per my understanding:
If a userspace needs to set a mode, it will just create a blob with 
drm_mode_mode_info,
and get the blob-id. This blob-id would be supplied to 
drm_mode_atomic_ioctl as a crtc

property mode_id.
At the kernel side,  the crtc property mode_id is set by looking-up for 
mode blob from blob id.

I am doing the change in the user mode aspect-ratio 

[PATCH v2 2/2] amdgpu/dc/dml: Support clang option for stack alignment

[Matthias Kaehlcke]

DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.

Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.

Reported-by: Guenter Roeck 
Signed-off-by: Matthias Kaehlcke 
---
Changes in v2:
- use consistent syntax and formatting for assignment of cc_stack_align

 drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index b8cadf833e71..a92189eddab0 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -24,7 +24,13 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4
+ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+   cc_stack_align := -mpreferred-stack-boundary=4
+else ifneq ($(call cc-option, -mstack-alignment=16),)
+   cc_stack_align := -mstack-alignment=16
+endif
+
+subdir-ccflags-y += -mhard-float -msse $(cc_stack_align)
 
 DML = display_mode_lib.o display_rq_dlg_calc.o \
  display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
-- 
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 v2 1/2] amdgpu/dc/dml: Consolidate redundant CFLAGS

[Matthias Kaehlcke]

Use subdir-ccflags instead of specifying the same flags for every source
file.

Signed-off-by: Matthias Kaehlcke 
Reviewed-by: Guenter Roeck 
---
Changes in v2:
- added 'Reviewed-by: Guenter Roeck ' tag

 drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 3488af2b5786..b8cadf833e71 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -24,15 +24,7 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-CFLAGS_display_mode_vba.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_mode_lib.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_pipe_clocks.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
-CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
-CFLAGS_soc_bounding_box.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4
-
+subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4
 
 DML = display_mode_lib.o display_rq_dlg_calc.o \
  display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
-- 
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 2/2] amdgpu/dc/dml: Support clang option for stack alignment

[Matthias Kaehlcke]

El Wed, Feb 07, 2018 at 05:34:44PM -0800 Guenter Roeck ha dit:

> On Wed, Feb 7, 2018 at 5:21 PM, Matthias Kaehlcke  wrote:
> > DML uses the compiler option -mpreferred-stack-boundary=4 to configure
> > a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> > instead, which expects as parameter the alignment in bytes, and not a
> > power of two like -mpreferred-stack-boundary.
> >
> > Probe for both compiler options and use the correct one, similar to
> > what is done in arch/x86/Makefile.
> >
> > Reported-by: Guenter Roeck 
> > Signed-off-by: Matthias Kaehlcke 
> > ---
> >  drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > index b8cadf833e71..740975931d21 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > @@ -24,7 +24,13 @@
> >  # It provides the general basic services required by other DAL
> >  # subcomponents.
> >
> > -subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4
> > +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> > +   cc_stack_align=-mpreferred-stack-boundary=4
> > +else ifneq ($(call cc-option, -mstack-alignment=16),)
> > +   cc_stack_align := -mstack-alignment=16
> > +endif
> > +
> Any reason for using both = and := ?

Not really, will fix.

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

[PATCH 1/2] amdgpu/dc/dml: Consolidate redundant CFLAGS

[Matthias Kaehlcke]

Use subdir-ccflags instead of specifying the same flags for every source
file.

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 3488af2b5786..b8cadf833e71 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -24,15 +24,7 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-CFLAGS_display_mode_vba.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_mode_lib.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_pipe_clocks.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
-CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
-CFLAGS_soc_bounding_box.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4
-
+subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4
 
 DML = display_mode_lib.o display_rq_dlg_calc.o \
  display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
-- 
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 2/2] amdgpu/dc/dml: Support clang option for stack alignment

[Matthias Kaehlcke]

DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.

Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.

Reported-by: Guenter Roeck 
Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index b8cadf833e71..740975931d21 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -24,7 +24,13 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4
+ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+   cc_stack_align=-mpreferred-stack-boundary=4
+else ifneq ($(call cc-option, -mstack-alignment=16),)
+   cc_stack_align := -mstack-alignment=16
+endif
+
+subdir-ccflags-y += -mhard-float -msse $(cc_stack_align)
 
 DML = display_mode_lib.o display_rq_dlg_calc.o \
  display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
-- 
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 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

Hi Archit,

On 07/02/18 12:33, Kieran Bingham wrote:
> Hi Archit,
> 
> Thank you for your review,
> 



>>>   unsigned int val;
>>>   int ret;
>>>   @@ -1153,24 +1151,35 @@ static int adv7511_probe(struct i2c_client *i2c,
>>> const struct i2c_device_id *id)
>>>   if (ret)
>>>   goto uninit_regulators;
>>>   -    regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, 
>>> edid_i2c_addr);
>>> -    regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
>>> - main_i2c_addr - 0xa);
> 
> 
> Packet address here is written as an offset of -0x0a, which gives 0x2f or 
> 0x33 ... ?
> 
> I think these current offsets are platform specific to a specific platform :)

I appear to be using platform specific maths specific to a non-conforming
platform or universe :-)

Sorry for the incorrect assertion here. - I mixed up 8bit and 7bit values.

The offsets are valid (when calculated correctly) - however - as per my reply to
Laurent - I believe the patch which determined the offsets was using the wrong
base :).

Also - due to a hardware issue on the ADV7511 - the Wheat (as the only known
user of two chips on the same bus) will need to be updated to ensure the current
assignments don't conflict.

--
Kieran

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

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

Hi Laurent,

On 07/02/18 21:59, Laurent Pinchart wrote:
> Hi Kieran,
> 
> On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
>> On 29/01/18 10:26, Laurent Pinchart wrote:
>>> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
 The ADV7511 has four 256-byte maps that can be accessed via the main I²C
 ports. Each map has it own I²C address and acts as a standard slave
 device on the I²C bus.

 Allow a device tree node to override the default addresses so that
 address conflicts with other devices on the same bus may be resolved at
 the board description level.

 Signed-off-by: Kieran Bingham 
 ---

  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
>>>
>>> I don't mind personally, but device tree maintainers usually ask for DT
>>> bindings changes to be split to a separate patch.
>>>
  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 ++-
  3 files changed, 37 insertions(+), 13 deletions(-)

 diff --git
 a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 index 0047b1394c70..f6bb9f6d3f48 100644
 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt

 @@ -70,6 +70,9 @@ Optional properties:
rather than generate its own timings for HDMI output.
  
  - clocks: from common clock binding: reference to the CEC clock.
  - clock-names: from common clock binding: must be "cec".

 +- reg-names : Names of maps with programmable addresses.
 +  It can contain any map needing a non-default address.
 +  Possible maps names are : "main", "edid", "cec", "packet"
>>>
>>> Is the reg-names property (and the additional maps) mandatory or optional
>>> ? If mandatory you should also update the existing DT sources that use
>>> those bindings.
>>
>> They are currently optional. I do prefer it that way - but perhaps due to an
>> issue mentioned below we might need to make this driver mandatory ?
>>
>>> If optional you should define which I2C addresses will be used when
>>> the maps are not specified (and in that case I think we should go for
>>> the addresses listed as default in the datasheet, which correspond to the
>>> current driver implementation when the main address is 0x3d/0x7a).
>>
>> The current addresses do not correspond to the datasheet, even when the
>> implementation main address is set to 0x3d.
> 
> Don't they ? The driver currently uses the following (8-bit) I2C addresses:
> 
> EDID:   main + 4  = 0x7e (0x3f)
> Packet: main - 10 = 0x70 (0x38)
> CEC:main - 2  = 0x78 (0x3c)
> 
> Those are the default addresses according to section 4.1 of the ADV7511W 
> programming guide (rev. B), and they match the ones you set in this patch.

Sorry - I was clearly subtracting 8bit values from a 7bit address in my failed
assertion, to both you and Archit.



>> Thus, in my opinion - they are currently 'wrong' - but perhaps changing them
>> is considered breakage too.
>>
>> A particular issue will arise here too - as on this device - when the device
>> is in low-power mode (after probe, before use) - the maps will respond on
>> their *hardware default* addresses (the ones implemented in this patch),
>> and thus consume that address on the I2C bus regardless of their settings
>> in the driver.
> 
> We've discussed this previously and I share you concern. Just to make sure I 
> remember correctly, did all the secondary maps reset to their default 
> addresses, or just the EDID map ?


The following responds on the bus when programmed at alternative addresses, and
in low power mode. The responses are all 0, but that's still going to conflict
with other hardware if it tries to use the 'un-used' addresses.

Packet (0x38),
Main (0x39),
Fixed (set to 0 by software, but shows up at 0x3e)
and EDID (0x3f).

So actually it's only the CEC which don't respond when in "low-power-mode".


As far as I can see, (git grep  -B3 adi,adv75) - The r8a7792-wheat.dts is the
only instance of a device using 0x3d, which means that Sergei's patch changed
the behaviour of all the existing devices before that.

Thus - this patch could be seen to be a 'correction' back to the original
behaviour for all devices except the Wheat, and possibly devices added after
Sergei's patch went in.

However - by my understanding, - any device which has only one ADV75(3,1)+
should use the hardware defined addresses (the hardware defaults will be
conflicting on the bus anyway, thus should be assigned to the ADV7511)

Any platform which uses *two* ADV7511 devices on the same bus should actually
set *both* devices to use entirely separate addresses - or they will still
conflict with each other.

Now - if my understanding is correct 

RE: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

[Deepak Singh Rawat]

Hi Lukasz,

I hope you are doing great. I was busy with some other stuff but now will be 
working on page-flip damage. At this point I have high level understanding of 
what changes to make and before I start just wanted to confirm from you, 
whether you have made any progress to avoid duplicate work.

Thanks,
Deepak

From: Lukasz Spintzyk [mailto:lukasz.spint...@displaylink.com] 
Sent: Thursday, January 4, 2018 5:53 AM
To: Thomas Hellstrom ; dri-devel@lists.freedesktop.org; 
daniel.vet...@intel.com; gust...@padovan.org; seanp...@chromium.org; 
airl...@linux.ie; Deepak Singh Rawat 
Subject: Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane



On 28/12/2017 10:03, Thomas Hellstrom wrote:
Hi, Lukasz! 

(Sorry for top-posting). 

We have Deepak from our team working on the same subject. I think he's in over 
the holidays so I'll add him to the CC list. 
Great!


Adding damage to the plane state is, IMO the correct way to do it. However, 
from your proposal it's not clear whether damage is given in the plane-, crtc- 
or framebuffer coordinates. The last conclusion from our email thread 
discussion was that they should be given in framebuffer coordinates with 
helpers to compute plane coordinates or crtc coordinates. The reason being that 
it's easier for user-space apps to send damage that way, and again, we have the 
full information that we can clip and scale if necessary. Most drivers probably 
want the damage in clipped plane- or crtc coordinates. Helpers could for 
example be in the form of region iterators. 
Personally i don't know the difference between plane rects and framebuffer 
rects. I don't know what would be better. I was thinking about coordinates of 
framebuffer that is attached to drm_plane_state.


Full (multi-rect) damage regions are OK with us, although we should keep in 
mind that we won't be able to compute region unions in the kernel (yet?). 
Implying: Should we forbid overlapping rects at the interface level or should 
we just recommend rects not to be overlapping? The former would be pretty hard 
to enforce efficiently. 
I would be for recommendation. We can add some helper functions to combine 
rects and set some limits on number of rects to prevent abuse of that interface.


Another thing we should think about is how to use this interface for the legacy 
"dirtyfb" call. Probably we need to clear the damage property on each 
state-update, or set a flag that "this is a dirtyfb state update". 

IMO we should also have as an end goal of this work to have gnome-shell on drm 
sending damage regions on page-flip, which means either porting gnome-shell to 
atomic or set up a new legacy page-flip-with-atomic ioctl. 
Can't we reuse dirtyfb ioctl for this purpose? It would be called before 
page_flip ioctl?


/Thomas 


On 12/21/2017 12:10 PM, Lukasz Spintzyk wrote: 

Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5 
Signed-off-by: Lukasz Spintzyk mailto:lukasz.spint...@displaylink.com 
--- 
  drivers/gpu/drm/drm_atomic.c  | 10 ++ 
  drivers/gpu/drm/drm_mode_config.c |  6 ++ 
  drivers/gpu/drm/drm_plane.c   |  1 + 
  include/drm/drm_mode_config.h |  5 + 
  include/drm/drm_plane.h   |  3 +++ 
  5 files changed, 25 insertions(+) 

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c 
index b76d49218cf1..cd3b4ed7b04c 100644 
--- a/drivers/gpu/drm/drm_atomic.c 
+++ b/drivers/gpu/drm/drm_atomic.c 
@@ -759,6 +759,14 @@ static 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 == config->dirty_rects_property) { 
+    bool replaced = false; 
+    int ret = drm_atomic_replace_property_blob_from_id(dev, 
+    >dirty_blob, 
+    val, 
+    -1, 
+    ); 
+    return ret; 
  } else if (plane->funcs->atomic_set_property) { 
  return plane->funcs->atomic_set_property(plane, state, 
  property, val); 
@@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane, 
  *val = state->rotation; 
  } else if (property == plane->zpos_property) { 
  *val = state->zpos; 
+    } else if (property == config->dirty_rects_property) { 
+    *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0; 
  } 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_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c 
index bc5c46306b3d..d5f1021c6ece 100644 
--- a/drivers/gpu/drm/drm_mode_config.c 
+++ b/drivers/gpu/drm/drm_mode_config.c 
@@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev) 
  return -ENOMEM; 
  dev->mode_config.prop_crtc_id = 

Re: [PATCH RFC v2 3/7] cgroup: Add interface to allow drivers to lookup process cgroup membership

[Tejun Heo]

Hello,

On Thu, Feb 01, 2018 at 11:53:11AM -0800, Matt Roper wrote:
> +/**
> + * cgroup_for_driver_process - return the cgroup for a process
> + * @pid: process to lookup cgroup for
> + *
> + * Returns the cgroup from the v2 hierarchy that a process belongs to.
> + * This function is intended to be called from drivers and will obtain
> + * the necessary cgroup locks.
> + *
> + * RETURNS:
> + * Process' cgroup in the default (v2) hierarchy
> + */
> +struct cgroup *
> +cgroup_for_driver_process(struct pid *pid)

I think you probably want to use task_dfl_cgroup().  We can add
task_get_dfl_cgroup() in a similar fashion to task_get_css() if
necessary.

Thanks.

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

Re: [PATCH RFC v2 1/7] cgroup: Allow drivers to store data associated with a cgroup

[Tejun Heo]

Hello,

On Thu, Feb 01, 2018 at 11:53:09AM -0800, Matt Roper wrote:
>  * Drivers may be built as modules (and unloaded/reloaded) which is not
>something cgroup controllers support today.

As discussed in the other subthread, this shouldn't be a concern.

>  * Drivers may wish to provide their own interface to allow userspace to
>adjust driver-specific settings (e.g., via a driver ioctl rather than
>via the kernfs filesystem).
>  * A single driver may be managing multiple devices and wish to maintain
>different driver-specific cgroup data for each.

If you look at io and rdma controllers, they already do this.

> Note that technically these interfaces aren't restricted to drivers
> (other non-driver parts of the kernel could make use of them as well).
> I expect drivers to be the primary consumers of this interface and
> couldn't think of a more appropriate generic name (the term "subsystem"
> would probably be more accurate, but that's already used by cgroup
> controllers).

Let's please not do "driver", it's really confusing.  Just coming up
with a made-up word would be fine as long as the connection can be
made and the word is easily identifiable.  e.g. cgroup cdata / pdata for
cgroup custom / priv data.

> +/*
> + * Driver-specific cgroup data.  Drivers should subclass this structure with
> + * their own fields for data that should be stored alongside individual
> + * cgroups.
> + */
> +struct cgroup_driver_data {
> + /* Driver this data structure is associated with */
> + struct cgroup_driver *drv;
> +
> + /* Node in cgroup's data hashtable */
> + struct hlist_node cgroupnode;
> +
> + /* Node in driver's data list; used to cleanup on driver unload */
> + struct list_head drivernode;
> +};
...
> +struct cgroup_driver {
> + /* Functions this driver uses to manage its data */
> + struct cgroup_driver_funcs *funcs;
> +
> + /*
> +  * List of driver-specific data structures that need to be cleaned up
> +  * if driver is unloaded.
> +  */
> + struct list_head datalist;
> +};

It generally looks great but can we do something like the following in
terms of interface?

  struct cgroup_cdata {
  const void *key;
  void (*free)(struct cgroup_cdata *cdata);
  /* whatever other necessary fields */
  char data[];
  };

  int cgroup_cdata_install(struct cgroup *cgrp, struct cgroup_cdata *cdata);
  struct cgroup_cdata *cgroup_cdata_lookup(struct cgroup *cgrp, const void 
*key);
  int cgroup_cdata_free(struct cgroup *cgrp, const void *key);
  /* free is also automatically called when the cgroup is released */

And please use a separate lock or mutex for managing them.

Thanks.

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

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Laurent Pinchart]

Hi Kieran,

On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
> On 29/01/18 10:26, Laurent Pinchart wrote:
> > On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
> >> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
> >> ports. Each map has it own I²C address and acts as a standard slave
> >> device on the I²C bus.
> >> 
> >> Allow a device tree node to override the default addresses so that
> >> address conflicts with other devices on the same bus may be resolved at
> >> the board description level.
> >> 
> >> Signed-off-by: Kieran Bingham 
> >> ---
> >> 
> >>  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
> > 
> > I don't mind personally, but device tree maintainers usually ask for DT
> > bindings changes to be split to a separate patch.
> > 
> >>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
> >>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 ++-
> >>  3 files changed, 37 insertions(+), 13 deletions(-)
> >> 
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >> index 0047b1394c70..f6bb9f6d3f48 100644
> >> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >> 
> >> @@ -70,6 +70,9 @@ Optional properties:
> >>rather than generate its own timings for HDMI output.
> >>  
> >>  - clocks: from common clock binding: reference to the CEC clock.
> >>  - clock-names: from common clock binding: must be "cec".
> >> 
> >> +- reg-names : Names of maps with programmable addresses.
> >> +  It can contain any map needing a non-default address.
> >> +  Possible maps names are : "main", "edid", "cec", "packet"
> > 
> > Is the reg-names property (and the additional maps) mandatory or optional
> > ? If mandatory you should also update the existing DT sources that use
> > those bindings.
> 
> They are currently optional. I do prefer it that way - but perhaps due to an
> issue mentioned below we might need to make this driver mandatory ?
> 
> > If optional you should define which I2C addresses will be used when
> > the maps are not specified (and in that case I think we should go for
> > the addresses listed as default in the datasheet, which correspond to the
> > current driver implementation when the main address is 0x3d/0x7a).
> 
> The current addresses do not correspond to the datasheet, even when the
> implementation main address is set to 0x3d.

Don't they ? The driver currently uses the following (8-bit) I2C addresses:

EDID:   main + 4  = 0x7e (0x3f)
Packet: main - 10 = 0x70 (0x38)
CEC:main - 2  = 0x78 (0x3c)

Those are the default addresses according to section 4.1 of the ADV7511W 
programming guide (rev. B), and they match the ones you set in this patch.

> Thus, in my opinion - they are currently 'wrong' - but perhaps changing them
> is considered breakage too.
> 
> A particular issue will arise here too - as on this device - when the device
> is in low-power mode (after probe, before use) - the maps will respond on
> their *hardware default* addresses (the ones implemented in this patch),
> and thus consume that address on the I2C bus regardless of their settings
> in the driver.

We've discussed this previously and I share you concern. Just to make sure I 
remember correctly, did all the secondary maps reset to their default 
addresses, or just the EDID map ?

> > You should also update the definition of the reg property that currently
> > just states
> > 
> > - reg: I2C slave address
> > 
> > And finally you might want to define the term "map" in this context.
> > Here's a proposal (if we make all maps mandatory).
> > 
> > The ADV7511 internal registers are split into four pages exposed through
> > different I2C addresses, creating four register maps. The I2C addresses of
> > all four maps shall be specified by the reg and reg-names property.
> > 
> > - reg: I2C slave addresses, one per reg-names entry
> > - reg-names: map names, shall be "main", "edid", "cec", "packet"
> > 
> >>  Required nodes:
> >> @@ -88,7 +91,12 @@ Example
> >> 
> >>adv7511w: hdmi@39 {
> >>compatible = "adi,adv7511w";
> >> -  reg = <39>;
> >> +  /*
> >> +   * The EDID page will be accessible on address 0x66 on the i2c
> >> +   * bus. All other maps continue to use their default addresses.
> >> +   */
> >> +  reg = <0x39 0x66>;
> >> +  reg-names = "main", "edid";
> >>interrupt-parent = <>;
> >>interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> >>clocks = <_clock>;

[snip]

> >> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> index efa29db5fc2b..7ec33837752b 100644
> >> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> >> +++ 

Re: [Intel-gfx] [IGT PATCH RFC] tools: Introduce intel_cgroup tool

[Tejun Heo]

Hello,

Forgot to respond to one point.

On Thu, Feb 01, 2018 at 03:14:38PM -0800, Matt Roper wrote:
>  * The drivers that want to make use of this functionality may be built
>as modules rather than compiled directly into the kernel.  This is
>important because the cgroups subsystem removed the ability to have
>cgroup controllers in modules a few years ago.  While it might be
>possible to resurrect module-based cgroup controller support, my
>impression is that the cgroups community would prefer a separate
>non-controller mechanism for doing what we want to do.  E.g., see
>https://www.spinics.net/lists/cgroups/msg18674.html for some brief
>discussion on this topic.

So, this isn't a concern.  If we need to have modular controllers, we
can resurrect module support, hopefully in a simpler way, or could do
something similar to what rdma controller did.  We shouldn't make
userland interface decisions based on this sort of implementation
details.

Thanks.

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

Re: [PATCH] amdgpu/dc: Fix enum mismatch in calls to program_color_matrix()

[Harry Wentland]

On 2018-02-07 04:43 PM, Matthias Kaehlcke wrote:
> The driver passes GRAPHICS_CSC_ADJUST_TYPE_SW of type enum
> graphics_csc_adjust_type to program_color_matrix(), however the function
> expects a parameter of type enum grph_color_adjust_option. Supposedly
> the intention was to pass GRPH_COLOR_MATRIX_SW, which has the same value
> as GRAPHICS_CSC_ADJUST_TYPE_SW, so the mismatch didn't cause any trouble.
> 
> Pass GRPH_COLOR_MATRIX_SW to program_color_matrix() instead of
> GRAPHICS_CSC_ADJUST_TYPE_SW, this also fixes the following warning when
> building the kernel with clang:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.c:1129:24:
>   error: implicit conversion from enumeration type
>   'enum graphics_csc_adjust_type' to different enumeration type
>   'enum grph_color_adjust_option' [-Werror,-Wenum-conversion]
> xfm_dce, tbl_entry, GRAPHICS_CSC_ADJUST_TYPE_SW);
> 
> Signed-off-by: Matthias Kaehlcke 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_transform.c   | 2 +-
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
> index 0f662e6ee9bd..ac28113c4d67 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
> @@ -1126,7 +1126,7 @@ void dce110_opp_set_csc_adjustment(
>   CSC_COLOR_MODE_GRAPHICS_OUTPUT_CSC;
>  
>   program_color_matrix(
> - xfm_dce, tbl_entry, GRAPHICS_CSC_ADJUST_TYPE_SW);
> + xfm_dce, tbl_entry, GRPH_COLOR_MATRIX_SW);
>  
>   /*  We did everything ,now program DxOUTPUT_CSC_CONTROL */
>   configure_graphics_mode(xfm_dce, config, GRAPHICS_CSC_ADJUST_TYPE_SW,
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c
> index feb397b5c1a3..4245e1f818a3 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c
> @@ -727,7 +727,7 @@ void dce110_opp_v_set_csc_adjustment(
>   CSC_COLOR_MODE_GRAPHICS_OUTPUT_CSC;
>  
>   program_color_matrix_v(
> - xfm_dce, tbl_entry, GRAPHICS_CSC_ADJUST_TYPE_SW);
> + xfm_dce, tbl_entry, GRPH_COLOR_MATRIX_SW);
>  
>   /*  We did everything ,now program DxOUTPUT_CSC_CONTROL */
>   configure_graphics_mode_v(xfm_dce, config, GRAPHICS_CSC_ADJUST_TYPE_SW,
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #4 from Dmitry  ---
Created attachment 137223
  --> https://bugs.freedesktop.org/attachment.cgi?id=137223=edit
Xorg log

Attach Xorg log. DC then turned, I'll watch the reaction.

-- 
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] [IGT PATCH RFC] tools: Introduce intel_cgroup tool

[Tejun Heo]

Hello, Matt, Chris.

On Thu, Feb 01, 2018 at 03:14:38PM -0800, Matt Roper wrote:
> > Hmm. Could we not avoid drm_ioctl + well known param names and use a
> > more generic tool to set cgroup attributes? Just feels wrong that a
> > such a generic interface boils down to a driver specific ioctl.

So, everything which shows up in the cgroup hierarchy should satisfy
the following two conditions.

* The control mechanism should adhere to one of the resource
  distribution models defined in Documentation/cgroup-v2.txt.  This is
  to ensure consistency across different resources which in turn
  allows things like delegation.

* This one is a bit vague and I probably should find a better way to
  describe it but each controller should encapsulate a generic core
  resource.  Here, I don't think it makes sense to have intel gfx
  controller when there are a lot of commmonalities in the graphics
  hardware across different vendors.  It should be better abstracted.

It's true that it's difficult to figure out the right generic design
without actually trying, and I think that's why it'd be better to
start scoped in the scope of the specific driver.  The smaller scope
would allow for less strict expectations, more latitude, and easier
experimentations.

> I think the nicest interface for setting cgroup attributes would be to
> find a way to add our own kernfs entries to the cgroup filesystem, the
> same way real cgroup controllers do.  Then we could do something like
> "echo 123 > /cgroup2/apps/highprio/i915.card0.priority" and not need to
> call any ioctl's at all.  Without creating an actual cgroup controller,
> I think this might be challenging, but I'm investigating it on the side
> right now to see if it's a viable option.

So, I strongly believe that it isn't the right approach to add i915
prefixed interface files to cgroup interface.

Thanks.

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

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #3 from Dmitry  ---
Created attachment 137222
  --> https://bugs.freedesktop.org/attachment.cgi?id=137222=edit
dmesg

Attach dmesg

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

[PATCH 2/2] drm/msm/mdp4: Return directly after a failed kzalloc() in mdp4_kms_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 7 Feb 2018 22:34:45 +0100

* Return directly after a call of the function "kzalloc" failed
  at the beginning.

* Delete an initialisation and a check (for the local variable "kms")
  which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 5c5965a9d1f9..4f15cd569ee1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -411,15 +411,13 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
struct platform_device *pdev = to_platform_device(dev->dev);
struct mdp4_platform_config *config = mdp4_get_config(pdev);
struct mdp4_kms *mdp4_kms;
-   struct msm_kms *kms = NULL;
+   struct msm_kms *kms;
struct msm_gem_address_space *aspace;
int irq, ret;
 
mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
-   if (!mdp4_kms) {
-   ret = -ENOMEM;
-   goto fail;
-   }
+   if (!mdp4_kms)
+   return ERR_PTR(-ENOMEM);
 
mdp_kms_init(_kms->base, _funcs);
 
@@ -550,8 +548,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
return kms;
 
 fail:
-   if (kms)
-   mdp4_destroy(kms);
+   mdp4_destroy(kms);
return ERR_PTR(ret);
 }
 
-- 
2.16.1

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

[PATCH 1/2] drm/msm/mdp4: Delete an error message for a failed memory allocation in mdp4_kms_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 7 Feb 2018 22:22:28 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index f7f087419ed8..5c5965a9d1f9 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -417,7 +417,6 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
 
mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
if (!mdp4_kms) {
-   dev_err(dev->dev, "failed to allocate kms\n");
ret = -ENOMEM;
goto fail;
}
-- 
2.16.1

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

[PATCH 0/2] drm/msm/mdp4: Adjustments for mdp4_kms_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 7 Feb 2018 22:38: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
  Return directly after a failed kzalloc()

 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

-- 
2.16.1

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

[PATCH] amdgpu/dc: Fix enum mismatch in calls to program_color_matrix()

[Matthias Kaehlcke]

The driver passes GRAPHICS_CSC_ADJUST_TYPE_SW of type enum
graphics_csc_adjust_type to program_color_matrix(), however the function
expects a parameter of type enum grph_color_adjust_option. Supposedly
the intention was to pass GRPH_COLOR_MATRIX_SW, which has the same value
as GRAPHICS_CSC_ADJUST_TYPE_SW, so the mismatch didn't cause any trouble.

Pass GRPH_COLOR_MATRIX_SW to program_color_matrix() instead of
GRAPHICS_CSC_ADJUST_TYPE_SW, this also fixes the following warning when
building the kernel with clang:

drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_transform.c:1129:24:
  error: implicit conversion from enumeration type
  'enum graphics_csc_adjust_type' to different enumeration type
  'enum grph_color_adjust_option' [-Werror,-Wenum-conversion]
xfm_dce, tbl_entry, GRAPHICS_CSC_ADJUST_TYPE_SW);

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/amd/display/dc/dce/dce_transform.c   | 2 +-
 drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c 
b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
index 0f662e6ee9bd..ac28113c4d67 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c
@@ -1126,7 +1126,7 @@ void dce110_opp_set_csc_adjustment(
CSC_COLOR_MODE_GRAPHICS_OUTPUT_CSC;
 
program_color_matrix(
-   xfm_dce, tbl_entry, GRAPHICS_CSC_ADJUST_TYPE_SW);
+   xfm_dce, tbl_entry, GRPH_COLOR_MATRIX_SW);
 
/*  We did everything ,now program DxOUTPUT_CSC_CONTROL */
configure_graphics_mode(xfm_dce, config, GRAPHICS_CSC_ADJUST_TYPE_SW,
diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c
index feb397b5c1a3..4245e1f818a3 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_opp_csc_v.c
@@ -727,7 +727,7 @@ void dce110_opp_v_set_csc_adjustment(
CSC_COLOR_MODE_GRAPHICS_OUTPUT_CSC;
 
program_color_matrix_v(
-   xfm_dce, tbl_entry, GRAPHICS_CSC_ADJUST_TYPE_SW);
+   xfm_dce, tbl_entry, GRPH_COLOR_MATRIX_SW);
 
/*  We did everything ,now program DxOUTPUT_CSC_CONTROL */
configure_graphics_mode_v(xfm_dce, config, GRAPHICS_CSC_ADJUST_TYPE_SW,
-- 
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: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
> On 05.02.2018 07:08, Rob Herring wrote:
> > On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> >> These bindings allow to describe most known standard USB connectors
> >> and it should be possible to extend it if necessary.
> >> USB connectors, beside USB can be used to route other protocols,
> >> for example UART, Audio, MHL. In such case every device passing data
> >> through the connector should have appropriate graph bindings.
> >>
> >> Signed-off-by: Andrzej Hajda 
> >> ---
> >> v2:
> >> - moved connector type(A,B,C) to compatible string (Rob),
> >> - renamed size property to type (Rob),
> >> - changed type description to be less confusing (Laurent),
> >> - removed vendor specific compatibles (implied by graph port number),
> > How so? More below...
> >
> >> - added requirement of connector being a child of IC (Rob),
> >> - removed max-mode (subtly suggested by Rob, it should be detected anyway
> >>   by USB Controller in runtime, downside is that device is not able to
> >>   report its real capabilities, maybe better would be to make it 
> >> optional(?)),
> >> - assigned port numbers to data buses (Rob).
> >>
> >> Regards
> >> Andrzej
> >>
> >> Signed-off-by: Andrzej Hajda 
> >> ---
> >>  .../bindings/connector/usb-connector.txt   | 48 
> >> ++
> >>  1 file changed, 48 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/connector/usb-connector.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> >> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >> new file mode 100644
> >> index ..02020f5d760a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> >> @@ -0,0 +1,48 @@
> >> +USB Connector
> >> +=
> >> +
> >> +USB connector node represents physical USB connector. It should be
> >> +a child of USB interface controller.
> >> +
> >> +Required properties:
> >> +- compatible: describes type of the connector, must be one of:
> >> +"usb-a-connector", "usb-b-connector", "usb-c-connector",
> > Nit: one per line.
> >
> >> +
> >> +Optional properties:
> >> +- label: symbolic name for the connector
> >> +- type: size of the connector, should be specified in case of USB-A, USB-B
> >> +  non-standard (large) connector sizes: "mini", "micro"
> >> +
> >> +Required nodes:
> >> +- any data bus to the connector should be modeled using the OF graph 
> >> bindings
> >> +  specified in bindings/graph.txt, unless the bus is between parent node 
> >> and
> >> +  the connector. Since single connector can have multpile data buses 
> >> every bus
> >> +  has assigned OF graph port number as follows:
> >> +0: High Speed (HS), present in all connectors,
> >> +1: Super Speed (SS), present in SS capable connectors,
> >> +2: Sideband use (SBU), present in USB-C,
> >> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung 
> >> micro-USB
> > This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
> > That makes me think the Samsung connector should have its own compatible 
> > string.
> 
> Do you mean, sth like:
>     connector {
>             compatible = "samsung,usb-connector-11pin";
>             label = "micro-USB";
>             ports {
>                     #address-cells = <1>;
>                     #size-cells = <0>;
> 
>                     port@3 {
>                             reg = <3>;
>                             musb_con_mhl_in: endpoint {
>                                     remote-endpoint = <_out>;
>                             };
>                     };
>     };

Yes, basically.

> 
> Or should I add "usb-b-connector" extra compatible and "type" property?

type would be micro? I think type and "usb-b-connector" are fine if this 
is a superset like a USB3 SS micro connector.

> I slightly prefer my approach(less different bindings), but I am also OK
> with the above.

How do you know it is a Samsung connector then? Just because you have 
port 3? I think it is better to be explicit.

> 
> >
> > Can we go ahead and define the video modes of Type-C? Normally, if 2 
> > data streams are mutually exclusive, then they are a single port with 2 
> > endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
> > port 3 is always video. We can still know what is mutually exclusive 
> > based on the compatible. 
> 
> I am sorry, I do not understand what you mean. Port 3 is present only in
> 11-pin Samsung micro-USB, USB Type-C has only ports 0, 1, 2.

So video on Type C would be on port 1 (SS), endpoint ? ? That's not 
defined in the binding and I want to define it.

> Here is list of possible ports depending on connector type:
> - USB 2.0: HS
> - 11-pin Samsung micro-USB: HS,MHL
> - USB 3.x type A,B: HS,SS
> - USB-C: HS,SS,SBU
> 
> All ports have separate lines, so they 

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

[Pandiyan, Dhinakaran]

On Wed, 2018-02-07 at 10:41 +0100, Thierry Reding wrote:
> On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote:
> > 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);
> 
> Isn't this the wrong way around? Shouldn't we instead make the
> ->get_vblank_counter() callback return u64 like drm_crtc_vblank_count()?

Here's how I understand this - 

To use the software emulated vblank counter, the driver should set
max_vblank_count = 0 and the core takes care of calculating elapsed
vblanks.

->get_vblank_counter() is meant to return the hardware counter if
available, which would be a 32-bit value. Hence the explicit typecast to
32-bit for the fallback case too.

Having said that, I believe drm_crtc_accurate_vblank_count() is the
appropriate function for fallback.

-DK



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

[PATCH] drm/msm/mdp5: Delete an error message for a failed memory allocation in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 7 Feb 2018 21:50:07 +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/msm/mdp/mdp5/mdp5_ctl.c | 1 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 4 +---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index 439e0a300e25..daa224df4457 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -717,7 +717,6 @@ struct mdp5_ctl_manager *mdp5_ctlm_init(struct drm_device 
*dev,
 
ctl_mgr = kzalloc(sizeof(*ctl_mgr), GFP_KERNEL);
if (!ctl_mgr) {
-   dev_err(dev->dev, "failed to allocate CTL manager\n");
ret = -ENOMEM;
goto fail;
}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 3e9bba4d6624..5bf54ca7ab0a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -844,10 +844,8 @@ static int interface_init(struct mdp5_kms *mdp5_kms)
continue;
 
intf = kzalloc(sizeof(*intf), GFP_KERNEL);
-   if (!intf) {
-   dev_err(dev->dev, "failed to construct INTF%d\n", i);
+   if (!intf)
return -ENOMEM;
-   }
 
intf->num = i;
intf->type = intf_types[i];
-- 
2.16.1

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

Re: [PATCH] drm/amd/display: Remove extra pairs of parentheses in dce_calcs.c

[Harry Wentland]

On 2018-02-07 02:49 PM, Matthias Kaehlcke wrote:
> The double parentheses are not needed. Removing them fixes multiple
> warnings like this when building with clang:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:617:42:
>   error: equality comparison with extraneous parentheses
> [-Werror,-Wparentheses-equality]
>   if ((data->graphics_micro_tile_mode == bw_def_rotated_micro_tiling)) {
> 
> Signed-off-by: Matthias Kaehlcke 

Thanks.
Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index 2e11fac2a63d..bb03a9c64d5a 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -623,7 +623,7 @@ static void calculate_bandwidth(
>   }
>   else {
>   /*graphics portrait tiling mode*/
> - if ((data->graphics_micro_tile_mode == 
> bw_def_rotated_micro_tiling)) {
> + if (data->graphics_micro_tile_mode == 
> bw_def_rotated_micro_tiling) {
>   data->orthogonal_rotation[i] = 
> 0;
>   }
>   else {
> @@ -634,7 +634,7 @@ static void calculate_bandwidth(
>   else {
>   if ((i < 4)) {
>   /*underlay landscape tiling mode is 
> only supported*/
> - if ((data->underlay_micro_tile_mode == 
> bw_def_display_micro_tiling)) {
> + if (data->underlay_micro_tile_mode == 
> bw_def_display_micro_tiling) {
>   data->orthogonal_rotation[i] = 
> 0;
>   }
>   else {
> @@ -643,7 +643,7 @@ static void calculate_bandwidth(
>   }
>   else {
>   /*graphics landscape tiling mode*/
> - if ((data->graphics_micro_tile_mode == 
> bw_def_display_micro_tiling)) {
> + if (data->graphics_micro_tile_mode == 
> bw_def_display_micro_tiling) {
>   data->orthogonal_rotation[i] = 
> 0;
>   }
>   else {
> @@ -947,14 +947,14 @@ static void calculate_bandwidth(
>   }
>   for (i = 0; i <= maximum_number_of_surfaces - 1; i++) {
>   if (data->enable[i]) {
> - if ((data->number_of_displays == 1 && 
> data->number_of_underlay_surfaces == 0)) {
> + if (data->number_of_displays == 1 && 
> data->number_of_underlay_surfaces == 0) {
>   /*set maximum chunk limit if only one graphic 
> pipe is enabled*/
>   data->outstanding_chunk_request_limit[i] = 
> bw_int_to_fixed(127);
>   }
>   else {
>   data->outstanding_chunk_request_limit[i] = 
> bw_ceil2(bw_div(data->adjusted_data_buffer_size[i], 
> data->pipe_chunk_size_in_bytes[i]), bw_int_to_fixed(1));
>   /*clamp maximum chunk limit in the graphic 
> display pipe*/
> - if ((i >= 4)) {
> + if (i >= 4) {
>   
> data->outstanding_chunk_request_limit[i] = bw_max2(bw_int_to_fixed(127), 
> data->outstanding_chunk_request_limit[i]);
>   }
>   }
> @@ -1337,7 +1337,7 @@ static void calculate_bandwidth(
>   /*if stutter and dram clock state change are gated before cursor then 
> the cursor latency hiding does not limit stutter or dram clock state change*/
>   for (i = 0; i <= maximum_number_of_surfaces - 1; i++) {
>   if (data->enable[i]) {
> - if 
> ((dceip->graphics_lb_nodownscaling_multi_line_prefetching == 1)) {
> + if 
> (dceip->graphics_lb_nodownscaling_multi_line_prefetching == 1) {
>   data->maximum_latency_hiding[i] = 
> bw_add(data->minimum_latency_hiding[i], bw_mul(bw_frc_to_fixed(8, 10), 
> data->total_dmifmc_urgent_latency));
>   }
>   else {
> @@ -1396,7 +1396,7 @@ static void calculate_bandwidth(
>   }
>   /*determine the number of displays with margin to switch in the 
> v_active region*/
>   for (k = 0; k <= maximum_number_of_surfaces - 1; k++) 

Re: [PATCH] drm/amd/powerplay: Remove extra pair of parentheses

[Alex Deucher]

On Wed, Feb 7, 2018 at 2:19 PM, Guenter Roeck  wrote:
> On Wed, Feb 7, 2018 at 11:10 AM, Matthias Kaehlcke  wrote:
>> The double parentheses are not needed. Removing them fixes the following
>> warning when building with clang:
>>
>> drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29:
>>   error: equality comparison with extraneous parentheses
>> [-Werror,-Wparentheses-equality]
>>   if ((data->vdd_gfx_control == SMU7_VOLTAGE_CONTROL_BY_SVID2)) {
>>
>> Signed-off-by: Matthias Kaehlcke 
>
> Reviewed-by: Guenter Roeck 

Applied.  Thanks!

Alex

>
>> ---
>>  drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c 
>> b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
>> index 79e5c05571bc..f5b3de29b632 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
>> @@ -416,7 +416,7 @@ static int tonga_populate_cac_tables(struct pp_hwmgr 
>> *hwmgr,
>> 
>> convert_to_vid(vddc_lookup_table->entries[index].us_cac_high);
>> }
>>
>> -   if ((data->vdd_gfx_control == SMU7_VOLTAGE_CONTROL_BY_SVID2)) {
>> +   if (data->vdd_gfx_control == SMU7_VOLTAGE_CONTROL_BY_SVID2) {
>> /* We are populating vddgfx CAC data to BapmVddgfx table in 
>> split mode */
>> for (count = 0; count < vddgfx_level_count; count++) {
>> index = phm_get_voltage_index(vddgfx_lookup_table,
>> --
>> 2.16.0.rc1.238.g530d649a79-goog
>>
> ___
> 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

[PULL] drm-intel-next-fixes

[Rodrigo Vivi]

Hi Dave,

Here goes drm-intel-next-fixes-2018-02-07:

Fix for pcode timeouts on BXT and GLK, cmdparser fixes and fixes
for new vbt version on CFL and CNL.

GVT contains vGPU reset enhancement, which refines vGPU reset flow
and the support of virtual aperture read/write when x-no-mmap=on
is set in KVM, which is required by a test case from Redhat and
also another fix for virtual OpRegion.

Thanks,
Rodrigo.

The following changes since commit b8a89f530f5692c70778c965f0bc8f5a61fbe703:

  Merge branch 'linux-4.16' of git://github.com/skeggsb/linux into drm-next 
(2018-02-06 06:33:04 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2018-02-07

for you to fetch changes up to 6dd3104e78943685d5183efe883d83a5f2361bf1:

  drm/i915/bios: add DP max link rate to VBT child device struct (2018-02-07 
12:32:14 -0800)


Fix for pcode timeouts on BXT and GLK, cmdparser fixes and fixes
for new vbt version on CFL and CNL.

GVT contains vGPU reset enhancement, which refines vGPU reset flow
and the support of virtual aperture read/write when x-no-mmap=on
is set in KVM, which is required by a test case from Redhat and
also another fix for virtual OpRegion.


Changbin Du (1):
  drm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=on

Imre Deak (1):
  drm/i915/bxt, glk: Increase PCODE timeouts during CDCLK freq changing

Jani Nikula (1):
  drm/i915/bios: add DP max link rate to VBT child device struct

Michal Srb (2):
  drm/i915/cmdparser: Check reg_table_count before derefencing.
  drm/i915/cmdparser: Do not check past the cmd length.

Rodrigo Vivi (2):
  drm/i915/cnp: Ignore VBT request for know invalid DDC pin.
  drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

Tina Zhang (1):
  drm/i915/gvt: Use KVM r/w to access guest opregion

Weinan Li (2):
  drm/i915/gvt: refine intel_vgpu_submission_ops as per engine ops
  drm/i915/gvt: only reset execlist state of one engine during VM engine 
reset

 drivers/gpu/drm/i915/gvt/cfg_space.c| 15 +
 drivers/gpu/drm/i915/gvt/execlist.c | 22 
 drivers/gpu/drm/i915/gvt/gvt.h  |  6 +-
 drivers/gpu/drm/i915/gvt/handlers.c |  7 +--
 drivers/gpu/drm/i915/gvt/kvmgt.c| 36 +++-
 drivers/gpu/drm/i915/gvt/mmio.c | 42 --
 drivers/gpu/drm/i915/gvt/opregion.c | 98 +++--
 drivers/gpu/drm/i915/gvt/sched_policy.c | 14 -
 drivers/gpu/drm/i915/gvt/scheduler.c| 19 ---
 drivers/gpu/drm/i915/gvt/scheduler.h|  1 +
 drivers/gpu/drm/i915/gvt/vgpu.c |  3 +-
 drivers/gpu/drm/i915/i915_cmd_parser.c  | 10 +++-
 drivers/gpu/drm/i915/i915_drv.h |  6 +-
 drivers/gpu/drm/i915/intel_bios.c   | 20 +--
 drivers/gpu/drm/i915/intel_cdclk.c  | 22 ++--
 drivers/gpu/drm/i915/intel_pm.c |  6 +-
 drivers/gpu/drm/i915/intel_vbt_defs.h   |  2 +
 17 files changed, 193 insertions(+), 136 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
Does it work with DC enabled?

-- 
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 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  ---
Please include your dmesg output and Xorg log if using X.

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

[PATCH] drm/tegra/fb: Delete an error message for a failed memory allocation in tegra_fbdev_create()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 7 Feb 2018 21:17:17 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tegra/fb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 001cb77e2f59..e63a0b228751 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -325,10 +325,8 @@ static struct tegra_fbdev *tegra_fbdev_create(struct 
drm_device *drm)
struct tegra_fbdev *fbdev;
 
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
-   if (!fbdev) {
-   dev_err(drm->dev, "failed to allocate DRM fbdev\n");
+   if (!fbdev)
return ERR_PTR(-ENOMEM);
-   }
 
drm_fb_helper_prepare(drm, >base, _fb_helper_funcs);
 
-- 
2.16.1

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

[Bug 197925] [amdgpu_dc][carrizo] multiple monitor handling errors

[bugzilla-daemon]

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

--- Comment #12 from kwka...@gmx.com ---
Still not fixed v4.15-11781-g413879a10b0b

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

[PATCH] drm/amd/display: Remove extra pairs of parentheses in dce_calcs.c

[Matthias Kaehlcke]

The double parentheses are not needed. Removing them fixes multiple
warnings like this when building with clang:

drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:617:42:
  error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
  if ((data->graphics_micro_tile_mode == bw_def_rotated_micro_tiling)) {

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
index 2e11fac2a63d..bb03a9c64d5a 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
+++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
@@ -623,7 +623,7 @@ static void calculate_bandwidth(
}
else {
/*graphics portrait tiling mode*/
-   if ((data->graphics_micro_tile_mode == 
bw_def_rotated_micro_tiling)) {
+   if (data->graphics_micro_tile_mode == 
bw_def_rotated_micro_tiling) {
data->orthogonal_rotation[i] = 
0;
}
else {
@@ -634,7 +634,7 @@ static void calculate_bandwidth(
else {
if ((i < 4)) {
/*underlay landscape tiling mode is 
only supported*/
-   if ((data->underlay_micro_tile_mode == 
bw_def_display_micro_tiling)) {
+   if (data->underlay_micro_tile_mode == 
bw_def_display_micro_tiling) {
data->orthogonal_rotation[i] = 
0;
}
else {
@@ -643,7 +643,7 @@ static void calculate_bandwidth(
}
else {
/*graphics landscape tiling mode*/
-   if ((data->graphics_micro_tile_mode == 
bw_def_display_micro_tiling)) {
+   if (data->graphics_micro_tile_mode == 
bw_def_display_micro_tiling) {
data->orthogonal_rotation[i] = 
0;
}
else {
@@ -947,14 +947,14 @@ static void calculate_bandwidth(
}
for (i = 0; i <= maximum_number_of_surfaces - 1; i++) {
if (data->enable[i]) {
-   if ((data->number_of_displays == 1 && 
data->number_of_underlay_surfaces == 0)) {
+   if (data->number_of_displays == 1 && 
data->number_of_underlay_surfaces == 0) {
/*set maximum chunk limit if only one graphic 
pipe is enabled*/
data->outstanding_chunk_request_limit[i] = 
bw_int_to_fixed(127);
}
else {
data->outstanding_chunk_request_limit[i] = 
bw_ceil2(bw_div(data->adjusted_data_buffer_size[i], 
data->pipe_chunk_size_in_bytes[i]), bw_int_to_fixed(1));
/*clamp maximum chunk limit in the graphic 
display pipe*/
-   if ((i >= 4)) {
+   if (i >= 4) {

data->outstanding_chunk_request_limit[i] = bw_max2(bw_int_to_fixed(127), 
data->outstanding_chunk_request_limit[i]);
}
}
@@ -1337,7 +1337,7 @@ static void calculate_bandwidth(
/*if stutter and dram clock state change are gated before cursor then 
the cursor latency hiding does not limit stutter or dram clock state change*/
for (i = 0; i <= maximum_number_of_surfaces - 1; i++) {
if (data->enable[i]) {
-   if 
((dceip->graphics_lb_nodownscaling_multi_line_prefetching == 1)) {
+   if 
(dceip->graphics_lb_nodownscaling_multi_line_prefetching == 1) {
data->maximum_latency_hiding[i] = 
bw_add(data->minimum_latency_hiding[i], bw_mul(bw_frc_to_fixed(8, 10), 
data->total_dmifmc_urgent_latency));
}
else {
@@ -1396,7 +1396,7 @@ static void calculate_bandwidth(
}
/*determine the number of displays with margin to switch in the 
v_active region*/
for (k = 0; k <= maximum_number_of_surfaces - 1; k++) {
-   if ((data->enable[k] == 1 && 
data->display_pstate_change_enable[k] == 1)) {
+   if (data->enable[k] == 1 && 
data->display_pstate_change_enable[k] == 1) {

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

Bug ID: 105005
   Summary: No image after downtime (RX460)
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: terapy-sess...@bk.ru

Created attachment 137221
  --> https://bugs.freedesktop.org/attachment.cgi?id=137221=edit
photo

No display after idle for RX460 after upgrading to linux 4.15.1 distribution
Arch. DC is not included, the problem on DP and HDMI. Also this problem even
earlier, long ago, appeared on AMD Kaveri a10 7850k.

P.S. monitor AOC G2260VWQ6

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

[Sean Paul]

On Wed, Feb 07, 2018 at 11:41:49AM -0600, Rob Herring wrote:
> On Tue, Feb 6, 2018 at 3:48 PM, Sean Paul  wrote:
> > 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.
> 
> TBC, I'm fine if you use panel-timing as that's already established
> for cases were only 1 mode exists.

Ah! So the dt change you were asking for was just s/override-mode/panel-timing/.
I'll respin a v3 with the improved documentation and reinstate the 
"panel-timing"
subnode.

Sean

> 
> Rob

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

Re: [PATCH 3/3] drm/tegra: fb: Implement ->fb_mmap() callback

[stefan]

On 07.02.2018 18:45, Thierry Reding wrote:
> From: Thierry Reding 
> 
> This fixes hangs with legacy applications that use the mmap() syscall on
> the fbdev device to map framebuffer memory. The fbdev implementation for
> mmap() creates a mapping that conflicts with DRM usage and causes a hang
> when the memory is accessed through the mapping.

That helps using applications making use of mmap & fbdev on an Apalis
TK1!

Tested-by: Stefan Agner 

--
Stefan

> 
> Reported-by: Marcel Ziswiler 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/tegra/fb.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
> index 001cb77e2f59..0786159edef3 100644
> --- a/drivers/gpu/drm/tegra/fb.c
> +++ b/drivers/gpu/drm/tegra/fb.c
> @@ -224,12 +224,28 @@ struct drm_framebuffer *tegra_fb_create(struct
> drm_device *drm,
>  }
>  
>  #ifdef CONFIG_DRM_FBDEV_EMULATION
> +static int tegra_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> + struct drm_fb_helper *helper = info->par;
> + struct tegra_bo *bo;
> + int err;
> +
> + bo = tegra_fb_get_plane(helper->fb, 0);
> +
> + err = drm_gem_mmap_obj(>gem, bo->gem.size, vma);
> + if (err < 0)
> + return err;
> +
> + return __tegra_gem_mmap(>gem, vma);
> +}
> +
>  static struct fb_ops tegra_fb_ops = {
>   .owner = THIS_MODULE,
>   DRM_FB_HELPER_DEFAULT_OPS,
>   .fb_fillrect = drm_fb_helper_sys_fillrect,
>   .fb_copyarea = drm_fb_helper_sys_copyarea,
>   .fb_imageblit = drm_fb_helper_sys_imageblit,
> + .fb_mmap = tegra_fb_mmap,
>  };
>  
>  static int tegra_fbdev_probe(struct drm_fb_helper *helper,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-next-4.16

[Alex Deucher]

Hi Dave,

Just one fix this week for 4.16.  This is on top of the pull request I
sent last week.  One of the fixes from last week got applied to the wrong
asic by accident.  The patch this week fixes that.

The following changes since commit 7e24a3ea825e546487c3fc47f8cbf6512f6c9e8c:

  drm/amdgpu: disable coarse grain clockgating for ST (2018-01-29 23:30:44 
-0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.16

for you to fetch changes up to fb4bbba2775399149ca902f31eb5c46cc7a8d8b8:

  drm/amdgpu: re-enable CGCG on CZ and disable on ST (2018-02-06 00:05:22 -0500)


Shirish S (1):
  drm/amdgpu: re-enable CGCG on CZ and disable on ST

 drivers/gpu/drm/amd/amdgpu/vi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/powerplay: Remove extra pair of parentheses

[Matthias Kaehlcke]

The double parentheses are not needed. Removing them fixes the following
warning when building with clang:

drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29:
  error: equality comparison with extraneous parentheses
[-Werror,-Wparentheses-equality]
  if ((data->vdd_gfx_control == SMU7_VOLTAGE_CONTROL_BY_SVID2)) {

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
index 79e5c05571bc..f5b3de29b632 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c
@@ -416,7 +416,7 @@ static int tonga_populate_cac_tables(struct pp_hwmgr *hwmgr,

convert_to_vid(vddc_lookup_table->entries[index].us_cac_high);
}
 
-   if ((data->vdd_gfx_control == SMU7_VOLTAGE_CONTROL_BY_SVID2)) {
+   if (data->vdd_gfx_control == SMU7_VOLTAGE_CONTROL_BY_SVID2) {
/* We are populating vddgfx CAC data to BapmVddgfx table in 
split mode */
for (count = 0; count < vddgfx_level_count; count++) {
index = phm_get_voltage_index(vddgfx_lookup_table,
-- 
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/amd/powerplay: Fix enum mismatch

[Alex Deucher]

On Wed, Feb 7, 2018 at 2:01 PM, Guenter Roeck  wrote:
> On Wed, Feb 7, 2018 at 10:58 AM, Matthias Kaehlcke  wrote:
>> In several locations the driver uses AMD_CG_STATE_UNGATE (type enum
>> amd_clockgating_state) instead of AMD_PG_STATE_UNGATE (type enum
>> amd_powergating_stat) and vice versa. Both constants have the same
>> value, so this doesn't cause any problems, but we still want to pass
>> the correct type.
>>
>> Fixing the mismatch resolves multiple warnings like this when building
>> with clang:
>>
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_clockpowergating.c:169:7:
>>   error: implicit conversion from enumeration type 'enum
>>   amd_powergating_state' to different enumeration type 'enum
>>   amd_clockgating_state' [-Werror,-Wenum-conversion]
>> AMD_PG_STATE_UNGATE);
>>
>> Signed-off-by: Matthias Kaehlcke 
>
> Reviewed-by: Guenter Roeck 

Applied.  thanks!

Alex

>
>> ---
>>  drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c   | 8 
>>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c | 2 +-
>>  2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c 
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
>> index 44de0874629f..416abebb8b86 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
>> @@ -166,10 +166,10 @@ void cz_dpm_powergate_uvd(struct pp_hwmgr *hwmgr, bool 
>> bgate)
>> cz_dpm_powerup_uvd(hwmgr);
>> cgs_set_clockgating_state(hwmgr->device,
>> AMD_IP_BLOCK_TYPE_UVD,
>> -   AMD_PG_STATE_UNGATE);
>> +   AMD_CG_STATE_UNGATE);
>> cgs_set_powergating_state(hwmgr->device,
>> AMD_IP_BLOCK_TYPE_UVD,
>> -   AMD_CG_STATE_UNGATE);
>> +   AMD_PG_STATE_UNGATE);
>> cz_dpm_update_uvd_dpm(hwmgr, false);
>> }
>>
>> @@ -197,11 +197,11 @@ void cz_dpm_powergate_vce(struct pp_hwmgr *hwmgr, bool 
>> bgate)
>> cgs_set_clockgating_state(
>> hwmgr->device,
>> AMD_IP_BLOCK_TYPE_VCE,
>> -   AMD_PG_STATE_UNGATE);
>> +   AMD_CG_STATE_UNGATE);
>> cgs_set_powergating_state(
>> hwmgr->device,
>> AMD_IP_BLOCK_TYPE_VCE,
>> -   AMD_CG_STATE_UNGATE);
>> +   AMD_PG_STATE_UNGATE);
>> cz_dpm_update_vce_dpm(hwmgr);
>> cz_enable_disable_vce_dpm(hwmgr, true);
>> }
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c 
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c
>> index 69a0678ace98..402aa9cb1f78 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c
>> @@ -162,7 +162,7 @@ void smu7_powergate_uvd(struct pp_hwmgr *hwmgr, bool 
>> bgate)
>> AMD_CG_STATE_UNGATE);
>> cgs_set_powergating_state(hwmgr->device,
>> AMD_IP_BLOCK_TYPE_UVD,
>> -   AMD_CG_STATE_UNGATE);
>> +   AMD_PG_STATE_UNGATE);
>> smu7_update_uvd_dpm(hwmgr, false);
>> }
>>
>> --
>> 2.16.0.rc1.238.g530d649a79-goog
>>
> ___
> 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

[PATCH] drm/amd/powerplay: Fix enum mismatch

[Matthias Kaehlcke]

In several locations the driver uses AMD_CG_STATE_UNGATE (type enum
amd_clockgating_state) instead of AMD_PG_STATE_UNGATE (type enum
amd_powergating_stat) and vice versa. Both constants have the same
value, so this doesn't cause any problems, but we still want to pass
the correct type.

Fixing the mismatch resolves multiple warnings like this when building
with clang:

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_clockpowergating.c:169:7:
  error: implicit conversion from enumeration type 'enum
  amd_powergating_state' to different enumeration type 'enum
  amd_clockgating_state' [-Werror,-Wenum-conversion]
AMD_PG_STATE_UNGATE);

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c   | 8 
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
index 44de0874629f..416abebb8b86 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
@@ -166,10 +166,10 @@ void cz_dpm_powergate_uvd(struct pp_hwmgr *hwmgr, bool 
bgate)
cz_dpm_powerup_uvd(hwmgr);
cgs_set_clockgating_state(hwmgr->device,
AMD_IP_BLOCK_TYPE_UVD,
-   AMD_PG_STATE_UNGATE);
+   AMD_CG_STATE_UNGATE);
cgs_set_powergating_state(hwmgr->device,
AMD_IP_BLOCK_TYPE_UVD,
-   AMD_CG_STATE_UNGATE);
+   AMD_PG_STATE_UNGATE);
cz_dpm_update_uvd_dpm(hwmgr, false);
}
 
@@ -197,11 +197,11 @@ void cz_dpm_powergate_vce(struct pp_hwmgr *hwmgr, bool 
bgate)
cgs_set_clockgating_state(
hwmgr->device,
AMD_IP_BLOCK_TYPE_VCE,
-   AMD_PG_STATE_UNGATE);
+   AMD_CG_STATE_UNGATE);
cgs_set_powergating_state(
hwmgr->device,
AMD_IP_BLOCK_TYPE_VCE,
-   AMD_CG_STATE_UNGATE);
+   AMD_PG_STATE_UNGATE);
cz_dpm_update_vce_dpm(hwmgr);
cz_enable_disable_vce_dpm(hwmgr, true);
}
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c
index 69a0678ace98..402aa9cb1f78 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c
@@ -162,7 +162,7 @@ void smu7_powergate_uvd(struct pp_hwmgr *hwmgr, bool bgate)
AMD_CG_STATE_UNGATE);
cgs_set_powergating_state(hwmgr->device,
AMD_IP_BLOCK_TYPE_UVD,
-   AMD_CG_STATE_UNGATE);
+   AMD_PG_STATE_UNGATE);
smu7_update_uvd_dpm(hwmgr, false);
}
 
-- 
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: Enabling i915 Panel Self Refresh by default on some devices ?

[Rodrigo Vivi]

Hans de Goede  writes:

> Hi,
>
> On 06-02-18 00:14, Rodrigo Vivi wrote:
>>
>> Hi Hans,
>>
>> On Fri, Feb 02, 2018 at 09:55:32AM +, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 01-02-18 13:31, Hans de Goede wrote:
 Hi All,

 As you may have heard I've recently been working on improving
 Linux laptop battery life, specifically the OOTB experience
 without tweaking any options such as e.g. powertop --auto-tune
 would do, see:

 https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
>>
>> First of all thank you very much for triggering that. It's been
>> so helpful.
>>
>> Also sorry for not having replied sooner here.
>>

 So far this is going quite nicely, it looks like Fedora 28
 will have SATA ALPM (big win), autosuspend of USB Bluetooth HCIs
 and snd_intel_hda powersaving all enabled OOTB.

 Looking for more savings I've run some quick tests with
 i915.enable_psr=1, this seems to be another nice win (for an idle
 system) of aprox. 0.5W.

 So as with the other 3 items I just mentioned I'm now looking into
 somehow enabling this be default, at least one some models.

 Currently I'm thinking doing a whitelist or blacklist (*) for this,
 but first I think we need some more data about on how much models
 this just works and where it is causing issues, as such I've done
 a blog post to gather this data:

 https://hansdegoede.livejournal.com/18653.html

 So I will revisit this eventually, once people have had some time
 to respond to this blog-post.

 In the mean time I wonder if anyone can explain why this options
 is currently disabled by default. E.g. are there any known specific
 models laptops / panels which are causing issues, are the bugzillas
 for this? Etc. ?

 Also does anyone know if any problems are mainly panel or laptop
 model specific ? I would expect this to mostly be panel specific
 and not depend on the model laptop (given then certain models
 ship with different panels over their production lifetime).

 Regards,

 Hans

 p.s.

 If anyone on this list can make 10 minutes to run the tests
 described in my blogpost and gather the data mentioned there, then
 that would be great.


 *) I know that maintaining such a white/blacklist in the kernel
 is going to be a pain, so my current thinking on this is to make
 this runtime configurable through a sysfs attribute and then
 use a udev rule + udev hwdb entries for this.
>>>
>>> So a quick update on this. The response has been quite overwhelming,
>>> with well over 50 test-reports received sofar. The results are all
>>> over the place, some people see no changes, some people report the
>>> aprox. 0.5W saving my own test show and many people also report
>>> display problems, sometimes combined with a significant increase in
>>> power-consumption.
>>
>> Do you have that public somewhere? I couldn't see the comments on your blog
>> or on wiki.
>
> Not yet, I asked people to email me their results and the response has
> been quite overwhelming and I've been busy with other stuff, I do plan
> to eventually build a table with all the info like the SATA one here:
>
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife#How_To_Test

That would be perfect. Specially with VBT info.

>
> Is there anything specific you would like to see in there?

This is the info available for psr on my decoded vbt:

BDB block 9 - PSR block:
Panel 2 *
Full link: no
Require AUX to wakeup: no
Lines to wait before link standby: 0
Idle frames to for PSR enable: 0
TP1 wakeup time: 5000 usec (0x32)
TP2/TP3 wakeup time: 5000 usec (0x32)


But now I realized that this bit that I'm talking about is actually on
Block 2 and it is not currently being decoded:

 u16 psr_enabled:1;

We need some work on igt tool apparently to decode this bit. So better
to request users the undecoded version.

>
>>> I need to take a closer look at all the results, but right now I
>>> believe that the best way forward with this is (unfortunately) a
>>> whitelist matching on a combination of panel-id (from edid) and
>>> dmi data, so that we can at least enable this on popular models
>>> (any model with atleast one user willing to contribute).
>>
>> First I'd like to check what platform people used on the test.
>
> Right, this is why I asked for "cat /proc/cpuinfo | grep "model name""
> output so that we will know which iGPU generation people are
> using. I've also asked for vendor + model name of the laptop.
>
>> Also on SKL+ platforms I expect bad issues since 
>> https://patchwork.freedesktop.org/series/37598/
>> is not merged yet. Anyone using DC state plus this will probably
>> have a bad experience.
>
> Ah, that may explain quite a few of the 

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

[Thomas Hellstrom]

Hi,

On 02/07/2018 02:22 PM, Christian König wrote:

Understood, but why is that?

Well because customers requested it :)

What we try to do here is having a parameter which says when less than 
x megabytes of memory are left then fail the allocation.


This is basically to prevent buggy applications which try to allocate 
as much memory as possible until they receive an -ENOMEM from running 
into the OOM killer.


OK. Understood.



That's true, but with VRAM, TTM overcommits swap space which may lead 
to ugly memory allocation failures at hibernate time.
Yeah, that is exactly the reason why I said that Roger should disable 
the limit during suspend swap out :)


Well that was really in the context of the swapping implementation 
rather in the context of this change so it was a little off-topic. Even 
if disabling this limit, TTM can overcommit. But looking at the swapping 
implementation is a different issue.


/Thomas







Regards,
Christian.

Am 07.02.2018 um 14:17 schrieb Thomas Hellstrom:

Hi, Roger.

On 02/07/2018 09:25 AM, He, Roger wrote:
Why should TTM be different in that aspect? It would be good to 
know your reasoning WRT this?


Now, in TTM struct ttm_bo_device it already has member no_retry to 
indicate your option.
If you prefer no OOM triggered by TTM, set it as true. The default 
is false to keep original behavior.

AMD prefers return value of no memory rather than OOM for now.


Understood, but why is that? I mean just because TTM doesn't invoke 
the OOM killer, that doesn't mean that the process will, the next 
millisecond, page in a number of pages and invoke it? So this 
mechanism would be pretty susceptible to races?
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,


I prefer current mechanism of swap out. At the beginning the swapped 
pages stay in system memory by shmem until OS move to status with 
high memory pressure, that has an obvious advantage. For example, if 
the BO is swapped out into shmem, but not really be flushed into 
swap disk. When validate it and swap in it at this moment, the 
overhead is small compared to swap in from disk.


But that is true for a page handed off to the swap-cache as well. It 
won't be immediately flushed to disc, only when the swap cache is 
shrunk.


In addition, No need swap space reservation for TTM pages when 
allocation since swap disk is shared not only for TTM exclusive.


That's true, but with VRAM, TTM overcommits swap space which may lead 
to ugly memory allocation failures at hibernate time.


So again we provide a flag no_retry in struct ttm_bo_device to let 
driver set according to its request.


Thanks,
Thomas





Thanks
Roger(Hongbo.He)

-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Wednesday, February 07, 2018 2:43 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org

Cc: Koenig, Christian 
Subject: Re: [PATCH 0/5] prevent OOM triggered by TTM

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

Re: [PATCH] drm/nouveau: Make clock gate support conditional

[Lyude Paul]

Reviewed-by: Lyude Paul 

On Wed, 2018-02-07 at 18:40 +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The recently introduced clock gate support breaks on Tegra chips because
> no thermal support is enabled for those devices. Conditionalize the code
> on the existence of thermal support to fix this.
> 
> Fixes: b138eca661cc ("drm/nouveau: Add support for basic clockgating on
> Kepler1")
> Cc: Martin Peres 
> Cc: Lyude Paul 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> index bf62303571b3..3695cde669f8 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
> @@ -301,7 +301,7 @@ nvkm_therm_attr_set(struct nvkm_therm *therm,
>  void
>  nvkm_therm_clkgate_enable(struct nvkm_therm *therm)
>  {
> - if (!therm->func->clkgate_enable || !therm->clkgating_enabled)
> + if (!therm || !therm->func->clkgate_enable || !therm-
> >clkgating_enabled)
>   return;
>  
>   nvkm_debug(>subdev,
> @@ -312,7 +312,7 @@ nvkm_therm_clkgate_enable(struct nvkm_therm *therm)
>  void
>  nvkm_therm_clkgate_fini(struct nvkm_therm *therm, bool suspend)
>  {
> - if (!therm->func->clkgate_fini || !therm->clkgating_enabled)
> + if (!therm || !therm->func->clkgate_fini || !therm-
> >clkgating_enabled)
>   return;
>  
>   nvkm_debug(>subdev,
> @@ -395,7 +395,7 @@ void
>  nvkm_therm_clkgate_init(struct nvkm_therm *therm,
>   const struct nvkm_therm_clkgate_pack *p)
>  {
> - if (!therm->func->clkgate_init || !therm->clkgating_enabled)
> + if (!therm || !therm->func->clkgate_init || !therm-
> >clkgating_enabled)
>   return;
>  
>   therm->func->clkgate_init(therm, p);
-- 
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)

[bugzilla-daemon]

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

--- Comment #5 from Robin Kauffman  ---
(In reply to Michel Dänzer from comment #4)
> Which versions of Mesa & LLVM are you using?

LLVM & Clang 7.0 Git, LLVM commit e0c16f05e9fbc1dcd291814ceab9dbc5, Clang
commit e0c16f05e9fbc1dcd291814ceab9dbc5.  Both were merged 2018/01/31.  Let me
know if you need more detail.

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

[PATCH 2/3] drm/tegra: gem: Make __tegra_gem_mmap() available more widely

[Thierry Reding]

From: Thierry Reding 

This function allows mapping a GEM object into a virtual memory address
space, which makes it useful outside of the GEM code.

While at it, rename the function so it doesn't clash with the function
that implements the DRM_TEGRA_GEM_MMAP IOCTL.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/gem.c | 7 +++
 drivers/gpu/drm/tegra/gem.h | 1 +
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 0e390ae73559..4b80fe58d4f7 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -464,8 +464,7 @@ const struct vm_operations_struct tegra_bo_vm_ops = {
.close = drm_gem_vm_close,
 };
 
-static int tegra_gem_mmap(struct drm_gem_object *gem,
- struct vm_area_struct *vma)
+int __tegra_gem_mmap(struct drm_gem_object *gem, struct vm_area_struct *vma)
 {
struct tegra_bo *bo = to_tegra_bo(gem);
 
@@ -512,7 +511,7 @@ int tegra_drm_mmap(struct file *file, struct vm_area_struct 
*vma)
 
gem = vma->vm_private_data;
 
-   return tegra_gem_mmap(gem, vma);
+   return __tegra_gem_mmap(gem, vma);
 }
 
 static struct sg_table *
@@ -633,7 +632,7 @@ static int tegra_gem_prime_mmap(struct dma_buf *buf, struct 
vm_area_struct *vma)
if (err < 0)
return err;
 
-   return tegra_gem_mmap(gem, vma);
+   return __tegra_gem_mmap(gem, vma);
 }
 
 static void *tegra_gem_prime_vmap(struct dma_buf *buf)
diff --git a/drivers/gpu/drm/tegra/gem.h b/drivers/gpu/drm/tegra/gem.h
index 7e1635a01c81..bb369c129fdd 100644
--- a/drivers/gpu/drm/tegra/gem.h
+++ b/drivers/gpu/drm/tegra/gem.h
@@ -75,6 +75,7 @@ int tegra_bo_dumb_create(struct drm_file *file, struct 
drm_device *drm,
 
 extern const struct vm_operations_struct tegra_bo_vm_ops;
 
+int __tegra_gem_mmap(struct drm_gem_object *gem, struct vm_area_struct *vma);
 int tegra_drm_mmap(struct file *file, struct vm_area_struct *vma);
 
 struct dma_buf *tegra_gem_prime_export(struct drm_device *drm,
-- 
2.15.1

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

[PATCH 1/3] drm/tegra: gem: Reshuffle declarations

[Thierry Reding]

From: Thierry Reding 

Move declarations in the gem.h header file into the same order as the
corresponding definitions in gem.c.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/gem.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.h b/drivers/gpu/drm/tegra/gem.h
index 8eaf5e3f6630..7e1635a01c81 100644
--- a/drivers/gpu/drm/tegra/gem.h
+++ b/drivers/gpu/drm/tegra/gem.h
@@ -73,10 +73,10 @@ void tegra_bo_free_object(struct drm_gem_object *gem);
 int tegra_bo_dumb_create(struct drm_file *file, struct drm_device *drm,
 struct drm_mode_create_dumb *args);
 
-int tegra_drm_mmap(struct file *file, struct vm_area_struct *vma);
-
 extern const struct vm_operations_struct tegra_bo_vm_ops;
 
+int tegra_drm_mmap(struct file *file, struct vm_area_struct *vma);
+
 struct dma_buf *tegra_gem_prime_export(struct drm_device *drm,
   struct drm_gem_object *gem,
   int flags);
-- 
2.15.1

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

[PATCH 3/3] drm/tegra: fb: Implement ->fb_mmap() callback

[Thierry Reding]

From: Thierry Reding 

This fixes hangs with legacy applications that use the mmap() syscall on
the fbdev device to map framebuffer memory. The fbdev implementation for
mmap() creates a mapping that conflicts with DRM usage and causes a hang
when the memory is accessed through the mapping.

Reported-by: Marcel Ziswiler 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/fb.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 001cb77e2f59..0786159edef3 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -224,12 +224,28 @@ struct drm_framebuffer *tegra_fb_create(struct drm_device 
*drm,
 }
 
 #ifdef CONFIG_DRM_FBDEV_EMULATION
+static int tegra_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   struct drm_fb_helper *helper = info->par;
+   struct tegra_bo *bo;
+   int err;
+
+   bo = tegra_fb_get_plane(helper->fb, 0);
+
+   err = drm_gem_mmap_obj(>gem, bo->gem.size, vma);
+   if (err < 0)
+   return err;
+
+   return __tegra_gem_mmap(>gem, vma);
+}
+
 static struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = drm_fb_helper_sys_fillrect,
.fb_copyarea = drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
+   .fb_mmap = tegra_fb_mmap,
 };
 
 static int tegra_fbdev_probe(struct drm_fb_helper *helper,
-- 
2.15.1

___
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 3:48 PM, Sean Paul  wrote:
> 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.

TBC, I'm fine if you use panel-timing as that's already established
for cases were only 1 mode exists.

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

[PATCH] drm/nouveau: Make clock gate support conditional

[Thierry Reding]

From: Thierry Reding 

The recently introduced clock gate support breaks on Tegra chips because
no thermal support is enabled for those devices. Conditionalize the code
on the existence of thermal support to fix this.

Fixes: b138eca661cc ("drm/nouveau: Add support for basic clockgating on 
Kepler1")
Cc: Martin Peres 
Cc: Lyude Paul 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
index bf62303571b3..3695cde669f8 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -301,7 +301,7 @@ nvkm_therm_attr_set(struct nvkm_therm *therm,
 void
 nvkm_therm_clkgate_enable(struct nvkm_therm *therm)
 {
-   if (!therm->func->clkgate_enable || !therm->clkgating_enabled)
+   if (!therm || !therm->func->clkgate_enable || !therm->clkgating_enabled)
return;
 
nvkm_debug(>subdev,
@@ -312,7 +312,7 @@ nvkm_therm_clkgate_enable(struct nvkm_therm *therm)
 void
 nvkm_therm_clkgate_fini(struct nvkm_therm *therm, bool suspend)
 {
-   if (!therm->func->clkgate_fini || !therm->clkgating_enabled)
+   if (!therm || !therm->func->clkgate_fini || !therm->clkgating_enabled)
return;
 
nvkm_debug(>subdev,
@@ -395,7 +395,7 @@ void
 nvkm_therm_clkgate_init(struct nvkm_therm *therm,
const struct nvkm_therm_clkgate_pack *p)
 {
-   if (!therm->func->clkgate_init || !therm->clkgating_enabled)
+   if (!therm || !therm->func->clkgate_init || !therm->clkgating_enabled)
return;
 
therm->func->clkgate_init(therm, p);
-- 
2.15.1

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

[Bug 103142] R600g+sb: optimizer apparently stuck in an endless loop

[bugzilla-daemon]

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

Gert Wollny  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
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 103142] R600g+sb: optimizer apparently stuck in an endless loop

[bugzilla-daemon]

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

--- Comment #7 from Gert Wollny  ---
It seems sb is trying to create an operation that tries to use two distinct
relative indices within the same instruction, this is forbidden and the
scheduler gets stuck. 

from the post scheduler dump: 

 # 0.y => t175||FP@R0.y
  # 0.z => t194||FP@R0.z
  new current_AR assigned: R13.x.235@R0.w
  current_AR is R13.x.235@R0.w  trying to use R15.x.126@R1.x
  current_AR is R13.x.235@R0.w  trying to use R15.x.126@R1.x
!! interf slot: 0  : 
  ADD t80@R1.x,A26.y[R13.x.235@R0.w]_608F@R5.y,  \
   A26.y[R15.x.126@R1.x]_609F@R5.y

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

[PATCH v2 5/5] 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.

Changes in v2:
 - Wrap the timing in display-timings node to match binding (Rob/Thierry)

Cc: Doug Anderson 
Cc: Eric Anholt 
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 | 16 
 1 file changed, 16 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..800eabd39076 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -98,6 +98,22 @@
backlight = <>;
power-supply = <_disp>;
 
+   display-timings {
+   timing0: override {
+   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 v2 1/5] dt-bindings: Add headings to simple-panel bindings

[Sean Paul]

In preparation for a new subnode section in a follow-on patch, add
explicit headings to the existings sections for simple-panel.

Changes in v2:
 - Added

Cc: Doug Anderson 
Cc: Eric Anholt 
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 
---
 Documentation/devicetree/bindings/display/panel/simple-panel.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 16d8ff088b7d..45a457ad38f0 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -1,4 +1,8 @@
 Simple display panel
+
+
+panel node
+--
 
 Required properties:
 - power-supply: See panel-common.txt
-- 
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 v2 0/5] 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

Sean Paul (5):
  dt-bindings: Add headings to simple-panel bindings
  dt-bindings: Add display-timing subnode to simple-panel
  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|  36 +++
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  |  16 
 drivers/gpu/drm/panel/panel-simple.c   | 104 ++---
 3 files changed, 141 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

[PATCH v2 4/5] 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.

Changes in v2:
 - None

Cc: Doug Anderson 
Cc: Eric Anholt 
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 c1635b35f97e..0de176a6a041 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1816,23 +1816,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 v2 2/5] dt-bindings: Add display-timing subnode to simple-panel

[Sean Paul]

This patch adds a new subnode to simple-panel allowing us to override
the typical timing expressed in the panel's display_timing.

Changes in v2:
 - Split out the binding into a new patch (Rob)
 - display-timings is a new section (Rob)
 - Use the full display-timings subnode instead of picking the timing
   out (Rob/Thierry)

Cc: Doug Anderson 
Cc: Eric Anholt 
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| 32 ++
 1 file changed, 32 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 45a457ad38f0..9717b9b79d98 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -12,6 +12,24 @@ Optional properties:
 - enable-gpios: GPIO pin to enable or disable the panel
 - backlight: phandle of the backlight device attached to the panel
 
+display-timings subnode
+---
+
+This optional subnode is for devices which require a mode differing from the
+panel's "typical" display timing as programmed in the simple-panel driver.
+Overriding the driver mode must only be done in the following scenario:
+ - The restrictions motivating the override cannot be applied to the platform's
+   display driver (ie: it must be specific to the device not the platform)
+ - The panel must not have a fixed mode attributed to it in the driver
+ - The panel must provide at list one display_timing range by which the 
override
+   mode can be validated against
+ - The override mode will use the 'typ' values from the display-timings subnode
+ - You must provide all required properties for the display-timings subnode
+
+Format information on the display-timings subnode can be found in
+display-timing.txt.
+
+
 Example:
 
panel: panel {
@@ -22,4 +40,18 @@ Example:
enable-gpios = < 90 0>;
 
backlight = <>;
+
+   display-timings {
+   timing0: override {
+   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>;
+   };
+   };
};
-- 
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 v2 3/5] 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

Changes in v2:
 - Parse the full display-timings node (using the native-mode) (Rob)

Cc: Doug Anderson 
Cc: Eric Anholt 
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
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/panel/panel-simple.c | 77 +++-
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..c1635b35f97e 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 panel_simple_add_override_mode(struct device *dev,
+  struct panel_simple *panel,
+  const struct display_timing *ot)
+{
+   const struct panel_desc *desc = panel->desc;
+   struct videomode vm;
+   int i;
+
+   if (desc->num_modes) {
+   dev_err(dev, "Reject override mode: panel has a fixed mode\n");
+   return;
+   }
+   if (!desc->num_timings) {
+   dev_err(dev, "Reject override mode: no timings specified\n");
+   return;
+   }
+
+   for (i = 0; i < panel->desc->num_timings; i++) {
+   const struct display_timing *dt = >desc->timings[i];
+
+   if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
+   continue;
+
+   if (ot->flags != dt->flags)
+   continue;
+
+   videomode_from_timing(ot, );
+   drm_display_mode_from_videomode(, >override_mode);
+   panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
+DRM_MODE_TYPE_PREFERRED;
+ 

Re: [PATCH] drm/fb-helper: Redo fb format<->fb_bitfield mapping

[Ville Syrjälä]

On Wed, Feb 07, 2018 at 05:08:30PM +, Eric Engestrom wrote:
> On Wednesday, 2018-02-07 17:24:45 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Replace the switch statements that try to map between the fb format and
> > the fb_bitfield infromation with a single table.
> > 
> > Note that this changes the behaviour of drm_fb_helper_check_var() to
> > return an error of the requested fb_bitfields don't match the actual
> > pixel format. Previously we just sort of semi-trusted some of the
> > bpp/depth information the user was asking for, and never actually
> > checked if that matches the fb pixel format.
> > 
> > This prepares us to use all different rgb format channel layouts.
> > Basically would just need some decent way for the driver/cmdline
> > to select the one you want.
> > 
> > I didn't think about endianness here at all. Not sure how fbdev is
> > supposed to deal with that stuff anyway, and I don't think we ever
> > reached a real concensus on the drm fourcc endianness either. So
> > I'll just pretend everything is little endian and ignore everything
> > else.
> > 
> > Cc: Linus Walleij 
> > Cc: Noralf Trønnes 
> > Cc: Ilia Mirkin 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 280 
> > +++-
> >  1 file changed, 163 insertions(+), 117 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 035784ddd133..0c906e3a5bb1 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -40,6 +40,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "drm_crtc_internal.h"
> >  #include "drm_crtc_helper_internal.h"
> > @@ -1561,6 +1562,147 @@ int drm_fb_helper_ioctl(struct fb_info *info, 
> > unsigned int cmd,
> >  }
> >  EXPORT_SYMBOL(drm_fb_helper_ioctl);
> >  
> > +#define FB_FORMAT_C(c) { \
> > +   .format = DRM_FORMAT_C##c,\
> > +   .blue   = { .length = (c), }, \
> > +   .green  = { .length = (c), }, \
> > +   .red= { .length = (c), }, \
> > +}
> > +#define FB_FORMAT_RGB(r, g, b) { \
> > +   .format = DRM_FORMAT_RGB##r##g##b, \
> > +   .blue   = { .length = (b), .offset = 0, }, \
> > +   .green  = { .length = (g), .offset = (b), }, \
> > +   .red= { .length = (r), .offset = (b)+(g), }, \
> > +}
> > +#define FB_FORMAT_BGR(b, g, r) { \
> > +   .format = DRM_FORMAT_BGR##b##g##r, \
> > +   .red= { .length = (r), .offset = 0, }, \
> > +   .green  = { .length = (g), .offset = (r), }, \
> > +   .blue   = { .length = (b), .offset = (r)+(g), }, \
> > +}
> > +#define FB_FORMAT_XRGB(x, r, g, b) { \
> > +   .format = DRM_FORMAT_XRGB##x##r##g##b, \
> > +   .blue   = { .length = (b), .offset = 0, }, \
> > +   .green  = { .length = (g), .offset = (b), }, \
> > +   .red= { .length = (r), .offset = (b)+(g), }, \
> > +}
> > +#define FB_FORMAT_XBGR(x, b, g, r) { \
> > +   .format = DRM_FORMAT_XBGR##x##b##g##r, \
> > +   .red= { .length = (r), .offset = 0, }, \
> > +   .green  = { .length = (g), .offset = (r), }, \
> > +   .blue   = { .length = (b), .offset = (r)+(g), }, \
> > +}
> > +#define FB_FORMAT_RGBX(r, g, b, x) { \
> > +   .format = DRM_FORMAT_RGBX##r##g##b##x, \
> > +   .blue   = { .length = (b), .offset = (x), }, \
> > +   .green  = { .length = (g), .offset = (x)+(b), }, \
> > +   .red= { .length = (r), .offset = (x)+(b)+(g), }, \
> > +}
> > +#define FB_FORMAT_BGRX(b, g, r, x) { \
> > +   .format = DRM_FORMAT_BGRX##b##g##r##x, \
> > +   .red= { .length = (r), .offset = (x), }, \
> > +   .green  = { .length = (g), .offset = (x)+(r), }, \
> > +   .blue   = { .length = (b), .offset = (x)+(r)+(g), }, \
> > +}
> > +#define FB_FORMAT_ARGB(a, r, g, b) { \
> > +   .format = DRM_FORMAT_ARGB##a##r##g##b, \
> > +   .blue   = { .length = (b), .offset = 0, }, \
> > +   .green  = { .length = (g), .offset = (b), }, \
> > +   .red= { .length = (r), .offset = (b)+(g), }, \
> > +   .transp = { .length = (a), .offset = (b)+(g)+(r), }, \
> > +}
> > +#define FB_FORMAT_ABGR(a, b, g, r) { \
> > +   .format = DRM_FORMAT_ABGR##a##b##g##r, \
> > +   .red= { .length = (r), .offset = 0, }, \
> > +   .green  = { .length = (g), .offset = (r), }, \
> > +   .blue   = { .length = (b), .offset = (r)+(g), },\
> > +   .transp = { .length = (a), .offset = (r)+(g)+(b), }, \
> > +}
> > +#define FB_FORMAT_RGBA(r, g, b, a) { \
> > +   .format = DRM_FORMAT_RGBA##r##g##b##a, \
> > +   .transp = { .length = (a), .offset = 0, }, \
> > +   .blue   = { .length = (b), .offset = (a), }, \
> > +   .green  = { .length = (g), .offset = (a)+(b), }, \
> > +   .red= { .length = (r), .offset = (a)+(b)+(g), }, \
> > +}
> > +#define FB_FORMAT_BGRA(b, g, r, a) { \
> > +   .format = DRM_FORMAT_BGRA##b##g##r##a, \
> > +   .transp = { .length = (a), .offset = 0, }, \
> > +   .red= { .length 

[Bug 198713] AMD DC crashes when computing clocks/detecting freesync

[bugzilla-daemon]

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

--- Comment #3 from Jon (j...@moozaad.co.uk) ---
(In reply to Mike Lothian from comment #2)
> As a workaround try amdgpu.dc=0

Well spotted. Workaround has stopped the traces as you'd expect. It's also
stopped the weird blue flicker I was getting in KDE with OGL3 compositor
(different DC bug).

I hope the above is useful for getting PRE_VEGA out of experimental!


Missing from original report, it's 3x BenQ XL2730Z, all display port.

-- 
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] drm/fb-helper: Redo fb format<->fb_bitfield mapping

[Eric Engestrom]

On Wednesday, 2018-02-07 17:24:45 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Replace the switch statements that try to map between the fb format and
> the fb_bitfield infromation with a single table.
> 
> Note that this changes the behaviour of drm_fb_helper_check_var() to
> return an error of the requested fb_bitfields don't match the actual
> pixel format. Previously we just sort of semi-trusted some of the
> bpp/depth information the user was asking for, and never actually
> checked if that matches the fb pixel format.
> 
> This prepares us to use all different rgb format channel layouts.
> Basically would just need some decent way for the driver/cmdline
> to select the one you want.
> 
> I didn't think about endianness here at all. Not sure how fbdev is
> supposed to deal with that stuff anyway, and I don't think we ever
> reached a real concensus on the drm fourcc endianness either. So
> I'll just pretend everything is little endian and ignore everything
> else.
> 
> Cc: Linus Walleij 
> Cc: Noralf Trønnes 
> Cc: Ilia Mirkin 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 280 
> +++-
>  1 file changed, 163 insertions(+), 117 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 035784ddd133..0c906e3a5bb1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  #include "drm_crtc_helper_internal.h"
> @@ -1561,6 +1562,147 @@ int drm_fb_helper_ioctl(struct fb_info *info, 
> unsigned int cmd,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_ioctl);
>  
> +#define FB_FORMAT_C(c) { \
> + .format = DRM_FORMAT_C##c,\
> + .blue   = { .length = (c), }, \
> + .green  = { .length = (c), }, \
> + .red= { .length = (c), }, \
> +}
> +#define FB_FORMAT_RGB(r, g, b) { \
> + .format = DRM_FORMAT_RGB##r##g##b, \
> + .blue   = { .length = (b), .offset = 0, }, \
> + .green  = { .length = (g), .offset = (b), }, \
> + .red= { .length = (r), .offset = (b)+(g), }, \
> +}
> +#define FB_FORMAT_BGR(b, g, r) { \
> + .format = DRM_FORMAT_BGR##b##g##r, \
> + .red= { .length = (r), .offset = 0, }, \
> + .green  = { .length = (g), .offset = (r), }, \
> + .blue   = { .length = (b), .offset = (r)+(g), }, \
> +}
> +#define FB_FORMAT_XRGB(x, r, g, b) { \
> + .format = DRM_FORMAT_XRGB##x##r##g##b, \
> + .blue   = { .length = (b), .offset = 0, }, \
> + .green  = { .length = (g), .offset = (b), }, \
> + .red= { .length = (r), .offset = (b)+(g), }, \
> +}
> +#define FB_FORMAT_XBGR(x, b, g, r) { \
> + .format = DRM_FORMAT_XBGR##x##b##g##r, \
> + .red= { .length = (r), .offset = 0, }, \
> + .green  = { .length = (g), .offset = (r), }, \
> + .blue   = { .length = (b), .offset = (r)+(g), }, \
> +}
> +#define FB_FORMAT_RGBX(r, g, b, x) { \
> + .format = DRM_FORMAT_RGBX##r##g##b##x, \
> + .blue   = { .length = (b), .offset = (x), }, \
> + .green  = { .length = (g), .offset = (x)+(b), }, \
> + .red= { .length = (r), .offset = (x)+(b)+(g), }, \
> +}
> +#define FB_FORMAT_BGRX(b, g, r, x) { \
> + .format = DRM_FORMAT_BGRX##b##g##r##x, \
> + .red= { .length = (r), .offset = (x), }, \
> + .green  = { .length = (g), .offset = (x)+(r), }, \
> + .blue   = { .length = (b), .offset = (x)+(r)+(g), }, \
> +}
> +#define FB_FORMAT_ARGB(a, r, g, b) { \
> + .format = DRM_FORMAT_ARGB##a##r##g##b, \
> + .blue   = { .length = (b), .offset = 0, }, \
> + .green  = { .length = (g), .offset = (b), }, \
> + .red= { .length = (r), .offset = (b)+(g), }, \
> + .transp = { .length = (a), .offset = (b)+(g)+(r), }, \
> +}
> +#define FB_FORMAT_ABGR(a, b, g, r) { \
> + .format = DRM_FORMAT_ABGR##a##b##g##r, \
> + .red= { .length = (r), .offset = 0, }, \
> + .green  = { .length = (g), .offset = (r), }, \
> + .blue   = { .length = (b), .offset = (r)+(g), },\
> + .transp = { .length = (a), .offset = (r)+(g)+(b), }, \
> +}
> +#define FB_FORMAT_RGBA(r, g, b, a) { \
> + .format = DRM_FORMAT_RGBA##r##g##b##a, \
> + .transp = { .length = (a), .offset = 0, }, \
> + .blue   = { .length = (b), .offset = (a), }, \
> + .green  = { .length = (g), .offset = (a)+(b), }, \
> + .red= { .length = (r), .offset = (a)+(b)+(g), }, \
> +}
> +#define FB_FORMAT_BGRA(b, g, r, a) { \
> + .format = DRM_FORMAT_BGRA##b##g##r##a, \
> + .transp = { .length = (a), .offset = 0, }, \
> + .red= { .length = (r), .offset = (a), }, \
> + .green  = { .length = (g), .offset = (a)+(r), }, \
> + .blue   = { .length = (b), .offset = (a)+(r)+(g), }, \
> +}
> +
> +struct drm_fb_helper_format {
> + u32 

Re: nouveau 30bpp / deep color status

[Ville Syrjälä]

On Wed, Feb 07, 2018 at 06:28:42PM +0200, Ville Syrjälä wrote:
> On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
> > In case anyone's curious about 30bpp framebuffer support, here's the
> > current status:
> > 
> > Kernel:
> > 
> > Ben and I have switched the code to using a 256-based LUT for Kepler+,
> > and I've also written a patch to cause the addfb ioctl to use the
> > proper format. You can pick this up at:
> > 
> > https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
> > https://patchwork.freedesktop.org/patch/202322/
> > 
> > With these two, you should be able to use "X -depth 30" again on any
> > G80+ GPU to bring up a screen (as you could in kernel 4.9 and
> > earlier). However this still has some deficiencies, some of which I've
> > addressed:
> > 
> > xf86-video-nouveau:
> > 
> > DRI3 was broken, and Xv was broken. Patches available at:
> > 
> > https://github.com/imirkin/xf86-video-nouveau/commits/master
> > 
> > mesa:
> > 
> > The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the
> > nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could).
> > Mesa was only enabled for XRGB, so I've piped XBGR through all the
> > same places:
> > 
> > https://github.com/imirkin/mesa/commits/30bpp
> > 
> > libdrm:
> > 
> > For testing, I added a modetest gradient pattern split horizontally.
> > Top half is 10bpc, bottom half is 8bpc. This is useful for seeing
> > whether you're really getting 10bpc, or if things are getting
> > truncated along the way. Definitely hacky, but ... wasn't intending on
> > upstreaming it anyways:
> > 
> > https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441
> > 
> > -
> > 
> > Results with the patches (tested on a GK208B and a "deep color" TV over 
> > HDMI):
> >  - modetest with a 10bpc gradient shows up smoother than an 8bpc
> > gradient. However it's still dithered to 8bpc, not "real" 10bpc.
> >  - things generally work in X -- dri2 and dri3, xv, and obviously
> > regular X rendering / acceleration
> >  - lots of X software can't handle 30bpp modes (mplayer hates it for
> > xv and x11 rendering, aterm bails on shading the root pixmap, probably
> > others)
> > 
> > I'm also told that with DP, it should actually send the higher-bpc
> > data over the wire. With HDMI, we're still stuck at 24bpp for now
> > (although the hardware can do 36bpp as well). This is why my gradient
> > result above was still dithered.
> > 
> > Things to do - mostly nouveau specific, but probably some general
> > infra needed too:
> >  - Figure out how to properly expose the 1024-sized LUT
> 
> We have the properties in the kernel. Not sure if x11 could expose it
> to clients somehow, or would we just have to interpolate the missing
> bits in the ddx?

Oh, and I think we're going to have to come up with a fancier uapi for
this stuff because in the future the input points may not be evenly
spaced (for HDR stuff). Also the hardware may provide various different
modes for the gamma LUTs with different tradeoffs. So we may even want
to somehow try to enumerate the different modes and let userspace pick
the mode that best suits its needs.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100784] Fullscreen fade transitions in starsector run at a few frames per second

[bugzilla-daemon]

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

--- Comment #4 from Jon  ---
Present in 18.0.0 too. Still drops to single figures for transitions from space
station menu to solar map. Doesn't seem present from galactic map to solar map.

-- 
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 196771] [AMDGPU] Scrambled video output during boot on WQHD monitor

[bugzilla-daemon]

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

Rokas Kupstys (rokups+kernel-b...@zoho.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |OBSOLETE

--- Comment #8 from Rokas Kupstys (rokups+kernel-b...@zoho.com) ---
 amdgpu.dc=1 with 4.15 kernel fixes the issue.

-- 
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: nouveau 30bpp / deep color status

[Ville Syrjälä]

On Sun, Feb 04, 2018 at 06:50:45PM -0500, Ilia Mirkin wrote:
> In case anyone's curious about 30bpp framebuffer support, here's the
> current status:
> 
> Kernel:
> 
> Ben and I have switched the code to using a 256-based LUT for Kepler+,
> and I've also written a patch to cause the addfb ioctl to use the
> proper format. You can pick this up at:
> 
> https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
> https://patchwork.freedesktop.org/patch/202322/
> 
> With these two, you should be able to use "X -depth 30" again on any
> G80+ GPU to bring up a screen (as you could in kernel 4.9 and
> earlier). However this still has some deficiencies, some of which I've
> addressed:
> 
> xf86-video-nouveau:
> 
> DRI3 was broken, and Xv was broken. Patches available at:
> 
> https://github.com/imirkin/xf86-video-nouveau/commits/master
> 
> mesa:
> 
> The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the
> nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could).
> Mesa was only enabled for XRGB, so I've piped XBGR through all the
> same places:
> 
> https://github.com/imirkin/mesa/commits/30bpp
> 
> libdrm:
> 
> For testing, I added a modetest gradient pattern split horizontally.
> Top half is 10bpc, bottom half is 8bpc. This is useful for seeing
> whether you're really getting 10bpc, or if things are getting
> truncated along the way. Definitely hacky, but ... wasn't intending on
> upstreaming it anyways:
> 
> https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441
> 
> -
> 
> Results with the patches (tested on a GK208B and a "deep color" TV over HDMI):
>  - modetest with a 10bpc gradient shows up smoother than an 8bpc
> gradient. However it's still dithered to 8bpc, not "real" 10bpc.
>  - things generally work in X -- dri2 and dri3, xv, and obviously
> regular X rendering / acceleration
>  - lots of X software can't handle 30bpp modes (mplayer hates it for
> xv and x11 rendering, aterm bails on shading the root pixmap, probably
> others)
> 
> I'm also told that with DP, it should actually send the higher-bpc
> data over the wire. With HDMI, we're still stuck at 24bpp for now
> (although the hardware can do 36bpp as well). This is why my gradient
> result above was still dithered.
> 
> Things to do - mostly nouveau specific, but probably some general
> infra needed too:
>  - Figure out how to properly expose the 1024-sized LUT

We have the properties in the kernel. Not sure if x11 could expose it
to clients somehow, or would we just have to interpolate the missing
bits in the ddx?

>  - Add fp16 scanout

i915 could do this as well. There was a patch to just add the fourcc
on account of gvt needing it for some Windows thing. IIRC I asked them
to actually implement it in i915 proper but no patch ever surfaced.

>  - Stop relying on the max bpc of the monitor/connector and make
> decisions based on the "effective" bpc (e.g. based on the
> currently-set fb format, take hdmi/dp into account, etc). This will
> also affect the max clock somehow. Perhaps there should be a way to
> force a connector to a certain bpc.

We used to look at the fb depth for the primary plane when picking the
output bpc, but that doesn't really work when you have multiple planes,
and you generally don't want to have to do a modeset to flip to a fb
with another format. So in the end we just chose to go for the max
bpc possible.

There are some potential issues with deep color though (crappy HDMI
cables, dongles etc.) so I suggested a property to allow the user
to limit it below a certain value. Problem is that IIRC the patch we
got was just adding it to i915, whereas we really want to put it
into the drm core so that everyone will implement the same thing.

>  - Add higher-bpc HDMI support

Bunch of interesting stuff in i915 to figure out the sink/dongle clock
limit etc. If someone else is going to implement HDMI deep color we
should perhaps look into lifting some of that stuff into some common
place.

>  - Add 10bpc dithering (only makes sense if >= 10bpc output is
> *actually* enabled first)
>  - Investigate YUV HDMI modes (esp since they can enable 4K@60 on HDMI
> 1.4 hardware)

We have 4:2:0 in i915, and pretty close to having YCbCr 4:4:4 too.
The 4:4:4 thing would need some new properties though so that the user
can actually enable it. What we do with 4:2:0 is enable it automagically
when the display can't do RGB 4:4:4 for the given mode. But there's 
currently no way for the user to say that they prefer YCbCr 4:2:0 over
RGB 4:4:4.

>  - Test out Wayland compositors
>  - Teach xf86-video-modesetting about addfb2 or that nouveau's
> ordering is different.
> 
> I don't necessarily plan on working further on this, so if there are
> interested parties, they should definitely try to pick it up. I'll try
> to upstream all my changes though.
> 
> Cheers,
> 
>   -ilia
> ___
> dri-devel mailing list
> 

[Bug 198713] AMD DC crashes when computing clocks/detecting freesync

[bugzilla-daemon]

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

Mike Lothian (m...@fireburn.co.uk) changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #2 from Mike Lothian (m...@fireburn.co.uk) ---
You don't need amdgpu.dc=1 set, it's already enabled in the .config that you
provided:

CONFIG_DRM_AMD_DC = y
CONFIG_DRM_AMD_DC_PRE_VEGA = y

As a workaround try amdgpu.dc=0

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

[Bug 198713] AMD DC crashes when computing clocks/detecting freesync

[bugzilla-daemon]

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

--- Comment #1 from Jon (j...@moozaad.co.uk) ---
Created attachment 274055
  --> https://bugzilla.kernel.org/attachment.cgi?id=274055=edit
kernel config from /boot

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

[Bug 198713] New: AMD DC crashes when computing clocks/detecting freesync

[bugzilla-daemon]

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

Bug ID: 198713
   Summary: AMD DC crashes when computing clocks/detecting
freesync
   Product: Drivers
   Version: 2.5
Kernel Version: 4.15.1-7
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: j...@moozaad.co.uk
Regression: No

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

Fury X  w/ BenQ XL2730Z connected with DisplayPort

amdgpu.dc=1 is NOT set.

See attached dmesg for 12 traces related to DC.

It looks to be crashing whilst detecting/computing clocks when freesync is
detected. I've not set it to be enabled.

-- 
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 1/2] media: adv7604: Add support for i2c_new_secondary_device

[Kieran Bingham]

Hi Rob,

On 29/01/18 20:08, Rob Herring wrote:
> On Mon, Jan 22, 2018 at 12:49:56PM +, Kieran Bingham wrote:
>> From: Jean-Michel Hautbois 
>>
>> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
>> I²C ports. Each map has it own I²C address and acts as a standard slave
>> device on the I²C bus.
>>
>> Allow a device tree node to override the default addresses so that
>> address conflicts with other devices on the same bus may be resolved at
>> the board description level.
>>
>> Signed-off-by: Jean-Michel Hautbois 
>> [Kieran: Re-adapted for mainline]
>> Signed-off-by: Kieran Bingham 
>> ---
>> Based upon the original posting :
>>   https://lkml.org/lkml/2014/10/22/469
>> ---
>>  .../devicetree/bindings/media/i2c/adv7604.txt  | 18 ++-
> 
> Reviewed-by: Rob Herring 

Thank you.

> In the future, please split bindings to separate patch.

Yes, of course - sorry - I should probably have known better here.

I was clearly being lazy as the original patch had bindings in with the driver.
Although I don't think I've got an excuse for the second patch in the series :D

I've split them out for the v2.

--
Kieran

>>  drivers/media/i2c/adv7604.c| 60 
>> ++
>>  2 files changed, 55 insertions(+), 23 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] drm/omap: Fail probe if irq registration fails

[Tomi Valkeinen]

On 07/02/18 14:10, Jyri Sarha wrote:
> Call to omap_drm_irq_install() may fail with an error code. In such a
> case the driver probe should fail.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 71ea43f..e6e7a2c 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -329,9 +329,9 @@ static int omap_modeset_init(struct drm_device *dev)
>  
>   drm_mode_config_reset(dev);
>  
> - omap_drm_irq_install(dev);
> + ret = omap_drm_irq_install(dev);
>  
> - return 0;
> + return ret;
>  }

It's better to do "if (ret) return ret;" so that it's easy (and less
error prone) to modify the code later.

Other than that:

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
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 0/3] drm/panel: simple: Add mode support to devicetree

[Sean Paul]

On Wed, Feb 07, 2018 at 09:16:22AM +, Eric Anholt wrote:
> Sean Paul  writes:
> 
> > 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.
> 
> Couldn't you just add a different compatible string for the panel
> driver, and use that to have a different mode exposed from the panel?

Yep, there's a couple ways to skin this cat. We could just change the mode to
what the kevin device needs since it's the only one that uses this panel atm
(that's what the original patch in the context link does). We could also expose
multiple modes for the panel and let userspace sort it out.

That said, we already have timing ranges in panel-simple and the goal is to
leverage those such that we don't need additional compatible panels/extra modes.

Sean

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

[PATCH] drm/fb-helper: Redo fb format<->fb_bitfield mapping

[Ville Syrjala]

From: Ville Syrjälä 

Replace the switch statements that try to map between the fb format and
the fb_bitfield infromation with a single table.

Note that this changes the behaviour of drm_fb_helper_check_var() to
return an error of the requested fb_bitfields don't match the actual
pixel format. Previously we just sort of semi-trusted some of the
bpp/depth information the user was asking for, and never actually
checked if that matches the fb pixel format.

This prepares us to use all different rgb format channel layouts.
Basically would just need some decent way for the driver/cmdline
to select the one you want.

I didn't think about endianness here at all. Not sure how fbdev is
supposed to deal with that stuff anyway, and I don't think we ever
reached a real concensus on the drm fourcc endianness either. So
I'll just pretend everything is little endian and ignore everything
else.

Cc: Linus Walleij 
Cc: Noralf Trønnes 
Cc: Ilia Mirkin 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_fb_helper.c | 280 +++-
 1 file changed, 163 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 035784ddd133..0c906e3a5bb1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_crtc_helper_internal.h"
@@ -1561,6 +1562,147 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned 
int cmd,
 }
 EXPORT_SYMBOL(drm_fb_helper_ioctl);
 
+#define FB_FORMAT_C(c) { \
+   .format = DRM_FORMAT_C##c,\
+   .blue   = { .length = (c), }, \
+   .green  = { .length = (c), }, \
+   .red= { .length = (c), }, \
+}
+#define FB_FORMAT_RGB(r, g, b) { \
+   .format = DRM_FORMAT_RGB##r##g##b, \
+   .blue   = { .length = (b), .offset = 0, }, \
+   .green  = { .length = (g), .offset = (b), }, \
+   .red= { .length = (r), .offset = (b)+(g), }, \
+}
+#define FB_FORMAT_BGR(b, g, r) { \
+   .format = DRM_FORMAT_BGR##b##g##r, \
+   .red= { .length = (r), .offset = 0, }, \
+   .green  = { .length = (g), .offset = (r), }, \
+   .blue   = { .length = (b), .offset = (r)+(g), }, \
+}
+#define FB_FORMAT_XRGB(x, r, g, b) { \
+   .format = DRM_FORMAT_XRGB##x##r##g##b, \
+   .blue   = { .length = (b), .offset = 0, }, \
+   .green  = { .length = (g), .offset = (b), }, \
+   .red= { .length = (r), .offset = (b)+(g), }, \
+}
+#define FB_FORMAT_XBGR(x, b, g, r) { \
+   .format = DRM_FORMAT_XBGR##x##b##g##r, \
+   .red= { .length = (r), .offset = 0, }, \
+   .green  = { .length = (g), .offset = (r), }, \
+   .blue   = { .length = (b), .offset = (r)+(g), }, \
+}
+#define FB_FORMAT_RGBX(r, g, b, x) { \
+   .format = DRM_FORMAT_RGBX##r##g##b##x, \
+   .blue   = { .length = (b), .offset = (x), }, \
+   .green  = { .length = (g), .offset = (x)+(b), }, \
+   .red= { .length = (r), .offset = (x)+(b)+(g), }, \
+}
+#define FB_FORMAT_BGRX(b, g, r, x) { \
+   .format = DRM_FORMAT_BGRX##b##g##r##x, \
+   .red= { .length = (r), .offset = (x), }, \
+   .green  = { .length = (g), .offset = (x)+(r), }, \
+   .blue   = { .length = (b), .offset = (x)+(r)+(g), }, \
+}
+#define FB_FORMAT_ARGB(a, r, g, b) { \
+   .format = DRM_FORMAT_ARGB##a##r##g##b, \
+   .blue   = { .length = (b), .offset = 0, }, \
+   .green  = { .length = (g), .offset = (b), }, \
+   .red= { .length = (r), .offset = (b)+(g), }, \
+   .transp = { .length = (a), .offset = (b)+(g)+(r), }, \
+}
+#define FB_FORMAT_ABGR(a, b, g, r) { \
+   .format = DRM_FORMAT_ABGR##a##b##g##r, \
+   .red= { .length = (r), .offset = 0, }, \
+   .green  = { .length = (g), .offset = (r), }, \
+   .blue   = { .length = (b), .offset = (r)+(g), },\
+   .transp = { .length = (a), .offset = (r)+(g)+(b), }, \
+}
+#define FB_FORMAT_RGBA(r, g, b, a) { \
+   .format = DRM_FORMAT_RGBA##r##g##b##a, \
+   .transp = { .length = (a), .offset = 0, }, \
+   .blue   = { .length = (b), .offset = (a), }, \
+   .green  = { .length = (g), .offset = (a)+(b), }, \
+   .red= { .length = (r), .offset = (a)+(b)+(g), }, \
+}
+#define FB_FORMAT_BGRA(b, g, r, a) { \
+   .format = DRM_FORMAT_BGRA##b##g##r##a, \
+   .transp = { .length = (a), .offset = 0, }, \
+   .red= { .length = (r), .offset = (a), }, \
+   .green  = { .length = (g), .offset = (a)+(r), }, \
+   .blue   = { .length = (b), .offset = (a)+(r)+(g), }, \
+}
+
+struct drm_fb_helper_format {
+   u32 format;
+   struct fb_bitfield red, green, blue, transp;
+};
+
+static const struct drm_fb_helper_format fb_formats[] = {
+   FB_FORMAT_C(8),
+
+   FB_FORMAT_XRGB(1, 5, 5, 5),
+   

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

Hi Laurent,

On 29/01/18 10:26, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.

Thanks for your review,

> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
>> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
>> ports. Each map has it own I²C address and acts as a standard slave
>> device on the I²C bus.
>>
>> Allow a device tree node to override the default addresses so that
>> address conflicts with other devices on the same bus may be resolved at
>> the board description level.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
> 
> I don't mind personally, but device tree maintainers usually ask for DT 
> bindings changes to be split to a separate patch.
> 
>>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
>>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 ---
>>  3 files changed, 37 insertions(+), 13 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> index 0047b1394c70..f6bb9f6d3f48 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -70,6 +70,9 @@ Optional properties:
>>rather than generate its own timings for HDMI output.
>>  - clocks: from common clock binding: reference to the CEC clock.
>>  - clock-names: from common clock binding: must be "cec".
>> +- reg-names : Names of maps with programmable addresses.
>> +It can contain any map needing a non-default address.
>> +Possible maps names are : "main", "edid", "cec", "packet"
> 
> Is the reg-names property (and the additional maps) mandatory or optional ? > 
> If mandatory you should also update the existing DT sources that use those
> bindings.

They are currently optional. I do prefer it that way - but perhaps due to an
issue mentioned below we might need to make this driver mandatory ?


> If optional you should define which I2C addresses will be used when 
> the maps are not specified > (and in that case I think we should go for the
> addresses listed as default in the datasheet, which correspond to the current 
> driver implementation when the main address is 0x3d/0x7a).

The current addresses do not correspond to the datasheet, even when the
implementation main address is set to 0x3d.

Thus, in my opinion - they are currently 'wrong' - but perhaps changing them is
considered breakage too.

A particular issue will arise here too - as on this device - when the device is
in low-power mode (after probe, before use) - the maps will respond on their
*hardware default* addresses (the ones implemented in this patch), and thus
consume that address on the I2C bus regardless of their settings in the driver.


> You should also update the definition of the reg property that currently just 
> states
> 
> - reg: I2C slave address
> 
> And finally you might want to define the term "map" in this context. Here's a 
> proposal (if we make all maps mandatory).
> 
> The ADV7511 internal registers are split into four pages exposed through 
> different I2C addresses, creating four register maps. The I2C addresses of 
> all 
> four maps shall be specified by the reg and reg-names property.
> 
> - reg: I2C slave addresses, one per reg-names entry
> - reg-names: map names, shall be "main", "edid", "cec", "packet"
> 
>>  Required nodes:
>>  
>> @@ -88,7 +91,12 @@ Example
>>  
>>  adv7511w: hdmi@39 {
>>  compatible = "adi,adv7511w";
>> -reg = <39>;
>> +/*
>> + * The EDID page will be accessible on address 0x66 on the i2c
>> + * bus. All other maps continue to use their default addresses.
>> + */
>> +reg = <0x39 0x66>;
>> +reg-names = "main", "edid";
>>  interrupt-parent = <>;
>>  interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
>>  clocks = <_clock>;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> index d034b2cb5eee..7d81ce3808e0 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -53,8 +53,10 @@
>>  #define ADV7511_REG_POWER   0x41
>>  #define ADV7511_REG_STATUS  0x42
>>  #define ADV7511_REG_EDID_I2C_ADDR   0x43
>> +#define ADV7511_REG_EDID_I2C_ADDR_DEFAULT   0x3f
>>  #define ADV7511_REG_PACKET_ENABLE1  0x44
>>  #define ADV7511_REG_PACKET_I2C_ADDR 0x45
>> +#define ADV7511_REG_PACKET_I2C_ADDR_DEFAULT 0x38
>>  #define ADV7511_REG_DSD_ENABLE  0x46
>>  #define ADV7511_REG_VIDEO_INPUT_CFG20x48
>>  #define ADV7511_REG_INFOFRAME_UPDATE0x4a
>> @@ -89,6 +91,7 @@
>>  #define ADV7511_REG_TMDS_CLOCK_INV  

[GIT PULL] fbdev changes for v4.16

[Bartlomiej Zolnierkiewicz]

Hi Linus,

Please pull fbdev changes for v4.16.  There is nothing really major here
(please see the signed tag description for details).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics


The following changes since commit 464e1d5f23cca236b930ef068c328a64cab78fb1:

  Linux 4.15-rc5 (2017-12-23 20:47:16 -0800)

are available in the git repository at:

  https://github.com/bzolnier/linux.git tags/fbdev-v4.16

for you to fetch changes up to 5865889fe4319415e439095391dda52f23030d60:

  video: udlfb: Switch from the pr_*() to the dev_*() logging functions 
(2018-01-16 16:35:20 +0100)


fbdev changes for v4.16:

- fix display-timings lookup in the Device Tree in atmel_lcdfb
  driver (Johan Hovold)

- fix video mode and line_length to be set correctly in vfb driver
  (Pieter "PoroCYon" Sluys)

- fix returning nonsensical values to the user-space on GIO_FONTX
  ioctl when using dummy console (Nicolas Pitre)

- add missing license tag to mmpfb driver (Arnd Bergmann)

- convert radeonfb and pxa3xx_gcu drivers to use ktime_get[_ts64]()
  instead of the deprecated do_gettimeofday() (Arnd Bergmann)

- switch udlfb driver from using the pr_*() logging functions to
  the dev_*() ones + related cleanups (Ladislav Michl)

- use __raw I/O accessors also on arm64 (Ji Zhang)

- fix Kconfig help text for intelfb driver (Randy Dunlap)

- do not duplicate features data in omapfb driver (Ladislav Michl)

- misc cleanups (Colin Ian King, Markus Elfring, Rasmus Villemoes,
  Vasyl Gomonovych, Himanshu Jha, Michael Trimarchi)


Arnd Bergmann (3):
  fbdev: radeon: use ktime_get() for HZ calibration
  fbdev: pxa3xx: use ktime_get_ts64 for time stamps
  video: fbdev/mmp: add MODULE_LICENSE

Bartlomiej Zolnierkiewicz (1):
  Merge tag 'v4.15-rc5' of git://git.kernel.org/.../torvalds/linux into 
fbdev-for-next

Colin Ian King (1):
  video: fbdev: remove redundant self assignment of 'height'

Himanshu Jha (1):
  fbdev: auo_k190x: Use zeroing memory allocator instead of allocator/memset

Ji Zhang (1):
  fbdev: arm64 use __raw I/O memory api

Johan Hovold (1):
  video: fbdev: atmel_lcdfb: fix display-timings lookup

Ladislav Michl (7):
  omapfb: dss: Do not duplicate features data
  video: udlfb: Remove unnecessary local variable
  video: udlfb: Remove redundant gdev variable
  video: udlfb: Remove noisy warnings
  video: udlfb: Do not name private data 'dev'
  video: udlfb: Constify read only data
  video: udlfb: Switch from the pr_*() to the dev_*() logging functions

Markus Elfring (5):
  video/fbdev/wm8505fb: Delete an error message for a failed memory 
allocation in wm8505fb_probe()
  video/fbdev/vt8500lcdfb: Delete an error message for a failed memory 
allocation in vt8500lcd_probe()
  video: udlfb: Improve a size determination in dlfb_alloc_urb_list()
  video: udlfb: Delete an unnecessary return statement in two functions
  video: smscufx: Improve a size determination in two functions

Michael Trimarchi (1):
  fbdev: mxsfb: use framebuffer_alloc in the correct way

Nicolas Pitre (1):
  console/dummy: leave .con_font_get set to NULL

Pieter \"PoroCYon\" Sluys (1):
  vfb: fix video mode and line_length being set when loaded

Randy Dunlap (1):
  fb: intelfb: fix Kconfig symbol info in help text

Rasmus Villemoes (1):
  fbdev: au1200fb: delete duplicate header contents

Vasyl Gomonovych (1):
  video: fbdev: omap2: Use PTR_ERR_OR_ZERO()

 drivers/video/console/dummycon.c|   1 -
 drivers/video/fbdev/Kconfig |   2 +-
 drivers/video/fbdev/atmel_lcdfb.c   |   8 +-
 drivers/video/fbdev/aty/radeon_base.c   |  18 +-
 drivers/video/fbdev/au1200fb.h  | 286 ---
 drivers/video/fbdev/auo_k190x.c |   3 +-
 drivers/video/fbdev/mmp/core.c  |   5 +
 drivers/video/fbdev/mxsfb.c |  45 +-
 drivers/video/fbdev/omap2/omapfb/dss/dispc.c|  39 +-
 drivers/video/fbdev/omap2/omapfb/dss/dss.c  |  45 +-
 drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c|   5 +-
 drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c |  31 +-
 drivers/video/fbdev/pxa3xx-gcu.c|  16 +-
 drivers/video/fbdev/smscufx.c   |   5 +-
 drivers/video/fbdev/udlfb.c | 655 
 drivers/video/fbdev/vfb.c   |  17 +
 drivers/video/fbdev/vga16fb.c   |   1 -
 drivers/video/fbdev/vt8500lcdfb.c   |   4 +-
 drivers/video/fbdev/wm8505fb.c  |   4 +-
 include/linux/fb.h  |   5 +-
 include/video/udlfb.h   |   3 +-
 21 files changed, 421 insertions(+), 777 deletions(-)

___
dri-devel 

[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 #2 from VF  ---
No, neither radeon.bapm=O nor radeon.bapm=1 help neither in K4.4.0-112 nor
K4.15.1

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

[drm-intel:drm-intel-next-queued 1/1] drivers/gpu//drm/i915/i915_pmu.c:473:18: error: 'struct dev_pm_info' has no member named 'suspended_jiffies'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   1fe699e30113ed6f6e853ff44710d256072ea627
commit: 1fe699e30113ed6f6e853ff44710d256072ea627 [1/1] drm/i915/pmu: Fix sleep 
under atomic in RC6 readout
config: i386-randconfig-x019-201805 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 1fe699e30113ed6f6e853ff44710d256072ea627
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/i915_pmu.c: In function 'get_rc6':
>> drivers/gpu//drm/i915/i915_pmu.c:473:18: error: 'struct dev_pm_info' has no 
>> member named 'suspended_jiffies'
  kdev->power.suspended_jiffies;
 ^
   drivers/gpu//drm/i915/i915_pmu.c:475:20: error: 'struct dev_pm_info' has no 
member named 'suspended_jiffies'
  val = kdev->power.suspended_jiffies -
   ^
>> drivers/gpu//drm/i915/i915_pmu.c:477:31: error: 'struct dev_pm_info' has no 
>> member named 'accounting_timestamp'
  val += jiffies - kdev->power.accounting_timestamp;
  ^

vim +473 drivers/gpu//drm/i915/i915_pmu.c

   417  
   418  static u64 get_rc6(struct drm_i915_private *i915, bool locked)
   419  {
   420  unsigned long flags;
   421  u64 val;
   422  
   423  if (intel_runtime_pm_get_if_in_use(i915)) {
   424  val = intel_rc6_residency_ns(i915, IS_VALLEYVIEW(i915) ?
   425 VLV_GT_RENDER_RC6 :
   426 GEN6_GT_GFX_RC6);
   427  
   428  if (HAS_RC6p(i915))
   429  val += intel_rc6_residency_ns(i915, 
GEN6_GT_GFX_RC6p);
   430  
   431  if (HAS_RC6pp(i915))
   432  val += intel_rc6_residency_ns(i915, 
GEN6_GT_GFX_RC6pp);
   433  
   434  intel_runtime_pm_put(i915);
   435  
   436  /*
   437   * If we are coming back from being runtime suspended 
we must
   438   * be careful not to report a larger value than returned
   439   * previously.
   440   */
   441  
   442  if (!locked)
   443  spin_lock_irqsave(>pmu.lock, flags);
   444  
   445  if (val >= 
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) {
   446  
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
   447  i915->pmu.sample[__I915_SAMPLE_RC6].cur = val;
   448  } else {
   449  val = 
i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
   450  }
   451  
   452  if (!locked)
   453  spin_unlock_irqrestore(>pmu.lock, flags);
   454  } else {
   455  struct pci_dev *pdev = i915->drm.pdev;
   456  struct device *kdev = >dev;
   457  unsigned long flags2;
   458  
   459  /*
   460   * We are runtime suspended.
   461   *
   462   * Report the delta from when the device was suspended 
to now,
   463   * on top of the last known real value, as the 
approximated RC6
   464   * counter value.
   465   */
   466  if (!locked)
   467  spin_lock_irqsave(>pmu.lock, flags);
   468  
   469  spin_lock_irqsave(>power.lock, flags2);
   470  
   471  if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
   472  i915->pmu.suspended_jiffies_last =
 > 473  
 > kdev->power.suspended_jiffies;
   474  
   475  val = kdev->power.suspended_jiffies -
   476i915->pmu.suspended_jiffies_last;
 > 477  val += jiffies - kdev->power.accounting_timestamp;
   478  
   479  spin_unlock_irqrestore(>power.lock, flags2);
   480  
   481  val = jiffies_to_nsecs(val);
   482  val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
   483  i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
   484  
   485  if (!locked)
   486  spin_unlock_irqrestore(>pmu.lock, flags);
   487  }
   488  
   489  return val;
   490  }
   491  

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

[PATCH libdrm] meson: use pkg-config to detect libatomic_ops

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 amdgpu/meson.build| 2 +-
 etnaviv/meson.build   | 2 +-
 freedreno/meson.build | 2 +-
 intel/meson.build | 2 +-
 meson.build   | 3 ++-
 nouveau/meson.build   | 2 +-
 omap/meson.build  | 2 +-
 radeon/meson.build| 2 +-
 tegra/meson.build | 2 +-
 9 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/amdgpu/meson.build b/amdgpu/meson.build
index 8b0452056e2513892c2c..7040ebab86e271022323 100644
--- a/amdgpu/meson.build
+++ b/amdgpu/meson.build
@@ -37,7 +37,7 @@ libdrm_amdgpu = shared_library(
   ],
   include_directories : [inc_root, inc_drm],
   link_with : libdrm,
-  dependencies : dep_pthread_stubs,
+  dependencies : [dep_pthread_stubs, dep_atomic_ops],
   version : '1.0.0',
   install : true,
 )
diff --git a/etnaviv/meson.build b/etnaviv/meson.build
index 1767733bd510efdaad86..ca2aa544c58924a15d8b 100644
--- a/etnaviv/meson.build
+++ b/etnaviv/meson.build
@@ -31,7 +31,7 @@ libdrm_etnaviv = shared_library(
   include_directories : [inc_root, inc_drm],
   link_with : libdrm,
   c_args : warn_c_args,
-  dependencies : [dep_pthread_stubs, dep_rt],
+  dependencies : [dep_pthread_stubs, dep_rt, dep_atomic_ops],
   version : '1.0.0',
   install : true,
 )
diff --git a/freedreno/meson.build b/freedreno/meson.build
index de6a413fa93e63c0ad4a..da993c10355578838f29 100644
--- a/freedreno/meson.build
+++ b/freedreno/meson.build
@@ -44,7 +44,7 @@ libdrm_freedreno = shared_library(
   [files_freedreno, config_file],
   c_args : warn_c_args,
   include_directories : [inc_root, inc_drm],
-  dependencies : [dep_valgrind, dep_pthread_stubs, dep_rt],
+  dependencies : [dep_valgrind, dep_pthread_stubs, dep_rt, dep_atomic_ops],
   link_with : libdrm,
   version : '1.0.0',
   install : true,
diff --git a/intel/meson.build b/intel/meson.build
index ad877274f8d488a80d54..42402f60e38cd5e7359f 100644
--- a/intel/meson.build
+++ b/intel/meson.build
@@ -29,7 +29,7 @@ libdrm_intel = shared_library(
   ],
   include_directories : [inc_root, inc_drm],
   link_with : libdrm,
-  dependencies : [dep_pciaccess, dep_pthread_stubs, dep_rt, dep_valgrind],
+  dependencies : [dep_pciaccess, dep_pthread_stubs, dep_rt, dep_valgrind, 
dep_atomic_ops],
   c_args : warn_c_args,
   version : '1.0.0',
   install : true,
diff --git a/meson.build b/meson.build
index a19e600c7475b2578e2d..f45c14a70baa2456582d 100644
--- a/meson.build
+++ b/meson.build
@@ -51,6 +51,7 @@ cc = meson.get_compiler('c')
 intel_atomics = false
 lib_atomics = false
 
+dep_atomic_ops = dependency('atomic_ops', required : false)
 if cc.compiles('''
 int atomic_add(int *i) { return __sync_add_and_fetch (i, 1); }
 int atomic_cmpxchg(int *i, int j, int k) { return 
__sync_val_compare_and_swap (i, j, k); }
@@ -58,7 +59,7 @@ if cc.compiles('''
 name : 'Intel Atomics')
   intel_atomics = true
   with_atomics = true
-elif cc.has_header('atomic_ops.h')
+elif dep_atomic_ops.found()
   lib_atomics = true
   with_atomics = true
 elif cc.has_function('atomic_cas_uint')
diff --git a/nouveau/meson.build b/nouveau/meson.build
index f031cd63b71bab9f7e7a..b8affd9ef776c99ba896 100644
--- a/nouveau/meson.build
+++ b/nouveau/meson.build
@@ -25,7 +25,7 @@ libdrm_nouveau = shared_library(
   c_args : warn_c_args,
   include_directories : [inc_root, inc_drm],
   link_with : libdrm,
-  dependencies : dep_threads,
+  dependencies : [dep_threads, dep_atomic_ops],
   version : '2.0.0',
   install : true,
 )
diff --git a/omap/meson.build b/omap/meson.build
index 1881087fb0d180b668d3..f89436f0e99970b381aa 100644
--- a/omap/meson.build
+++ b/omap/meson.build
@@ -24,7 +24,7 @@ libdrm_omap = shared_library(
   include_directories : [inc_root, inc_drm],
   c_args : warn_c_args,
   link_with : libdrm,
-  dependencies : [dep_pthread_stubs],
+  dependencies : [dep_pthread_stubs, dep_atomic_ops],
   version : '1.0.0',
   install : true,
 )
diff --git a/radeon/meson.build b/radeon/meson.build
index b02166fe87ea27470e4b..557a878042bb78df4096 100644
--- a/radeon/meson.build
+++ b/radeon/meson.build
@@ -31,7 +31,7 @@ libdrm_radeon = shared_library(
   c_args : warn_c_args,
   include_directories : [inc_root, inc_drm],
   link_with : libdrm,
-  dependencies : [dep_pthread_stubs],
+  dependencies : [dep_pthread_stubs, dep_atomic_ops],
   version : '1.0.1',
   install : true,
 )
diff --git a/tegra/meson.build b/tegra/meson.build
index 99fdd194f50aceb6858b..7ac815177718d301b76c 100644
--- a/tegra/meson.build
+++ b/tegra/meson.build
@@ -23,7 +23,7 @@ libdrm_tegra = shared_library(
   [files('tegra.c'), config_file],
   include_directories : [inc_root, inc_drm],
   link_with : libdrm,
-  dependencies : [dep_pthread_stubs],
+  dependencies : [dep_pthread_stubs, dep_atomic_ops],
   c_args : warn_c_args,
   version : '0.0.0',
   install : true,
-- 
Cheers,
  Eric

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

[PATCH v3 2/3] drm/omap: Add get_ovl_name() and get_mgr_name() to dispc_ops

[Jyri Sarha]

Add get_ovl_name() and get_mgr_name() to dispc_ops and get rid of
adhoc names here and there in the omapdrm code. This moves the names
of hardware entities to omapdss side where they have to be when new
omapdss backend drivers are introduced.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 21 +
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  3 +++
 drivers/gpu/drm/omapdrm/omap_crtc.c   | 11 ++-
 drivers/gpu/drm/omapdrm/omap_irq.c| 19 +++
 drivers/gpu/drm/omapdrm/omap_plane.c  | 13 +++--
 5 files changed, 36 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 4e8f68e..070053f 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -680,6 +680,24 @@ void dispc_runtime_put(void)
WARN_ON(r < 0 && r != -ENOSYS);
 }
 
+static const char *dispc_get_ovl_name(enum omap_plane_id plane)
+{
+   static const char *ovl_names[] = {
+   [OMAP_DSS_GFX]  = "GFX",
+   [OMAP_DSS_VIDEO1]   = "VID1",
+   [OMAP_DSS_VIDEO2]   = "VID2",
+   [OMAP_DSS_VIDEO3]   = "VID3",
+   [OMAP_DSS_WB]   = "WB",
+   };
+
+   return ovl_names[plane];
+}
+
+static const char *dispc_get_mgr_name(enum omap_channel channel)
+{
+   return mgr_desc[channel].name;
+}
+
 static u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
 {
return mgr_desc[channel].vsync_irq;
@@ -4506,6 +4524,9 @@ static void dispc_errata_i734_wa(void)
.get_num_ovls = dispc_get_num_ovls,
.get_num_mgrs = dispc_get_num_mgrs,
 
+   .get_ovl_name = dispc_get_ovl_name,
+   .get_mgr_name = dispc_get_mgr_name,
+
.get_memory_bandwidth_limit = dispc_get_memory_bandwidth_limit,
 
.mgr_enable = dispc_mgr_enable,
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index f8f83e8..d7ed1a4 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -691,6 +691,9 @@ struct dispc_ops {
int (*get_num_ovls)(void);
int (*get_num_mgrs)(void);
 
+   const char *(*get_ovl_name)(enum omap_plane_id plane);
+   const char *(*get_mgr_name)(enum omap_channel channel);
+
u32 (*get_memory_bandwidth_limit)(void);
 
void (*mgr_enable)(enum omap_channel channel, bool enable);
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 1b8154e..fee8a63 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -662,13 +662,6 @@ static void omap_crtc_reset(struct drm_crtc *crtc)
  * Init and Cleanup
  */
 
-static const char *channel_names[] = {
-   [OMAP_DSS_CHANNEL_LCD] = "lcd",
-   [OMAP_DSS_CHANNEL_DIGIT] = "tv",
-   [OMAP_DSS_CHANNEL_LCD2] = "lcd2",
-   [OMAP_DSS_CHANNEL_LCD3] = "lcd3",
-};
-
 void omap_crtc_pre_init(void)
 {
memset(omap_crtcs, 0, sizeof(omap_crtcs));
@@ -696,7 +689,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
channel = out->dispc_channel;
omap_dss_put_device(out);
 
-   DBG("%s", channel_names[channel]);
+   DBG("%s", priv->dispc_ops->get_mgr_name(channel));
 
/* Multiple displays on same channel is not allowed */
if (WARN_ON(omap_crtcs[channel] != NULL))
@@ -711,7 +704,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
init_waitqueue_head(_crtc->pending_wait);
 
omap_crtc->channel = channel;
-   omap_crtc->name = channel_names[channel];
+   omap_crtc->name = priv->dispc_ops->get_mgr_name(channel);
 
ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
_crtc_funcs, NULL);
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 53ba424..b0f6850 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -144,15 +144,10 @@ static void omap_irq_fifo_underflow(struct 
omap_drm_private *priv,
 {
static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
  DEFAULT_RATELIMIT_BURST);
-   static const struct {
-   const char *name;
-   u32 mask;
-   } sources[] = {
-   { "gfx", DISPC_IRQ_GFX_FIFO_UNDERFLOW },
-   { "vid1", DISPC_IRQ_VID1_FIFO_UNDERFLOW },
-   { "vid2", DISPC_IRQ_VID2_FIFO_UNDERFLOW },
-   { "vid3", DISPC_IRQ_VID3_FIFO_UNDERFLOW },
-   };
+   static const u32 irqbits[] = { DISPC_IRQ_GFX_FIFO_UNDERFLOW,
+  DISPC_IRQ_VID1_FIFO_UNDERFLOW,
+  DISPC_IRQ_VID2_FIFO_UNDERFLOW,
+  DISPC_IRQ_VID3_FIFO_UNDERFLOW };
 
const u32 mask = DISPC_IRQ_GFX_FIFO_UNDERFLOW

[PATCH v3 1/3] drm/omap: Fail probe if irq registration fails

[Jyri Sarha]

Call to omap_drm_irq_install() may fail with an error code. In such a
case the driver probe should fail.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 71ea43f..e6e7a2c 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -329,9 +329,9 @@ static int omap_modeset_init(struct drm_device *dev)
 
drm_mode_config_reset(dev);
 
-   omap_drm_irq_install(dev);
+   ret = omap_drm_irq_install(dev);
 
-   return 0;
+   return ret;
 }
 
 /*
-- 
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 v3 3/3] drm/omap: Make omapdss API more generic

[Jyri Sarha]

The new omapdss API is HW independent and cleans up some of the DSS5
specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
register bits and replace them with HW independent generic u64 based
macros. The new macros make it more straight forward to implement the
IRQ code for the future DSS versions that do not share the same
register structure as DSS2 to DSS5 has.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 106 ++
 drivers/gpu/drm/omapdrm/dss/dispc.h   |  33 ++
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  64 --
 drivers/gpu/drm/omapdrm/omap_crtc.c   |  16 +++--
 drivers/gpu/drm/omapdrm/omap_crtc.h   |   2 +-
 drivers/gpu/drm/omapdrm/omap_drv.h|   3 +-
 drivers/gpu/drm/omapdrm/omap_irq.c| 120 +++---
 drivers/gpu/drm/omapdrm/omap_irq.h|   2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c  |   7 ++
 drivers/gpu/drm/omapdrm/omap_plane.h  |   1 +
 10 files changed, 214 insertions(+), 140 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 070053f..4085bea 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -698,27 +698,10 @@ static const char *dispc_get_mgr_name(enum omap_channel 
channel)
return mgr_desc[channel].name;
 }
 
-static u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
+static bool dispc_mgr_has_framedone(enum omap_channel channel)
 {
-   return mgr_desc[channel].vsync_irq;
-}
-
-static u32 dispc_mgr_get_framedone_irq(enum omap_channel channel)
-{
-   if (channel == OMAP_DSS_CHANNEL_DIGIT && dispc.feat->no_framedone_tv)
-   return 0;
-
-   return mgr_desc[channel].framedone_irq;
-}
-
-static u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel)
-{
-   return mgr_desc[channel].sync_lost_irq;
-}
-
-u32 dispc_wb_get_framedone_irq(void)
-{
-   return DISPC_IRQ_FRAMEDONEWB;
+   return channel != OMAP_DSS_CHANNEL_DIGIT ||
+   !dispc.feat->no_framedone_tv;
 }
 
 static void dispc_mgr_enable(enum omap_channel channel, bool enable)
@@ -3604,6 +3587,77 @@ static void dispc_write_irqenable(u32 mask)
dispc_read_reg(DISPC_IRQENABLE);
 }
 
+struct dispc_irq_bit {
+   u32 hw;
+   u64 api;
+};
+
+static const struct dispc_irq_bit dispc_irq_bits[] = {
+   { DISPC_IRQ_OCP_ERR, DSS_IRQ_DEVICE_OCP_ERR },
+
+   { DISPC_IRQ_FRAMEDONE, DSS_IRQ_MGR_FRAME_DONE(0) },
+   { DISPC_IRQ_VSYNC, DSS_IRQ_MGR_VSYNC_EVEN(0) },
+   { DISPC_IRQ_SYNC_LOST, DSS_IRQ_MGR_SYNC_LOST(0) },
+
+   { DISPC_IRQ_EVSYNC_EVEN, DSS_IRQ_MGR_VSYNC_EVEN(1) },
+   { DISPC_IRQ_EVSYNC_ODD, DSS_IRQ_MGR_VSYNC_ODD(1) },
+   { DISPC_IRQ_SYNC_LOST_DIGIT, DSS_IRQ_MGR_SYNC_LOST(1) },
+   { DISPC_IRQ_FRAMEDONETV, DSS_IRQ_MGR_FRAME_DONE(1) },
+
+   { DISPC_IRQ_SYNC_LOST2, DSS_IRQ_MGR_SYNC_LOST(2) },
+   { DISPC_IRQ_VSYNC2, DSS_IRQ_MGR_VSYNC_EVEN(2) },
+   { DISPC_IRQ_FRAMEDONE2, DSS_IRQ_MGR_FRAME_DONE(2) },
+
+   { DISPC_IRQ_SYNC_LOST3, DSS_IRQ_MGR_SYNC_LOST(3) },
+   { DISPC_IRQ_VSYNC3, DSS_IRQ_MGR_VSYNC_EVEN(3) },
+   { DISPC_IRQ_FRAMEDONE3, DSS_IRQ_MGR_FRAME_DONE(3) },
+
+   { DISPC_IRQ_GFX_FIFO_UNDERFLOW, DSS_IRQ_OVL_FIFO_UNDERFLOW(0) },
+   { DISPC_IRQ_VID1_FIFO_UNDERFLOW, DSS_IRQ_OVL_FIFO_UNDERFLOW(1) },
+   { DISPC_IRQ_VID2_FIFO_UNDERFLOW, DSS_IRQ_OVL_FIFO_UNDERFLOW(2) },
+   { DISPC_IRQ_VID3_FIFO_UNDERFLOW, DSS_IRQ_OVL_FIFO_UNDERFLOW(3) },
+};
+
+static u64 dispc_hw_to_api_irq(u32 hw)
+{
+   u64 api = 0;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dispc_irq_bits); i++)
+   if (hw & dispc_irq_bits[i].hw)
+   api |= dispc_irq_bits[i].api;
+
+   return api;
+}
+
+static u32 dispc_api_to_hw_irq(u64 api)
+{
+   u32 hw = 0;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dispc_irq_bits); i++)
+   if (api & dispc_irq_bits[i].api)
+   hw |= dispc_irq_bits[i].hw;
+
+   return hw;
+}
+
+static u64 dispc_api_read_and_clear_irqstatus(void)
+{
+   u32 hw_status = dispc_read_irqstatus();
+
+   dispc_clear_irqstatus(hw_status);
+
+   return dispc_hw_to_api_irq(hw_status);
+}
+
+static void dispc_api_write_irqenable(u64 enable)
+{
+   u32 hw_enable = dispc_api_to_hw_irq(enable);
+
+   dispc_write_irqenable(hw_enable);
+}
+
 void dispc_enable_sidle(void)
 {
REG_FLD_MOD(DISPC_SYSCONFIG, 2, 4, 3);  /* SIDLEMODE: smart idle */
@@ -4453,7 +4507,7 @@ static void dispc_errata_i734_wa_fini(void)
 
 static void dispc_errata_i734_wa(void)
 {
-   u32 framedone_irq = dispc_mgr_get_framedone_irq(OMAP_DSS_CHANNEL_LCD);
+   u32 framedone_irq = DISPC_IRQ_FRAMEDONE;
struct omap_overlay_info ovli;
struct dss_lcd_mgr_config lcd_conf;
u32 gatestate;
@@ -4511,9 +4565,8 @@ static void dispc_errata_i734_wa(void)
 }
 
 static const struct dispc_ops dispc_ops = {

[PATCH v3 0/3] drm/omap: Make omapdss API more generic + related patches

[Jyri Sarha]

Since v2:
- Simplify dispc_mgr_has_framedone() 
- dispc_hw_to_api_irq() and dispc_api_to_hw_irq() use new dispc_irq_bits[]
- rename dispc_ops read_irqstatus() to read_and_clear_irqstatus() and remove
  clearmask
- precalculate priv->irq_uf_mask in omap_drm_irq_install() and use it in
  omap_irq_fifo_underflow()

Here is the v2 round:
https://lists.freedesktop.org/archives/dri-devel/2018-January/161353.html

Since RFC:

This the v2 rouns of a this RFC patch:
https://patchwork.kernel.org/patch/10066245/

The first patch is a simple fix that should be applied in any case.

I did not split the mgr_has_framedone() callback as a separate patch. It
quite literally replaces the mgr_get_framedone_irq() and makes no
sense without the "drm/omap: Make omapdss API more generic"-patch.

Best regards,
  Jyri

Jyri Sarha (3):
  drm/omap: Fail probe if irq registration fails
  drm/omap: Add get_ovl_name() and get_mgr_name() to dispc_ops
  drm/omap: Make omapdss API more generic

 drivers/gpu/drm/omapdrm/dss/dispc.c   | 113 --
 drivers/gpu/drm/omapdrm/dss/dispc.h   |  33 +
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  67 --
 drivers/gpu/drm/omapdrm/omap_crtc.c   |  27 +++-
 drivers/gpu/drm/omapdrm/omap_crtc.h   |   2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c|   4 +-
 drivers/gpu/drm/omapdrm/omap_drv.h|   3 +-
 drivers/gpu/drm/omapdrm/omap_irq.c| 125 +++---
 drivers/gpu/drm/omapdrm/omap_irq.h|   2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c  |  18 ++---
 drivers/gpu/drm/omapdrm/omap_plane.h  |   1 +
 11 files changed, 237 insertions(+), 158 deletions(-)

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

[Rafael J. Wysocki]

On 2/6/2018 10:54 PM, Imre Deak wrote:

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 = 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)
+  

Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node

[Andrzej Hajda]

On 05.02.2018 19:07, Thierry Reding wrote:
> On Mon, Feb 05, 2018 at 06:39:05PM +0100, Lucas Stach wrote:
>> Am Montag, den 05.02.2018, 18:33 +0100 schrieb Thierry Reding:
>>> On Mon, Feb 05, 2018 at 05:11:30PM +0100, Thierry Reding wrote:
 On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
>> Hi Rob,
>>
>> Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
>>> On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
  wrote:
 On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> The i2c adapter on DP AUX is purely a software construct. Linking
> it to the device node of the parent device is wrong, as it leads to
> 2 devices sharing the same device node, which is bad practice, as
 Who says that two devices can't share the same device node? It's done
 all the time.
>>> It's done *some of the time* and I would not consider it best practice.
>>>
> well as the i2c trying to populate children of the i2c adapter by
> looking at the child device nodes of the parent device.
 A set of patches landed in v4.9 to work around this issue in a better
 way. See:

 98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' 
 subnode
 7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode
>>> What does this buy us? I don't see why this needs to be in DT either.
>>> Contrary to popular belief, DT is not the only way to instantiate
>>> devices, C code can still do it.
>>>
>>> Also, if this one line removal has no side effects, then how was it
>>> even needed? We can always add it back if there's some argument for
>>> why it is needed.
>> Okay, so I take this as you mostly agreeing with the rationale of this
>> patch.
> For some general background on this: I was originally using this for DP
> support on Tegra (though that ended up never getting merged because of a
> particularily frustrating episode of trying to get better link training
> support into the core helpers) and use it as a means to obtain the I2C
> controller used for DDC. On Tegra, and I suspect other devices as well,
> the DP AUX controller is separate from the encoder, so the idea was to
> link them together using a standard ddc-i2c-bus phandle.
>
> I ended up not needing that because the encoder and DP AUX controller
> are so tightly linked on Tegra that I need direct access to the DP AUX
> anyway and can therefore directly get the I2C controller from that.
>
> If there aren't any other users of this, I suppose we could simply
> remove the line. Should someone turn up in the future and require the
> I2C controller to be looked up from a phandle we could add it again,
> at which point we'd have to investigate again how to get rid of the
> errors.
>
> Acked-by: Thierry Reding 
 I'm going to have to retract that: I just noticed that this patch breaks
 eDP for Venice2 (and presumably all Tegra124 Nyan boards as well, though
 I don't have those to test with).

 My description above isn't quite correct. For eDP device we do use the
 ddc-i2c-bus property in DT to denote which I2C bus to use for probing
 the EDID. So the reason why eDP now breaks is because the simple-panel
 driver will look for the I2C adapter, not find a matching one and defer
 probe (indefinitely).

 A, perhaps nicer, alternative I found to make it work is the below
 patch. Would that be more reasonable? Looping in Wolfram.

 Thierry
 --- >8 ---
 diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
 index 8d474bb1dc15..f88527a61cd1 100644
 --- a/drivers/i2c/i2c-core-of.c
 +++ b/drivers/i2c/i2c-core-of.c
 @@ -118,6 +118,14 @@ static int of_dev_node_match(struct device *dev, void 
 *data)
>>  return dev->of_node == data;
  }
  
 +static int of_parent_node_match(struct device *dev, void *data)
 +{
>> +if (dev->parent)
>> +return dev->parent->of_node == data;
 +
>> +return 0;
 +}
 +
  /* must call put_device() when done with returned i2c_client device */
  struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
  {
 @@ -143,6 +151,9 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
 device_node *node)
>>  struct i2c_adapter *adapter;
  
>>  dev = bus_find_device(_bus_type, NULL, node, 
>> of_dev_node_match);
>> +if (!dev)
>> +dev = bus_find_device(_bus_type, NULL, node, 
>> of_parent_node_match);
 +
>>  if (!dev)
>>  return NULL;
  
>>> I'd like to point out that 

Re: [PATCH v3 2/3] drm/omap: Add get_ovl_name() and get_mgr_name() to dispc_ops

[Tomi Valkeinen]

On 07/02/18 14:10, Jyri Sarha wrote:
> Add get_ovl_name() and get_mgr_name() to dispc_ops and get rid of
> adhoc names here and there in the omapdrm code. This moves the names
> of hardware entities to omapdss side where they have to be when new
> omapdss backend drivers are introduced.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 21 +
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  3 +++
>  drivers/gpu/drm/omapdrm/omap_crtc.c   | 11 ++-
>  drivers/gpu/drm/omapdrm/omap_irq.c| 19 +++
>  drivers/gpu/drm/omapdrm/omap_plane.c  | 13 +++--
>  5 files changed, 36 insertions(+), 31 deletions(-)

Reviewed-by: Tomi Valkeinen 

-- 
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 0/5] prevent OOM triggered by TTM

[Christian König]

Understood, but why is that?

Well because customers requested it :)

What we try to do here is having a parameter which says when less than x 
megabytes of memory are left then fail the allocation.


This is basically to prevent buggy applications which try to allocate as 
much memory as possible until they receive an -ENOMEM from running into 
the OOM killer.


That's true, but with VRAM, TTM overcommits swap space which may lead 
to ugly memory allocation failures at hibernate time.
Yeah, that is exactly the reason why I said that Roger should disable 
the limit during suspend swap out :)


Regards,
Christian.

Am 07.02.2018 um 14:17 schrieb Thomas Hellstrom:

Hi, Roger.

On 02/07/2018 09:25 AM, He, Roger wrote:
Why should TTM be different in that aspect? It would be good to 
know your reasoning WRT this?


Now, in TTM struct ttm_bo_device it already has member no_retry to 
indicate your option.
If you prefer no OOM triggered by TTM, set it as true. The default is 
false to keep original behavior.

AMD prefers return value of no memory rather than OOM for now.


Understood, but why is that? I mean just because TTM doesn't invoke 
the OOM killer, that doesn't mean that the process will, the next 
millisecond, page in a number of pages and invoke it? So this 
mechanism would be pretty susceptible to races?
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,


I prefer current mechanism of swap out. At the beginning the swapped 
pages stay in system memory by shmem until OS move to status with 
high memory pressure, that has an obvious advantage. For example, if 
the BO is swapped out into shmem, but not really be flushed into swap 
disk. When validate it and swap in it at this moment, the overhead is 
small compared to swap in from disk.


But that is true for a page handed off to the swap-cache as well. It 
won't be immediately flushed to disc, only when the swap cache is shrunk.


In addition, No need swap space reservation for TTM pages when 
allocation since swap disk is shared not only for TTM exclusive.


That's true, but with VRAM, TTM overcommits swap space which may lead 
to ugly memory allocation failures at hibernate time.


So again we provide a flag no_retry in struct ttm_bo_device to let 
driver set according to its request.


Thanks,
Thomas





Thanks
Roger(Hongbo.He)

-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Wednesday, February 07, 2018 2:43 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org

Cc: Koenig, Christian 
Subject: Re: [PATCH 0/5] prevent OOM triggered by TTM

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

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

[Thomas Hellstrom]

Hi, Roger.

On 02/07/2018 09:25 AM, He, Roger wrote:

Why should TTM be different in that aspect? It would be good to know 
your reasoning WRT this?

Now, in TTM struct ttm_bo_device it already has member no_retry to indicate 
your option.
If you prefer no OOM triggered by TTM, set it as true. The default is false to 
keep original behavior.
AMD prefers return value of no memory rather than OOM for now.


Understood, but why is that? I mean just because TTM doesn't invoke the 
OOM killer, that doesn't mean that the process will, the next 
millisecond, page in a number of pages and invoke it? So this mechanism 
would be pretty susceptible to races?

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,

I prefer current mechanism of swap out. At the beginning the swapped pages stay 
in system memory by shmem until OS move to status with high memory pressure, 
that has an obvious advantage. For example, if the BO is swapped out into 
shmem, but not really be flushed into swap disk. When validate it and swap in 
it at this moment, the overhead is small compared to swap in from disk.


But that is true for a page handed off to the swap-cache as well. It 
won't be immediately flushed to disc, only when the swap cache is shrunk.



In addition, No need swap space reservation for TTM pages when allocation since 
swap disk is shared not only for TTM exclusive.


That's true, but with VRAM, TTM overcommits swap space which may lead to 
ugly memory allocation failures at hibernate time.



So again we provide a flag no_retry in struct ttm_bo_device to let driver set 
according to its request.


Thanks,
Thomas





Thanks
Roger(Hongbo.He)

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

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

Re: [PATCH 17/17] drm/dp: Add drm_dp_link_choose() helper

[Jani Nikula]

On Mon, 05 Feb 2018, Thierry Reding  wrote:
> From: Thierry Reding 
>
> This helper chooses an appropriate configuration, according to the
> bitrate requirements of the video mode and the capabilities of the
> DisplayPort sink.
>
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 55 
> +
>  include/drm/drm_dp_helper.h |  5 
>  2 files changed, 60 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index c8b18c0161d7..fb6ee3ebc37d 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -557,6 +557,61 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct 
> drm_dp_link *link)
>  }
>  EXPORT_SYMBOL(drm_dp_link_configure);
>  
> +/**
> + * drm_dp_link_choose() - choose the lowest possible configuration for a mode
> + * @link: DRM DP link object
> + * @mode: DRM display mode
> + * @info: DRM display information
> + *
> + * According to the eDP specification, a source should select a configuration
> + * with the lowest number of lanes and the lowest possible link rate that can
> + * match the bitrate requirements of a video mode. However it must ensure not
> + * to exceed the capabilities of the sink.

Just a couple of notes here:

Recent eDP allows more rates than just the ones mentioned. So you'll
actually have a number of source and sink rates, and you'll have to
intersect them to find the common rates. We have this in i915.

Although the spec says use the "smallest" link parameters possible,
we've found that many panels out in the wild only work at the maximum
sink parameters. Presumably the sink max rate and width correspond to
the native resolution, and not much testing happens using other
parameters. :(


BR,
Jani.


> + *
> + * Returns: 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_choose(struct drm_dp_link *link,
> +const struct drm_display_mode *mode,
> +const struct drm_display_info *info)
> +{
> + /* available link symbol clock rates */
> + static const unsigned int rates[3] = { 162000, 27, 54 };
> + /* available number of lanes */
> + static const unsigned int lanes[3] = { 1, 2, 4 };
> + unsigned long requirement, capacity;
> + unsigned int rate = link->max_rate;
> + unsigned int i, j;
> +
> + /* bandwidth requirement */
> + requirement = mode->clock * info->bpc * 3;
> +
> + for (i = 0; i < ARRAY_SIZE(lanes) && lanes[i] <= link->max_lanes; i++) {
> + for (j = 0; j < ARRAY_SIZE(rates) && rates[j] <= rate; j++) {
> + /*
> +  * Capacity for this combination of lanes and rate,
> +  * factoring in the ANSI 8B/10B encoding.
> +  *
> +  * Link rates in the DRM DP helpers are really link
> +  * symbol frequencies, so a tenth of the actual rate
> +  * of the link.
> +  */
> + capacity = lanes[i] * (rates[j] * 10) * 8 / 10;
> +
> + if (capacity >= requirement) {
> + DRM_DEBUG_KMS("using %u lanes at %u kHz 
> (%lu/%lu kbps)\n",
> +   lanes[i], rates[j], requirement,
> +   capacity);
> + link->lanes = lanes[i];
> + link->rate = rates[j];
> + return 0;
> + }
> + }
> + }
> +
> + return -ERANGE;
> +}
> +EXPORT_SYMBOL(drm_dp_link_choose);
> +
>  /**
>   * drm_dp_downstream_max_clock() - extract branch device max
>   * pixel rate for legacy VGA
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 4c7badcde945..39d134f9a954 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  /*
>   * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
>   * DP and DPCD versions are independent.  Differences from 1.0 are not noted,
> @@ -1194,6 +1196,9 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
> drm_dp_link *link);
>  int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
>  int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
>  int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
> +int drm_dp_link_choose(struct drm_dp_link *link,
> +const struct drm_display_mode *mode,
> +const struct drm_display_info *info);
>  int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>   const u8 port_cap[4]);
>  int 

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

[bugzilla-daemon]

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

--- Comment #13 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) 
---
You can ignore comment 11. I I thought the email reply had not worked. So I
posted a revised version directly. Comment 10 is the correct one.

-- 
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 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

Hi Archit,

Thank you for your review,

On 29/01/18 04:11, Archit Taneja wrote:
> Hi,
> 
> On 01/22/2018 06:20 PM, Kieran Bingham wrote:
>> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
>> ports. Each map has it own I²C address and acts as a standard slave
>> device on the I²C bus.
>>
>> Allow a device tree node to override the default addresses so that
>> address conflicts with other devices on the same bus may be resolved at
>> the board description level.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>   .../bindings/display/bridge/adi,adv7511.txt    | 10 +-
>>   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
>>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 
>> ++
>>   3 files changed, 37 insertions(+), 13 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> index 0047b1394c70..f6bb9f6d3f48 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -70,6 +70,9 @@ Optional properties:
>>     rather than generate its own timings for HDMI output.
>>   - clocks: from common clock binding: reference to the CEC clock.
>>   - clock-names: from common clock binding: must be "cec".
>> +- reg-names : Names of maps with programmable addresses.
>> +    It can contain any map needing a non-default address.
>> +    Possible maps names are : "main", "edid", "cec", "packet"
>>     Required nodes:
>>   @@ -88,7 +91,12 @@ Example
>>     adv7511w: hdmi@39 {
>>   compatible = "adi,adv7511w";
>> -    reg = <39>;
>> +    /*
>> + * The EDID page will be accessible on address 0x66 on the i2c
>> + * bus. All other maps continue to use their default addresses.
>> + */
>> +    reg = <0x39 0x66>;
>> +    reg-names = "main", "edid";
>>   interrupt-parent = <>;
>>   interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
>>   clocks = <_clock>;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> index d034b2cb5eee..7d81ce3808e0 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -53,8 +53,10 @@
>>   #define ADV7511_REG_POWER    0x41
>>   #define ADV7511_REG_STATUS    0x42
>>   #define ADV7511_REG_EDID_I2C_ADDR    0x43
>> +#define ADV7511_REG_EDID_I2C_ADDR_DEFAULT    0x3f
>>   #define ADV7511_REG_PACKET_ENABLE1    0x44   
>>   #define ADV7511_REG_PACKET_I2C_ADDR    0x45
>> +#define ADV7511_REG_PACKET_I2C_ADDR_DEFAULT    0x38
>>   #define ADV7511_REG_DSD_ENABLE    0x46
>>   #define ADV7511_REG_VIDEO_INPUT_CFG2    0x48
>>   #define ADV7511_REG_INFOFRAME_UPDATE    0x4a
>> @@ -89,6 +91,7 @@
>>   #define ADV7511_REG_TMDS_CLOCK_INV    0xde
>>   #define ADV7511_REG_ARC_CTRL    0xdf
>>   #define ADV7511_REG_CEC_I2C_ADDR    0xe1
>> +#define ADV7511_REG_CEC_I2C_ADDR_DEFAULT    0x3c
> 
> Minor comment: The defines above make look like new register
> defines. It would be nice to remove the "REG_" from them, and
> place them somewhere after the register definitions.


Sure.


>>   #define ADV7511_REG_CEC_CTRL    0xe2
>>   #define ADV7511_REG_CHIP_ID_HIGH    0xf5
>>   #define ADV7511_REG_CHIP_ID_LOW    0xf6
>> @@ -322,6 +325,7 @@ struct adv7511 {
>>   struct i2c_client *i2c_main;
>>   struct i2c_client *i2c_edid;
>>   struct i2c_client *i2c_cec;
>> +    struct i2c_client *i2c_packet;
>>     struct regmap *regmap;
>>   struct regmap *regmap_cec;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> index efa29db5fc2b..7ec33837752b 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> @@ -969,8 +969,8 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
>>   {
>>   int ret;
>>   -    adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
>> - adv->i2c_main->addr - 1);
> 
> This patch avoids deriving the CEC/EDID map addresses from the main map. I 
> think
> this would break what the original patch tried to do:

That was intentional.

The ADV7511 data-sheet defines default addresses for these maps.
 (or rather the hardware does)

> 
> d25a4cbba4b9da7c2d674b2f8ecf84af1b24988e
> "drm/bridge: adv7511: add support for the 2nd chip"
> 
> Maybe the default macros can be a function of the main address?

I'm loathed to do that, because then intrinsic knowledge must be known that if I
define a device at address X ... it will also use magic offset A B and C.

IMO - the driver should define the defaults to match the hardware.

Anything else is an override ...





>> +    adv->i2c_cec = 

[PATCH] drm/bochs: make structure bochs_bo_driver static

[Colin King]

From: Colin Ian King 

The structure bochs_bo_driver is local to the source and does not need to
be in global scope, so make it static.

Cleans up sparse warning:
drivers/gpu/drm/bochs/bochs_mm.c:197:22: warning: symbol 'bochs_bo_driver'
was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/bochs/bochs_mm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 704e879711e4..b1d5aee46316 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -194,7 +194,7 @@ static struct ttm_tt *bochs_ttm_tt_create(struct 
ttm_bo_device *bdev,
return tt;
 }
 
-struct ttm_bo_driver bochs_bo_driver = {
+static struct ttm_bo_driver bochs_bo_driver = {
.ttm_tt_create = bochs_ttm_tt_create,
.ttm_tt_populate = ttm_pool_populate,
.ttm_tt_unpopulate = ttm_pool_unpopulate,
-- 
2.15.1

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

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Maxime Ripard]

On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
> > > > Also, how was it tested? This seems quite weird that we haven't caught
> > > > that one sooner, and I'm a bit worried about the possible regressions
> > > > here.
> > > 
> > > It sounds really strange to me too,
> > > because everybody under uboot use "sync:3"(HIGH).
> > > I will retry to measure,
> > > unfortunately at home I don't have a scope,
> > > but I think I'm going to have one soon, because of this. :)
> > 
> > Here I am with scope captures and tcon0 registers dump:
> > tcon0_regs => https://pasteboard.co/H4r8Zcs.png
> > dclk_d0 => https://pasteboard.co/H4r8QRe.png
> > dclk_de => https://pasteboard.co/H4r8zh4R.png
> > dclk_vsnc => https://pasteboard.co/H4r8Hye.png
> > 
> > As you can see circled in reg on registers,
> > TCON0_IO_POL_REG = 0x.
> > But on all the waveforms you can see:
> > - dclk_d0: clock phase is 0, but it starts with falling edge, otherwise
> > the rising front overlaps dclk rising edge(not good), so to me this is
> > falling, then I mean it Negative.
> > - dclk_de: de pulse is clearly negative, even if register is 0 and its'
> > polarity bit is 0.
> > - dclk_vsnc: same as dclk_de
> > - dclk_hsync: I didn't take scope screenshot but I can assure you it's
> > negative.
> > 
> > You can also check all the other registers about TCON0.
> > 
> > Now I proceed testing it on A33, maybe the peripheral is slightly
> > different between Axx SoCs, if I find it that way,
> > it should be only a check about SoC or peripheral ID,
> > and treat polarity as it should be done.
> 
> Here I am with A33 waveforms:
> tcon0_regs => https://pasteboard.co/H4rXfN0M.png
> dclk_d0 => https://pasteboard.co/H4rVXwy.png
> dclk_de => https://pasteboard.co/H4rWDt8.png
> dclk_vsnc => https://pasteboard.co/H4rWRACu.png
> dclk_hsync => https://pasteboard.co/H4rWK6I.png
> 
> It behaves the same way as A20, so as I mean IO polarity,
> all signals(except D0-D23), are inverted.
> For A33 I've used A33-OLinuXino.
> For A20 our LiNova1.

If you have an A33 handy, you probably want to read that mail:
https://lists.freedesktop.org/archives/dri-devel/2017-July/147951.html

Especially the 90-phase part.

Maxime

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


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

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

[He, Roger]

Sure, will make it turn off as default and make the limit configurable.

Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Wednesday, February 07, 2018 4:41 PM
To: He, Roger ; Thomas Hellstrom ; 
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: Re: [PATCH 0/5] prevent OOM triggered by TTM

> AMD prefers return value of no memory rather than OOM for now.
Yeah, but Thomas is right that the default for this feature should be that it 
is turned off.

That's why I said that we should make the limit configurable.

Regards,
Christian.

Am 07.02.2018 um 09:25 schrieb He, Roger:
>   Why should TTM be different in that aspect? It would be good to know 
> your reasoning WRT this?
>
> Now, in TTM struct ttm_bo_device it already has member no_retry to indicate 
> your option.
> If you prefer no OOM triggered by TTM, set it as true. The default is false 
> to keep original behavior.
> AMD prefers return value of no memory rather than OOM for now.
>
>
>
>   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,
>
> I prefer current mechanism of swap out. At the beginning the swapped pages 
> stay in system memory by shmem until OS move to status with high memory 
> pressure, that has an obvious advantage. For example, if the BO is swapped 
> out into shmem, but not really be flushed into swap disk. When validate it 
> and swap in it at this moment, the overhead is small compared to swap in from 
> disk. In addition, No need swap space reservation for TTM pages when 
> allocation since swap disk is shared not only for TTM exclusive.
> So again we provide a flag no_retry in struct ttm_bo_device to let driver set 
> according to its request.
>
>
> Thanks
> Roger(Hongbo.He)
>
> -Original Message-
> From: Thomas Hellstrom [mailto:tho...@shipmail.org]
> Sent: Wednesday, February 07, 2018 2:43 PM
> To: He, Roger ; amd-...@lists.freedesktop.org; 
> dri-devel@lists.freedesktop.org
> Cc: Koenig, Christian 
> Subject: Re: [PATCH 0/5] prevent OOM triggered by TTM
>
> 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

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

[Bug 104989] [r600] [bisected] OpenGL applications can't render anything at all

[bugzilla-daemon]

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

Vlad Golovkin  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

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

[Thierry Reding]

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

I was actually going to suggest the same change. I don't mind if the
name isn't explicit about this being an override. The important thing is
that we document this as being an override.

> 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've thought about that, but I think that'd be putting too much of a
burden on the panel drivers and/or display drivers. In the simplest case
it may be sufficient to restrict the pixel clock, in which case it would
be fairly easy for the driver to adjust the other parameters.

But what if you also need to restrict the porches. At some point it'll
become very difficult for the driver to automatically determine which of
the other parameters to adjust and how. Chances are that whoever needs
to deal with the restrictions already knows how to adjust the parameters
to fixup the mode.

I think this gives us a nice balance of simplicity when people don't
care (they'd just use the typical timings) and flexibility when they do
(adjust the mode to take into account display driver restrictions and
completely specify the mode if the restrictions are too complicated for
code to realistically apply them).

Thierry


signature.asc
Description: PGP signature
___
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/06/2018 03:23 PM, Gerd Hoffmann wrote:

   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?


Both are correct descriptions of typical behaviors. But it isn't spec'ed 
anywhere who has to do the buffer allocation.


In practical terms, the buffer allocation happens in either the 2D GUI 
toolkit (gtk+, for example), or the EGL implementation. Someone using 
this in a real product would most probably be interested in avoiding any 
extra copies and make sure that both allocate buffers via virtio-gpu, for 
example.


Depending on the use case, they could be also interested in supporting 
unmodified clients with an extra copy per buffer presentation.


That's to say that if we cannot come up with a zero-copy solution for 
unmodified clients, we should at least support zero-copy for cooperative 
clients.



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?


Yep.


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.


Yep.


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?


As per the above, the GUI toolkit could have been modified so the client 
directly creates a shareable buffer, and renders directly to it without 
any extra copies.


If clients cannot be modified, then it's the guest proxy what has to 
create the shareable buffer and keep it in sync with the client's 
non-shareable buffer at the right times, by intercepting 
wl_surface.commit messages and copying buffer contents.



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


How can KVM_SET_USER_MEMORY_REGION ever be safely used then? I would have 
expected that callers of that ioctl have enough knowledge to be able to 
choose a physical address that won't conflict with the guest's kernel.


I see that the ivshmem device in QEMU registers the memory region in BAR 
2 of a PCI device instead. Would that be better in your opinion?



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?


The latter: 
https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shm_pool


Regards,

Tomeu
___