[Bug 105883] booting with kernel using amd-staging-drm-next on 2400G hangs

[bugzilla-daemon]

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

--- Comment #7 from Joshua Lee  ---
I'm not sure where the kernel log is on arch. When I add that option to my
kernel command line that you recommended, both my drm-next-staging kernel and
4.16 mainline kernels fail. I have to remove it, then my 4.16 kernel works, but
the drm-next-staging kernel still fails to operate the screen. (The kernel
doesn't crash, as my keyboard still works, I can even press control-alt-delete
to reboot, so I suspect it just isn't using my screen in the amdgpu driver.)

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

Re: [PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

[Keith Packard]

Jason Ekstrand  writes:

> Yeah, I suppose an application could ask for 10k frames in the future or
> something ridiculous like that.  For sync_file, people strongly want a
> finite time guarantee for security/deadlock reasons.  I don't know how
> happy they would be with a finite time of 10 minutes...

Sure, we've put arbitrary finite limits on vblank counters in other
places, so adding some kind of arbitrary limit like a couple of seconds
would be entirely reasonable here. The Vulkan API doesn't need any of
this complexity at all; the one I'm doing only lets you create a fence
for the next vblank.

> Ok, that's not expected... Part of the point of sync objects is that
> they're re-usable.  The client is free to not re-use them or to be very
> careful about the recycling process.

Heh. I thought the opposite -- lightweight objects that you'd use once
and delete. I can certainly change the API to pass in an existing
syncobj rather than creating a new one. That would be easier in some
ways as it reduces the failure paths a bit.

> Is the event the important part or the moderately accurate timestamp?

I need the timestamp and sequence number, getting them in an event would
mean not having to make another syscall.

> We could probably modify drm_syncobj to have a "last signaled"
> timestamp that's queryable through an IOCTL.

That's exactly what I did, but it only works for these new syncobjs. The
fields are global and could be filled in by other bits of the code.

> Is the sequence number returned necessary?  Will it ever be different from
> the one requested?

Yes, when the application queues it just slightly too late.

The application doesn't actually need either of these values directly,
but the system needs them to respond to requests to queue presentation
at a specific time, so the vulkan driver wants 'recent' vblank
time/sequence data to estimate when a vblank will occur.

-- 
-keith


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

Re: [PATCH 1/2 v2] drm/pl111: Support the Versatile Express

[Eric Anholt]

Linus Walleij  writes:

> The Versatile Express uses a special configuration controller
> deeply embedded in the system motherboard FPGA to multiplex the
> two to three (!) CLCD instances out to the single SiI9022
> bridge.
>
> Set up an extra file with the logic to probe to the FPGA mux
> register on the system controller bus, then parse the memory
> range argument to figure out what path the CLCD signal is
> actually taking, and set up the mux accordingly.
>
> If there is a CLCD instance on the core tile (the daughterboard
> with the CPUs fitted) then that CLCD instance will take
> precedence since it can address all memory.
>
> Scale down the Versatile Express to 16BPP so we can support a
> 1024x768 display despite the bus bandwidth restrictions on this
> platform.
>
> Cc: Liviu Dudau 
> Cc: Pawel Moll 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - No changes just reposting rebased on mainline changes.
> ---
>  drivers/gpu/drm/pl111/Makefile  |   1 +
>  drivers/gpu/drm/pl111/pl111_drm.h   |   3 +-
>  drivers/gpu/drm/pl111/pl111_versatile.c |  48 ++-
>  drivers/gpu/drm/pl111/pl111_vexpress.c  | 106 
> 
>  drivers/gpu/drm/pl111/pl111_vexpress.h  |  22 +++
>  5 files changed, 178 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.c
>  create mode 100644 drivers/gpu/drm/pl111/pl111_vexpress.h
>
> diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
> index 9c5e8dba8ac6..19a8189dc54f 100644
> --- a/drivers/gpu/drm/pl111/Makefile
> +++ b/drivers/gpu/drm/pl111/Makefile
> @@ -3,6 +3,7 @@ pl111_drm-y +=pl111_display.o \
>   pl111_versatile.o \
>   pl111_drv.o
>  
> +pl111_drm-$(CONFIG_ARCH_VEXPRESS) += pl111_vexpress.o
>  pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
>  
>  obj-$(CONFIG_DRM_PL111) += pl111_drm.o
> diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
> b/drivers/gpu/drm/pl111/pl111_drm.h
> index 8639b2d4ddf7..916154ac733a 100644
> --- a/drivers/gpu/drm/pl111/pl111_drm.h
> +++ b/drivers/gpu/drm/pl111/pl111_drm.h
> @@ -64,7 +64,8 @@ struct pl111_drm_dev_private {
>   struct drm_bridge *bridge;
>   struct drm_simple_display_pipe pipe;
>  
> - void *regs;
> + void __iomem *clcd_memory;

This doesn't seem to be used anywhere.

> diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c 
> b/drivers/gpu/drm/pl111/pl111_versatile.c
> index 9302f516045e..569edf02a36a 100644
> --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> @@ -1,12 +1,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include "pl111_versatile.h"
> +#include "pl111_vexpress.h"
>  #include "pl111_drm.h"
>  
>  static struct regmap *versatile_syscon_map;
> @@ -22,6 +24,7 @@ enum versatile_clcd {
>   REALVIEW_CLCD_PB11MP,
>   REALVIEW_CLCD_PBA8,
>   REALVIEW_CLCD_PBX,
> + VEXPRESS_CLCD_V2M,
>  };
>  
>  static const struct of_device_id versatile_clcd_of_match[] = {
> @@ -53,6 +56,10 @@ static const struct of_device_id versatile_clcd_of_match[] 
> = {
>   .compatible = "arm,realview-pbx-syscon",
>   .data = (void *)REALVIEW_CLCD_PBX,
>   },
> + {
> + .compatible = "arm,vexpress-muxfpga",
> + .data = (void *)VEXPRESS_CLCD_V2M,
> + },
>   {},
>  };
>  
> @@ -286,12 +293,26 @@ static const struct pl111_variant_data pl111_realview = 
> {
>   .fb_bpp = 16,
>  };
>  
> +/*
> + * Versatile Express PL111 variant, again we just push the maximum
> + * BPP to 16 to be able to get 1024x768 without saturating the memory
> + * bus. The clockdivider also seems broken on the Versatile Express.
> + */
> +static const struct pl111_variant_data pl111_vexpress = {
> + .name = "PL111 Versatile Express",
> + .formats = pl111_realview_pixel_formats,
> + .nformats = ARRAY_SIZE(pl111_realview_pixel_formats),
> + .fb_bpp = 16,
> + .broken_clockdivider = true,
> +};
> +
>  int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private 
> *priv)
>  {
>   const struct of_device_id *clcd_id;
>   enum versatile_clcd versatile_clcd_type;
>   struct device_node *np;
>   struct regmap *map;
> + int ret;
>  
>   np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
>_id);
> @@ -301,7 +322,25 @@ int pl111_versatile_init(struct device *dev, struct 
> pl111_drm_dev_private *priv)
>   }
>   versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
>  
> - map = syscon_node_to_regmap(np);
> + /* Versatile Express special handling */
> + if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
> + struct platform_device *pdev;
> +
> + /* Call into deep Vexpress 

Re: [PATCH 2/2 v2] drm/pl111: Enable device-specific assigned memory

[Eric Anholt]

Linus Walleij  writes:

> The Versatile Express has 8 MB of dedicated video RAM (VRAM)
> on the motherboard, which is what we should be using for the
> PL111 if available. On this platform, the memory backplane
> is constructed so that only this memory will work properly
> with the CLCD on the motherboard, using any other memory
> region just gives random snow on the display.
>
> The CA9 Versatile Express also has a PL111 instance on its
> core tile. This is OK, it has been tested with the motherboard
> VRAM and that works just as fine as regular CMA memory.
>
> The memory is assigned to the device using the memory-region
> device tree property and a "shared-dma-pool" reserved
> memory pool like this:
>
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> vram: vram@4800 {
> compatible = "shared-dma-pool";
> reg = <0x4800 0x0080>;
> no-map;
> };
> };
>
> clcd@1f000 {
> compatible = "arm,pl111", "arm,primecell";
>   (...)
> memory-region = <>;
> }·;
>
> Cc: Liviu Dudau 
> Cc: Mali DP Maintainers 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Make sure to also call of_reserved_mem_device_release() at
>   remove() and errorpath.
> ---
>  drivers/gpu/drm/pl111/pl111_drv.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index 4621259d5387..bc57c15d9fe4 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -60,6 +60,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -257,6 +258,10 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
>   drm->dev_private = priv;
>   priv->variant = variant;
>  
> + ret = of_reserved_mem_device_init(dev);
> + if (!ret)
> + dev_info(dev, "using device-specific reserved memory\n");
> +
>   if (of_property_read_u32(dev->of_node, "max-memory-bandwidth",
>>memory_bw)) {
>   dev_info(dev, "no max memory bandwidth specified, assume 
> unlimited\n");
> @@ -275,7 +280,8 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
>   priv->regs = devm_ioremap_resource(dev, _dev->res);
>   if (IS_ERR(priv->regs)) {
>   dev_err(dev, "%s failed mmio\n", __func__);
> - return PTR_ERR(priv->regs);
> + ret = PTR_ERR(priv->regs);
> + goto mem_rel;
>   }

Shouldn't this error path be jumping to dev_unref, as well?  We're
trying to match drm_dev_alloc(), right?

I'm still a little bothered that we're allowing imports to pl111 of CMA
buffers that we can't scan out.  Could we just refuse all
.gem_prime_import*() on this platform?


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

[Bug 105941] Dolphin emulator crashes a few seconds after playing a game

[bugzilla-daemon]

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

Bug ID: 105941
   Summary: Dolphin emulator crashes a few seconds after playing a
game
   Product: Mesa
   Version: 18.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: eutychio...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

With mesa 18.0.0 and amdgpu module with oland gpu,dolphin-emu crashes.Mesa 18
with radeon module and mesa 17.3.8 with amdgpu module do not crash.

Additional info: tried kernels 4.14 and 4.16,dolphin-emu git and stable,opengl
backend

-- 
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/stm: ltdc: add user update info in plane print state

[Philippe Cornu]

This patch adds the user update information in
frames-per-second into the drm debugfs plane state.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/ltdc.c | 22 ++
 drivers/gpu/drm/stm/ltdc.h |  8 
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 2b745cfc9000..061d2b6e5157 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -729,6 +729,8 @@ static void ltdc_plane_atomic_update(struct drm_plane 
*plane,
reg_update_bits(ldev->regs, LTDC_L1CR + lofs,
LXCR_LEN | LXCR_CLUTEN, val);
 
+   ldev->plane_fpsi[plane->index].counter++;
+
mutex_lock(>err_lock);
if (ldev->error_status & ISR_FUIF) {
DRM_DEBUG_DRIVER("Fifo underrun\n");
@@ -754,6 +756,25 @@ static void ltdc_plane_atomic_disable(struct drm_plane 
*plane,
 oldstate->crtc->base.id, plane->base.id);
 }
 
+static void ltdc_plane_atomic_print_state(struct drm_printer *p,
+ const struct drm_plane_state *state)
+{
+   struct drm_plane *plane = state->plane;
+   struct ltdc_device *ldev = plane_to_ltdc(plane);
+   struct fps_info *fpsi = >plane_fpsi[plane->index];
+   int ms_since_last;
+   ktime_t now;
+
+   now = ktime_get();
+   ms_since_last = ktime_to_ms(ktime_sub(now, fpsi->last_timestamp));
+
+   drm_printf(p, "\tuser_updates=%dfps\n",
+  DIV_ROUND_CLOSEST(fpsi->counter * 1000, ms_since_last));
+
+   fpsi->last_timestamp = now;
+   fpsi->counter = 0;
+}
+
 static const struct drm_plane_funcs ltdc_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -761,6 +782,7 @@ static const struct drm_plane_funcs ltdc_plane_funcs = {
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+   .atomic_print_state = ltdc_plane_atomic_print_state,
 };
 
 static const struct drm_plane_helper_funcs ltdc_plane_helper_funcs = {
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 61a80d00bc3b..1e16d6afb0d2 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -20,6 +20,13 @@ struct ltdc_caps {
bool non_alpha_only_l1; /* non-native no-alpha formats on layer 1 */
 };
 
+#define LTDC_MAX_LAYER 4
+
+struct fps_info {
+   unsigned int counter;
+   ktime_t last_timestamp;
+};
+
 struct ltdc_device {
void __iomem *regs;
struct clk *pixel_clk;  /* lcd pixel clock */
@@ -27,6 +34,7 @@ struct ltdc_device {
struct ltdc_caps caps;
u32 error_status;
u32 irq_status;
+   struct fps_info plane_fpsi[LTDC_MAX_LAYER];
 };
 
 int ltdc_load(struct drm_device *ddev);
-- 
2.15.1

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

[PATCH] drm/stm: move enable/disable_vblank to crtc

[Philippe Cornu]

enable/disable_vblank() functions at drm_driver level
are deprecated. Move them to the ltdc drm_crtc_funcs
structure.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/drv.c  |  2 --
 drivers/gpu/drm/stm/ltdc.c | 10 ++
 drivers/gpu/drm/stm/ltdc.h |  2 --
 3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 9ab00a87f7cc..8698e08313e1 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -72,8 +72,6 @@ static struct drm_driver drv_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .enable_vblank = ltdc_crtc_enable_vblank,
-   .disable_vblank = ltdc_crtc_disable_vblank,
 };
 
 static int drv_load(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 1a3277e483d5..2b745cfc9000 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -569,9 +569,9 @@ static const struct drm_crtc_helper_funcs 
ltdc_crtc_helper_funcs = {
.atomic_disable = ltdc_crtc_atomic_disable,
 };
 
-int ltdc_crtc_enable_vblank(struct drm_device *ddev, unsigned int pipe)
+static int ltdc_crtc_enable_vblank(struct drm_crtc *crtc)
 {
-   struct ltdc_device *ldev = ddev->dev_private;
+   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
 
DRM_DEBUG_DRIVER("\n");
reg_set(ldev->regs, LTDC_IER, IER_LIE);
@@ -579,9 +579,9 @@ int ltdc_crtc_enable_vblank(struct drm_device *ddev, 
unsigned int pipe)
return 0;
 }
 
-void ltdc_crtc_disable_vblank(struct drm_device *ddev, unsigned int pipe)
+static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc)
 {
-   struct ltdc_device *ldev = ddev->dev_private;
+   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
 
DRM_DEBUG_DRIVER("\n");
reg_clear(ldev->regs, LTDC_IER, IER_LIE);
@@ -594,6 +594,8 @@ static const struct drm_crtc_funcs ltdc_crtc_funcs = {
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+   .enable_vblank = ltdc_crtc_enable_vblank,
+   .disable_vblank = ltdc_crtc_disable_vblank,
.gamma_set = drm_atomic_helper_legacy_gamma_set,
 };
 
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index edb268129c54..61a80d00bc3b 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -29,8 +29,6 @@ struct ltdc_device {
u32 irq_status;
 };
 
-int ltdc_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe);
-void ltdc_crtc_disable_vblank(struct drm_device *dev, unsigned int pipe);
 int ltdc_load(struct drm_device *ddev);
 void ltdc_unload(struct drm_device *ddev);
 
-- 
2.15.1

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

[Bug 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when run under Wine

[bugzilla-daemon]

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

--- Comment #10 from QwertyChouskie  ---
Can confirm TrackMania Nations Forever is fixed in 18.0-rc5.

-- 
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 105911] DVI-D monitor connected to DVI-I output not detected (regression from kernel 4.14.32 to kernel 4.16.0 using graphic core)

[bugzilla-daemon]

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

--- Comment #10 from Matthias Nagel  ---
Created attachment 138677
  --> https://bugs.freedesktop.org/attachment.cgi?id=138677=edit
dmesg output of kernel 4.16.0 with dc_log=1

Created new dmesg with amdgpu.dc_log=1, but I do not see any changes in output.

And there no kernel message, if I plug/unplug the monitor.

-- 
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 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

[bugzilla-daemon]

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

Nico Sneck (nicosn...@hotmail.com) changed:

   What|Removed |Added

 CC||nicosn...@hotmail.com

--- Comment #52 from Nico Sneck (nicosn...@hotmail.com) ---
I have this same issue, with an Asus K73TK laptop. It has an A6-3420M-APU and a
7670M dGPU.

On boot these appear in dmesg:

[   27.436081] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for
more than 5secs aborting
[   27.436195] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing CE9C (len 62, WS 0, PS 0) @ 0xCEB8
[   27.436307] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing BB9C (len 1036, WS 4, PS 0) @ 0xBC99
[   27.436420] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing BB32 (len 76, WS 0, PS 8) @ 0xBB3A
[   27.436740] [drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume
failed
[   29.148572] [drm] PCIE GART of 1024M enabled (table at 0x00162000).
[   29.370027] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0x)
[   29.370149] [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed
on resume
[   29.370321] [drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume
failed
[   34.372053] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for
more than 5secs aborting
[   34.372115] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing C546 (len 1136, WS 0, PS 0) @ 0xC570

Adding a PX quirk for this device worked, and booting happens without errors
now.
I'll send the patch to amd-gfx.

-- 
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 199229] choppy cursor on ryzen 5 2400g

[bugzilla-daemon]

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

david becerra (davidbecerrapor...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #2 from david becerra (davidbecerrapor...@gmail.com) ---
issue is fixed on 4.16.0, closing

-- 
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] media: omapfb: relax compilation if COMPILE_TEST

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Friday, 6 April 2018 18:33:20 EEST Mauro Carvalho Chehab wrote:
> The dependency of DRM_OMAP = n can be relaxed for just
> compilation test.
> 
> This allows building the omap3isp driver with allyesconfig
> on ARM.

omapfb has nothing to do with omap3isp. I assume you meant omap_vout.

There's a reason why both DRM_OMAP and FB_OMAP2 can't be compiled at the same 
time, they export identical symbols. I believe you will end up with link 
failures if you do so.

> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/video/fbdev/omap2/omapfb/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig
> b/drivers/video/fbdev/omap2/omapfb/Kconfig index e6226aeed17e..e42794a5e26c
> 100644
> --- a/drivers/video/fbdev/omap2/omapfb/Kconfig
> +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
> @@ -4,7 +4,7 @@ config OMAP2_VRFB
>  menuconfig FB_OMAP2
>  tristate "OMAP2+ frame buffer support"
>  depends on FB
> -depends on DRM_OMAP = n
> +depends on DRM_OMAP = n || COMPILE_TEST
> 
>  select FB_OMAP2_DSS
>   select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3

-- 
Regards,

Laurent Pinchart



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

[Bug 104391] DC R9 285 HDMI audio regression since drm/amd/display: try to find matching audio inst for enc inst first

[bugzilla-daemon]

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

--- Comment #3 from Andy Furniss  ---
Thanks, I'll close when the fix makes it into something public.

Current agd5f drm-next-4.18-wip still has the issue.

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

Re: [PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Laurent Pinchart]

Hi Jacopo,

On Saturday, 7 April 2018 12:45:56 EEST jacopo mondi wrote:
> On Fri, Apr 06, 2018 at 06:40:14PM +0300, Laurent Pinchart wrote:
> > Hi Jacopo,
> > 
> > (CC'ing Mark Brown)
> 
> Hi Mark
> 
> [snip]
> 
> >> Anyway, we spent enough time on naming issues, starting from my first
> >> stupid 'pdwn' permutations then on this semi-standard names.
> >> 
> >> I'll send next version with 'powerdown-gpios' and 'oe-gpios'
> >> properties hoping that would be finally accepted by everyone.
> > 
> > I certainly won't complain (as long as you write pwdn instead of pdwn in
> > the driver :-)).
> 
> Oh, so you won't complain if I address your comments? Thank you! :D
> By the way, the dumb pdwn name comes, again, from the chip name. I can
> change it to a saner name for sure...

And I've just realized that, I thought it was a typo :-/ If it comes with the 
datasheet I'm fine with either.

> >> Same on the mandatory/optional VCC supply thing. Let's try to make
> >> next version the final one. If the optional property with the dummy
> >> regulator doesn't satisfy you and it is preferred to have a
> >> fixed-regulator anyhow in DT I'll do in next version, othewise let's try
> >> not to change it again. I'll just remark here that in the current Eagle
> >> design vcc is connected to a power rail with no regulator at all :)
> > 
> > I don't like the dummy regulator much, as it generates a dev_warn(), which
> > makes me believe that it's a hack rather than a proper solution. You might
> > want to ask Mark Brown for his opinion.
> 
> Sure: Hi Mark, a bit of context here to save you a long(er) reading.
> 
> Unsurprisingly, the chip for which I'm writing this small driver needs
> a power supply to be properly functional :) In the development board
> it is installed on, the power supply is connected to a power rail,
> with no regulator. At the same time, some other designs may instead
> include a regulator.

To be precise, with an always-on regulator that can't be software-controlled.

> I assume that's a very common situation. I started by describing the
> regulator as optional in DT bindings, and use regulator_get_optional(). If
> that function returns PTR_ERR, the regulator is then ignored in driver's
> power management routines.
> 
> In this last version I thought I was acting smart and copied what happens
> in other DRM bridges like adv7511, which use 'regulator_get()' and work
> with a dummy if no regulator is provided in DT. Laurent has the above
> doubts on using a dummy, and I actually share some of his concerns
> (that dev_warn() is how I found out adv7511 was using a dummy, actually).
> 
> To sum up: when a regulator is described as optional in DT, do you
> suggest to work with a dummy if it's not there, or use the _optional()
> version of regulator_get() and manually set it to NULL and ignore it
> in the enable/disable driver's routines?
> 
> Bonus question: Laurent likes to have the regulator described as required,
> and thus require it to be described in DT also in cases where it is not
> actually there using a 'fixed-regulator' and refuse to probe if the
> regulator is not available. Do you encourage this approach, or prefer to
> have it optional and handle it in the driver in one of the above described
> ways?

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Laurent


On Fri, Apr 06, 2018 at 06:40:14PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> (CC'ing Mark Brown)

Hi Mark

[snip]
> >
> > Anyway, we spent enough time on naming issues, starting from my first
> > stupid 'pdwn' permutations then on this semi-standard names.
> >
> > I'll send next version with 'powerdown-gpios' and 'oe-gpios'
> > properties hoping that would be finally accepted by everyone.
>
> I certainly won't complain (as long as you write pwdn instead of pdwn in the
> driver :-)).
>

Oh, so you won't complain if I address your comments? Thank you! :D
By the way, the dumb pdwn name comes, again, from the chip name. I can
change it to a saner name for sure...

> > Same on the mandatory/optional VCC supply thing. Let's try to make
> > next version the final one. If the optional property with the dummy
> > regulator doesn't satisfy you and it is preferred to have a fixed-regulator
> > anyhow in DT I'll do in next version, othewise let's try not to change
> > it again. I'll just remark here that in the current Eagle design vcc is
> > connected to a power rail with no regulator at all :)
>
> I don't like the dummy regulator much, as it generates a dev_warn(), which
> makes me believe that it's a hack rather than a proper solution. You might
> want to ask Mark Brown for his opinion.
>

Sure: Hi Mark, a bit of context here to save you a long(er) reading.

Unsurprisingly, the chip for which I'm writing this small driver needs
a power supply to be properly functional :) In the development board
it is installed on, the power supply is connected to a power rail,
with no regulator. At the same time, some other designs may instead
include a regulator. I assume that's a very common situation. I
started by describing the regulator as optional in DT bindings, and
use regulator_get_optional(). If that function returns PTR_ERR, the
regulator is then ignored in driver's power management routines.

In this last version I thought I was acting smart and copied what happens
in other DRM bridges like adv7511, which use 'regulator_get()' and work
with a dummy if no regulator is provided in DT. Laurent has the above
doubts on using a dummy, and I actually share some of his concerns
(that dev_warn() is how I found out adv7511 was using a dummy, actually).

To sum up: when a regulator is described as optional in DT, do you
suggest to work with a dummy if it's not there, or use the _optional()
version of regulator_get() and manually set it to NULL and ignore it
in the enable/disable driver's routines?

Bonus question: Laurent likes to have the regulator described as required,
and thus require it to be described in DT also in cases where it is not
actually there using a 'fixed-regulator' and refuse to probe if the regulator
is not available. Do you encourage this approach, or prefer to have it
optional and handle it in the driver in one of the above described
ways?

Thank you
j


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

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Hans de Goede]

Hi,

On 06-04-18 18:06, Ville Syrjälä wrote:

On Thu, Apr 05, 2018 at 01:37:31PM +0200, Hans de Goede wrote:

Hi,

On 04-04-18 22:49, Ville Syrjälä wrote:

On Wed, Apr 04, 2018 at 10:06:29PM +0200, Hans de Goede wrote:

Hi,

On 04-04-18 17:50, Ville Syrjälä wrote:

On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote:

Hi,

On 30-03-18 15:25, Hans de Goede wrote:

Hi,

On 30-03-18 14:44, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:37:40)

Hi,

On 30-03-18 14:30, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:27:15)

Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).


We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)


Yet the GOP is happily using the first page. I think we may need to make
a difference here between the GPU not using the first page and the
display engine/pipeline not using the first page. Note that my patch
only influences the inheriting of the initial framebuffer as allocated
by the GOP. It does not influence any other allocations from the
reserved range, those will still all avoid the first page.

Without this patch fastboot / flickerfree support is essentially broken
on any gen8+ hardware given that one of the goals of atomic is to be
able to do flickerfree transitions I think that this warrants a closer
look then just simply saying never use the first page.


The concern is what else (i.e. nothing that we allocated ourselves) that
may be in the first page...


Given that the GOP has put its framebuffer there at least at boot there
is nothing there, otherwise it would show up on the display.

We have a whole bunch of code to inherit the BIOS fb in intel_display.c
and AFAIK that code is there because this inheriting the BIOS fb is
deemed an important feature. So I'm not happy at all with the handwavy
best to not touch it answer I'm getting to this patch.

Unless there are some clear answer from the hardware folks which specifically
say we cannot put a framebuffer there (and then why is the GOP doing it?)
then I believe that the best way forward here is to get various people to
test with this patch and the best way to do that is probably to put it
in next. Note I deliberately did not add a Cc stable.


To elaborate on this, the excluding of the first 4k of the stolen memory
region causes intel_alloc_initial_plane_obj() from intel_display.c to fail,
which in turn causes intel_find_initial_plane_obj() to call
intel_plane_disable_noatomic(intel_crtc, intel_plane); which temporarily
completely turns off the display which leads to a very ugly flickering
of the display at boot (as well as replacing the vendor logo with a
black screen).

I think we can all agree that this behavior is undesirable and even a
regression in behavior caused by the fix to exclude the first 4k.

Chris, if my patch is not an acceptable way to fix this, then how do you
suggest that we fix this?

Digging a bit deeper I found this:

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol16-workarounds.pdf

Which says:

"WaSkipStolenMemoryFirstPage:

WA to skip the first page of stolen
memory due to sporadic HW write on *CS Idle"

And also about FBC:

"First line of FBC getting corrupted when FBC
compressed frame buffer offset is programmed to
zero. Command streamers are doing flush writes to
base of stolen.
WA: New restriction to program FBC compressed
frame buffer offset to at least 4KB."

So using the 

[DPU PATCH 2/2] drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY

[Abhinav Kumar]

Currently the DSI PHY timings are hard-coded for a specific panel
for the 10nm PHY.

Replace this with the auto PHY timing calculator which can calculate
the PHY timings for any panel.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 111 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   2 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c |  28 
 3 files changed, 113 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8e9d5c2..5b42885 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -265,6 +265,117 @@ int msm_dsi_dphy_timing_calc_v2(struct 
msm_dsi_dphy_timing *timing,
return 0;
 }
 
+int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing *timing,
+  struct msm_dsi_phy_clk_request *clk_req)
+{
+   const unsigned long bit_rate = clk_req->bitclk_rate;
+   const unsigned long esc_rate = clk_req->escclk_rate;
+   s32 ui, ui_x8, lpx;
+   s32 tmax, tmin;
+   s32 pcnt0 = 50;
+   s32 pcnt1 = 50;
+   s32 pcnt2 = 10;
+   s32 pcnt3 = 30;
+   s32 pcnt4 = 10;
+   s32 pcnt5 = 2;
+   s32 coeff = 1000; /* Precision, should avoid overflow */
+   s32 hb_en, hb_en_ckln;
+   s32 temp;
+
+   if (!bit_rate || !esc_rate)
+   return -EINVAL;
+
+   timing->hs_halfbyte_en = 0;
+   hb_en = 0;
+   timing->hs_halfbyte_en_ckln = 0;
+   hb_en_ckln = 0;
+
+   ui = mult_frac(NSEC_PER_MSEC, coeff, bit_rate / 1000);
+   ui_x8 = ui << 3;
+   lpx = mult_frac(NSEC_PER_MSEC, coeff, esc_rate / 1000);
+
+   temp = S_DIV_ROUND_UP(38 * coeff, ui_x8);
+   tmin = max_t(s32, temp, 0);
+   temp = (95 * coeff) / ui_x8;
+   tmax = max_t(s32, temp, 0);
+   timing->clk_prepare = linear_inter(tmax, tmin, pcnt0, 0, false);
+
+
+   temp = 300 * coeff - (timing->clk_prepare << 3) * ui;
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = (tmin > 255) ? 511 : 255;
+   timing->clk_zero = linear_inter(tmax, tmin, pcnt5, 0, false);
+
+   tmin = DIV_ROUND_UP(60 * coeff + 3 * ui, ui_x8);
+   temp = 105 * coeff + 12 * ui - 20 * coeff;
+   tmax = (temp + 3 * ui) / ui_x8;
+   timing->clk_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
+
+   temp = S_DIV_ROUND_UP(40 * coeff + 4 * ui, ui_x8);
+   tmin = max_t(s32, temp, 0);
+   temp = (85 * coeff + 6 * ui) / ui_x8;
+   tmax = max_t(s32, temp, 0);
+   timing->hs_prepare = linear_inter(tmax, tmin, pcnt1, 0, false);
+
+   temp = 145 * coeff + 10 * ui - (timing->hs_prepare << 3) * ui;
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 255;
+   timing->hs_zero = linear_inter(tmax, tmin, pcnt4, 0, false);
+
+   tmin = DIV_ROUND_UP(60 * coeff + 4 * ui, ui_x8) - 1;
+   temp = 105 * coeff + 12 * ui - 20 * coeff;
+   tmax = (temp / ui_x8) - 1;
+   timing->hs_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
+
+   temp = 50 * coeff + ((hb_en << 2) - 8) * ui;
+   timing->hs_rqst = S_DIV_ROUND_UP(temp, ui_x8);
+
+   tmin = DIV_ROUND_UP(100 * coeff, ui_x8) - 1;
+   tmax = 255;
+   timing->hs_exit = linear_inter(tmax, tmin, pcnt2, 0, false);
+
+   temp = 50 * coeff + ((hb_en_ckln << 2) - 8) * ui;
+   timing->hs_rqst_ckln = S_DIV_ROUND_UP(temp, ui_x8);
+
+   temp = 60 * coeff + 52 * ui - 43 * ui;
+   tmin = DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 63;
+   timing->shared_timings.clk_post =
+   linear_inter(tmax, tmin, pcnt2, 0, false);
+
+   temp = 8 * ui + (timing->clk_prepare << 3) * ui;
+   temp += (((timing->clk_zero + 3) << 3) + 11) * ui;
+   temp += hb_en_ckln ? (((timing->hs_rqst_ckln << 3) + 4) * ui) :
+   (((timing->hs_rqst_ckln << 3) + 8) * ui);
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 63;
+   if (tmin > tmax) {
+   temp = linear_inter(tmax << 1, tmin, pcnt2, 0, false);
+   timing->shared_timings.clk_pre = temp >> 1;
+   timing->shared_timings.clk_pre_inc_by_2 = 1;
+   } else {
+   timing->shared_timings.clk_pre =
+   linear_inter(tmax, tmin, pcnt2, 0, false);
+   timing->shared_timings.clk_pre_inc_by_2 = 0;
+   }
+
+   timing->ta_go = 3;
+   timing->ta_sure = 0;
+   timing->ta_get = 4;
+
+   DBG("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d",
+   timing->shared_timings.clk_pre, timing->shared_timings.clk_post,
+   timing->shared_timings.clk_pre_inc_by_2, timing->clk_zero,
+   timing->clk_trail, timing->clk_prepare, timing->hs_exit,
+   timing->hs_zero, timing->hs_prepare, timing->hs_trail,
+   timing->hs_rqst, timing->hs_rqst_ckln, timing->hs_halfbyte_en,
+   

[DPU PATCH 1/2] drm/msm/dsi: check video mode engine status before waiting

[Abhinav Kumar]

Make sure the video mode engine is on before waiting
for the video done interrupt.

Otherwise it leads to silent timeouts increasing display
turn ON time.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7a03a94..24766c3 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -173,6 +173,7 @@ struct msm_dsi_host {
 
bool registered;
bool power_on;
+   bool enabled;
int irq;
 };
 
@@ -986,13 +987,18 @@ static void dsi_set_tx_power_mode(int mode, struct 
msm_dsi_host *msm_host)
 
 static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
 {
+   u32 ret = 0;
+
dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);
 
reinit_completion(_host->video_comp);
 
-   wait_for_completion_timeout(_host->video_comp,
+   ret = wait_for_completion_timeout(_host->video_comp,
msecs_to_jiffies(70));
 
+   if (ret <= 0)
+   pr_err("wait for video done failed\n");
+
dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 0);
 }
 
@@ -1001,7 +1007,7 @@ static void dsi_wait4video_eng_busy(struct msm_dsi_host 
*msm_host)
if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
return;
 
-   if (msm_host->power_on) {
+   if (msm_host->power_on && msm_host->enabled) {
dsi_wait4video_done(msm_host);
/* delay 4 ms to skip BLLP */
usleep_range(2000, 4000);
@@ -2203,7 +2209,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host *host)
 *  pm_runtime_put_autosuspend(_host->pdev->dev);
 * }
 */
-
+   msm_host->enabled = true;
return 0;
 }
 
@@ -2219,7 +2225,7 @@ int msm_dsi_host_disable(struct mipi_dsi_host *host)
 * Reset to disable video engine so that we can send off cmd.
 */
dsi_sw_reset(msm_host);
-
+   msm_host->enabled = false;
return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[DPU PATCH 2/2] drm/panel: add backlight control support for truly panel

[Abhinav Kumar]

Register truly panel as a backlight led device and
provide methods to control its backlight operation.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/panel/panel-truly-dual-dsi.c | 96 +++-
 1 file changed, 94 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-truly-dual-dsi.c 
b/drivers/gpu/drm/panel/panel-truly-dual-dsi.c
index 47891ee..5d0ef90 100644
--- a/drivers/gpu/drm/panel/panel-truly-dual-dsi.c
+++ b/drivers/gpu/drm/panel/panel-truly-dual-dsi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -23,6 +24,9 @@
 #include 
 #include 
 
+#define BL_NODE_NAME_SIZE 32
+#define PRIM_DISPLAY_NODE 0
+
 struct truly_wqxga {
struct device *dev;
struct drm_panel panel;
@@ -33,6 +37,8 @@ struct truly_wqxga {
struct gpio_desc *mode_gpio;
 
struct backlight_device *backlight;
+   /* WLED params */
+   struct led_trigger *wled;
struct videomode vm;
 
struct mipi_dsi_device *dsi[2];
@@ -447,6 +453,83 @@ static void truly_wqxga_panel_del(struct truly_wqxga *ctx)
put_device(>dsi[1]->dev);
 }
 
+static int truly_backlight_device_update_status(struct backlight_device *bd)
+{
+   int brightness;
+   int max_brightness;
+   int rc = 0;
+
+   struct truly_wqxga *ctx = dev_get_drvdata(>dev);
+
+   brightness = bd->props.brightness;
+   max_brightness = bd->props.max_brightness;
+
+   if ((bd->props.power != FB_BLANK_UNBLANK) ||
+   (bd->props.state & BL_CORE_FBBLANK) ||
+ (bd->props.state & BL_CORE_SUSPENDED))
+   brightness = 0;
+
+   if (brightness > max_brightness)
+   brightness = max_brightness;
+
+   /* Need to check WLED driver capability upstream */
+   if (ctx && ctx->wled)
+   led_trigger_event(ctx->wled, brightness);
+
+   return rc;
+}
+
+static int truly_backlight_device_get_brightness(struct backlight_device *bd)
+{
+   return bd->props.brightness;
+}
+
+static const struct backlight_ops truly_backlight_device_ops = {
+   .update_status = truly_backlight_device_update_status,
+   .get_brightness = truly_backlight_device_get_brightness,
+};
+
+static int truly_backlight_setup(struct truly_wqxga *ctx)
+{
+   struct backlight_properties props;
+   char bl_node_name[BL_NODE_NAME_SIZE];
+
+   if (!ctx) {
+   dev_err(ctx->dev, "invalid context\n");
+   return -EINVAL;
+   }
+
+   if (!ctx->backlight) {
+   memset(, 0, sizeof(props));
+   props.type = BACKLIGHT_RAW;
+   props.power = FB_BLANK_UNBLANK;
+   props.max_brightness = 4096;
+
+   snprintf(bl_node_name, BL_NODE_NAME_SIZE, "panel%u-backlight",
+PRIM_DISPLAY_NODE);
+
+   ctx->backlight =  backlight_device_register(bl_node_name,
+   ctx->dev, ctx,
+   _backlight_device_ops, );
+
+   if (IS_ERR_OR_NULL(ctx->backlight)) {
+   pr_err("Failed to register backlight\n");
+   ctx->backlight = NULL;
+   return -ENODEV;
+   }
+
+   /* Register with the LED driver interface */
+   led_trigger_register_simple("bkl-trigger", >wled);
+
+   if (!ctx->wled) {
+   pr_err("backlight led registration failed\n");
+   return -ENODEV;
+   }
+   }
+
+   return 0;
+}
+
 static int truly_wqxga_probe(struct mipi_dsi_device *dsi)
 {
struct device *dev = >dev;
@@ -466,10 +549,11 @@ static int truly_wqxga_probe(struct mipi_dsi_device *dsi)
secondary = of_find_mipi_dsi_device_by_node(np);
of_node_put(np);
 
+   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+
if (!secondary)
return -EPROBE_DEFER;
 
-   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
put_device(>dev);
return -ENOMEM;
@@ -485,6 +569,12 @@ static int truly_wqxga_probe(struct mipi_dsi_device *dsi)
put_device(>dev);
return ret;
}
+
+   ret = truly_backlight_setup(ctx);
+   if (ret) {
+   put_device(>dev);
+   return ret;
+   }
}
 
ret = mipi_dsi_attach(dsi);
@@ -504,8 +594,10 @@ static int truly_wqxga_remove(struct mipi_dsi_device *dsi)
mipi_dsi_detach(dsi);
 
/* delete panel only for the DSI1 interface */
-   if (ctx)
+   if (ctx) {
truly_wqxga_panel_del(ctx);
+   kfree(ctx);
+   }
 
return 0;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member 

[DPU PATCH 1/2] drm/panel: Add Truly Dual DSI video mode panel

[Abhinav Kumar]

From: Archit Taneja 

Add support for truly dual DSI video mode panel
panel used in MSM reference platforms.

Signed-off-by: Archit Taneja 
Signed-off-by: Abhinav Kumar 
---
 .../bindings/display/truly,dual_wqxga.txt  |  47 ++
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-truly-dual-dsi.c   | 530 +
 4 files changed, 585 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
 create mode 100644 drivers/gpu/drm/panel/panel-truly-dual-dsi.c

diff --git a/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt 
b/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
new file mode 100644
index 000..a1b24c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/truly,dual_wqxga.txt
@@ -0,0 +1,47 @@
+Truly model NT35597 1440x2560 DSI Panel
+
+Required properties:
+- compatible: should be "truly,dual_wqxga"
+- vdda-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply
+- lab-supply: phandle of the regulator that provides the supply voltage
+  for LCD bias
+- ibb-supply: phandle of the regulator that provides the supply voltage
+  for LCD bias
+- reset-gpios: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
+- mode-gpios: phandle of the gpio for choosing the mode of the display
+  for single DSI or Dual DSI
+- display-timings: Node for the Panel timings
+- link2: phandle to the secondary node of the panel
+
+Example:
+
+   dsi@ae94000 {
+   panel@0 {
+   compatible = "truly,dual_wqxga";
+   reg = <0>;
+   link2 = <>;
+   vdda-supply = <_l14>;
+
+   pinctrl-names = "default", "suspend";
+   pinctrl-0 = <_dsi_active>;
+   pinctrl-1 = <_dsi_suspend>;
+
+   reset-gpios = < 6 0>;
+   mode-gpios = < 52 0>;
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <268316138>;
+   hactive = <1440>;
+   vactive = <2560>;
+   hfront-porch = <200>;
+   hback-porch = <64>;
+   hsync-len = <32>;
+   vfront-porch = <8>;
+   vback-porch = <7>;
+   vsync-len = <1>;
+   };
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 988048e..a63c3f7 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -168,4 +168,11 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
 
+config DRM_PANEL_TRULY_WQXGA
+   tristate "Truly WQXGA"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Truly WQXGA Dual DSI
+ Video Mode panel
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3d2a88d..64891f6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TRULY_WQXGA) += panel-truly-dual-dsi.o
diff --git a/drivers/gpu/drm/panel/panel-truly-dual-dsi.c 
b/drivers/gpu/drm/panel/panel-truly-dual-dsi.c
new file mode 100644
index 000..47891ee
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-truly-dual-dsi.c
@@ -0,0 +1,530 @@
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+struct truly_wqxga {
+   struct device *dev;
+   struct