[Bug 99278] kwin corruption when desktop effects enabled
https://bugs.freedesktop.org/show_bug.cgi?id=99278 Bug ID: 99278 Summary: kwin corruption when desktop effects enabled Product: Mesa Version: 13.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: vedran at miletic.net QA Contact: dri-devel at lists.freedesktop.org Created attachment 128760 --> https://bugs.freedesktop.org/attachment.cgi?id=128760&action=edit Photo Using Fedora 25 with Mesa 13 and LLVM 3.8 on: 04:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Venus XTX [Radeon HD 8890M / R9 M275X/M375X] [1002:6820] (rev 81) identified as "AMD CAPE VERDE" by Mesa. Photo is attached. This is a dual GPU laptop (Lenovo Z51-70), main GPU being 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) While corruption happens, dmesg | grep radeon does not show anything suspicious, just: [21253.931482] radeon :04:00.0: WB enabled [21253.931484] radeon :04:00.0: fence driver on ring 0 use gpu addr 0x00010c00 and cpu addr 0x99e2d0bb1c00 [21253.931485] radeon :04:00.0: fence driver on ring 1 use gpu addr 0x00010c04 and cpu addr 0x99e2d0bb1c04 [21253.931486] radeon :04:00.0: fence driver on ring 2 use gpu addr 0x00010c08 and cpu addr 0x99e2d0bb1c08 [21253.931486] radeon :04:00.0: fence driver on ring 3 use gpu addr 0x00010c0c and cpu addr 0x99e2d0bb1c0c [21253.931487] radeon :04:00.0: fence driver on ring 4 use gpu addr 0x00010c10 and cpu addr 0x99e2d0bb1c10 [21253.932296] radeon :04:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xbefe01235a18 [21253.952686] radeon :04:00.0: fence driver on ring 6 use gpu addr 0x00010c18 and cpu addr 0x99e2d0bb1c18 [21253.952687] radeon :04:00.0: fence driver on ring 7 use gpu addr 0x00010c1c and cpu addr 0x99e2d0bb1c1c Should I test LLVM 3.9/4.0-git? Any other info that could be useful? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/02fbb71a/attachment-0001.html>
[PATCH] drm: nouveau: fix build when LEDS_CLASS=m
On Wed, Jan 4, 2017 at 10:17 PM, Randy Dunlap wrote: > On 01/04/17 19:09, Ilia Mirkin wrote: >> On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap >> wrote: >>> On 01/04/17 06:25, Ilia Mirkin wrote: On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote: > On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >> From: Randy Dunlap >> >> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >> CONFIG_DRM_NOUVEAU=y. >> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >> kconfig value as LEDS_CLASS. >> >> drivers/built-in.o: In function `nouveau_do_suspend': >> nouveau_drm.c:(.text+0x2030b1): undefined reference to >> `nouveau_led_suspend' >> drivers/built-in.o: In function `nouveau_do_resume': >> nouveau_drm.c:(.text+0x2034ca): undefined reference to >> `nouveau_led_resume' >> drivers/built-in.o: In function `nouveau_drm_unload': >> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >> drivers/built-in.o: In function `nouveau_drm_load': >> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >> >> BTW, this line in Kbuild: >> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >> >> Signed-off-by: Randy Dunlap >> Reported-by: kbuild test robot >> Cc: Martin Peres >> Cc: Ben Skeggs > > Thrown into drm-misc, thanks. > -Daniel Wasn't there already a different solution from Martin for this, using IS_REACHABLE, instead of adding a dependency in Kconfig? >>> >>> nouveau_led.h contains a few lines that are bounded by >>> #if IS_ENABLED(CONFIG_LEDS_CLASS) >>> >>> but that's not sufficient. >>> >>> Is there another patch? >> >> https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html >> >> Not sure why it's not upstream yet. I guess Ben missed it? > > Ok, if you all are OK with a slightly crippled driver. The LED functionality is to allow adjusting the light inside the case of the high-end GTX TITAN boards. I think people will be fine with that level of crippled for when they build nouveau in and the leds class as a module. -ilia
[PATCH] drm: nouveau: fix build when LEDS_CLASS=m
On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap wrote: > On 01/04/17 06:25, Ilia Mirkin wrote: >> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote: >>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: From: Randy Dunlap Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same kconfig value as LEDS_CLASS. drivers/built-in.o: In function `nouveau_do_suspend': nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' drivers/built-in.o: In function `nouveau_do_resume': nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' drivers/built-in.o: In function `nouveau_drm_unload': nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' drivers/built-in.o: In function `nouveau_drm_load': nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' BTW, this line in Kbuild: nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. Signed-off-by: Randy Dunlap Reported-by: kbuild test robot Cc: Martin Peres Cc: Ben Skeggs >>> >>> Thrown into drm-misc, thanks. >>> -Daniel >> >> Wasn't there already a different solution from Martin for this, using >> IS_REACHABLE, instead of adding a dependency in Kconfig? > > nouveau_led.h contains a few lines that are bounded by > #if IS_ENABLED(CONFIG_LEDS_CLASS) > > but that's not sufficient. > > Is there another patch? https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html Not sure why it's not upstream yet. I guess Ben missed it? -ilia
[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460
https://bugs.freedesktop.org/show_bug.cgi?id=99275 --- Comment #6 from Reimar Imhof --- Just something I do not understand: While having a look at the Xorg.log I couldn't find anything about loading xf86-video-amdgpu. I just found lines about /usr/lib64/xorg/modules/drivers/ati_drv.so and /usr/lib64/xorg/modules/drivers/radeon_drv.so Do I need a special config for loading the amdgpu driver? There is no video-driver specific config in /etc/X11/xorg.conf.d/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/307e1119/attachment.html>
[drm-intel:drm-intel-nightly 440/455] warning: (DRM_NOUVEAU && ..) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && ..)
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 3ff9912451fd6840732ac0184f0561c9e6c4107f commit: a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8 [440/455] drm: nouveau: fix build when LEDS_CLASS=m config: x86_64-randconfig-x016-201701 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout a5ad0fd8524e5144512a5c25eda5a5d6fd55fda8 # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has unmet direct dependencies (ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/gzip Size: 20322 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/58e6f82e/attachment-0001.gz>
[PATCH] drm: nouveau: fix build when LEDS_CLASS=m
g/drivers/gpu/drm/nouveau/Kconfig >> +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig >> @@ -1,6 +1,7 @@ >> config DRM_NOUVEAU >> tristate "Nouveau (NVIDIA) cards" >> depends on DRM && PCI >> +depends on LEDS_CLASS || LEDS_CLASS=n >> select FW_LOADER >> select DRM_KMS_HELPER >> select DRM_TTM >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center -- next part -- An embedded and charset-unspecified text was scrubbed... Name: .config URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/acb58a4b/attachment-0001.ksh>
[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460
https://bugs.freedesktop.org/show_bug.cgi?id=99275 --- Comment #5 from Reimar Imhof --- I've attached the logs and the info about changed components. They are all from download.opensuse.org/repositories/X11:/XOrg/openSUSE_Leap_42.2/ The flicker problem is not about the menu but the drop down list that opens when you enter an address to the firefox address field. A second effect: When I re-size a window using kernel 4.8.14 the background (or underlying windows) shine through. When I do so using kernel 4.9 it also starts flickering and shows artifacts from the background. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/f9d92192/attachment.html>
[PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()
Hi Chris, Thanks for your patches! On 4 January 2017 at 20:40, Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote: >> As the fence->status is an optional field that may be set before >> dma_fence_signal() is called to convey that the fence completed with an >> error, we have to ensure that it is always set to zero on initialisation >> so that the typical use (i.e. unset) always flags a successful completion. >> >> Signed-off-by: Chris Wilson >> Reviewed-by: Tvrtko Ursulin > > Yeah, this looks all pretty. On the series: > > Reviewed-by: Daniel Vetter > FWIW, please feel free, for this series, to apply my Reviewed-by: Sumit Semwal > I'll defer to Gustavo for another pass over it and merging it to drm-misc. > -Daniel > Best, Sumit. >> --- >> drivers/dma-buf/dma-fence.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c >> index 3444f293ad4a..9130f790ebf3 100644 >> --- a/drivers/dma-buf/dma-fence.c >> +++ b/drivers/dma-buf/dma-fence.c >> @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct >> dma_fence_ops *ops, >> fence->context = context; >> fence->seqno = seqno; >> fence->flags = 0UL; >> + fence->status = 0; >> >> trace_dma_fence_init(fence); >> } >> -- >> 2.11.0 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thanks and regards, Sumit Semwal Linaro Mobile Group - Kernel Team Lead Linaro.org â Open source software for ARM SoCs
[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #4 from Reimar Imhof ---
Created attachment 128758
--> https://bugs.freedesktop.org/attachment.cgi?id=128758&action=edit
rpm -qa --queryformat "%{Name} - %{Version} - %{Vendor}\n" | grep
build.opensuse.org/X11
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/185ca08e/attachment.html>
[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460
https://bugs.freedesktop.org/show_bug.cgi?id=99275 --- Comment #3 from Reimar Imhof --- Created attachment 128757 --> https://bugs.freedesktop.org/attachment.cgi?id=128757&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/ed44e3cc/attachment.html>
[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460
https://bugs.freedesktop.org/show_bug.cgi?id=99275 --- Comment #2 from Reimar Imhof --- Created attachment 128756 --> https://bugs.freedesktop.org/attachment.cgi?id=128756&action=edit dmesg.txt -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/0714c191/attachment.html>
[PATCH 9/9] drm/i915: Add render decompression support
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.
Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.
Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
but it works.
Also not all planes will be capable of scanning out compressed surfaces,
and eg. 90/270 degree rotation is not supported in combination with
decompression either.
This patch may contain work from at least the following people:
* Vandana Kannan
* Daniel Vetter
* Ben Widawsky
Cc: Vandana Kannan
Cc: Daniel Vetter
Cc: Ben Widawsky
Cc: Jason Ekstrand
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 22
drivers/gpu/drm/i915/intel_display.c | 219 +--
drivers/gpu/drm/i915/intel_pm.c | 8 +-
drivers/gpu/drm/i915/intel_sprite.c | 5 +
4 files changed, 240 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa77afa..05e18e742776 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6209,6 +6209,28 @@ enum {
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
+#define PLANE_AUX_DIST_1_A 0x701c0
+#define PLANE_AUX_DIST_2_A 0x702c0
+#define PLANE_AUX_DIST_1_B 0x711c0
+#define PLANE_AUX_DIST_2_B 0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+ _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+ _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define PLANE_AUX_OFFSET_1_A 0x701c4
+#define PLANE_AUX_OFFSET_2_A 0x702c4
+#define PLANE_AUX_OFFSET_1_B 0x711c4
+#define PLANE_AUX_OFFSET_2_B 0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe) \
+ _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe) \
+ _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 38de9df0ec60..b547332eeda1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer
*fb, int plane)
return 128;
else
return 512;
+ case I915_FORMAT_MOD_Y_TILED_CCS:
+ if (plane == 1)
+ return 64;
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
+ case I915_FORMAT_MOD_Yf_TILED_CCS:
+ if (plane == 1)
+ return 64;
+ /* fall through */
case I915_FORMAT_MOD_Yf_TILED:
/*
* Bspec seems to suggest that the Yf tile width would
@@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
struct drm_i915_private *dev_priv = to_i915(fb->dev);
/* AUX_DIST needs only 4K alignment */
- if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
+ if (plane == 1)
return 4096;
switch (fb->modifier) {
@@ -2166,6 +2174,8 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
if (INTEL_GEN(dev_priv) >= 9)
return 256 * 1024;
return 0;
+ case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Yf_TILED_CCS:
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MO
[PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The location
of CCS is provided by userspace as just another plane with its own offset.
By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.
Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.
v2: Drop the 'dev' argument from the hook
v3: Include the description of the CCS surface layout
Cc: Vandana Kannan
Cc: Daniel Vetter
Cc: Ben Widawsky
Cc: Jason Ekstrand
Reviewed-by: Ben Widawsky
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 36 ++
include/uapi/drm/drm_fourcc.h| 49
2 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c4662b2e9613..38de9df0ec60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2478,6 +2478,41 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t
fb_modifier)
}
}
+static const struct drm_format_info ccs_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
4, 1, }, .hsub = 16, .vsub = 8, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+ int num_formats, u32 format)
+{
+ int i;
+
+ for (i = 0; i < num_formats; i++) {
+ if (formats[i].format == format)
+ return &formats[i];
+ }
+
+ return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
+{
+ switch (cmd->modifier[0]) {
+ case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Yf_TILED_CCS:
+ return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+ default:
+ return NULL;
+ }
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -16083,6 +16118,7 @@ static void intel_atomic_state_free(struct
drm_atomic_state *state)
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+ .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7fabcde..4581e3d41e5c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -230,6 +230,55 @@ extern "C" {
#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
/*
+ * Intel color control surface (CCS) for render compression
+ *
+ * The framebuffer format must be one of the 8:8:8:8 RGB formats,
+ * the main surface will be plane index 0 and will be Y/Yf-tiled,
+ * the CCS will be plane index 1.
+ *
+ * Each byte of CCS contains 4 pairs of bits, with each pair of bits
+ * matching an area of 8x4 pixels of the main surface. Which would seem
+ * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
+ * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
+ * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
+ * ---
+ * | 01 | 23 |
+ * --
+ * | 45 | 67 |
+ * ---
+ *
+ * Actually only the lower bit of the pair seems to have any effect.
+ * No idea why. 0 in the lower bit would seem to mean not compressed,
+ * and 1 is compressed. The interpreation of the main surface data
+ * when the block is marked compressed is unknown as of now.
+ *
+ * CCS tile is laid out in 8 byte horizontal strips each strip thus corresponds
+ * to a 128x8 pixel are of the main surface. So each 8x8 bytes of the CCS
+ * (1 cacheline) will match an area of 4x2 tiles on th
[PATCH 7/9] drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages
From: Ville Syrjälä
DRM_UT_CORE generates way too much noise usually, so having the
framebuffer init failures use DRM_UT_CORE is a pain when trying to
find out the reason why you failed in creating a framebuffer.
Let's use DRM_UT_KMS for these debug messages instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 66 ++--
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5fee5a7ac9a4..c4662b2e9613 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2512,8 +2512,8 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
*/
if (i915_gem_object_is_tiled(intel_fb->obj) &&
(x + width) * cpp > fb->pitches[i]) {
- DRM_DEBUG("bad fb plane %d offset: 0x%x\n",
- i, fb->offsets[i]);
+ DRM_DEBUG_KMS("bad fb plane %d offset: 0x%x\n",
+ i, fb->offsets[i]);
return -EINVAL;
}
@@ -2594,9 +2594,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
max_size = max(max_size, offset + size);
}
- if (max_size * tile_size > to_intel_framebuffer(fb)->obj->base.size) {
- DRM_DEBUG("fb too big for bo (need %u bytes, have %zu bytes)\n",
- max_size * tile_size,
to_intel_framebuffer(fb)->obj->base.size);
+ if (max_size * tile_size > intel_fb->obj->base.size) {
+ DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu
bytes)\n",
+ max_size * tile_size, intel_fb->obj->base.size);
return -EINVAL;
}
@@ -15904,14 +15904,14 @@ static int intel_framebuffer_init(struct drm_device
*dev,
*/
if (tiling != I915_TILING_NONE &&
tiling !=
intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
- DRM_DEBUG("tiling_mode doesn't match fb modifier\n");
+ DRM_DEBUG_KMS("tiling_mode doesn't match fb
modifier\n");
return -EINVAL;
}
} else {
if (tiling == I915_TILING_X) {
mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
} else if (tiling == I915_TILING_Y) {
- DRM_DEBUG("No Y tiling for legacy addfb\n");
+ DRM_DEBUG_KMS("No Y tiling for legacy addfb\n");
return -EINVAL;
}
}
@@ -15921,16 +15921,16 @@ static int intel_framebuffer_init(struct drm_device
*dev,
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
if (INTEL_GEN(dev_priv) < 9) {
- DRM_DEBUG("Unsupported tiling 0x%llx!\n",
- mode_cmd->modifier[0]);
+ DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
+ mode_cmd->modifier[0]);
return -EINVAL;
}
case DRM_FORMAT_MOD_NONE:
case I915_FORMAT_MOD_X_TILED:
break;
default:
- DRM_DEBUG("Unsupported fb modifier 0x%llx!\n",
- mode_cmd->modifier[0]);
+ DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
+ mode_cmd->modifier[0]);
return -EINVAL;
}
@@ -15940,17 +15940,17 @@ static int intel_framebuffer_init(struct drm_device
*dev,
*/
if (INTEL_INFO(dev_priv)->gen < 4 &&
tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
- DRM_DEBUG("tiling_mode must match fb modifier exactly on
gen2/3\n");
+ DRM_DEBUG_KMS("tiling_mode must match fb modifier exactly on
gen2/3\n");
return -EINVAL;
}
pitch_limit = intel_fb_pitch_limit(dev_priv, mode_cmd->modifier[0],
mode_cmd->pixel_format);
if (mode_cmd->pitches[0] > pitch_limit) {
- DRM_DEBUG("%s pitch (%u) must be at less than %d\n",
- mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ?
- "tiled" : "linear",
- mode_cmd->pitches[0], pitch_limit);
+ DRM_DEBUG_KMS("%s pitch (%u) must be at less than %d\n",
+ mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ?
+ "tiled" : "linear",
+ mode_cmd->pitches[0], pitch_limit);
return -EINVAL;
}
@@ -15960,9 +15960,9 @@ static int intel_framebuffer_init(struct drm_device
*dev,
*/
if (tiling != I915_TILING_NONE &&
mode_cmd->pitches[0] != i915_gem_obj
[PATCH 6/9] drm/i915: Pass the correct plane index to _intel_compute_tile_offset()
From: Ville Syrjälä intel_fill_fb_info() should pass the correct plane index to _intel_compute_tile_offset() once we start to care about the AUX surface. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0ca0dbccc005..5fee5a7ac9a4 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2525,7 +2525,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv, intel_fb->normal[i].y = y; offset = _intel_compute_tile_offset(dev_priv, &x, &y, - fb, 0, fb->pitches[i], + fb, i, fb->pitches[i], DRM_ROTATE_0, tile_size); offset /= tile_size; -- 2.10.2
[PATCH 5/9] drm/i915: Fix Yf tile width
From: Ville Syrjälä
Based on empirical evidence the display engine (at least) always
treats Yf tiles as 128Bx32. Currently we're assuming the tile dimensions
change based on the pixel format. Let's adjust our code to match the
hardware.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bc398743e941..0ca0dbccc005 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2070,20 +2070,12 @@ intel_tile_width_bytes(const struct drm_framebuffer
*fb, int plane)
else
return 512;
case I915_FORMAT_MOD_Yf_TILED:
- switch (cpp) {
- case 1:
- return 64;
- case 2:
- case 4:
- return 128;
- case 8:
- case 16:
- return 256;
- default:
- MISSING_CASE(cpp);
- return cpp;
- }
- break;
+ /*
+* Bspec seems to suggest that the Yf tile width would
+* depend on the cpp. In reality it doesn't, at least
+* as far as the display engine is concerned.
+*/
+ return 128;
default:
MISSING_CASE(fb->modifier);
return cpp;
--
2.10.2
[PATCH 4/9] drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane
From: Ville Syrjälä
To make life easier let's allow skl_plane_stride() to be called for the
AUX surface even when there is no AUX surface. Avoids special cases in
the callers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4d514ca1da88..bc398743e941 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3261,7 +3261,12 @@ static void skl_detach_scalers(struct intel_crtc
*intel_crtc)
u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
unsigned int rotation)
{
- u32 stride = intel_fb_pitch(fb, plane, rotation);
+ u32 stride;
+
+ if (plane >= fb->format->num_planes)
+ return 0;
+
+ stride = intel_fb_pitch(fb, plane, rotation);
/*
* The stride is either expressed as a multiple of 64 bytes chunks for
--
2.10.2
[PATCH 3/9] drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()
From: Ville Syrjälä
Let's try to keep the alignment requirements in one place, and so
towards that end let's move the AUX_DIST alignment handling into
intel_surf_alignment() alongside the main surface alignment stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0cb80aba89a..4d514ca1da88 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2163,6 +2163,10 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
{
struct drm_i915_private *dev_priv = to_i915(fb->dev);
+ /* AUX_DIST needs only 4K alignment */
+ if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
+ return 4096;
+
switch (fb->modifier) {
case DRM_FORMAT_MOD_NONE:
return intel_linear_alignment(dev_priv);
@@ -2452,13 +2456,7 @@ u32 intel_compute_tile_offset(int *x, int *y,
const struct drm_framebuffer *fb = state->base.fb;
unsigned int rotation = state->base.rotation;
int pitch = intel_fb_pitch(fb, plane, rotation);
- u32 alignment;
-
- /* AUX_DIST needs only 4K alignment */
- if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
- alignment = 4096;
- else
- alignment = intel_surf_alignment(fb, plane);
+ u32 alignment = intel_surf_alignment(fb, plane);
return _intel_compute_tile_offset(dev_priv, x, y, fb, plane, pitch,
rotation, alignment);
--
2.10.2
[PATCH 2/9] drm/i915: Plumb drm_framebuffer into more places
From: Ville Syrjälä
Now that framebuffers can be used even before calling
drm_framebuffer_init() we can start to plumb them into more places,
instead of passing individual pieces for fb metadata.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 127 +++
drivers/gpu/drm/i915/intel_drv.h | 11 +--
drivers/gpu/drm/i915/intel_fbdev.c | 4 +-
3 files changed, 57 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e2150a64860c..f0cb80aba89a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2050,10 +2050,13 @@ static unsigned int intel_tile_size(const struct
drm_i915_private *dev_priv)
return IS_GEN2(dev_priv) ? 2048 : 4096;
}
-static unsigned int intel_tile_width_bytes(const struct drm_i915_private
*dev_priv,
- uint64_t fb_modifier, unsigned int
cpp)
+static unsigned int
+intel_tile_width_bytes(const struct drm_framebuffer *fb, int plane)
{
- switch (fb_modifier) {
+ struct drm_i915_private *dev_priv = to_i915(fb->dev);
+ unsigned int cpp = fb->format->cpp[plane];
+
+ switch (fb->modifier) {
case DRM_FORMAT_MOD_NONE:
return cpp;
case I915_FORMAT_MOD_X_TILED:
@@ -2082,41 +2085,38 @@ static unsigned int intel_tile_width_bytes(const struct
drm_i915_private *dev_pr
}
break;
default:
- MISSING_CASE(fb_modifier);
+ MISSING_CASE(fb->modifier);
return cpp;
}
}
-unsigned int intel_tile_height(const struct drm_i915_private *dev_priv,
- uint64_t fb_modifier, unsigned int cpp)
+static unsigned int
+intel_tile_height(const struct drm_framebuffer *fb, int plane)
{
- if (fb_modifier == DRM_FORMAT_MOD_NONE)
+ if (fb->modifier == DRM_FORMAT_MOD_NONE)
return 1;
else
- return intel_tile_size(dev_priv) /
- intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
+ return intel_tile_size(to_i915(fb->dev)) /
+ intel_tile_width_bytes(fb, plane);
}
/* Return the tile dimensions in pixel units */
-static void intel_tile_dims(const struct drm_i915_private *dev_priv,
+static void intel_tile_dims(const struct drm_framebuffer *fb, int plane,
unsigned int *tile_width,
- unsigned int *tile_height,
- uint64_t fb_modifier,
- unsigned int cpp)
+ unsigned int *tile_height)
{
- unsigned int tile_width_bytes =
- intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
+ unsigned int tile_width_bytes = intel_tile_width_bytes(fb, plane);
+ unsigned int cpp = fb->format->cpp[plane];
*tile_width = tile_width_bytes / cpp;
- *tile_height = intel_tile_size(dev_priv) / tile_width_bytes;
+ *tile_height = intel_tile_size(to_i915(fb->dev)) / tile_width_bytes;
}
unsigned int
-intel_fb_align_height(struct drm_device *dev, unsigned int height,
- uint32_t pixel_format, uint64_t fb_modifier)
+intel_fb_align_height(const struct drm_framebuffer *fb,
+ int plane, unsigned int height)
{
- unsigned int cpp = drm_format_plane_cpp(pixel_format, 0);
- unsigned int tile_height = intel_tile_height(to_i915(dev), fb_modifier,
cpp);
+ unsigned int tile_height = intel_tile_height(fb, plane);
return ALIGN(height, tile_height);
}
@@ -2158,21 +2158,23 @@ static unsigned int intel_linear_alignment(const struct
drm_i915_private *dev_pr
return 0;
}
-static unsigned int intel_surf_alignment(const struct drm_i915_private
*dev_priv,
-uint64_t fb_modifier)
+static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
+int plane)
{
- switch (fb_modifier) {
+ struct drm_i915_private *dev_priv = to_i915(fb->dev);
+
+ switch (fb->modifier) {
case DRM_FORMAT_MOD_NONE:
return intel_linear_alignment(dev_priv);
case I915_FORMAT_MOD_X_TILED:
- if (INTEL_INFO(dev_priv)->gen >= 9)
+ if (INTEL_GEN(dev_priv) >= 9)
return 256 * 1024;
return 0;
case I915_FORMAT_MOD_Y_TILED:
case I915_FORMAT_MOD_Yf_TILED:
return 1 * 1024 * 1024;
default:
- MISSING_CASE(fb_modifier);
+ MISSING_CASE(fb->modifier);
return 0;
}
}
@@ -2189,7 +2191,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
unsigned int rotation)
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
- alignment = intel_surf_alignment(de
[PATCH 1/9] drm: Add mode_config .get_format_info() hook
From: Ville Syrjälä
Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.
v2: Fix drm_get_format_info() kernel doc (Laurent)
Don't pass 'dev' to the new hook (Laurent)
Cc: Laurent Pinchart
Cc: Ben Widawsky
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_fourcc.c | 25 +
drivers/gpu/drm/drm_framebuffer.c| 9 +++--
drivers/gpu/drm/drm_modeset_helper.c | 2 +-
include/drm/drm_fourcc.h | 6 ++
include/drm/drm_mode_config.h| 14 ++
6 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 20a4011f790d..de3c9fe116fc 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -177,7 +177,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct
drm_device *dev,
int ret;
int i;
- info = drm_format_info(mode_cmd->pixel_format);
+ info = drm_get_format_info(dev, mode_cmd);
if (!info)
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8da8eb..f9b6445e846a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -199,6 +199,31 @@ const struct drm_format_info *drm_format_info(u32 format)
EXPORT_SYMBOL(drm_format_info);
/**
+ * drm_get_format_info - query information for a given framebuffer
configuration
+ * @dev: DRM device
+ * @mode_cmd: metadata from the userspace fb creation request
+ *
+ * Returns:
+ * The instance of struct drm_format_info that describes the pixel format, or
+ * NULL if the format is unsupported.
+ */
+const struct drm_format_info *
+drm_get_format_info(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ const struct drm_format_info *info = NULL;
+
+ if (dev->mode_config.funcs->get_format_info)
+ info = dev->mode_config.funcs->get_format_info(mode_cmd);
+
+ if (!info)
+ info = drm_format_info(mode_cmd->pixel_format);
+
+ return info;
+}
+EXPORT_SYMBOL(drm_get_format_info);
+
+/**
* drm_format_num_planes - get the number of planes for format
* @format: pixel format (DRM_FORMAT_*)
*
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 588ccc3a2218..e276fcdc3a62 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -126,11 +126,13 @@ int drm_mode_addfb(struct drm_device *dev,
return 0;
}
-static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
+static int framebuffer_check(struct drm_device *dev,
+const struct drm_mode_fb_cmd2 *r)
{
const struct drm_format_info *info;
int i;
+ /* check if the format is supported at all */
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
@@ -140,6 +142,9 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2
*r)
return -EINVAL;
}
+ /* now let the driver pick its own format info */
+ info = drm_get_format_info(dev, r);
+
if (r->width == 0 || r->width % info->hsub) {
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
@@ -263,7 +268,7 @@ drm_internal_framebuffer_create(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}
- ret = framebuffer_check(r);
+ ret = framebuffer_check(dev, r);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/drm_modeset_helper.c
b/drivers/gpu/drm/drm_modeset_helper.c
index cc44a9a4b004..2b33825f2f93 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -78,7 +78,7 @@ void drm_helper_mode_fill_fb_struct(struct drm_device *dev,
int i;
fb->dev = dev;
- fb->format = drm_format_info(mode_cmd->pixel_format);
+ fb->format = drm_get_format_info(dev, mode_cmd);
fb->width = mode_cmd->width;
fb->height = mode_cmd->height;
for (i = 0; i < 4; i++) {
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index fcc08da850c8..6942e84b6edd 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -25,6 +25,9 @@
#include
#include
+struct drm_device;
+struct drm_mode_fb_cmd2;
+
/**
* struct drm_format_info - information about a DRM format
* @format: 4CC format identifier (DRM_FORMAT_*)
@@ -55,6 +58,9 @@ struct drm_format_name_buf {
const struct drm_format_info *__drm_format_info(u32 format);
const struct drm_format_info *drm_format_info(u32 format);
+const struct drm_format_info *
+drm_get_format_info(struct drm_device *dev,
+
[PATCH 0/9] drm/i915: SKL+ render decompression support
From: Ville Syrjälä This series enables the SKL+ display engine render decompression support. Some bits and pieces of the i915 code are based on work from various people, but I just put my name on it since it would be hard to figure out which parts came from where. Entire series available here: git://github.com/vsyrjala/linux.git fb_format_dedup_4_ccs Cc: Vandana Kannan Cc: Daniel Vetter Cc: Ben Widawsky Cc: Jason Ekstrand Cc: Laurent Pinchart Ville Syrjälä (9): drm: Add mode_config .get_format_info() hook drm/i915: Plumb drm_framebuffer into more places drm/i915: Move nv12 chroma plane handling into intel_surf_alignment() drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane drm/i915: Fix Yf tile width drm/i915: Pass the correct plane index to _intel_compute_tile_offset() drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages drm/i915: Implement .get_format_info() hook for CCS drm/i915: Add render decompression support drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- drivers/gpu/drm/drm_fourcc.c | 25 ++ drivers/gpu/drm/drm_framebuffer.c| 9 +- drivers/gpu/drm/drm_modeset_helper.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 22 ++ drivers/gpu/drm/i915/intel_display.c | 474 +-- drivers/gpu/drm/i915/intel_drv.h | 11 +- drivers/gpu/drm/i915/intel_fbdev.c | 4 +- drivers/gpu/drm/i915/intel_pm.c | 8 +- drivers/gpu/drm/i915/intel_sprite.c | 5 + include/drm/drm_fourcc.h | 6 + include/drm/drm_mode_config.h| 14 ++ include/uapi/drm/drm_fourcc.h| 49 13 files changed, 478 insertions(+), 153 deletions(-) -- 2.10.2
[PATCH v5] drm: add fourcc codes for 16bit R and RG
On Wed, Jan 04, 2017 at 07:24:09PM +0100, Rainer Hochecker wrote:
> From: Rainer Hochecker
>
> Thanks for bearing with me. My ml skills have greatly improved now :)
>
> v5 of patch:
>
> This adds fourcc codes for 16bit planes required for DRM buffer
> export to mesa.
>
> Signed-off-by: Rainer Hochecker
> ---
> include/uapi/drm/drm_fourcc.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index a5890bf..e7f6bcd 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -41,10 +41,17 @@ extern "C" {
> /* 8 bpp Red */
> #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
>
> +/* 16 bpp Red */
> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> [15:0] R */
little endian
> +
> /* 16 bpp RG */
> #define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /*
> [15:0] R:G 8:8 little endian */
> #define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /*
> [15:0] G:R 8:8 little endian */
>
> +/* 32 bpp RG */
> +#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
> 16:16 little endian */
> +#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
> 16:16 little endian */
> +
> /* 8 bpp RGB */
> #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
> 3:3:2 */
> #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
> 2:3:3 */
> --
> 2.9.3
--
Ville Syrjälä
Intel OTC
[PATCH 9/9] drm/i915: Add render decompression support
On 17-01-04 20:42:32, Ville Syrjälä wrote:
>From: Ville Syrjälä
>
>SKL+ display engine can scan out certain kinds of compressed surfaces
>produced by the render engine. This involved telling the display engine
>the location of the color control surfae (CCS) which describes
>which parts of the main surface are compressed and which are not. The
>location of CCS is provided by userspace as just another plane with its
>own offset.
>
>Add the required stuff to validate the user provided AUX plane metadata
>and convert the user provided linear offset into something the hardware
>can consume.
>
>Due to hardware limitations we require that the main surface and
>the AUX surface (CCS) be part of the same bo. The hardware also
>makes life hard by not allowing you to provide separate x/y offsets
>for the main and AUX surfaces (excpet with NV12), so finding suitable
>offsets for both requires a bit of work. Assuming we still want keep
>playing tricks with the offsets. I've just gone with a dumb "search
>backward for suitable offsets" approach, which is far from optimal,
>but it works.
>
>Also not all planes will be capable of scanning out compressed surfaces,
>and eg. 90/270 degree rotation is not supported in combination with
>decompression either.
>
>This patch may contain work from at least the following people:
>* Vandana Kannan
>* Daniel Vetter
>* Ben Widawsky
>
>Cc: Vandana Kannan
>Cc: Daniel Vetter
>Cc: Ben Widawsky
>Cc: Jason Ekstrand
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/i915/i915_reg.h | 22
> drivers/gpu/drm/i915/intel_display.c | 219 +--
> drivers/gpu/drm/i915/intel_pm.c | 8 +-
> drivers/gpu/drm/i915/intel_sprite.c | 5 +
> 4 files changed, 240 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>index 00970aa77afa..05e18e742776 100644
>--- a/drivers/gpu/drm/i915/i915_reg.h
>+++ b/drivers/gpu/drm/i915/i915_reg.h
>@@ -6209,6 +6209,28 @@ enum {
> _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
> _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
>
>+#define PLANE_AUX_DIST_1_A0x701c0
>+#define PLANE_AUX_DIST_2_A0x702c0
>+#define PLANE_AUX_DIST_1_B0x711c0
>+#define PLANE_AUX_DIST_2_B0x712c0
>+#define _PLANE_AUX_DIST_1(pipe) \
>+ _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
>+#define _PLANE_AUX_DIST_2(pipe) \
>+ _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
>+#define PLANE_AUX_DIST(pipe, plane) \
>+ _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
>+
>+#define PLANE_AUX_OFFSET_1_A 0x701c4
>+#define PLANE_AUX_OFFSET_2_A 0x702c4
>+#define PLANE_AUX_OFFSET_1_B 0x711c4
>+#define PLANE_AUX_OFFSET_2_B 0x712c4
>+#define _PLANE_AUX_OFFSET_1(pipe) \
>+ _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
>+#define _PLANE_AUX_OFFSET_2(pipe) \
>+ _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
>+#define PLANE_AUX_OFFSET(pipe, plane) \
>+ _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
>+
> /* legacy palette */
> #define _LGC_PALETTE_A 0x4a000
> #define _LGC_PALETTE_B 0x4a800
>diff --git a/drivers/gpu/drm/i915/intel_display.c
>b/drivers/gpu/drm/i915/intel_display.c
>index 38de9df0ec60..b547332eeda1 100644
>--- a/drivers/gpu/drm/i915/intel_display.c
>+++ b/drivers/gpu/drm/i915/intel_display.c
>@@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer
>*fb, int plane)
> return 128;
> else
> return 512;
>+ case I915_FORMAT_MOD_Y_TILED_CCS:
>+ if (plane == 1)
>+ return 64;
>+ /* fall through */
> case I915_FORMAT_MOD_Y_TILED:
> if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
> return 128;
> else
> return 512;
>+ case I915_FORMAT_MOD_Yf_TILED_CCS:
>+ if (plane == 1)
>+ return 64;
>+ /* fall through */
> case I915_FORMAT_MOD_Yf_TILED:
> /*
>* Bspec seems to suggest that the Yf tile width would
>@@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const struct
>drm_framebuffer *fb,
> struct drm_i915_private *dev_priv = to_i915(fb->dev);
>
> /* AUX_DIST needs only 4K alignment */
>- if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
>+ if (plane == 1)
This looks wrong at least within this context, surely multi-planar formats might
have different alignment restrictions?
> return 4096;
>
> switch (fb->modifier) {
>@@ -2166,6 +2174,8 @@ static unsigned int intel_surf_alignment(const struct
>drm_framebuffer *fb,
> if (INTEL
[PATCH] drm/i915/dp: Stop enabling limited color ranges for everything
Until now, it seems we've been erroneously enabling limited color ranges
for the vast majority of DisplayPort monitors. I noticed this after
writing a frame dump comparison test for the Chamelium and noticing that
every i915 device I had was failing, while amdgpu machines were fine:
https://people.freedesktop.org/~lyudess/archive/01-03-2017/
It looks like this is because the DisplayPort spec tells us to use
limited color ranges whenever we detect a CEA mode in use. However, from
the looks of it there's another rather confusing part of the spec that
got missed: source devices are allowed to use the full range of values
for pixels -even- if the sink device declares that it's using a CEA
mode. It's up to the sink device to limit the pixel range to the CEA
ranges if it needs.
Signed-off-by: Lyude
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Ville Syrjälä
---
I'm really surprised that this bug would have been around as long as it looks
like it has been without anyone noticing it, so I figured I'd just send a patch
to the mailing list so you guys can point out whether or not this is really the
correct thing to do.
drivers/gpu/drm/i915/intel_dp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d9bc19b..6642abd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1649,12 +1649,15 @@ intel_dp_compute_config(struct intel_encoder *encoder,
found:
if (intel_dp->color_range_auto) {
/*
+* We are required to use the limited CEA RGB range when a CEA
+* mode is declared in the EDID. However, limiting the pixel
+* value range is up to the sink, not the source. So, just
+* don't enable limited color ranges.
* See:
* CEA-861-E - 5.1 Default Encoding Parameters
* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
*/
- pipe_config->limited_color_range =
- bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
+ pipe_config->limited_color_range = false;
} else {
pipe_config->limited_color_range =
intel_dp->limited_color_range;
--
2.9.3
[PATCH v6] drm: add fourcc codes for 16bit R and RG
From: Rainer Hochecker
This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.
Signed-off-by: Rainer Hochecker
---
include/uapi/drm/drm_fourcc.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..d230e58 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
/* 8 bpp Red */
#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R
little endian */
+
/* 16 bpp RG */
#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 little endian */
+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
16:16 little endian */
+#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 little endian */
+
/* 8 bpp RGB */
#define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
3:3:2 */
#define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
2:3:3 */
--
2.9.3
[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460
https://bugs.freedesktop.org/show_bug.cgi?id=99275 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. Is it just the menu that flickers or the whole screen? Did you also change any other components (mesa, ddx, etc.)? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/e963ed44/attachment.html>
[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460
https://bugs.freedesktop.org/show_bug.cgi?id=99275 Bug ID: 99275 Summary: Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: tuxuser at quantentunnel.de CC: tiwai at suse.de Created attachment 128754 --> https://bugs.freedesktop.org/attachment.cgi?id=128754&action=edit hwinfo System: openSuse Leap 42.2, kernel from download.opensuse.org/repositories/Kernel:/stable/standard/ 4.9.0-4.g1af4b0f Mesa from download.opensuse.org/repositories/X11:/XOrg/openSUSE_Leap_42.2/ graphics adapter: amd radeon rx 460 cpu: i5-6402p desktop: kde5 (from 42.2-oss/update) Problem: Address-drop-down in firefox flickers. Steps to reproduce: start firefox enter address (example: www.heise.de) enter an other address address drop down starts to flicker. Perhaps problem shows up only when virtual desktop has been changed before firefox was started. (I use cube animation for virtual desktop change.) Problem also occurs with tumbleweed live system. There is no problem with kernel 4.8.x (4.8.14) I've also reported this bug at https://bugzilla.suse.com/show_bug.cgi?id=1017938 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/a627e627/attachment.html>
[PATCH v5] drm: add fourcc codes for 16bit R and RG
From: Rainer Hochecker
Thanks for bearing with me. My ml skills have greatly improved now :)
v5 of patch:
This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.
Signed-off-by: Rainer Hochecker
---
include/uapi/drm/drm_fourcc.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..e7f6bcd 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
/* 8 bpp Red */
#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
+
/* 16 bpp RG */
#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 little endian */
+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] R:G
16:16 little endian */
+#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 little endian */
+
/* 8 bpp RGB */
#define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
3:3:2 */
#define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
2:3:3 */
--
2.9.3
[Intel-gfx] [PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw
On Wed, 2017-01-04 at 10:33 +0100, Daniel Vetter wrote:
> On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote:
> > Link bandwidth is shared between multiple display streams in DP MST
> > configurations. The DP MST topology manager structure maintains the shared
> > link bandwidth for a primary link directly connected to the GPU. For atomic
> > modesetting drivers, checking if there is sufficient link bandwidth for a
> > mode needs to be done during the atomic_check phase to avoid failed
> > modesets. Let's encsapsulate the available link bw information in a state
> > structure so that bw can be allocated and released atomically for each of
> > the ports sharing the primary link.
> >
> > Signed-off-by: Dhinakaran Pandiyan
>
> Overall issue with the patch is that dp helpers now have 2 places where
> available_slots is stored: One for atomic drivers in ->state, and the
> legacy one. I think it'd be good to rework the legacy codepaths (i.e.
> drm_dp_find_vcpi_slots) to use mgr->state->avail_slots, and remove
> mgr->avail_slots entirely.
PATCH 2/6 does that. mgr->avail_slots is not updated in the legacy code
path, so the check turns out to be against mgr->total_slots. So, I did
just that, albeit explicitly.
-DK
>
> Another design concern below, but in principle this looks like what we
> need.
> -Daniel
>
>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 66
> > +++
> > drivers/gpu/drm/drm_atomic_helper.c | 10 ++
> > drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
> > include/drm/drm_atomic.h | 13 +++
> > include/drm/drm_dp_mst_helper.h | 13 +++
> > 5 files changed, 112 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 681d5f9..b8e2cea 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -31,6 +31,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "drm_crtc_internal.h"
> > @@ -62,6 +63,7 @@ void drm_atomic_state_default_release(struct
> > drm_atomic_state *state)
> > kfree(state->connectors);
> > kfree(state->crtcs);
> > kfree(state->planes);
> > + kfree(state->dp_mst_topologies);
> > }
> > EXPORT_SYMBOL(drm_atomic_state_default_release);
> >
> > @@ -189,6 +191,18 @@ void drm_atomic_state_default_clear(struct
> > drm_atomic_state *state)
> > state->planes[i].ptr = NULL;
> > state->planes[i].state = NULL;
> > }
> > +
> > + for (i = 0; i < state->num_mst_topologies; i++) {
> > + struct drm_dp_mst_topology_mgr *mgr =
> > state->dp_mst_topologies[i].ptr;
> > +
> > + if (!mgr)
> > + continue;
> > +
> > + kfree(state->dp_mst_topologies[i].state);
> > + state->dp_mst_topologies[i].ptr = NULL;
> > + state->dp_mst_topologies[i].state = NULL;
> > + }
> > +
> > }
> > EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >
> > @@ -981,6 +995,58 @@ static void drm_atomic_plane_print_state(struct
> > drm_printer *p,
> > plane->funcs->atomic_print_state(p, state);
> > }
> >
> > +struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct
> > drm_atomic_state *state,
> > + struct drm_dp_mst_topology_mgr *mgr)
> > +{
> > +
> > + int ret, i;
> > + size_t new_size;
> > + struct __drm_dp_mst_topology_state *new_arr;
> > + struct drm_dp_mst_topology_state *new_mst_state;
> > + int num_topologies;
> > + struct drm_mode_config *config = &mgr->dev->mode_config;
> > +
> > + WARN_ON(!state->acquire_ctx);
> > +
> > + ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
> > + if (ret)
> > + return ERR_PTR(ret);
> > +
> > + for (i = 0; i < state->num_mst_topologies; i++) {
> > + if (mgr == state->dp_mst_topologies[i].ptr &&
> > + state->dp_mst_topologies[i].state) {
> > + return state->dp_mst_topologies[i].state;
> > + }
> > + }
> > +
> > + num_topologies = state->num_mst_topologies + 1;
> > + new_size = sizeof(*state->dp_mst_topologies) * num_topologies;
> > + new_arr = krealloc(state->dp_mst_topologies, new_size, GFP_KERNEL);
> > + if (!new_arr)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + state->dp_mst_topologies = new_arr;
> > + memset(&state->dp_mst_topologies[state->num_mst_topologies], 0,
> > + sizeof(*state->dp_mst_topologies));
> > +
> > + new_mst_state = kmalloc(sizeof(*mgr->state), GFP_KERNEL);
> > + if (!new_mst_state)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + new_mst_state->avail_slots = mgr->state->avail_slots;
> > + state->dp_mst_topologies[state->num_mst_topologies].state =
> > new_mst_state;
> > + state->dp_mst_topologies[state->num_mst_topologies].ptr = mgr;
> > + state->num_mst_topologies = num_topologies;
> > + new_mst_state->mgr = mgr;
> > + mgr->state->state =
[PATCH] drm: nouveau: fix build when LEDS_CLASS=m
On 01/04/17 19:09, Ilia Mirkin wrote: > On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap wrote: >> On 01/04/17 06:25, Ilia Mirkin wrote: >>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote: On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and > CONFIG_DRM_NOUVEAU=y. > If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same > kconfig value as LEDS_CLASS. > > drivers/built-in.o: In function `nouveau_do_suspend': > nouveau_drm.c:(.text+0x2030b1): undefined reference to > `nouveau_led_suspend' > drivers/built-in.o: In function `nouveau_do_resume': > nouveau_drm.c:(.text+0x2034ca): undefined reference to > `nouveau_led_resume' > drivers/built-in.o: In function `nouveau_drm_unload': > nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' > drivers/built-in.o: In function `nouveau_drm_load': > nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' > > BTW, this line in Kbuild: > nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o > does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. > > Signed-off-by: Randy Dunlap > Reported-by: kbuild test robot > Cc: Martin Peres > Cc: Ben Skeggs Thrown into drm-misc, thanks. -Daniel >>> >>> Wasn't there already a different solution from Martin for this, using >>> IS_REACHABLE, instead of adding a dependency in Kconfig? >> >> nouveau_led.h contains a few lines that are bounded by >> #if IS_ENABLED(CONFIG_LEDS_CLASS) >> >> but that's not sufficient. >> >> Is there another patch? > > https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html > > Not sure why it's not upstream yet. I guess Ben missed it? Ok, if you all are OK with a slightly crippled driver. -- ~Randy
[PATCH 1/9] drm: Add mode_config .get_format_info() hook
On 17-01-04 20:42:24, Ville Syrjälä wrote:
>From: Ville Syrjälä
>
>Allow drivers to return a custom drm_format_info structure for special
>fb layouts. We'll use this for the compression control surface in i915.
>
>v2: Fix drm_get_format_info() kernel doc (Laurent)
>Don't pass 'dev' to the new hook (Laurent)
>
>Cc: Laurent Pinchart
>Cc: Ben Widawsky
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> drivers/gpu/drm/drm_fourcc.c | 25 +
> drivers/gpu/drm/drm_framebuffer.c| 9 +++--
> drivers/gpu/drm/drm_modeset_helper.c | 2 +-
> include/drm/drm_fourcc.h | 6 ++
> include/drm/drm_mode_config.h| 14 ++
> 6 files changed, 54 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>b/drivers/gpu/drm/drm_fb_cma_helper.c
>index 20a4011f790d..de3c9fe116fc 100644
>--- a/drivers/gpu/drm/drm_fb_cma_helper.c
>+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>@@ -177,7 +177,7 @@ struct drm_framebuffer
>*drm_fb_cma_create_with_funcs(struct drm_device *dev,
> int ret;
> int i;
>
>- info = drm_format_info(mode_cmd->pixel_format);
>+ info = drm_get_format_info(dev, mode_cmd);
> if (!info)
> return ERR_PTR(-EINVAL);
>
>diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>index 90d2cc8da8eb..f9b6445e846a 100644
>--- a/drivers/gpu/drm/drm_fourcc.c
>+++ b/drivers/gpu/drm/drm_fourcc.c
>@@ -199,6 +199,31 @@ const struct drm_format_info *drm_format_info(u32 format)
> EXPORT_SYMBOL(drm_format_info);
>
> /**
>+ * drm_get_format_info - query information for a given framebuffer
>configuration
>+ * @dev: DRM device
>+ * @mode_cmd: metadata from the userspace fb creation request
>+ *
>+ * Returns:
>+ * The instance of struct drm_format_info that describes the pixel format, or
>+ * NULL if the format is unsupported.
>+ */
>+const struct drm_format_info *
>+drm_get_format_info(struct drm_device *dev,
>+ const struct drm_mode_fb_cmd2 *mode_cmd)
>+{
>+ const struct drm_format_info *info = NULL;
>+
>+ if (dev->mode_config.funcs->get_format_info)
>+ info = dev->mode_config.funcs->get_format_info(mode_cmd);
>+
>+ if (!info)
>+ info = drm_format_info(mode_cmd->pixel_format);
>+
>+ return info;
>+}
>+EXPORT_SYMBOL(drm_get_format_info);
>+
>+/**
> * drm_format_num_planes - get the number of planes for format
> * @format: pixel format (DRM_FORMAT_*)
> *
>diff --git a/drivers/gpu/drm/drm_framebuffer.c
>b/drivers/gpu/drm/drm_framebuffer.c
>index 588ccc3a2218..e276fcdc3a62 100644
>--- a/drivers/gpu/drm/drm_framebuffer.c
>+++ b/drivers/gpu/drm/drm_framebuffer.c
>@@ -126,11 +126,13 @@ int drm_mode_addfb(struct drm_device *dev,
> return 0;
> }
>
>-static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
>+static int framebuffer_check(struct drm_device *dev,
>+ const struct drm_mode_fb_cmd2 *r)
> {
> const struct drm_format_info *info;
> int i;
>
>+ /* check if the format is supported at all */
> info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
> if (!info) {
> struct drm_format_name_buf format_name;
>@@ -140,6 +142,9 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2
>*r)
> return -EINVAL;
> }
>
>+ /* now let the driver pick its own format info */
>+ info = drm_get_format_info(dev, r);
>+
> if (r->width == 0 || r->width % info->hsub) {
> DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
> return -EINVAL;
>@@ -263,7 +268,7 @@ drm_internal_framebuffer_create(struct drm_device *dev,
> return ERR_PTR(-EINVAL);
> }
>
>- ret = framebuffer_check(r);
>+ ret = framebuffer_check(dev, r);
> if (ret)
> return ERR_PTR(ret);
>
>diff --git a/drivers/gpu/drm/drm_modeset_helper.c
>b/drivers/gpu/drm/drm_modeset_helper.c
>index cc44a9a4b004..2b33825f2f93 100644
>--- a/drivers/gpu/drm/drm_modeset_helper.c
>+++ b/drivers/gpu/drm/drm_modeset_helper.c
>@@ -78,7 +78,7 @@ void drm_helper_mode_fill_fb_struct(struct drm_device *dev,
> int i;
>
> fb->dev = dev;
>- fb->format = drm_format_info(mode_cmd->pixel_format);
>+ fb->format = drm_get_format_info(dev, mode_cmd);
> fb->width = mode_cmd->width;
> fb->height = mode_cmd->height;
> for (i = 0; i < 4; i++) {
>diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
>index fcc08da850c8..6942e84b6edd 100644
>--- a/include/drm/drm_fourcc.h
>+++ b/include/drm/drm_fourcc.h
>@@ -25,6 +25,9 @@
> #include
> #include
>
>+struct drm_device;
>+struct drm_mode_fb_cmd2;
>+
> /**
> * struct drm_format_info - information about a DRM format
> * @format: 4CC format identifier (DRM_FORMAT_*)
>@@ -55,6 +58,9 @@ struct drm_format_name_buf {
>
> const struct drm_format_info *__drm_format_info(u32 format)
[PATCH v5 0/3] Add support for the S6E3HA2 panel on TM2 board
Hi Hoegeun, On Wed, Jan 04, 2017 at 05:15:08PM +0900, Hoegeun Kwon wrote: > Purpose of this patch is add support for S6E3HA2 AMOLED panel on > the TM2 board. The first patch adds support for S6E3HA2 panel > device tree document and driver, the second patch add support for > S6E3HA2 panel device tree. > > Change for V5: > - The V5 has only one fix in V4 below. > - Removed the enable check of the mic driver in mode_set > callback, because mode_set should be performed every time. > > Changes for V4: > - Removed display-timings in devicetree, the display-timings has > been fixed to be provided by the device driver. > - Added the mode_set callback function into exynos_drm_mic, > because the exynos_drm_mic driver can not parse a videomode > struct by removing the display-timings from the devicetree. Next time, please add the full history, from "Changes for V1". Moreover in this patchset you haven't added the "Tested-by: Chanwoo..." in patch 2 and 3. Andi > > Hoegeun Kwon (2): > drm/exynos: mic: Add mode_set callback function > drm/panel: Add support for S6E3HA2 panel driver on TM2 board > > Hyungwon Hwang (1): > arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board > > .../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++ > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 + > drivers/gpu/drm/exynos/exynos_drm_mic.c| 30 +- > drivers/gpu/drm/panel/Kconfig | 6 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 > + > 6 files changed, 824 insertions(+), 11 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm: nouveau: fix build when LEDS_CLASS=m
On 01/04/17 06:25, Ilia Mirkin wrote: > On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote: >> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>> From: Randy Dunlap >>> >>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >>> CONFIG_DRM_NOUVEAU=y. >>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >>> kconfig value as LEDS_CLASS. >>> >>> drivers/built-in.o: In function `nouveau_do_suspend': >>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >>> drivers/built-in.o: In function `nouveau_do_resume': >>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >>> drivers/built-in.o: In function `nouveau_drm_unload': >>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >>> drivers/built-in.o: In function `nouveau_drm_load': >>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >>> >>> BTW, this line in Kbuild: >>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >>> >>> Signed-off-by: Randy Dunlap >>> Reported-by: kbuild test robot >>> Cc: Martin Peres >>> Cc: Ben Skeggs >> >> Thrown into drm-misc, thanks. >> -Daniel > > Wasn't there already a different solution from Martin for this, using > IS_REACHABLE, instead of adding a dependency in Kconfig? nouveau_led.h contains a few lines that are bounded by #if IS_ENABLED(CONFIG_LEDS_CLASS) but that's not sufficient. Is there another patch? -- ~Randy
[PATCH] drm: remove immutable flag from suggested X/Y connector properties
03.01.2017 11:40, Gerd Hoffmann wrote: >>> Makes sense I think, but for merging we need: >>> - some driver to implement >> >> This is where it starts getting tricky. vboxvideo is out of tree. In >> theory I could look at getting it merged, but that needs time I am >> rather short of (I am the only person maintaining that driver and it is >> just one of my responsibilities; and there are some bits there that are >> probably too ugly to merge as is). I don't think I am really the person >> to be doing this for qxl/virtio-gpu as that required adding the support >> to qemu too. > > Not only kernel driver and qemu. Right now neither qxl nor virtio-gpu > can communicate the actual layout back to the host. So this also > requires changes to the guest/host protocol (i.e. the virtual hardware). > >>> - some userspace to take advantage of it >> >> As I wrote, mutter would be the first candidate. > > Do you have any feedback from mutter developers on the two approaches > (touchscreen-style autoconfig or x+y offsets)? The first time I wrote to them no one responded to my e-mail[1]. I could try again, asking just that question, though my plan at this time was just to submit a patch. (For Daniel, I am looking at our source code again to see if I can get it in a merge-able state with a reasonable time investment. Then there would be the "some driver to implement".) [1] https://mail.gnome.org/archives/gnome-shell-list/2016-December/msg1.html Regards Michael > > cheers, > Gerd > -- Michael Thayer | VirtualBox engineer ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: RiesstraÃe 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
[PATCH 1/2] drm_fourcc: Add new P010 video format
On Thu, Jan 05, 2017 at 12:31:27AM +0800, ayaka wrote:
>
>
> On 01/04/2017 11:56 PM, Ville Syrjälä wrote:
> > On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote:
> >> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> >> per channel video format. Rockchip's vop support this
> >> video format(little endian only) as the input video format.
> >>
> >> Signed-off-by: Randy Li
> >> ---
> >> include/uapi/drm/drm_fourcc.h | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index 9e1bb7f..d2721da 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -119,6 +119,7 @@ extern "C" {
> >> #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
> >> subsampled Cb:Cr plane */
> >> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
> >> non-subsampled Cr:Cb plane */
> >> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> >> non-subsampled Cb:Cr plane */
> >> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
> >> subsampled Cr:Cb plane 10 bits per channel */
> > We could use a better description of the format here. IIRC there is
> > 10bits of actual data contained in each 16bits. So there should be a
> > proper comment explaning in which way the bits are stored.
> It is a little hard to describe P010,
/*
* 2 plane YCbCr
* index 0 = Y plane, [15:0] Y:X 10:6 little-endian
* index 1 = Cr:Cb plane, [31:0] Cr:X:Cb:X 10:6:10:6 little-endian
*/
/*
* 2 plane YCbCr
* index 0 = Y plane, [15:0] Y 16 little-endian
* index 1 = Cr:Cb plane, [31:0] Cr:Cb 16:16 little-endian
*/
or something like that (not 100% sure I got the order of bits and
whatnot correct).
--
Ville Syrjälä
Intel OTC
[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
On Wed, Jan 04, 2017 at 04:15:01PM +, Jose Abreu wrote:
> Hi Ville,
>
>
> On 04-01-2017 13:22, Ville Syrjälä wrote:
> > On Fri, Dec 30, 2016 at 04:53:16PM +, Jose Abreu wrote:
> >> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
> >> According to the spec the EDID may contain two blocks that
> >> signal this sampling mode:
> >>- YCbCr 4:2:0 Video Data Block
> >>- YCbCr 4:2:0 Video Capability Map Data Block
> >>
> >> The video data block contains the list of vic's were
> >> only YCbCr 4:2:0 sampling mode shall be used while the
> >> video capability map data block contains a mask were
> >> YCbCr 4:2:0 sampling mode may be used.
> >>
> >> This RFC patch adds support for parsing these two new blocks
> >> and introduces new flags to signal the drivers if the
> >> mode is 4:2:0'only or 4:2:0'able.
> >>
> >> The reason this is still a RFC is because there is no
> >> reference in kernel for this new sampling mode (specially in
> >> AVI infoframe part), so, I was hoping to hear some feedback
> >> first.
> >>
> >> Tested in a HDMI 2.0 compliance scenario.
> >>
> >> Signed-off-by: Jose Abreu
> >> Cc: Carlos Palminha
> >> Cc: Daniel Vetter
> >> Cc: Jani Nikula
> >> Cc: Sean Paul
> >> Cc: David Airlie
> >> Cc: dri-devel at lists.freedesktop.org
> >> Cc: linux-kernel at vger.kernel.org
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 139
> >> +++-
> >> drivers/gpu/drm/drm_modes.c | 10 +++-
> >> include/uapi/drm/drm_mode.h | 6 ++
> >> 3 files changed, 151 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 67d6a73..6ce1a38 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct drm_connector
> >> *connector,
> >> #define VENDOR_BLOCK0x03
> >> #define SPEAKER_BLOCK 0x04
> >> #define VIDEO_CAPABILITY_BLOCK0x07
> >> +#define VIDEO_DATA_BLOCK_420 0x0E
> >> +#define VIDEO_CAP_BLOCK_420 0x0F
> >> #define EDID_BASIC_AUDIO (1 << 6)
> >> #define EDID_CEA_YCRCB444 (1 << 5)
> >> #define EDID_CEA_YCRCB422 (1 << 4)
> >> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct drm_connector
> >> *connector, u16 structure,
> >>return modes;
> >> }
> >>
> >> +static int add_420_mode(struct drm_connector *connector, u8 vic)
> >> +{
> >> + struct drm_device *dev = connector->dev;
> >> + struct drm_display_mode *newmode;
> >> +
> >> + if (!drm_valid_cea_vic(vic))
> >> + return 0;
> >> +
> >> + newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
> >> + if (!newmode)
> >> + return 0;
> >> +
> >> + newmode->flags |= DRM_MODE_FLAG_420_ONLY;
> > Why does userspace need to know this? My thinking has been that the
> > driver would do the right thing automagically.
> >
> > We do probably want some kind of output colorspace property to allow the
> > user to select between RGB vs. YCbCr etc. But I think even with that we
> > should still allow the driver to automagically select YCbCr 4:2:0 output
> > since that's the only way the mode will work.
>
> I agree. When only 4:2:0 is supported there is no need to expose
> the flag to userspace. How shall then I signal drivers for this
> 4:2:0'only sampling mode?
>
> So, for the remaining modes, you propose a new field in the mode
> structure called 'colorspace' which contains the list of
> supported sampling modes for the given mode? I think it would be
> a nice addition. This way if a mode supports only RGB we only
> passed RGB flag; if 4:2:0 was also supported we passed the 4:2:0
> flag, ... And then user could select. We also have to inform user
> which one is being actually used.
IIRC there aren't any "RGB only" modes or anything like that. So
YCbCr 4:2:0 is the special case here. We could just add something to the
mode struct for it, or do we already have some other flags thing that's
not exposed to userspace? And I guess drivers should be able to opt into
supporting these 4:2:0 modes in similar way they opt into
interlaced/stereo/whatever.
>
> Best regards,
> Jose Miguel Abreu
>
> >
> >> + drm_mode_probed_add(connector, newmode);
> >> +
> >> + return 1;
> >> +}
> >> +
> >> +static int add_420_vdb_modes(struct drm_connector *connector, const u8
> >> *svds,
> >> + u8 svds_len)
> >> +{
> >> + int modes = 0, i;
> >> +
> >> + for (i = 0; i < svds_len; i++)
> >> + modes += add_420_mode(connector, svds[i]);
> >> +
> >> + return modes;
> >> +}
> >> +
> >> +static int add_420_vcb_modes(struct drm_connector *connector, const u8
> >> *svds,
> >> + u8 svds_len, const u8 *video_db, u8 video_len)
> >> +{
> >> + struct drm_display_mode *newmode = NULL;
> >> + int modes = 0, i, j;
> >> +
> >> + for (i = 0; i < svds_len; i++) {
> >> + u8 mask = svds[i];
> >> + for (j = 0; j < 8; j++) {
> >> + if (mask & (1 << j)) {
> >> +
[Bug 99019] "Star Ruler 2" game will freeze the system
https://bugs.freedesktop.org/show_bug.cgi?id=99019 --- Comment #7 from Samuel Pitoiset --- Thanks for the info Marek, this helped me to figure out the issue. I have a fix locally for that hang, will think more before sending it though. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/76d0fafd/attachment.html>
staging/fbtft: Backward Device Tree compatibility in a drm version
Hi,
I'm working on a drivers/gpu/drm version of drivers/staging/fbtft which
are drivers for tiny, usually SPI connected, displays. Now I'm wondering
if I can be backwards compatible and support Device Trees written for the
fbtft drivers. The main obstacle as I understand it, is the init property
which are values to be written to the controller registers to support a
different panel with the same controller. It even has encoded values for
delays... My understanding is that this is not accepted.
It's in fact a display panel description in the form of register values
and delays.
Here is what a binding doc would look like for one of the fbtft drivers:
* Samsung S6D02A1 Framebuffer Driver
Required properties:
- compatible: Should be "samsung,s6d02a1".
The node for this driver must be a child node of a SPI controller, hence
all mandatory properties described in ../spi/spi-bus.txt must be specified.
Optional properties:
- dc-gpios:D/C pin used with the 4-wire 8-bit data serial interface mode
- reset-gpios:Reset pin
- led-gpios:Backlight control
- width:Panel width in pixels
- height:Panel height in pixels
- rotate:Panel rotation in degrees counter clockwise (0,90,180,270)
- bgr:Panel is wired as BGR565 instead of RGB565
- buswidth:Bit width of the bus, in the case of SPI: 8 (4-wire) or 9
(3-wire) bits.
- txbuflen:Size of transfer buffer. Used for little-big endian
conversion.
- debug:Control debug output to the kernel log
- init:Panel initialization sequence overriding the driver default.
Values OR'ed with:
0x100 - Write the following values to this register.
0x200 - Delay in milliseconds
Example:
mz61581: mz61581 at 0{
compatible = "samsung,s6d02a1";
reg = <0>;
spi-max-frequency = <12800>;
spi-cpol;
spi-cpha;
width = <320>;
height = <480>;
rotate = <270>;
bgr;
buswidth = <8>;
txbuflen = <32768>;
reset-gpios = <&gpio 15 0>;
dc-gpios = <&gpio 25 0>;
led-gpios = <&gpio 18 0>;
init = <0x1b0 00
0x111
0x2ff
0x1b3 0x02 0x00 0x00 0x00
0x1c0 0x13 0x3b 0x00 0x02 0x00 0x01 0x00 0x43
0x1c1 0x08 0x16 0x08 0x08
0x1c4 0x11 0x07 0x03 0x03
0x1c6 0x00
0x1c8 0x03 0x03 0x13 0x5c 0x03 0x07 0x14 0x08 0x00 0x21
0x08 0x14 0x07 0x53 0x0c 0x13 0x03 0x03 0x21 0x00
0x135 0x00
0x136 0xa0
0x13a 0x55
0x144 0x00 0x01
0x1d0 0x07 0x07 0x1d 0x03
0x1d1 0x03 0x30 0x10
0x1d2 0x03 0x14 0x04
0x129
0x12c>;
/* This is a workaround to make sure the init sequence slows down
and doesn't fail */
debug = <3>;
};
Noralf.
[PATCH v4] drm: add fourcc codes for 16bit R and RG
On Wednesday, 2017-01-04 14:50:02 +0100, Rainer Hochecker wrote:
> From: Rainer Hochecker
>
> Signed-off-by: Rainer Hochecker
> ---
> include/uapi/drm/drm_fourcc.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index a5890bf..4d65fb6 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -41,10 +41,17 @@ extern "C" {
> /* 8 bpp Red */
> #define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
>
> +/* 16 bpp Red */
> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /*
> [15:0] R */
> +
> /* 16 bpp RG */
> #define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /*
> [15:0] R:G 8:8 little endian */
> #define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /*
> [15:0] G:R 8:8 little endian */
>
> +/* 32 bpp RG */
> +#define DRM_FORMAT_RG1616fourcc_code('R', 'G', '3', '2') /* [31:0] G:R
> 16:16 little endian */
Comment above is still wrong: s/G:R/R:G/ :)
> +#define DRM_FORMAT_GR1616fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
> 16:16 little endian */
> +
> /* 8 bpp RGB */
> #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
> 3:3:2 */
> #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
> 2:3:3 */
> --
> 2.9.3
>
[PATCH 1/2] drm_fourcc: Add new P010 video format
On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote:
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> per channel video format. Rockchip's vop support this
> video format(little endian only) as the input video format.
>
> Signed-off-by: Randy Li
> ---
> include/uapi/drm/drm_fourcc.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9e1bb7f..d2721da 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -119,6 +119,7 @@ extern "C" {
> #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1
> subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
> subsampled Cr:Cb plane 10 bits per channel */
We could use a better description of the format here. IIRC there is
10bits of actual data contained in each 16bits. So there should be a
proper comment explaning in which way the bits are stored.
>
> /*
> * 3 plane YCbCr
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
Unix Device Memory Allocation project
Am 04.01.2017 um 17:16 schrieb Rob Clark: > On Wed, Jan 4, 2017 at 11:02 AM, Christian König > wrote: >> Am 04.01.2017 um 16:47 schrieb Rob Clark: >>> On Wed, Jan 4, 2017 at 9:54 AM, Daniel Vetter wrote: On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote: > On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone > wrote: >>> Speaking of compression for display, especially the separate >>> compression buffer: That should be fully contained in the main DMABUF >>> and described by the per-BO metadata. Some other drivers want to use a >>> separate DMABUF for the compression buffer - while that may sound good >>> in theory, it's not economical for the reason described above. >> 'Some other drivers want to use a separate DMABUF', or 'some other >> hardware demands the data be separate'. Same with luma/chroma plane >> separation. Anyway, it doesn't really matter unless you're sharing >> render-compression formats across vendors, and AFBC is the only case >> of that I know of currently. > > jfwiw, UBWC on newer snapdragons too.. seems like we can share these > not just between gpu (render to and sample from) and display, but also > v4l2 decoder/encoder (and maybe camera?) > > I *think* we probably can treat the metadata buffers as a separate > plane.. at least we can for render target and blit src/dst, but not > 100% sure about sampling from a UBWC buffer.. that might force us to > have them in a single buffer. Conceptually treating them as two planes, and everywhere requiring that they're allocated from the same BO are orthogonal things. At least that's our plan with intel render compression last time I understood the current state ;-) >>> If the position of the different parts of the buffer are somewhere >>> required to be a function of w/h/bpp/etc then I'm not sure if there is >>> a strong advantage to treating them as separate BOs.. although I >>> suppose it doesn't preclude it either. As far as plumbing it through >>> mesa/st, it seems convenient to have a single buffer. (We have kind >>> of a hack to deal w/ multi-planar yuv, but I'd rather not propagate >>> that.. but I've not thought through those details so much yet.) >> >> Well I don't want to ruin your day, but there are different requirements >> from different hardware. >> >> For example the UVD engine found in all AMD graphics cards since r600 must >> have both planes in a single BO because the memory controller can only >> handle a rather small offset between the planes. >> >> On the other hand I know of embedded MPEG2/H264 decoders where the different >> planes must be on different memory channels. In this case I can imagine that >> you want one BO for each plane, because otherwise the device must stitch >> together one buffer object from two different memory regions (of course >> possible, but rather ugly). > true, but for a vendor specific compression/metadata plane, I think I > can ignore oddball settop box SoC constraints and care more about just > other devices that support the same compression. > >> So if we want to cover everything we essentially need to support all >> variants of one plane per BO as well as all planes in one BO with DMA-Buf. A >> bit tricky isn't it? > Just to make sure we are on same page, I was only really talking about > whether to have color+meta in same bo or treat it similar to two plane > yuv (ie. pair of fd+offset tuples). Not generic/vanilla (untiled, > uncompressed, etc) multiplanar YUV. Ups, sorry. I didn't realized that. Na, putting the metadata into the BO is probably only a good idea if the Metadata can be evaluated by the device and not the CPU as well. > > It probably isn't even important that various different vendor's > compression schemes are handled the same way. Maybe on intel it is > easier to treat it as two planes everywhere, but qcom easier to treat > as one. Application just sees it as one or more fd+offset tuples > (when it queries EGL img) and passes those blindly through to addfb2. Yeah, I mean that's the real core of the problem. On the one hand we want device from different vendors to understand each other and there are certain cases where even completely different devices can work with the same data. On the other hand each vendor has extremely specialized data formats for certain use cases and it is unlikely that somebody else can handle those. > Oh, and for some extra fun, I think video decoder can hand me > compressed NV12 where both Y and UV have their own meta buffer. So if > we treat as separate planes, that becomes four planes. (Hopefully no > compressed I420, or that becomes 6 planes! :-P) Well talking about extra fun. We additionally have this neat interlaced NV12 format that both NVidia and AMD uses for their video decoding. E.g. one Y plane top field, one UV plane top field, one Y plane bottom field and UV plane bottom field. That makes 4 planes where pl
[PULL] drm-misc-fixes
Hi Dave, One small bugfix to the atomic helpers from Laurent. Haz cc: stable. Cheers, Daniel The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88: Linux 4.10-rc2 (2017-01-01 14:31:53 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-01-04 for you to fetch changes up to aebe55c2d4b998741c0847ace1b4af47d73c763b: drm: Clean up planes in atomic commit helper failure path (2017-01-04 11:08:13 +0100) Laurent Pinchart (1): drm: Clean up planes in atomic commit helper failure path drivers/gpu/drm/drm_atomic_helper.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v5 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
Hi Hoegeun,
I tested this patch. But this patch does not include my tested-by tag.
Tested-by: Chanwoo Choi
Regards,
Chanwoo Choi
On 2017ë
01ì 04ì¼ 17:15, Hoegeun Kwon wrote:
> From: Hyungwon Hwang
>
> This patch add the panel device tree node for S6E3HA2 display
> controller to TM2 dts.
>
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Hoegeun Kwon
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 5b9451d..b3ba1ac 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -304,11 +304,28 @@
> reg = <1>;
>
> dsi_out: endpoint {
> + remote-endpoint = <&panel_in>;
> samsung,burst-clock-frequency = <51200>;
> samsung,esc-clock-frequency = <1600>;
> };
> };
> };
> +
> + panel at 0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> + };
> };
>
> &hsi2c_0 {
>
--
Regards,
Chanwoo Choi
[PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Hi Hoegeun,
I already tested this patch. But this patch does not include my tested-by tag.
Tested-by: Chanwoo Choi
Regards,
Chanwoo Choi
On 2017ë
01ì 04ì¼ 17:15, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Hoegeun Kwon
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741
> +
> 4 files changed, 788 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 000..6879f51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> @@ -0,0 +1,40 @@
> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
> +
> +Required properties:
> + - compatible: "samsung,s6e3ha2"
> + - reg: the virtual channel number of a DSI peripheral
> + - vdd3-supply: I/O voltage supply
> + - vci-supply: voltage supply for analog circuits
> + - reset-gpios: a GPIO spec for the reset pin (active low)
> + - enable-gpios: a GPIO spec for the panel enable pin (active high)
> + - te-gpios: a GPIO spec for the tearing effect synchronization signal
> +gpio pin (active high)
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [1]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +&dsi {
> + ...
> +
> + panel at 0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> + };
> +};
> +
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 62aba97..eea2902 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
> WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
> Xperia Z2 tablets
>
> +config DRM_PANEL_SAMSUNG_S6E3HA2
> + tristate "Samsung S6E3HA2 DSI video mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> +
> config DRM_PANEL_SAMSUNG_S6E8AA0
> tristate "Samsung S6E8AA0 DSI video mode panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index a5c7ec0..1d483b0 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
> panel-jdi-lt070me05000.o
> obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
> panel-panasonic-vvx10f034n00.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> new file mode 100644
> index 000..8c5a1c2
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> @@ -0,0 +1,741 @@
> +/*
> + * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * Donghwa Lee
> + * Hyungwon Hwang
> + * Hoegeun Kwon
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define S6E3HA2_MIN_BRIGHTNESS 0
> +#define S6E3HA2_MAX_BRIGHTNESS 100
> +#define S6E3HA2_DEFAULT_BRIGHTNESS 80
> +
> +#define S6E3HA2_NUM_GAMMA_STEPS 46
> +#define S6E3HA2_GAMMA_CMD_C
[RFC 0/6] drm: Add support for userspace drivers
On 04/01/17 17:06, Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 02:34:36PM +0100, Noralf Trønnes wrote: >> Hi, >> >> I was previously working on tinydrm as a replacement for staging/fbtft. >> During a break from that work, I started to think about if it would be >> possible to move the drivers to userspace instead. No point in having >> them in the kernel if it's not necessary. >> >> This patchset includes all the pieces necessary to get a userspace >> driver[1] working that is compatible with the fbtft/fb_ili9341 driver. >> It is tested with a SPI interfaced display hat/shield for the Raspberry Pi, >> which has an eeprom with a Device Tree fragment on it (merged by the >> bootloader). With the help of udev and systemd, the driver is able to >> autoload when the display is connected. >> Performance wise, the kernel driver can do ~19fps on a 320x240 spi at 32MHz >> display, whereas the userspace version does ~18fps. So performance is not >> an argument to keep the driver in the kernel. >> >> What do you think about this approach? > > It's a pretty nifty thing, and iirc some of the ideas for implementing > miracast centered around the same idea: Small userspace drm driver shim > that forwards everything to the miracast code running all in userspace. > David Herrmann looked into that years ago, not sure he ever got the full > stack up&running. This is actually something David Herrmann told us not to do, stating that it was too hard for Desktop Environments to select which GPUs to output to. I however disagreed as this is something they need to support anyway for USB GPUs and miracast could piggy back on this effort. An engineer in Intel Finland did work on this and we got approval for Open Sourcing it but I really have no time for this right now though :s That was my 2 cents. Martin
[PATCH v5 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 5b9451d..b3ba1ac 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -304,11 +304,28 @@
reg = <1>;
dsi_out: endpoint {
+ remote-endpoint = <&panel_in>;
samsung,burst-clock-frequency = <51200>;
samsung,esc-clock-frequency = <1600>;
};
};
};
+
+ panel at 0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
};
&hsi2c_0 {
--
1.9.1
[PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 +
4 files changed, 788 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..6879f51
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,40 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+ - compatible: "samsung,s6e3ha2"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: I/O voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin (active low)
+ - enable-gpios: a GPIO spec for the panel enable pin (active high)
+ - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [1]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+&dsi {
+ ...
+
+ panel at 0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+};
+
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..eea2902 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
Xperia Z2 tablets
+config DRM_PANEL_SAMSUNG_S6E3HA2
+ tristate "Samsung S6E3HA2 DSI video mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..8c5a1c2
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,741 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee
+ * Hyungwon Hwang
+ * Hoegeun Kwon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT 35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00,
[PATCH v5 1/3] drm/exynos: mic: Add mode_set callback function
Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0b..a0f459c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;
- ret = of_get_videomode(remote_node,
- &mic->vm, 0);
- if (ret) {
- DRM_ERROR("mic: failed to get videomode");
- goto exit;
- }
-
break;
default:
DRM_ERROR("mic: Unknown endpoint from MIC");
@@ -329,6 +322,24 @@ static void mic_post_disable(struct drm_bridge *bridge)
mutex_unlock(&mic_mutex);
}
+static void mic_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct exynos_mic *mic = bridge->driver_private;
+
+ mutex_lock(&mic_mutex);
+
+ drm_display_mode_to_videomode(mode, &mic->vm);
+
+ if (!mic->i80_mode)
+ mic_set_porch_timing(mic);
+ mic_set_img_size(mic);
+ mic_set_output_timing(mic);
+
+ mutex_unlock(&mic_mutex);
+}
+
static void mic_pre_enable(struct drm_bridge *bridge)
{
struct exynos_mic *mic = bridge->driver_private;
@@ -355,10 +366,6 @@ static void mic_pre_enable(struct drm_bridge *bridge)
goto turn_off_clks;
}
- if (!mic->i80_mode)
- mic_set_porch_timing(mic);
- mic_set_img_size(mic);
- mic_set_output_timing(mic);
mic_set_reg_on(mic, 1);
mic->enabled = 1;
mutex_unlock(&mic_mutex);
@@ -377,6 +384,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
static const struct drm_bridge_funcs mic_bridge_funcs = {
.disable = mic_disable,
.post_disable = mic_post_disable,
+ .mode_set = mic_mode_set,
.pre_enable = mic_pre_enable,
.enable = mic_enable,
};
--
1.9.1
[PATCH v5 0/3] Add support for the S6E3HA2 panel on TM2 board
Purpose of this patch is add support for S6E3HA2 AMOLED panel on the TM2 board. The first patch adds support for S6E3HA2 panel device tree document and driver, the second patch add support for S6E3HA2 panel device tree. Change for V5: - The V5 has only one fix in V4 below. - Removed the enable check of the mic driver in mode_set callback, because mode_set should be performed every time. Changes for V4: - Removed display-timings in devicetree, the display-timings has been fixed to be provided by the device driver. - Added the mode_set callback function into exynos_drm_mic, because the exynos_drm_mic driver can not parse a videomode struct by removing the display-timings from the devicetree. Hoegeun Kwon (2): drm/exynos: mic: Add mode_set callback function drm/panel: Add support for S6E3HA2 panel driver on TM2 board Hyungwon Hwang (1): arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board .../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++ arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 + drivers/gpu/drm/exynos/exynos_drm_mic.c| 30 +- drivers/gpu/drm/panel/Kconfig | 6 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 + 6 files changed, 824 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c -- 1.9.1
[Intel-gfx] [PATCH 9/9] drm/i915: Add render decompression support
Em Qua, 2017-01-04 Ã s 20:42 +0200, ville.syrjala at linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display
> engine
> the location of the color control surfae (CCS) which describes
> which parts of the main surface are compressed and which are not. The
> location of CCS is provided by userspace as just another plane with
> its
> own offset.
>
> Add the required stuff to validate the user provided AUX plane
> metadata
> and convert the user provided linear offset into something the
> hardware
> can consume.
>
> Due to hardware limitations we require that the main surface and
> the AUX surface (CCS) be part of the same bo. The hardware also
> makes life hard by not allowing you to provide separate x/y offsets
> for the main and AUX surfaces (excpet with NV12), so finding suitable
> offsets for both requires a bit of work. Assuming we still want keep
> playing tricks with the offsets. I've just gone with a dumb "search
> backward for suitable offsets" approach, which is far from optimal,
> but it works.
>
> Also not all planes will be capable of scanning out compressed
> surfaces,
> and eg. 90/270 degree rotation is not supported in combination with
> decompression either.
>
> This patch may contain work from at least the following people:
> * Vandana Kannan
> * Daniel Vetter
> * Ben Widawsky
As I mentioned to Ben in the other email, there are some points of
BSpec that say "if render decompression is enabled, to this", which we
largely ignored so far. I hope they are all marked as workarounds. From
a quick look, it looks like we need at least Display WAs #0390, #0531
and #1125, and maybe some other non-display WAs (please take a look at
the BSpec list). I'll assume they were not implemented yet since I
don't see WA comments on the patches. I think we need them, otherwise
we may introduce more SKL flickering problems.
Thanks,
Paulo
>
> Cc: Vandana Kannan
> Cc: Daniel Vetter
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Signed-off-by: Ville Syrjälä
> ---
>  drivers/gpu/drm/i915/i915_reg.h      |  22
> Â drivers/gpu/drm/i915/intel_display.c | 219
> +--
>  drivers/gpu/drm/i915/intel_pm.c      |   8 +-
>  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
> Â 4 files changed, 240 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa77afa..05e18e742776 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6209,6 +6209,28 @@ enum {
> Â _ID(id, _PS_ECC_STAT_1A,
> _PS_ECC_STAT_2A),   \
> Â _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> Â
> +#define PLANE_AUX_DIST_1_A 0x701c0
> +#define PLANE_AUX_DIST_2_A 0x702c0
> +#define PLANE_AUX_DIST_1_B 0x711c0
> +#define PLANE_AUX_DIST_2_B 0x712c0
> +#define _PLANE_AUX_DIST_1(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_1_A,
> PLANE_AUX_DIST_1_B)
> +#define _PLANE_AUX_DIST_2(pipe) \
> + _PIPE(pipe, PLANE_AUX_DIST_2_A,
> PLANE_AUX_DIST_2_B)
> +#define PLANE_AUX_DIST(pipe, plane)Â Â Â Â Â \
> + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
> _PLANE_AUX_DIST_2(pipe))
> +
> +#define PLANE_AUX_OFFSET_1_A 0x701c4
> +#define PLANE_AUX_OFFSET_2_A 0x702c4
> +#define PLANE_AUX_OFFSET_1_B 0x711c4
> +#define PLANE_AUX_OFFSET_2_B 0x712c4
> +#define _PLANE_AUX_OFFSET_1(pipe)Â Â Â Â Â Â Â \
> + _PIPE(pipe, PLANE_AUX_OFFSET_1_A,
> PLANE_AUX_OFFSET_1_B)
> +#define _PLANE_AUX_OFFSET_2(pipe)Â Â Â Â Â Â Â \
> + _PIPE(pipe, PLANE_AUX_OFFSET_2_A,
> PLANE_AUX_OFFSET_2_B)
> +#define PLANE_AUX_OFFSET(pipe, plane)Â Â Â \
> + _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe),
> _PLANE_AUX_OFFSET_2(pipe))
> +
> Â /* legacy palette */
> Â #define _LGC_PALETTE_AÂ Â Â Â Â Â Â Â Â Â Â 0x4a000
> Â #define _LGC_PALETTE_BÂ Â Â Â Â Â Â Â Â Â Â 0x4a800
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 38de9df0ec60..b547332eeda1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct
> drm_framebuffer *fb, int plane)
> Â return 128;
> Â else
> Â return 512;
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + if (plane == 1)
> + return 64;
> + /* fall through */
> Â case I915_FORMAT_MOD_Y_TILED:
> Â if (IS_GEN2(dev_priv) ||
> HAS_128_BYTE_Y_TILING(dev_priv))
> Â return 128;
> Â else
> Â return 512;
> + case I915_FORMAT_MOD_Yf_TILED_CCS:
> + if (plane == 1)
> + return 64;
> +
[PATCH v3 06/13] drm: bridge: Add LVDS encoder driver
Hi Daniel, On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote: > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote: > > On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote: > >> Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be > >> enough, or not? My idea is to use this for the case where the only > >> thing in dt is the panel, with no real bridge chip. And I think we > >> don't need anything beyond that one _init function, plus maybe some > >> additional paramaters ... > > > > There should be no bridge then. If you want the DRM core to manage panels > > automatically, then we should create specific helpers for that, not abuse > > the bridge infrastructure. Bridges should be instantiated from a hardware > > device and bound to drivers as usual. > > I guess that's the part where I disagree: Just because there's physically > no bridge doesn't mean we shouldn't just treat it as one in the software > abstraction. If it looks and acts like a bridge (even an empty one), then > imo it can be a bridge. > > If you insist on panels being panels, then I guess we need some other kind > of glue to bind them into arbitrary bridge chains. But given that the > callbacks match very closely, I don't see the point. > > In an idea world a panel would probably derive from a drm_bridge, but > we're not in that universe unfortunately ;-) Or both would derive from another object, but I agree that's how it should work. That's what I want to achieve, one step at a time. Creating dummy bridges isn't a step in that direction in my opinion, so I'd rather not do that, but work towards the right abstraction. -- Regards, Laurent Pinchart
[PATCH] drm: Add kernel-doc for drm_crtc_commit_get/put
On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote:
> I was lazy, rectify that! Also align with drm_atomic_state_get/put for
> ocd.
>
> v2: Git add helps.
>
> Signed-off-by: Daniel Vetter
Anyone feel like acking this, pretty please? ;-)
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 9 ++---
> include/drm/drm_atomic.h | 21 -
> 2 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index b1b54011a92c..26a4cfdf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -35,19 +35,14 @@
>
> #include "drm_crtc_internal.h"
>
> -static void crtc_commit_free(struct kref *kref)
> +void __drm_crtc_commit_free(struct kref *kref)
> {
> struct drm_crtc_commit *commit =
> container_of(kref, struct drm_crtc_commit, ref);
>
> kfree(commit);
> }
> -
> -void drm_crtc_commit_put(struct drm_crtc_commit *commit)
> -{
> - kref_put(&commit->ref, crtc_commit_free);
> -}
> -EXPORT_SYMBOL(drm_crtc_commit_put);
> +EXPORT_SYMBOL(__drm_crtc_commit_free);
>
> /**
> * drm_atomic_state_default_release -
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 91b18bd7cb50..97587ec36eae 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -199,12 +199,31 @@ struct drm_atomic_state {
> struct work_struct commit_work;
> };
>
> -void drm_crtc_commit_put(struct drm_crtc_commit *commit);
> +void __drm_crtc_commit_free(struct kref *kref);
> +
> +/**
> + * drm_crtc_commit_get - acquire a reference to the CRTC commit
> + * @commit: CRTC commit
> + *
> + * Increases the reference of @commit.
> + */
> static inline void drm_crtc_commit_get(struct drm_crtc_commit *commit)
> {
> kref_get(&commit->ref);
> }
>
> +/**
> + * drm_crtc_commit_put - release a reference to the CRTC commmit
> + * @commit: CRTC commit
> + *
> + * This releases a reference to @commit which is freed after removing the
> + * final reference. No locking required and callable from any context.
> + */
> +static inline void drm_crtc_commit_put(struct drm_crtc_commit *commit)
> +{
> + kref_put(&commit->ref, __drm_crtc_commit_free);
> +}
> +
> struct drm_atomic_state * __must_check
> drm_atomic_state_alloc(struct drm_device *dev);
> void drm_atomic_state_clear(struct drm_atomic_state *state);
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format
Hi Randy,
On 4 January 2017 at 16:29, Randy Li wrote:
> index 90d2cc8..23c8e99 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> + /* FIXME a pixel in Y for P010 is 10 bits */
> + { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
It seems like P010 stores each Y component in a 16-bit value, with the
bottom 6 bits ignored. So I think cpp here should be 2.
Cheers,
Daniel
Unix Device Memory Allocation project
Am 04.01.2017 um 16:47 schrieb Rob Clark: > On Wed, Jan 4, 2017 at 9:54 AM, Daniel Vetter wrote: >> On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote: >>> On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone >>> wrote: > Speaking of compression for display, especially the separate > compression buffer: That should be fully contained in the main DMABUF > and described by the per-BO metadata. Some other drivers want to use a > separate DMABUF for the compression buffer - while that may sound good > in theory, it's not economical for the reason described above. 'Some other drivers want to use a separate DMABUF', or 'some other hardware demands the data be separate'. Same with luma/chroma plane separation. Anyway, it doesn't really matter unless you're sharing render-compression formats across vendors, and AFBC is the only case of that I know of currently. >>> >>> jfwiw, UBWC on newer snapdragons too.. seems like we can share these >>> not just between gpu (render to and sample from) and display, but also >>> v4l2 decoder/encoder (and maybe camera?) >>> >>> I *think* we probably can treat the metadata buffers as a separate >>> plane.. at least we can for render target and blit src/dst, but not >>> 100% sure about sampling from a UBWC buffer.. that might force us to >>> have them in a single buffer. >> Conceptually treating them as two planes, and everywhere requiring that >> they're allocated from the same BO are orthogonal things. At least that's >> our plan with intel render compression last time I understood the current >> state ;-) > If the position of the different parts of the buffer are somewhere > required to be a function of w/h/bpp/etc then I'm not sure if there is > a strong advantage to treating them as separate BOs.. although I > suppose it doesn't preclude it either. As far as plumbing it through > mesa/st, it seems convenient to have a single buffer. (We have kind > of a hack to deal w/ multi-planar yuv, but I'd rather not propagate > that.. but I've not thought through those details so much yet.) Well I don't want to ruin your day, but there are different requirements from different hardware. For example the UVD engine found in all AMD graphics cards since r600 must have both planes in a single BO because the memory controller can only handle a rather small offset between the planes. On the other hand I know of embedded MPEG2/H264 decoders where the different planes must be on different memory channels. In this case I can imagine that you want one BO for each plane, because otherwise the device must stitch together one buffer object from two different memory regions (of course possible, but rather ugly). So if we want to cover everything we essentially need to support all variants of one plane per BO as well as all planes in one BO with DMA-Buf. A bit tricky isn't it? Regards, Christian. > > BR, > -R > >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Unix Device Memory Allocation project
Hi Christian, On 4 January 2017 at 16:02, Christian König wrote: > Am 04.01.2017 um 16:47 schrieb Rob Clark: >> If the position of the different parts of the buffer are somewhere >> required to be a function of w/h/bpp/etc then I'm not sure if there is >> a strong advantage to treating them as separate BOs.. although I >> suppose it doesn't preclude it either. As far as plumbing it through >> mesa/st, it seems convenient to have a single buffer. (We have kind >> of a hack to deal w/ multi-planar yuv, but I'd rather not propagate >> that.. but I've not thought through those details so much yet.) > > Well I don't want to ruin your day, but there are different requirements > from different hardware. > > For example the UVD engine found in all AMD graphics cards since r600 must > have both planes in a single BO because the memory controller can only > handle a rather small offset between the planes. This is, to a large extent, also true of Intel. > On the other hand I know of embedded MPEG2/H264 decoders where the different > planes must be on different memory channels. In this case I can imagine > you want one BO for each plane, because otherwise the device must stitch > together one buffer object from two different memory regions (of course > possible, but rather ugly). Not just embedded, but quite a few platforms where the ratio of required to available memory bandwidth is ... somewhat different to larger discrete systems. Striping allocations such that luma and chroma live on different memory channels isn't uncommon. But I think this is all orthogonal. If you keep auxiliary planes in separate BOs to metadata, you can still handle both cases. How to place buffers is purely an _allocation_ concern, where single vs. multiple BO is purely about addressing them. So your allocator API may become a little more complex - something which only device-specific userspace will ever address - whilst keeping a unified addressing/handle system for the generic parts of userspace which shouldn't have to care about whether the underlying hardware demands a small offset or a completely separate allocation. Having API pegged to the single-underlying-BO concept has been a giant pain for those who can't use single BOs. I don't see anything good coming of the idea for cross-device/cross-vendor sharing either, since it encodes yet more magic implicit detail into buffer sharing. Since that detail ultimately has to be resolved _somewhere_, it's a problem avoided rather than a problem solved. Cheers, Daniel
[PATCH v2] drm/atomic: Fix outdated comment.
On Wed, Jan 04, 2017 at 12:34:00PM +0100, Maarten Lankhorst wrote:
> Op 04-01-17 om 12:28 schreef Daniel Vetter:
> > On Wed, Jan 04, 2017 at 11:22:54AM +, Chris Wilson wrote:
> >> On Wed, Jan 04, 2017 at 12:15:55PM +0100, Maarten Lankhorst wrote:
> >>> Op 15-12-16 om 16:19 schreef Daniel Vetter:
> On Thu, Dec 15, 2016 at 03:29:42PM +0100, Maarten Lankhorst wrote:
> > drm_atomic_state_put is called unconditionally, so TEST_ONLY is no
> > different from commit.
> >
> > Signed-off-by: Maarten Lankhorst
> I think it'd be good to update the kerneldoc for the atomic_commit
> callback to mention that drivers should grab their own references using
> drm_atomic_state_get() when they need it.
>
> Applied this one meanwhile, thanks.
> >>> --->8---
> >>> Commit 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> >>> adds reference counting to atomic state, but didn't update the comments
> >>> in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more.
> >>>
> >>> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> >>> Cc: # v4.10-rc1+
> >>> Cc: Chris Wilson
> >>> Signed-off-by: Maarten Lankhorst
> >>> ---
> >>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>> index 681d5f97639d..6492546476b4 100644
> >>> --- a/drivers/gpu/drm/drm_atomic.c
> >>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> @@ -1599,10 +1599,9 @@ EXPORT_SYMBOL(drm_atomic_check_only);
> >>> * more locks but encountered a deadlock. The caller must then do the
> >>> usual w/w
> >>> * backoff dance and restart. All other errors are fatal.
> >>> *
> >>> - * Also note that on successful execution ownership of @state is
> >>> transferred
> >>> - * from the caller of this function to the function itself. The caller
> >>> must not
> >>> - * free or in any other way access @state. If the function fails then
> >>> the caller
> >>> - * must clean up @state itself.
> >>> + * In earlier versions of the atomic api, the caller was handing its
> >>> reference
> >>> + * of @state over to this function on success. This is no longer the
> >>> case, and
> >>> + * callers should always call drm_atomic_state_put().
> >>> *
> >>> * Returns:
> >>> * 0 on success, negative error code on failure.
> >>> @@ -1630,10 +1629,9 @@ EXPORT_SYMBOL(drm_atomic_commit);
> >>> * more locks but encountered a deadlock. The caller must then do the
> >>> usual w/w
> >>> * backoff dance and restart. All other errors are fatal.
> >>> *
> >>> - * Also note that on successful execution ownership of @state is
> >>> transferred
> >>> - * from the caller of this function to the function itself. The caller
> >>> must not
> >>> - * free or in any other way access @state. If the function fails then
> >>> the caller
> >>> - * must clean up @state itself.
> >>> + * In earlier versions of the atomic api, the caller was handing its
> >>> reference
> >>> + * of @state over to this function on success. This is no longer the
> >>> case, and
> >>> + * callers should always call drm_atomic_state_put().
> >> Reviewed-by: Chris Wilson
> >>
> >> But do we really want the confusion of mentioning what the api doesn't do
> >> any more?
> > Agreed, kerneldoc should state what is (and why), maybe with a FIXME if it
> > only makes sense with some hystorical context and what should be done
> > instead. git blame is for figuring out what was.
> >
> > Maarten, can you pls respin?
> > -Daniel
>
> 8<---
> Commit 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> adds reference counting to atomic state, but didn't update the comments
> in drm_atomic_(nonblocking_)commit. Clarify lifetime a bit more.
>
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: # v4.10-rc1+
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson
> Signed-off-by: Maarten Lankhorst
Applied to drm-misc, thanks.
-Daniel
> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 681d5f97639d..672f1de84d6c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1599,10 +1599,8 @@ EXPORT_SYMBOL(drm_atomic_check_only);
> * more locks but encountered a deadlock. The caller must then do the usual
> w/w
> * backoff dance and restart. All other errors are fatal.
> *
> - * Also note that on successful execution ownership of @state is transferred
> - * from the caller of this function to the function itself. The caller must
> not
> - * free or in any other way access @state. If the function fails then the
> caller
> - * must clean up @state itself.
> + * This function will take its own reference on @state.
> + * Callers should always release their reference with drm_atomic_state_put().
> *
> * Returns:
> * 0 on success, negative error code on failure.
> @@ -1630,10 +1628,8 @@ EXPORT_SYMBOL(drm_atomic_commit);
> * more locks but encountered a deadlock. The caller must then do the usual
> w/w
>
[PATCH] drm/atomic: Add target_vblank support in atomic helpers.
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, January 04, 2017 3:44 AM
> To: Grodzovsky, Andrey
> Cc: dri-devel at lists.freedesktop.org; daniel.vetter at ffwll.ch; Deucher,
> Alexander; Daenzer, Michel; Wentland, Harry
> Subject: Re: [PATCH] drm/atomic: Add target_vblank support in atomic
> helpers.
>
> On Tue, Jan 03, 2017 at 10:06:38AM -0500, Andrey Grodzovsky wrote:
> > Allows usage of the new page_flip_target hook for drivers implementing
> > the atomic path.
> > Provides default atomic helper for the new hook.
> >
> > Signed-off-by: Andrey Grodzovsky
>
> Please keep a per-patch changelog so that it's easier for everyone to follow
> the evolution of this patch.
>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 146
>
> > include/drm/drm_atomic_helper.h | 6 ++
> > include/drm/drm_crtc.h | 3 +
> > 3 files changed, 125 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 583f47f..5e76f90 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2733,6 +2733,59 @@ int drm_atomic_helper_resume(struct
> drm_device
> > *dev, } EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
> >
> > +static int drm_atomic_helper_page_flip_create_state(
>
> I'd just call this page_flip_common without the long namespace prefix since
> it's static. And without the create_state name since this function also does
> some basic checks.
>
> > + struct drm_atomic_state *state,
> > + struct drm_crtc *crtc,
> > + struct drm_framebuffer *fb,
> > + struct drm_pending_vblank_event *event) {
> > + struct drm_plane *plane = crtc->primary;
> > + struct drm_plane_state *plane_state;
> > + struct drm_crtc_state *crtc_state;
> > + int ret = 0;
> > +
> > + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > + if (IS_ERR(crtc_state))
> > + return PTR_ERR(crtc_state);
> > +
> > + crtc_state->event = event;
> > +
> > + plane_state = drm_atomic_get_plane_state(state, plane);
> > + if (IS_ERR(plane_state))
> > + return PTR_ERR(plane_state);
> > +
> > +
> > + ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> > + if (ret != 0)
> > + return ret;
> > + drm_atomic_set_fb_for_plane(plane_state, fb);
> > +
> > + /* Make sure we don't accidentally do a full modeset. */
> > + state->allow_modeset = false;
> > + if (!crtc_state->active) {
> > + DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy
> flip\n",
> > +crtc->base.id);
> > + return -EINVAL;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static void drm_atomic_helper_page_flip_prepare_retry(
> > + struct drm_atomic_state *state,
> > + struct drm_plane *plane)
> > +{
> > + drm_atomic_state_clear(state);
> > + drm_atomic_legacy_backoff(state);
> > +
> > + /*
> > +* Someone might have exchanged the framebuffer while we
> dropped locks
> > +* in the backoff code. We need to fix up the fb refcount tracking the
> > +* core does for us.
> > +*/
> > + plane->old_fb = plane->fb;
>
> There's a lot more places where we do this trick, please either refactor them
> all, or none. Personally I'd go with none since the function call is more
> verbose than the assignement, and you're hiding this rather important
> comment behind a function name that doesn't say what games are being
> played here.
>
> > +}
> > +
> > /**
> > * drm_atomic_helper_page_flip - execute a legacy page flip
> > * @crtc: DRM crtc
> > @@ -2756,8 +2809,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc
> > *crtc, {
> > struct drm_plane *plane = crtc->primary;
> > struct drm_atomic_state *state;
> > - struct drm_plane_state *plane_state;
> > - struct drm_crtc_state *crtc_state;
> > int ret = 0;
> >
> > if (flags & DRM_MODE_PAGE_FLIP_ASYNC) @@ -2768,35 +2819,79
> @@ int
> > drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> > return -ENOMEM;
> >
> > state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
> > +
> > retry:
> > - crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > - if (IS_ERR(crtc_state)) {
> > - ret = PTR_ERR(crtc_state);
> > + ret = drm_atomic_helper_page_flip_create_state(state, crtc, fb,
> event);
> > + if (ret != 0)
> > goto fail;
> > - }
> > - crtc_state->event = event;
> >
> > - plane_state = drm_atomic_get_plane_state(state, plane);
> > - if (IS_ERR(plane_state)) {
> > - ret = PTR_ERR(plane_state);
> > - goto fail;
> > - }
> > + ret = drm_atomic_nonblocking_commit(state);
> >
> > - ret = drm_atomic_set_crt
[PATCH v3 06/13] drm: bridge: Add LVDS encoder driver
Hi Daniel, On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote: > On Wed, Jan 4, 2017 at 2:08 PM, Laurent Pinchart wrote: > > On Wednesday 04 Jan 2017 09:18:18 Daniel Vetter wrote: > >> On Tue, Nov 29, 2016 at 10:57:07PM +0200, Laurent Pinchart wrote: > >>> On Tuesday 29 Nov 2016 10:54:09 Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote: > > The LVDS encoder driver is a DRM bridge driver that supports the > > parallel to LVDS encoders that don't require any configuration. The > > driver thus doesn't interact with the device, but creates an LVDS > > connector for the panel and exposes its size and timing based on > > information retrieved from DT. > > > > Signed-off-by: Laurent Pinchart > > > > Since it's 100% dummy, why put LVDS into the name? This little thing > here could be our generic "wrap drm_panel and attach it to a chain" > helper. So what about calling this _The_ drm_panel_bridge, and also > linking it into docs to feature it a bit more prominently. > >>> > >>> I'm not opposed to that, except that this driver should not be > >>> considered as just a helper to link a panel. It should only be used to > >>> support a real hardware bridge that requires no control. > >>> > I came up with this because I spotted some refactoring belows for > building this helper, until I realized that this driver _is_ the > helper I think we want ;-) Only thing missing is an exported function > to instantiate a bridge with just a drm_panel as the parameter. And > putting it into the drm_kms_helper.ko module. > >>> > >>> What would that be used for ? The bridge should be instantiated by this > >>> bridge driver, bound to a bridge device instantiated from DT (or the > >>> platform firmware of your choice). > >> > >> Atm every driver using drm_panel needs a bit of glue to bind it into it's > >> display chain. With this code, and bridge chaining, you'd get that for > >> free, and I think that would be rather useful. > > > > You would trade the bit of panel glue for a bit of bridge glue. Bridge > > chaining could perhaps help slightly at runtime there, but at init time > > the > > amount of glue would be similar. > > Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be > enough, or not? My idea is to use this for the case where the only > thing in dt is the panel, with no real bridge chip. And I think we > don't need anything beyond that one _init function, plus maybe some > additional paramaters ... There should be no bridge then. If you want the DRM core to manage panels automatically, then we should create specific helpers for that, not abuse the bridge infrastructure. Bridges should be instantiated from a hardware device and bound to drivers as usual. > > I've noticed one piece of code that is LVDS-specific in this driver, and > > that's connector creation. The connector type is hardcoded to LVDS. To > > make the driver more generic, we would need a way to find the connector > > type at runtime. I'm wondering whether I should do this now, or keep the > > driver LVDS- specific until someone comes up with a similar need. Without > > several potential users it's often hard to design a properly generic API. > > ... like whether the panel is dsi or lvds or soemthing else. Or maybe > we should just use LVDS for everything, because it's a panel, and > userspace shouldn't really care beyond that ;-) Feel free to propose a panel connector type :-) > >> And from a software point of view I'd say if it quacks like a bridge, and > >> walks like a bridge, it probably _is_ a bridge. Even if no one calls > >> that, or if physical the only thing on the board at that spot are a bunch > >> of dumb wires. > > > > I dream of moving all encoders to DRM bridge, and then unifying drm_bridge > > and drm_panel with a common set of operations that could be invoked on > > both objects. That way the core could chain bridges and panels quite > > easily. I plan to experiment with this when moving the omapdrm driver to > > DRM bridge and DRM panel (it currently includes a bunch of custom encoder > > and panel drivers). > > Agreed on that dream, auto-wrapping panels in dummy bridges would be a > first step towards that. But I think that's a step in the wrong direction. Ideally I'd like the encoders/bridges not to have to care about connectors and panels. There are multiple options, but a dummy bridge isn't a good idea in my opinion. > The other one is making drm_encoders entirely dummies, and I think we're 90% > there already. We need to convert everything to drm_bridge first, we're not quite there yet :-) > End result isn't quite as clean as a complete rewrite, but probably > good enough. And because uapi we can't get rid of drm_encoder anyway, > and keeping drm_panel as the internal thing embedded into a > drm_panel_bridge struct seems reasonable too. That way panel drivers > can cope
[PATCH v4 1/3] drm/exynos: mic: Add mode_set callback function
2017ë
01ì 04ì¼ 15:58ì Hoegeun Kwon ì´(ê°) ì´ ê¸:
> Before applying the patch, used the of_get_videomode function to
> parse the display-timings in the panel which is the child driver
> of dsi in the devicetree. this is wrong. So removed the
> of_get_videomode and fixed to get videomode struct through
> mode_set callback function.
>
> Signed-off-by: Hoegeun Kwon
> ---
> drivers/gpu/drm/exynos/exynos_drm_mic.c | 33
> ++---
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a0def0b..9a50ceb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
> }
> nodes[j++] = remote_node;
>
> - ret = of_get_videomode(remote_node,
> - &mic->vm, 0);
> - if (ret) {
> - DRM_ERROR("mic: failed to get videomode");
> - goto exit;
> - }
> -
> break;
> default:
> DRM_ERROR("mic: Unknown endpoint from MIC");
> @@ -329,6 +322,27 @@ static void mic_post_disable(struct drm_bridge *bridge)
> mutex_unlock(&mic_mutex);
> }
>
> +static void mic_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct exynos_mic *mic = bridge->driver_private;
> +
> + mutex_lock(&mic_mutex);
> + if (mic->enabled)
> + goto already_enabled;
mode setting should be performed every time mode_set callback is called so
remove above two lines.
> +
> + drm_display_mode_to_videomode(mode, &mic->vm);
> +
> + if (!mic->i80_mode)
> + mic_set_porch_timing(mic);
> + mic_set_img_size(mic);
> + mic_set_output_timing(mic);
> +
> +already_enabled:
So this label is unnecessary.
> + mutex_unlock(&mic_mutex);
> +}
> +
> static void mic_pre_enable(struct drm_bridge *bridge)
> {
> struct exynos_mic *mic = bridge->driver_private;
> @@ -355,10 +369,6 @@ static void mic_pre_enable(struct drm_bridge *bridge)
> goto turn_off_clks;
> }
>
> - if (!mic->i80_mode)
> - mic_set_porch_timing(mic);
> - mic_set_img_size(mic);
> - mic_set_output_timing(mic);
> mic_set_reg_on(mic, 1);
> mic->enabled = 1;
> mutex_unlock(&mic_mutex);
> @@ -377,6 +387,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
> static const struct drm_bridge_funcs mic_bridge_funcs = {
> .disable = mic_disable,
> .post_disable = mic_post_disable,
> + .mode_set = mic_mode_set,
> .pre_enable = mic_pre_enable,
> .enable = mic_enable,
> };
>
[PATCH v4 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Hi Hoegeun,
I tested this patch on Exynos5433-TM2 board. It is well working
Tested-by: Chanwoo Choi
Regards,
Chanwoo Choi
On 2017ë
01ì 04ì¼ 15:58, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Hoegeun Kwon
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741
> +
> 4 files changed, 788 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 000..6879f51
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> @@ -0,0 +1,40 @@
> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
> +
> +Required properties:
> + - compatible: "samsung,s6e3ha2"
> + - reg: the virtual channel number of a DSI peripheral
> + - vdd3-supply: I/O voltage supply
> + - vci-supply: voltage supply for analog circuits
> + - reset-gpios: a GPIO spec for the reset pin (active low)
> + - enable-gpios: a GPIO spec for the panel enable pin (active high)
> + - te-gpios: a GPIO spec for the tearing effect synchronization signal
> +gpio pin (active high)
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [1]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +&dsi {
> + ...
> +
> + panel at 0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> + };
> +};
> +
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 62aba97..eea2902 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
> WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
> Xperia Z2 tablets
>
> +config DRM_PANEL_SAMSUNG_S6E3HA2
> + tristate "Samsung S6E3HA2 DSI video mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> +
> config DRM_PANEL_SAMSUNG_S6E8AA0
> tristate "Samsung S6E8AA0 DSI video mode panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index a5c7ec0..1d483b0 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
> panel-jdi-lt070me05000.o
> obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
> panel-panasonic-vvx10f034n00.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> new file mode 100644
> index 000..8c5a1c2
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
> @@ -0,0 +1,741 @@
> +/*
> + * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * Donghwa Lee
> + * Hyungwon Hwang
> + * Hoegeun Kwon
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define S6E3HA2_MIN_BRIGHTNESS 0
> +#define S6E3HA2_MAX_BRIGHTNESS 100
> +#define S6E3HA2_DEFAULT_BRIGHTNESS 80
> +
> +#define S6E3HA2_NUM_GAMMA_STEPS 46
> +#define S6E3HA2_GAMMA_CMD_CNT
[PATCH v4 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
Hi Hoegeun,
On 2017ë
01ì 04ì¼ 15:58, Hoegeun Kwon wrote:
> From: Hyungwon Hwang
>
> This patch add the panel device tree node for S6E3HA2 display
> controller to TM2 dts.
>
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Chanwoo Choi
> Signed-off-by: Hoegeun Kwon
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 5b9451d..b3ba1ac 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -304,11 +304,28 @@
> reg = <1>;
>
> dsi_out: endpoint {
> + remote-endpoint = <&panel_in>;
> samsung,burst-clock-frequency = <51200>;
> samsung,esc-clock-frequency = <1600>;
> };
> };
> };
> +
> + panel at 0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> + };
> };
>
> &hsi2c_0 {
>
I tested this patch on Exynos5433-TM2 board.
It is well working to display the image to LCD panel.
Tested-by: Chanwoo Choi
--
Regards,
Chanwoo Choi
[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
Hi Ville,
On 04-01-2017 13:22, Ville Syrjälä wrote:
> On Fri, Dec 30, 2016 at 04:53:16PM +, Jose Abreu wrote:
>> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
>> According to the spec the EDID may contain two blocks that
>> signal this sampling mode:
>> - YCbCr 4:2:0 Video Data Block
>> - YCbCr 4:2:0 Video Capability Map Data Block
>>
>> The video data block contains the list of vic's were
>> only YCbCr 4:2:0 sampling mode shall be used while the
>> video capability map data block contains a mask were
>> YCbCr 4:2:0 sampling mode may be used.
>>
>> This RFC patch adds support for parsing these two new blocks
>> and introduces new flags to signal the drivers if the
>> mode is 4:2:0'only or 4:2:0'able.
>>
>> The reason this is still a RFC is because there is no
>> reference in kernel for this new sampling mode (specially in
>> AVI infoframe part), so, I was hoping to hear some feedback
>> first.
>>
>> Tested in a HDMI 2.0 compliance scenario.
>>
>> Signed-off-by: Jose Abreu
>> Cc: Carlos Palminha
>> Cc: Daniel Vetter
>> Cc: Jani Nikula
>> Cc: Sean Paul
>> Cc: David Airlie
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>> drivers/gpu/drm/drm_edid.c | 139
>> +++-
>> drivers/gpu/drm/drm_modes.c | 10 +++-
>> include/uapi/drm/drm_mode.h | 6 ++
>> 3 files changed, 151 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 67d6a73..6ce1a38 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct drm_connector
>> *connector,
>> #define VENDOR_BLOCK0x03
>> #define SPEAKER_BLOCK 0x04
>> #define VIDEO_CAPABILITY_BLOCK 0x07
>> +#define VIDEO_DATA_BLOCK_4200x0E
>> +#define VIDEO_CAP_BLOCK_420 0x0F
>> #define EDID_BASIC_AUDIO(1 << 6)
>> #define EDID_CEA_YCRCB444 (1 << 5)
>> #define EDID_CEA_YCRCB422 (1 << 4)
>> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct drm_connector
>> *connector, u16 structure,
>> return modes;
>> }
>>
>> +static int add_420_mode(struct drm_connector *connector, u8 vic)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_display_mode *newmode;
>> +
>> +if (!drm_valid_cea_vic(vic))
>> +return 0;
>> +
>> +newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
>> +if (!newmode)
>> +return 0;
>> +
>> +newmode->flags |= DRM_MODE_FLAG_420_ONLY;
> Why does userspace need to know this? My thinking has been that the
> driver would do the right thing automagically.
>
> We do probably want some kind of output colorspace property to allow the
> user to select between RGB vs. YCbCr etc. But I think even with that we
> should still allow the driver to automagically select YCbCr 4:2:0 output
> since that's the only way the mode will work.
I agree. When only 4:2:0 is supported there is no need to expose
the flag to userspace. How shall then I signal drivers for this
4:2:0'only sampling mode?
So, for the remaining modes, you propose a new field in the mode
structure called 'colorspace' which contains the list of
supported sampling modes for the given mode? I think it would be
a nice addition. This way if a mode supports only RGB we only
passed RGB flag; if 4:2:0 was also supported we passed the 4:2:0
flag, ... And then user could select. We also have to inform user
which one is being actually used.
Best regards,
Jose Miguel Abreu
>
>> +drm_mode_probed_add(connector, newmode);
>> +
>> +return 1;
>> +}
>> +
>> +static int add_420_vdb_modes(struct drm_connector *connector, const u8
>> *svds,
>> +u8 svds_len)
>> +{
>> +int modes = 0, i;
>> +
>> +for (i = 0; i < svds_len; i++)
>> +modes += add_420_mode(connector, svds[i]);
>> +
>> +return modes;
>> +}
>> +
>> +static int add_420_vcb_modes(struct drm_connector *connector, const u8
>> *svds,
>> +u8 svds_len, const u8 *video_db, u8 video_len)
>> +{
>> +struct drm_display_mode *newmode = NULL;
>> +int modes = 0, i, j;
>> +
>> +for (i = 0; i < svds_len; i++) {
>> +u8 mask = svds[i];
>> +for (j = 0; j < 8; j++) {
>> +if (mask & (1 << j)) {
>> +newmode = drm_display_mode_from_vic_index(
>> +connector, video_db, video_len,
>> +i * 8 + j);
>> +if (newmode) {
>> +newmode->flags |= DRM_MODE_FLAG_420;
>> +drm_mode_probed_add(connector, newmode);
>> +modes++;
>> +}
>> +}
>> +}
>> +}
>> +
>> +return modes;
>> +}
>> +
>> +static int add_420_vcb_modes_all(struct drm_connect
[PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()
On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote: > As the fence->status is an optional field that may be set before > dma_fence_signal() is called to convey that the fence completed with an > error, we have to ensure that it is always set to zero on initialisation > so that the typical use (i.e. unset) always flags a successful completion. > > Signed-off-by: Chris Wilson > Reviewed-by: Tvrtko Ursulin Yeah, this looks all pretty. On the series: Reviewed-by: Daniel Vetter I'll defer to Gustavo for another pass over it and merging it to drm-misc. -Daniel > --- > drivers/dma-buf/dma-fence.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 3444f293ad4a..9130f790ebf3 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct > dma_fence_ops *ops, > fence->context = context; > fence->seqno = seqno; > fence->flags = 0UL; > + fence->status = 0; > > trace_dma_fence_init(fence); > } > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC 3/6] dma-buf: Support generic userspace allocations
On Wed, Jan 04, 2017 at 02:34:39PM +0100, Noralf Trønnes wrote:
> Add a generic way for userspace to allocate dma-buf's for SPI transfers.
>
> Signed-off-by: Noralf Trønnes
Having a central dma-buf allocator is a common thing, there's already ION
in drivers/staging/android. If we need one I think it's better to
accelarate ION destaging than creating yet another one.
> ---
> drivers/dma-buf/Makefile | 2 +-
> drivers/dma-buf/dev.c| 211
> +++
> include/uapi/linux/dma-buf-dev.h | 35 +++
> 3 files changed, 247 insertions(+), 1 deletion(-)
> create mode 100644 drivers/dma-buf/dev.c
> create mode 100644 include/uapi/linux/dma-buf-dev.h
>
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index 210a10b..ec867f7 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1,3 +1,3 @@
> -obj-y := dma-buf.o fence.o reservation.o seqno-fence.o fence-array.o
> +obj-y := dma-buf.o fence.o reservation.o seqno-fence.o fence-array.o dev.o
> obj-$(CONFIG_SYNC_FILE) += sync_file.o
> obj-$(CONFIG_SW_SYNC)+= sw_sync.o sync_debug.o
> diff --git a/drivers/dma-buf/dev.c b/drivers/dma-buf/dev.c
> new file mode 100644
> index 000..536d9bf
> --- /dev/null
> +++ b/drivers/dma-buf/dev.c
> @@ -0,0 +1,211 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct dma_buf_dev_object {
> + struct device *dev;
> + unsigned long attrs;
> + dma_addr_t dma_addr;
> + void *vaddr;
> + size_t size;
> +};
> +
> +static struct sg_table *
> +dma_buf_dev_map_dma_buf(struct dma_buf_attachment *attach,
> + enum dma_data_direction dir)
> +{
> + struct dma_buf_dev_object *obj = attach->dmabuf->priv;
> + struct sg_table *sgt;
> + int ret;
> +
> + sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
> + if (!sgt)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = dma_get_sgtable(obj->dev, sgt, obj->vaddr,
> + obj->dma_addr, obj->size);
> + if (ret < 0)
> + goto err_free;
> +
> + if (!dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir)) {
> + ret = -ENOMEM;
> + goto err_free_table;
> + }
> +
> + return sgt;
> +
> +err_free_table:
> + sg_free_table(sgt);
> +err_free:
> + kfree(sgt);
> +
> + return ERR_PTR(ret);
> +}
> +
> +static void dma_buf_dev_unmap_dma_buf(struct dma_buf_attachment *attach,
> + struct sg_table *sgt,
> + enum dma_data_direction dir)
> +{
> + dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
> + sg_free_table(sgt);
> + kfree(sgt);
> +}
> +
> +static void dma_buf_dev_release(struct dma_buf *dma_buf)
> +{
> + struct dma_buf_dev_object *obj = dma_buf->priv;
> +
> +/* FIXME remove */
> +pr_info("%s()\n", __func__);
> + dma_free_attrs(obj->dev, obj->size, obj->vaddr, obj->dma_addr,
> +obj->attrs);
> + kfree(obj);
> +}
> +
> +static void *dma_buf_dev_kmap(struct dma_buf *dma_buf, unsigned long
> page_num)
> +{
> + struct dma_buf_dev_object *obj = dma_buf->priv;
> +
> + return obj->vaddr + page_num * PAGE_SIZE;
> +}
> +
> +static void *dma_buf_dev_vmap(struct dma_buf *dma_buf)
> +{
> + struct dma_buf_dev_object *obj = dma_buf->priv;
> +
> + return obj->vaddr;
> +}
> +
> +static int dma_buf_dev_mmap(struct dma_buf *dma_buf,
> + struct vm_area_struct *vma)
> +{
> + struct dma_buf_dev_object *obj = dma_buf->priv;
> + int ret;
> +
> + vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> +
> + ret = dma_mmap_attrs(obj->dev, vma, obj->vaddr, obj->dma_addr,
> + vma->vm_end - vma->vm_start, obj->attrs);
> +
> + return ret;
> +}
> +
> +static const struct dma_buf_ops dma_buf_dev_ops = {
> + .map_dma_buf = dma_buf_dev_map_dma_buf,
> + .unmap_dma_buf = dma_buf_dev_unmap_dma_buf,
> + .release = dma_buf_dev_release,
> + .kmap_atomic = dma_buf_dev_kmap,
> + .kmap = dma_buf_dev_kmap,
> + .vmap = dma_buf_dev_vmap,
> + .mmap = dma_buf_dev_mmap,
> +};
> +
> +struct dma_buf *dma_buf_dev_alloc_attrs(struct device *dev, size_t size,
> + unsigned long attrs, int flags)
> +{
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf_dev_object *obj;
> + struct dma_buf *dmabuf;
> + int ret;
> +
> + if (flags & ~(O_CLOEXEC | O_ACCMODE))
> + return ERR_PTR(-EINVAL);
> +
> + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> +
[RFC 0/6] drm: Add support for userspace drivers
On Wed, Jan 04, 2017 at 02:34:36PM +0100, Noralf Trønnes wrote: > Hi, > > I was previously working on tinydrm as a replacement for staging/fbtft. > During a break from that work, I started to think about if it would be > possible to move the drivers to userspace instead. No point in having > them in the kernel if it's not necessary. > > This patchset includes all the pieces necessary to get a userspace > driver[1] working that is compatible with the fbtft/fb_ili9341 driver. > It is tested with a SPI interfaced display hat/shield for the Raspberry Pi, > which has an eeprom with a Device Tree fragment on it (merged by the > bootloader). With the help of udev and systemd, the driver is able to > autoload when the display is connected. > Performance wise, the kernel driver can do ~19fps on a 320x240 spi at 32MHz > display, whereas the userspace version does ~18fps. So performance is not > an argument to keep the driver in the kernel. > > What do you think about this approach? It's a pretty nifty thing, and iirc some of the ideas for implementing miracast centered around the same idea: Small userspace drm driver shim that forwards everything to the miracast code running all in userspace. David Herrmann looked into that years ago, not sure he ever got the full stack up&running. For dumb panels itself I'm not sure it's the right design. Adding a kernel/userspace interface will make code sharing harder, and experience also says that we'll rework kms semantics every few years. In-kernel drivers seem to me like the better default choice, except when there's a clear reason for why userspace is the only option. For miracast that's the case, since porting the userspace video encode libraries to the kernel just doesn't make sense. For SPI and other slow buses I don't see any such compelling reason to move it into userspace. -Daniel > > Note: This patchset is based on 4.9 > > [1] https://github.com/notro/udrm > > > Noralf. > > > Noralf Trønnes (6): > drm/modes: Export drm_mode_convert_umode() > drm: Add support for userspace drivers > dma-buf: Support generic userspace allocations > spi: Let clients do scatter/gather transfers > spi: spidev: Add dma-buf support > spi: spidev: Add userspace driver support > > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/dev.c| 211 ++ > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_modes.c | 1 + > drivers/gpu/drm/udrm/Kconfig | 9 + > drivers/gpu/drm/udrm/Makefile| 4 + > drivers/gpu/drm/udrm/udrm-dev.c | 276 > drivers/gpu/drm/udrm/udrm-drv.c | 324 > drivers/gpu/drm/udrm/udrm-fb.c | 369 > drivers/gpu/drm/udrm/udrm-pipe.c | 170 +++ > drivers/gpu/drm/udrm/udrm.h | 84 > drivers/spi/Kconfig | 1 + > drivers/spi/spi.c| 24 ++- > drivers/spi/spidev.c | 447 > ++- > include/linux/spi/spi.h | 4 + > include/uapi/drm/udrm.h | 78 +++ > include/uapi/linux/dma-buf-dev.h | 35 +++ > include/uapi/linux/spi/spidev.h | 8 + > 19 files changed, 2032 insertions(+), 18 deletions(-) > create mode 100644 drivers/dma-buf/dev.c > create mode 100644 drivers/gpu/drm/udrm/Kconfig > create mode 100644 drivers/gpu/drm/udrm/Makefile > create mode 100644 drivers/gpu/drm/udrm/udrm-dev.c > create mode 100644 drivers/gpu/drm/udrm/udrm-drv.c > create mode 100644 drivers/gpu/drm/udrm/udrm-fb.c > create mode 100644 drivers/gpu/drm/udrm/udrm-pipe.c > create mode 100644 drivers/gpu/drm/udrm/udrm.h > create mode 100644 include/uapi/drm/udrm.h > create mode 100644 include/uapi/linux/dma-buf-dev.h > > -- > 2.10.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v4 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 5b9451d..b3ba1ac 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -304,11 +304,28 @@
reg = <1>;
dsi_out: endpoint {
+ remote-endpoint = <&panel_in>;
samsung,burst-clock-frequency = <51200>;
samsung,esc-clock-frequency = <1600>;
};
};
};
+
+ panel at 0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
};
&hsi2c_0 {
--
1.9.1
[PATCH v4 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 +
4 files changed, 788 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 000..6879f51
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,40 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+ - compatible: "samsung,s6e3ha2"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: I/O voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin (active low)
+ - enable-gpios: a GPIO spec for the panel enable pin (active high)
+ - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [1]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+&dsi {
+ ...
+
+ panel at 0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+};
+
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..eea2902 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
Xperia Z2 tablets
+config DRM_PANEL_SAMSUNG_S6E3HA2
+ tristate "Samsung S6E3HA2 DSI video mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) +=
panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 000..8c5a1c2
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,741 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee
+ * Hyungwon Hwang
+ * Hoegeun Kwon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT 35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00,
[PATCH v4 1/3] drm/exynos: mic: Add mode_set callback function
Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0b..9a50ceb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;
- ret = of_get_videomode(remote_node,
- &mic->vm, 0);
- if (ret) {
- DRM_ERROR("mic: failed to get videomode");
- goto exit;
- }
-
break;
default:
DRM_ERROR("mic: Unknown endpoint from MIC");
@@ -329,6 +322,27 @@ static void mic_post_disable(struct drm_bridge *bridge)
mutex_unlock(&mic_mutex);
}
+static void mic_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct exynos_mic *mic = bridge->driver_private;
+
+ mutex_lock(&mic_mutex);
+ if (mic->enabled)
+ goto already_enabled;
+
+ drm_display_mode_to_videomode(mode, &mic->vm);
+
+ if (!mic->i80_mode)
+ mic_set_porch_timing(mic);
+ mic_set_img_size(mic);
+ mic_set_output_timing(mic);
+
+already_enabled:
+ mutex_unlock(&mic_mutex);
+}
+
static void mic_pre_enable(struct drm_bridge *bridge)
{
struct exynos_mic *mic = bridge->driver_private;
@@ -355,10 +369,6 @@ static void mic_pre_enable(struct drm_bridge *bridge)
goto turn_off_clks;
}
- if (!mic->i80_mode)
- mic_set_porch_timing(mic);
- mic_set_img_size(mic);
- mic_set_output_timing(mic);
mic_set_reg_on(mic, 1);
mic->enabled = 1;
mutex_unlock(&mic_mutex);
@@ -377,6 +387,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
static const struct drm_bridge_funcs mic_bridge_funcs = {
.disable = mic_disable,
.post_disable = mic_post_disable,
+ .mode_set = mic_mode_set,
.pre_enable = mic_pre_enable,
.enable = mic_enable,
};
--
1.9.1
[PATCH v4 0/3] Add support for the S6E3HA2 panel on TM2 board
Purpose of this patch is add support for S6E3HA2 AMOLED panel on the TM2 board. The first patch adds support for S6E3HA2 panel device tree document and driver, the second patch add support for S6E3HA2 panel device tree. Changes for V4: - Removed display-timings in devicetree, the display-timings has been fixed to be provided by the device driver. - Added the mode_set callback function into exynos_drm_mic, because the exynos_drm_mic driver can not parse a videomode struct by removing the display-timings from the devicetree. Hoegeun Kwon (2): drm/exynos: mic: Add mode_set callback function drm/panel: Add support for S6E3HA2 panel driver on TM2 board Hyungwon Hwang (1): arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board .../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++ arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 + drivers/gpu/drm/exynos/exynos_drm_mic.c| 33 +- drivers/gpu/drm/panel/Kconfig | 6 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 + 6 files changed, 827 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c -- 1.9.1
[PATCH v3 06/13] drm: bridge: Add LVDS encoder driver
On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote: > On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote: > > Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be > > enough, or not? My idea is to use this for the case where the only > > thing in dt is the panel, with no real bridge chip. And I think we > > don't need anything beyond that one _init function, plus maybe some > > additional paramaters ... > > There should be no bridge then. If you want the DRM core to manage panels > automatically, then we should create specific helpers for that, not abuse the > bridge infrastructure. Bridges should be instantiated from a hardware device > and bound to drivers as usual. I guess that's the part where I disagree: Just because there's physically no bridge doesn't mean we shouldn't just treat it as one in the software abstraction. If it looks and acts like a bridge (even an empty one), then imo it can be a bridge. If you insist on panels being panels, then I guess we need some other kind of glue to bind them into arbitrary bridge chains. But given that the callbacks match very closely, I don't see the point. In an idea world a panel would probably derive from a drm_bridge, but we're not in that universe unfortunately ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Unix Device Memory Allocation project
On Wed, Jan 04, 2017 at 08:06:24AM -0500, Rob Clark wrote: > On Wed, Jan 4, 2017 at 7:03 AM, Daniel Stone wrote: > >> Speaking of compression for display, especially the separate > >> compression buffer: That should be fully contained in the main DMABUF > >> and described by the per-BO metadata. Some other drivers want to use a > >> separate DMABUF for the compression buffer - while that may sound good > >> in theory, it's not economical for the reason described above. > > > > 'Some other drivers want to use a separate DMABUF', or 'some other > > hardware demands the data be separate'. Same with luma/chroma plane > > separation. Anyway, it doesn't really matter unless you're sharing > > render-compression formats across vendors, and AFBC is the only case > > of that I know of currently. > > > jfwiw, UBWC on newer snapdragons too.. seems like we can share these > not just between gpu (render to and sample from) and display, but also > v4l2 decoder/encoder (and maybe camera?) > > I *think* we probably can treat the metadata buffers as a separate > plane.. at least we can for render target and blit src/dst, but not > 100% sure about sampling from a UBWC buffer.. that might force us to > have them in a single buffer. Conceptually treating them as two planes, and everywhere requiring that they're allocated from the same BO are orthogonal things. At least that's our plan with intel render compression last time I understood the current state ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 98984] Hexagonal shapes around lights in Cities: Skylines
https://bugs.freedesktop.org/show_bug.cgi?id=98984 --- Comment #3 from Samuel Pitoiset --- It seems like the issue has been recently fixed. I can't reproduce it with the following config: OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.3.0 / 4.8.13-1-ARCH, LLVM 4.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.1.0-devel (git-7e2a4d5770) But I can see the hexagonal shapes with: OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.3.0 / 4.8.13-1-ARCH, LLVM 3.9.0) OpenGL core profile version string: 4.3 (Core Profile) Mesa 13.0.2 Tested on RX 480. Can you try upgrading and eventually confirm? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/63cd2a7b/attachment.html>
[PATCH 02/10] drm/i915/psr: program vsc header for psr2
On Mon, Jan 02, 2017 at 05:00:55PM +0530, vathsala nagaraju wrote:
> Function hsw_psr_setup handles vsc header setup for psr1 and
> skl_psr_setup_vsc handles vsc header setup for psr2.
>
> Setup VSC header in function skl_psr_setup_vsc for psr2 support,
> as per edp 1.4 spec, table 6-11:VSC SDP HEADER Extension for psr2
> operation.
>
> v2: (Jani)
> - Initialize variables to 0
> - intel_dp_get_y_cord_status and intel_dp_get_y_cord_status made static
> - Correct indentation for continuation lines
> - Change DP_PSR_Y_COORDINATE to DP_PSR2_SU_Y_COORDINATE_REQUIRED
> - Change DPRX_FEATURE_ENUMERATION_LIST to DP_DPRX_*
> - Change VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED to DP_VSC_*
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: Vathsala Nagaraju
> Signed-off-by: Patil Deepti
Reviewed-by: Jim Bride
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_dp.c | 26 ++
> drivers/gpu/drm/i915/intel_psr.c | 17 +++--
> 3 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 22d3f61..36dc835 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1164,6 +1164,8 @@ struct i915_psr {
> bool psr2_support;
> bool aux_frame_sync;
> bool link_standby;
> + bool y_cord_support;
> + bool colorimetry_support;
> };
>
> enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fb12896..da577c9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3042,6 +3042,24 @@ static void chv_dp_post_pll_disable(struct
> intel_encoder *encoder,
> DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> }
>
> +static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> +{
> + uint8_t psr_caps = 0;
> +
> + drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_CAPS, &psr_caps);
> + return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
> +}
> +
> +static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
> +{
> + uint8_t dprx = 0;
> +
> + drm_dp_dpcd_readb(&intel_dp->aux,
> + DP_DPRX_FEATURE_ENUMERATION_LIST,
> + &dprx);
> + return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
> +}
> +
> /* These are source-specific values. */
> uint8_t
> intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3620,6 +3638,14 @@ void intel_dp_set_idle_link_train(struct intel_dp
> *intel_dp)
> dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> DRM_DEBUG_KMS("PSR2 %s on sink",
> dev_priv->psr.psr2_support ? "supported" : "not
> supported");
> +
> + if (dev_priv->psr.psr2_support) {
> + dev_priv->psr.y_cord_support =
> + intel_dp_get_y_cord_status(intel_dp);
> + dev_priv->psr.colorimetry_support =
> + intel_dp_get_colorimetry_status(intel_dp);
> + }
> +
> }
>
> /* Read the eDP Display control capabilities registers */
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 6aca8ff..c3aa649 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -122,13 +122,26 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
> static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
> {
> struct edp_vsc_psr psr_vsc;
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
>
> /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
> memset(&psr_vsc, 0, sizeof(psr_vsc));
> psr_vsc.sdp_header.HB0 = 0;
> psr_vsc.sdp_header.HB1 = 0x7;
> - psr_vsc.sdp_header.HB2 = 0x3;
> - psr_vsc.sdp_header.HB3 = 0xb;
> + if (dev_priv->psr.colorimetry_support &&
> + dev_priv->psr.y_cord_support) {
> + psr_vsc.sdp_header.HB2 = 0x5;
> + psr_vsc.sdp_header.HB3 = 0x13;
> + } else if (dev_priv->psr.y_cord_support) {
> + psr_vsc.sdp_header.HB2 = 0x4;
> + psr_vsc.sdp_header.HB3 = 0xe;
> + } else {
> + psr_vsc.sdp_header.HB2 = 0x3;
> + psr_vsc.sdp_header.HB3 = 0xc;
> + }
> +
> intel_psr_write_vsc(intel_dp, &psr_vsc);
> }
>
> --
> 1.9.1
[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost
https://bugs.freedesktop.org/show_bug.cgi?id=99120 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #27 from Christian König --- Mhm, interesting bug. I didn't know that .drirc config options could cause such problems. Figuring out what put the .drirc file in the home directory might be a good idea, but certainly not a job for the devs. Anyway let's close this bug report and move on. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/9e05af24/attachment.html>
[PATCH] drm/meson: Fix plane atomic check when no crtc for the plane
On Tue, Jan 03, 2017 at 10:20:54AM +0100, Neil Armstrong wrote:
> When no CRTC is associated with the plane, the meson_plane_atomic_check()
> call breaks the kernel with an Oops.
>
> Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_plane.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_plane.c
> b/drivers/gpu/drm/meson/meson_plane.c
> index 4942ca0..7890e30 100644
> --- a/drivers/gpu/drm/meson/meson_plane.c
> +++ b/drivers/gpu/drm/meson/meson_plane.c
> @@ -51,6 +51,9 @@ static int meson_plane_atomic_check(struct drm_plane *plane,
> struct drm_crtc_state *crtc_state;
> struct drm_rect clip = { 0, };
>
> + if (!state->crtc)
> + return 0;
> +
Since you're not going to call drm_plane_helper_check_state() you will
fail to update plane_state->visible.
What i915 does in this case is look for state->crtc first, and if that's
NULL it'll pick the crtc from the old state (plane->state->crtc). It
looks a bit ugly, but maybe we should hide it in a small helper function
that could be used by all drivers?
> crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> if (IS_ERR(crtc_state))
> return PTR_ERR(crtc_state);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[PATCH] drm: Add kernel-doc for drm_crtc_commit_get/put
On Wed, Jan 4, 2017 at 11:11 AM, Daniel Vetter wrote:
> On Wed, Dec 21, 2016 at 02:03:35PM +0100, Daniel Vetter wrote:
>> I was lazy, rectify that! Also align with drm_atomic_state_get/put for
>> ocd.
>>
>> v2: Git add helps.
>>
>> Signed-off-by: Daniel Vetter
>
> Anyone feel like acking this, pretty please? ;-)
Acked-by: Alex Deucher
> -Daniel
>
>> ---
>> drivers/gpu/drm/drm_atomic.c | 9 ++---
>> include/drm/drm_atomic.h | 21 -
>> 2 files changed, 22 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index b1b54011a92c..26a4cfdf 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -35,19 +35,14 @@
>>
>> #include "drm_crtc_internal.h"
>>
>> -static void crtc_commit_free(struct kref *kref)
>> +void __drm_crtc_commit_free(struct kref *kref)
>> {
>> struct drm_crtc_commit *commit =
>> container_of(kref, struct drm_crtc_commit, ref);
>>
>> kfree(commit);
>> }
>> -
>> -void drm_crtc_commit_put(struct drm_crtc_commit *commit)
>> -{
>> - kref_put(&commit->ref, crtc_commit_free);
>> -}
>> -EXPORT_SYMBOL(drm_crtc_commit_put);
>> +EXPORT_SYMBOL(__drm_crtc_commit_free);
>>
>> /**
>> * drm_atomic_state_default_release -
>> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
>> index 91b18bd7cb50..97587ec36eae 100644
>> --- a/include/drm/drm_atomic.h
>> +++ b/include/drm/drm_atomic.h
>> @@ -199,12 +199,31 @@ struct drm_atomic_state {
>> struct work_struct commit_work;
>> };
>>
>> -void drm_crtc_commit_put(struct drm_crtc_commit *commit);
>> +void __drm_crtc_commit_free(struct kref *kref);
>> +
>> +/**
>> + * drm_crtc_commit_get - acquire a reference to the CRTC commit
>> + * @commit: CRTC commit
>> + *
>> + * Increases the reference of @commit.
>> + */
>> static inline void drm_crtc_commit_get(struct drm_crtc_commit *commit)
>> {
>> kref_get(&commit->ref);
>> }
>>
>> +/**
>> + * drm_crtc_commit_put - release a reference to the CRTC commmit
>> + * @commit: CRTC commit
>> + *
>> + * This releases a reference to @commit which is freed after removing the
>> + * final reference. No locking required and callable from any context.
>> + */
>> +static inline void drm_crtc_commit_put(struct drm_crtc_commit *commit)
>> +{
>> + kref_put(&commit->ref, __drm_crtc_commit_free);
>> +}
>> +
>> struct drm_atomic_state * __must_check
>> drm_atomic_state_alloc(struct drm_device *dev);
>> void drm_atomic_state_clear(struct drm_atomic_state *state);
>> --
>> 2.11.0
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
On Fri, Dec 30, 2016 at 04:53:16PM +, Jose Abreu wrote:
> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
> According to the spec the EDID may contain two blocks that
> signal this sampling mode:
> - YCbCr 4:2:0 Video Data Block
> - YCbCr 4:2:0 Video Capability Map Data Block
>
> The video data block contains the list of vic's were
> only YCbCr 4:2:0 sampling mode shall be used while the
> video capability map data block contains a mask were
> YCbCr 4:2:0 sampling mode may be used.
>
> This RFC patch adds support for parsing these two new blocks
> and introduces new flags to signal the drivers if the
> mode is 4:2:0'only or 4:2:0'able.
>
> The reason this is still a RFC is because there is no
> reference in kernel for this new sampling mode (specially in
> AVI infoframe part), so, I was hoping to hear some feedback
> first.
>
> Tested in a HDMI 2.0 compliance scenario.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> ---
> drivers/gpu/drm/drm_edid.c | 139
> +++-
> drivers/gpu/drm/drm_modes.c | 10 +++-
> include/uapi/drm/drm_mode.h | 6 ++
> 3 files changed, 151 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 67d6a73..6ce1a38 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct drm_connector
> *connector,
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK0x04
> #define VIDEO_CAPABILITY_BLOCK 0x07
> +#define VIDEO_DATA_BLOCK_420 0x0E
> +#define VIDEO_CAP_BLOCK_420 0x0F
> #define EDID_BASIC_AUDIO (1 << 6)
> #define EDID_CEA_YCRCB444(1 << 5)
> #define EDID_CEA_YCRCB422(1 << 4)
> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct drm_connector
> *connector, u16 structure,
> return modes;
> }
>
> +static int add_420_mode(struct drm_connector *connector, u8 vic)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *newmode;
> +
> + if (!drm_valid_cea_vic(vic))
> + return 0;
> +
> + newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
> + if (!newmode)
> + return 0;
> +
> + newmode->flags |= DRM_MODE_FLAG_420_ONLY;
Why does userspace need to know this? My thinking has been that the
driver would do the right thing automagically.
We do probably want some kind of output colorspace property to allow the
user to select between RGB vs. YCbCr etc. But I think even with that we
should still allow the driver to automagically select YCbCr 4:2:0 output
since that's the only way the mode will work.
> + drm_mode_probed_add(connector, newmode);
> +
> + return 1;
> +}
> +
> +static int add_420_vdb_modes(struct drm_connector *connector, const u8 *svds,
> + u8 svds_len)
> +{
> + int modes = 0, i;
> +
> + for (i = 0; i < svds_len; i++)
> + modes += add_420_mode(connector, svds[i]);
> +
> + return modes;
> +}
> +
> +static int add_420_vcb_modes(struct drm_connector *connector, const u8 *svds,
> + u8 svds_len, const u8 *video_db, u8 video_len)
> +{
> + struct drm_display_mode *newmode = NULL;
> + int modes = 0, i, j;
> +
> + for (i = 0; i < svds_len; i++) {
> + u8 mask = svds[i];
> + for (j = 0; j < 8; j++) {
> + if (mask & (1 << j)) {
> + newmode = drm_display_mode_from_vic_index(
> + connector, video_db, video_len,
> + i * 8 + j);
> + if (newmode) {
> + newmode->flags |= DRM_MODE_FLAG_420;
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> + }
> + }
> + }
> +
> + return modes;
> +}
> +
> +static int add_420_vcb_modes_all(struct drm_connector *connector,
> + const u8 *video_db, u8 video_len)
> +{
> + struct drm_display_mode *newmode = NULL;
> + int modes = 0, i;
> +
> + for (i = 0; i < video_len; i++) {
> + newmode = drm_display_mode_from_vic_index(connector, video_db,
> + video_len, i);
> + if (newmode) {
> + newmode->flags |= DRM_MODE_FLAG_420;
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> + }
> +
> + return modes;
> +}
> +
> +static int do_hdmi_420_modes(struct drm_connector *connector, const u8 *vdb,
> + u8 vdb_len, const u8 *vcb, u8 vcb_len, const u8 *video_db,
> + u8 video_len
[PATCH v3 06/13] drm: bridge: Add LVDS encoder driver
Hi Daniel, On Wednesday 04 Jan 2017 09:18:18 Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 10:57:07PM +0200, Laurent Pinchart wrote: > > On Tuesday 29 Nov 2016 10:54:09 Daniel Vetter wrote: > >> On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote: > >>> The LVDS encoder driver is a DRM bridge driver that supports the > >>> parallel to LVDS encoders that don't require any configuration. The > >>> driver thus doesn't interact with the device, but creates an LVDS > >>> connector for the panel and exposes its size and timing based on > >>> information retrieved from DT. > >>> > >>> Signed-off-by: Laurent Pinchart > >>> > >> > >> Since it's 100% dummy, why put LVDS into the name? This little thing > >> here could be our generic "wrap drm_panel and attach it to a chain" > >> helper. So what about calling this _The_ drm_panel_bridge, and also > >> linking it into docs to feature it a bit more prominently. > > > > I'm not opposed to that, except that this driver should not be considered > > as just a helper to link a panel. It should only be used to support a > > real hardware bridge that requires no control. > > > >> I came up with this because I spotted some refactoring belows for > >> building this helper, until I realized that this driver _is_ the helper I > >> think we want ;-) Only thing missing is an exported function to > >> instantiate a bridge with just a drm_panel as the parameter. And putting > >> it into the drm_kms_helper.ko module. > > > > What would that be used for ? The bridge should be instantiated by this > > bridge driver, bound to a bridge device instantiated from DT (or the > > platform firmware of your choice). > > Atm every driver using drm_panel needs a bit of glue to bind it into it's > display chain. With this code, and bridge chaining, you'd get that for > free, and I think that would be rather useful. You would trade the bit of panel glue for a bit of bridge glue. Bridge chaining could perhaps help slightly at runtime there, but at init time the amount of glue would be similar. I've noticed one piece of code that is LVDS-specific in this driver, and that's connector creation. The connector type is hardcoded to LVDS. To make the driver more generic, we would need a way to find the connector type at runtime. I'm wondering whether I should do this now, or keep the driver LVDS- specific until someone comes up with a similar need. Without several potential users it's often hard to design a properly generic API. > And from a software point of view I'd say if it quacks like a bridge, and > walks like a bridge, it probably _is_ a bridge. Even if no one calls that, > or if physical the only thing on the board at that spot are a bunch of dumb > wires. I dream of moving all encoders to DRM bridge, and then unifying drm_bridge and drm_panel with a common set of operations that could be invoked on both objects. That way the core could chain bridges and panels quite easily. I plan to experiment with this when moving the omapdrm driver to DRM bridge and DRM panel (it currently includes a bunch of custom encoder and panel drivers). -- Regards, Laurent Pinchart
[PATCH v2 2/2] drm: Document deprecated load/unload hook
Daniel Vetter writes: > I know this is a bit more work on top, but if you type docs that say > something is ignored, it's a good excuse to fix the code. So, can you pls > do the mass refactoring (I'd just do one patch for everything) that > changesthe return type of this vfunc to void? > > Applied this one here meanwhile to drm-misc, thanks a lot. Thanks, Daniel. sure, I can do it, it's going to be a good way for me to learn coccinelle. -- Gabriel Krisman Bertazi
[PATCH] drm: sti: allow audio playback on HDMI even if disabled.
Acked-by: Vincent Abriou
On 09/30/2016 05:17 PM, Arnaud Pouliquen wrote:
> This fix allows to play audio while HDMI is disconnected.
> When HDMI is disable, audio configuration is stored and samples
> are dropped (by HDMI IP).
> When HDMI is enabled, audio HDMI configuration is applied and samples
> are outputted on HDMI wire.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/gpu/drm/sti/sti_hdmi.c | 205
> -
> 1 file changed, 101 insertions(+), 104 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index 376b076..9c0025e 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -788,6 +788,95 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
> hdmi->enabled = false;
> }
>
> +/**
> + * sti_hdmi_audio_get_non_coherent_n() - get N parameter for non-coherent
> + * clocks. None-coherent clocks means that audio and TMDS clocks have not the
> + * same source (drifts between clocks). In this case assumption is that CTS
> is
> + * automatically calculated by hardware.
> + *
> + * @audio_fs: audio frame clock frequency in Hz
> + *
> + * Values computed are based on table described in HDMI specification 1.4b
> + *
> + * Returns n value.
> + */
> +static int sti_hdmi_audio_get_non_coherent_n(unsigned int audio_fs)
> +{
> + unsigned int n;
> +
> + switch (audio_fs) {
> + case 32000:
> + n = 4096;
> + break;
> + case 44100:
> + n = 6272;
> + break;
> + case 48000:
> + n = 6144;
> + break;
> + case 88200:
> + n = 6272 * 2;
> + break;
> + case 96000:
> + n = 6144 * 2;
> + break;
> + case 176400:
> + n = 6272 * 4;
> + break;
> + case 192000:
> + n = 6144 * 4;
> + break;
> + default:
> + /* Not pre-defined, recommended value: 128 * fs / 1000 */
> + n = (audio_fs * 128) / 1000;
> + }
> +
> + return n;
> +}
> +
> +static int hdmi_audio_configure(struct sti_hdmi *hdmi)
> +{
> + int audio_cfg, n;
> + struct hdmi_audio_params *params = &hdmi->audio;
> + struct hdmi_audio_infoframe *info = ¶ms->cea;
> +
> + DRM_DEBUG_DRIVER("\n");
> +
> + if (!hdmi->enabled)
> + return 0;
> +
> + /* update N parameter */
> + n = sti_hdmi_audio_get_non_coherent_n(params->sample_rate);
> +
> + DRM_DEBUG_DRIVER("Audio rate = %d Hz, TMDS clock = %d Hz, n = %d\n",
> + params->sample_rate, hdmi->mode.clock * 1000, n);
> + hdmi_write(hdmi, n, HDMI_AUDN);
> +
> + /* update HDMI registers according to configuration */
> + audio_cfg = HDMI_AUD_CFG_SPDIF_DIV_2 | HDMI_AUD_CFG_DTS_INVALID |
> + HDMI_AUD_CFG_ONE_BIT_INVALID;
> +
> + switch (info->channels) {
> + case 8:
> + audio_cfg |= HDMI_AUD_CFG_CH78_VALID;
> + case 6:
> + audio_cfg |= HDMI_AUD_CFG_CH56_VALID;
> + case 4:
> + audio_cfg |= HDMI_AUD_CFG_CH34_VALID | HDMI_AUD_CFG_8CH;
> + case 2:
> + audio_cfg |= HDMI_AUD_CFG_CH12_VALID;
> + break;
> + default:
> + DRM_ERROR("ERROR: Unsupported number of channels (%d)!\n",
> + info->channels);
> + return -EINVAL;
> + }
> +
> + hdmi_write(hdmi, audio_cfg, HDMI_AUDIO_CFG);
> +
> + return hdmi_audio_infoframe_config(hdmi);
> +}
> +
> static void sti_hdmi_pre_enable(struct drm_bridge *bridge)
> {
> struct sti_hdmi *hdmi = bridge->driver_private;
> @@ -826,9 +915,12 @@ static void sti_hdmi_pre_enable(struct drm_bridge
> *bridge)
> if (hdmi_avi_infoframe_config(hdmi))
> DRM_ERROR("Unable to configure AVI infoframe\n");
>
> - /* Program AUDIO infoframe */
> - if (hdmi_audio_infoframe_config(hdmi))
> - DRM_ERROR("Unable to configure AUDIO infoframe\n");
> + if (hdmi->audio.enabled) {
> + if (hdmi_audio_configure(hdmi))
> + DRM_ERROR("Unable to configure audio\n");
> + } else {
> + hdmi_audio_infoframe_config(hdmi);
> + }
>
> /* Program VS infoframe */
> if (hdmi_vendor_infoframe_config(hdmi))
> @@ -1078,97 +1170,6 @@ static struct drm_encoder
> *sti_hdmi_find_encoder(struct drm_device *dev)
> return NULL;
> }
>
> -/**
> - * sti_hdmi_audio_get_non_coherent_n() - get N parameter for non-coherent
> - * clocks. None-coherent clocks means that audio and TMDS clocks have not the
> - * same source (drifts between clocks). In this case assumption is that CTS
> is
> - * automatically calculated by hardware.
> - *
> - * @audio_fs: audio frame clock frequency in Hz
> - *
> - * Values computed are based on table described in HDMI specification 1.4b
> - *
> - * Returns n value.
> - */
> -static int sti_hdmi_audio_get_non_coherent_n(unsigned int audio_
[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost
https://bugs.freedesktop.org/show_bug.cgi?id=99120 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/cd87e2c3/attachment.html>
[PATCH v3 06/13] drm: bridge: Add LVDS encoder driver
On Wed, Jan 4, 2017 at 2:08 PM, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday 04 Jan 2017 09:18:18 Daniel Vetter wrote: >> On Tue, Nov 29, 2016 at 10:57:07PM +0200, Laurent Pinchart wrote: >> > On Tuesday 29 Nov 2016 10:54:09 Daniel Vetter wrote: >> >> On Tue, Nov 29, 2016 at 11:04:36AM +0200, Laurent Pinchart wrote: >> >>> The LVDS encoder driver is a DRM bridge driver that supports the >> >>> parallel to LVDS encoders that don't require any configuration. The >> >>> driver thus doesn't interact with the device, but creates an LVDS >> >>> connector for the panel and exposes its size and timing based on >> >>> information retrieved from DT. >> >>> >> >>> Signed-off-by: Laurent Pinchart >> >>> >> >> >> >> Since it's 100% dummy, why put LVDS into the name? This little thing >> >> here could be our generic "wrap drm_panel and attach it to a chain" >> >> helper. So what about calling this _The_ drm_panel_bridge, and also >> >> linking it into docs to feature it a bit more prominently. >> > >> > I'm not opposed to that, except that this driver should not be considered >> > as just a helper to link a panel. It should only be used to support a >> > real hardware bridge that requires no control. >> > >> >> I came up with this because I spotted some refactoring belows for >> >> building this helper, until I realized that this driver _is_ the helper I >> >> think we want ;-) Only thing missing is an exported function to >> >> instantiate a bridge with just a drm_panel as the parameter. And putting >> >> it into the drm_kms_helper.ko module. >> > >> > What would that be used for ? The bridge should be instantiated by this >> > bridge driver, bound to a bridge device instantiated from DT (or the >> > platform firmware of your choice). >> >> Atm every driver using drm_panel needs a bit of glue to bind it into it's >> display chain. With this code, and bridge chaining, you'd get that for >> free, and I think that would be rather useful. > > You would trade the bit of panel glue for a bit of bridge glue. Bridge > chaining could perhaps help slightly at runtime there, but at init time the > amount of glue would be similar. Hm, something like drm_bridge_panel_bridge_init(dev, panel) should be enough, or not? My idea is to use this for the case where the only thing in dt is the panel, with no real bridge chip. And I think we don't need anything beyond that one _init function, plus maybe some additional paramaters ... > I've noticed one piece of code that is LVDS-specific in this driver, and > that's connector creation. The connector type is hardcoded to LVDS. To make > the driver more generic, we would need a way to find the connector type at > runtime. I'm wondering whether I should do this now, or keep the driver LVDS- > specific until someone comes up with a similar need. Without several potential > users it's often hard to design a properly generic API. ... like whether the panel is dsi or lvds or soemthing else. Or maybe we should just use LVDS for everything, because it's a panel, and userspace shouldn't really care beyond that ;-) >> And from a software point of view I'd say if it quacks like a bridge, and >> walks like a bridge, it probably _is_ a bridge. Even if no one calls that, >> or if physical the only thing on the board at that spot are a bunch of dumb >> wires. > > I dream of moving all encoders to DRM bridge, and then unifying drm_bridge and > drm_panel with a common set of operations that could be invoked on both > objects. That way the core could chain bridges and panels quite easily. I plan > to experiment with this when moving the omapdrm driver to DRM bridge and DRM > panel (it currently includes a bunch of custom encoder and panel drivers). Agreed on that dream, auto-wrapping panels in dummy bridges would be a first step towards that. The other one is making drm_encoders entirely dummies, and I think we're 90% there already. End result isn't quite as clean as a complete rewrite, but probably good enough. And because uapi we can't get rid of drm_encoder anyway, and keeping drm_panel as the internal thing embedded into a drm_panel_bridge struct seems reasonable too. That way panel drivers can cope with a slightly simpler interface than full bridges. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v4] drm: add fourcc codes for 16bit R and RG
From: Rainer Hochecker
Signed-off-by: Rainer Hochecker
---
include/uapi/drm/drm_fourcc.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..4d65fb6 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
/* 8 bpp Red */
#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
+
/* 16 bpp RG */
#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 little endian */
+/* 32 bpp RG */
+#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] G:R
16:16 little endian */
+#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 little endian */
+
/* 8 bpp RGB */
#define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
3:3:2 */
#define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
2:3:3 */
--
2.9.3
[PATCH] drm/meson: Fix plane atomic check when no crtc for the plane
On 01/04/2017 02:27 PM, Ville Syrjälä wrote:
> On Tue, Jan 03, 2017 at 10:20:54AM +0100, Neil Armstrong wrote:
>> When no CRTC is associated with the plane, the meson_plane_atomic_check()
>> call breaks the kernel with an Oops.
>>
>> Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_plane.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_plane.c
>> b/drivers/gpu/drm/meson/meson_plane.c
>> index 4942ca0..7890e30 100644
>> --- a/drivers/gpu/drm/meson/meson_plane.c
>> +++ b/drivers/gpu/drm/meson/meson_plane.c
>> @@ -51,6 +51,9 @@ static int meson_plane_atomic_check(struct drm_plane
>> *plane,
>> struct drm_crtc_state *crtc_state;
>> struct drm_rect clip = { 0, };
>>
>> +if (!state->crtc)
>> +return 0;
>> +
>
> Since you're not going to call drm_plane_helper_check_state() you will
> fail to update plane_state->visible.
Indeed I forgot about that, but i's not necessary yet since visibility is not
yet handled.
>
> What i915 does in this case is look for state->crtc first, and if that's
> NULL it'll pick the crtc from the old state (plane->state->crtc). It
> looks a bit ugly, but maybe we should hide it in a small helper function
> that could be used by all drivers?
Yes, an helper would be helpful.
>
>> crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
>> if (IS_ERR(crtc_state))
>> return PTR_ERR(crtc_state);
>> --
>> 1.9.1
Thanks,
Neil
[PATCH v3] drm: add fourcc codes for 16bit R and RG
From: Rainer Hochecker
This adds fourcc codes for 16bit planes required for DRM buffer
export to mesa.
Signed-off-by: Rainer Hochecker
---
include/uapi/drm/drm_fourcc.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..85079cd 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
/* 8 bpp Red */
#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
+
/* 16 bpp RG */
#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 little endian */
+/* 32 bpp GR */
+#define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2') /* [31:0] G:R
16:16 little endian */
+#define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 little endian */
+
/* 8 bpp RGB */
#define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
3:3:2 */
#define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
2:3:3 */
--
2.9.3
[PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote: > Hi Rob, > > Thank you for the review. > > On 03 January, 2017 23:51 CET, Rob Herring wrote: > >> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote: >> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++ >> > display bridge. >> > >> > Cc: Martyn Welch >> > Cc: Martin Donnelly >> > Cc: Javier Martinez Canillas >> > Cc: Enric Balletbo i Serra >> > Cc: Philipp Zabel >> > Cc: Rob Herring >> > Cc: Fabio Estevam >> > Signed-off-by: Peter Senna Tschudin >> > --- >> > There was an Acked-by from Rob Herring for V6, but I >> > changed >> > the bindings to use i2c_new_secondary_device() so I removed it from the >> > commit >> > message. >> > >> > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 >> > ++ >> >> Generally, bindings are not organized by vendor. Put in >> bindings/display/bridge/... instead. > > Will change that. > >> >> > 1 file changed, 39 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt >> > >> > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt >> > b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt >> > new file mode 100644 >> > index 000..1bc6ebf >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt >> > @@ -0,0 +1,39 @@ >> > +Driver for GE B850v3 LVDS/DP++ display bridge >> > + >> > +Required properties: >> > + - compatible : should be "ge,b850v3-lvds-dp". >> >> Isn't '-lvds-dp' redundant? The part# should be enough. > > b850v3 is the name of the product, this is why the proposed name. What about, > b850v3-dp2 dp2 indicating the second DP output? Humm, b850v3 is the board name? This node should be the name of the bridge chip. Rob
[RFC 6/6] spi: spidev: Add userspace driver support
Add support for spi userspace drivers backed by it's own spi_driver.
Userspace driver usage:
Open /dev/spidev
Write a string containing driver name and optional DT compatible.
This registers a spidev spi_driver.
Read/poll to receive notice when devices have been bound/probed.
The driver now uses /dev/spidevN.N as normal to access the device.
When the file is closed, the spi_driver is unregistered.
Signed-off-by: Noralf Trønnes
---
drivers/spi/spidev.c | 289 +--
1 file changed, 283 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 35e6377..b8f3559 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -26,11 +26,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
@@ -99,6 +101,20 @@ struct spidev_dmabuf {
unsigned int nents;
};
+struct spidev_drv {
+ struct spi_driver spidrv;
+ struct mutexevent_lock;
+ struct list_headevents;
+ wait_queue_head_t waitq;
+ struct completion completion;
+};
+
+struct spidev_drv_event {
+ struct list_head list;
+ u8 bus_num;
+ u8 chip_select;
+};
+
static LIST_HEAD(device_list);
static DEFINE_MUTEX(device_list_lock);
@@ -994,6 +1010,254 @@ static struct spi_driver spidev_spi_driver = {
/*-*/
+static int spidev_drv_probe(struct spi_device *spi)
+{
+ struct spi_driver *spidrv = to_spi_driver(spi->dev.driver);
+ struct spidev_drv *sdrv = container_of(spidrv, struct spidev_drv,
+ spidrv);
+ struct spidev_drv_event *new_device;
+ int ret;
+
+ ret = spidev_probe(spi);
+ if (ret)
+ return ret;
+
+ ret = mutex_lock_interruptible(&sdrv->event_lock);
+ if (ret)
+ goto out;
+
+ new_device = kzalloc(sizeof(*new_device), GFP_KERNEL);
+ if (new_device) {
+ new_device->bus_num = spi->master->bus_num;
+ new_device->chip_select = spi->chip_select;
+ list_add_tail(&new_device->list, &sdrv->events);
+ } else {
+ ret = -ENOMEM;
+ }
+
+ mutex_unlock(&sdrv->event_lock);
+
+ wake_up_interruptible(&sdrv->waitq);
+out:
+ if (ret)
+ dev_err(&spi->dev, "Failed to add event %d\n", ret);
+
+ return 0;
+}
+
+static int spidev_drv_remove(struct spi_device *spi)
+{
+ int ret;
+
+ ret = spidev_remove(spi);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static ssize_t spidev_drv_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+ char *str, *token, *drvname, *compatible;
+ struct of_device_id *of_ids = NULL;
+ struct spidev_drv *sdrv = NULL;
+ struct spi_driver *spidrv;
+ unsigned int i;
+ int status;
+
+ if (file->private_data)
+ return -EBUSY;
+
+ if (!count)
+ return 0;
+
+ if (count == 1)
+ return -EINVAL;
+
+ str = strndup_user(buffer, count);
+ if (IS_ERR(str))
+ return PTR_ERR(str);
+
+ for (i = 0, token = str; *token; token++)
+ if (*token == '\n')
+ i++;
+
+ if (i > 1) {
+ status = -EINVAL;
+ goto err_free;
+ }
+
+ drvname = str;
+ if (i) {
+ strsep(&str, "\n");
+ compatible = str;
+ } else {
+ compatible = NULL;
+ }
+
+ if (compatible && strlen(compatible) > 127) {
+ status = -EINVAL;
+ goto err_free;
+ }
+
+pr_info("spidev: Add driver '%s', compatible='%s'\n", drvname, compatible);
+
+ sdrv = kzalloc(sizeof(*sdrv), GFP_KERNEL);
+ if (!sdrv) {
+ status = -ENOMEM;
+ goto err_free;
+ }
+
+ INIT_LIST_HEAD(&sdrv->events);
+ mutex_init(&sdrv->event_lock);
+ init_waitqueue_head(&sdrv->waitq);
+
+ spidrv = &sdrv->spidrv;
+ spidrv->driver.name = drvname;
+ spidrv->probe = spidev_drv_probe;
+ spidrv->remove = spidev_drv_remove;
+
+ if (compatible) {
+ /* the second blank entry is the sentinel */
+ of_ids = kcalloc(2, sizeof(*of_ids), GFP_KERNEL);
+ if (!of_ids) {
+ status = -ENOMEM;
+ goto err_free;
+ }
+ strcpy(of_ids[0].compatible, compatible);
+ spidrv->driver.of_match_table = of_ids;
+ }
+
+ status = spi_register_driver(spidrv);
+ if (status < 0)
+ goto err_free;
+
+ file->private_data = sdrv;
+
+ return count;
+
+err_free:
+ kfree(sdrv);
[RFC 5/6] spi: spidev: Add dma-buf support
Add support for using dma-buf buffers in transfers from userspace.
FIXME: Backwards compatibility needs to be taken care of somehow.
Signed-off-by: Noralf Trønnes
---
drivers/spi/Kconfig | 1 +
drivers/spi/spidev.c| 158 +++-
include/uapi/linux/spi/spidev.h | 8 ++
3 files changed, 163 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b799547..ac6bbd1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -731,6 +731,7 @@ comment "SPI Protocol Masters"
config SPI_SPIDEV
tristate "User mode SPI device driver support"
+ select SG_SPLIT if DMA_SHARED_BUFFER
help
This supports user mode SPI protocol drivers.
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index d780491..35e6377 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -87,6 +89,16 @@ struct spidev_data {
u32 speed_hz;
};
+struct spidev_dmabuf {
+ struct device *dev;
+ struct dma_buf_attachment *attach;
+ enum dma_data_direction dir;
+ struct sg_table *sgt_dmabuf;
+ void *vaddr;
+ struct scatterlist *sgl;
+ unsigned int nents;
+};
+
static LIST_HEAD(device_list);
static DEFINE_MUTEX(device_list_lock);
@@ -205,21 +217,122 @@ spidev_write(struct file *filp, const char __user *buf,
return status;
}
+#ifdef CONFIG_DMA_SHARED_BUFFER
+
+static int spidev_dmabuf_map(struct spidev_dmabuf *sdmabuf, struct device *dev,
+int fd, enum dma_data_direction dir,
+u32 offset, u32 len)
+{
+ struct dma_buf_attachment *attach;
+ struct dma_buf *dmabuf;
+ struct sg_table *sgt;
+ void *vaddr;
+ size_t sizes[1] = { len, };
+ struct scatterlist *out[1];
+ int out_nents[1];
+ int ret;
+
+ dmabuf = dma_buf_get(fd);
+ if (IS_ERR(dmabuf))
+ return PTR_ERR(dmabuf);
+
+ attach = dma_buf_attach(dmabuf, dev);
+ if (IS_ERR(attach)) {
+ ret = PTR_ERR(attach);
+ goto err_put;
+ }
+
+ sgt = dma_buf_map_attachment(attach, dir);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto err_detach;
+ }
+
+ ret = sg_split(sgt->sgl, sgt->nents, offset, 1, sizes, out, out_nents,
GFP_KERNEL);
+ if (ret) {
+ goto err_unmap;
+ }
+
+ /* A virtual address is only necessary if master can't do dma. */
+// ret = dma_buf_begin_cpu_access(dmabuf, dir);
+// if (ret)
+// goto err_free_sg;
+
+ vaddr = dma_buf_vmap(dmabuf);
+ if (!vaddr) {
+ ret = -ENOMEM;
+ goto err_end_access;
+ }
+
+ sdmabuf->dev = dev;
+ sdmabuf->attach = attach;
+ sdmabuf->dir = dir;
+ sdmabuf->sgt_dmabuf = sgt;
+ sdmabuf->vaddr = vaddr;
+ sdmabuf->sgl = out[0];
+ sdmabuf->nents = out_nents[0];
+
+ return 0;
+
+err_end_access:
+// dma_buf_end_cpu_access(dmabuf, dir);
+//err_free_sg:
+ kfree(out[0]);
+err_unmap:
+ dma_buf_unmap_attachment(attach, sgt, dir);
+err_detach:
+ dma_buf_detach(dmabuf, attach);
+err_put:
+ dma_buf_put(dmabuf);
+
+ return ret;
+}
+
+static void spidev_dmabuf_unmap(struct spidev_dmabuf *sdmabuf)
+{
+ struct dma_buf *dmabuf;
+
+ if (!sdmabuf->attach)
+ return;
+
+ dmabuf = sdmabuf->attach->dmabuf;
+ dma_buf_vunmap(dmabuf, sdmabuf->vaddr);
+// dma_buf_end_cpu_access(dmabuf, sdmabuf->dir);
+ dma_buf_unmap_attachment(sdmabuf->attach, sdmabuf->sgt_dmabuf,
sdmabuf->dir);
+ dma_buf_detach(dmabuf, sdmabuf->attach);
+ dma_buf_put(dmabuf);
+}
+#else
+static int spidev_dmabuf_map(struct spidev_dmabuf *sdmabuf, struct device *dev,
+int fd, enum dma_data_direction dir,
+u32 offset, u32 len)
+{
+ return -ENOTSUPP;
+}
+
+static void spidev_dmabuf_unmap(struct spidev_dmabuf *sdmabuf) {}
+#endif
+
static int spidev_message(struct spidev_data *spidev,
struct spi_ioc_transfer *u_xfers, unsigned n_xfers)
{
+ struct spi_device *spi = spidev->spi;
struct spi_message msg;
struct spi_transfer *k_xfers;
struct spi_transfer *k_tmp;
struct spi_ioc_transfer *u_tmp;
+ struct spidev_dmabuf*sdmabufs, *s_tmp;
unsignedn, total, tx_total, rx_total;
u8 *tx_buf, *rx_buf;
int status = -EFAULT;
spi_message_init(&msg);
k_xfers = kcalloc(n_xfers, sizeof(*k_tmp), GFP_KERNEL);
- if (k_xfers == NULL)
- return -ENOMEM;
+ sdmabufs = kcalloc(n_xfers * 2, sizeof(*s_tmp), GFP_KERNE
[RFC 4/6] spi: Let clients do scatter/gather transfers
Just a hack. Someone probably has an idea about how this should be done.
Signed-off-by: Noralf Trønnes
---
drivers/spi/spi.c | 24 +---
include/linux/spi/spi.h | 4
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 838783c..b2958be 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -808,23 +808,28 @@ static int __spi_map_msg(struct spi_master *master,
struct spi_message *msg)
if (!master->can_dma(master, msg->spi, xfer))
continue;
- if (xfer->tx_buf != NULL) {
+ if (xfer->tx_buf != NULL && !xfer->tx_sg.nents) {
ret = spi_map_buf(master, tx_dev, &xfer->tx_sg,
(void *)xfer->tx_buf, xfer->len,
DMA_TO_DEVICE);
if (ret != 0)
return ret;
+
+ xfer->tx_sg_core_mapped = true;
}
- if (xfer->rx_buf != NULL) {
+ if (xfer->rx_buf != NULL && !xfer->rx_sg.nents) {
ret = spi_map_buf(master, rx_dev, &xfer->rx_sg,
xfer->rx_buf, xfer->len,
DMA_FROM_DEVICE);
if (ret != 0) {
spi_unmap_buf(master, tx_dev, &xfer->tx_sg,
DMA_TO_DEVICE);
+ xfer->tx_sg_core_mapped = false;
return ret;
}
+
+ xfer->rx_sg_core_mapped = true;
}
}
@@ -852,11 +857,16 @@ static int __spi_unmap_msg(struct spi_master *master,
struct spi_message *msg)
rx_dev = &master->dev;
list_for_each_entry(xfer, &msg->transfers, transfer_list) {
- if (!master->can_dma(master, msg->spi, xfer))
- continue;
-
- spi_unmap_buf(master, rx_dev, &xfer->rx_sg, DMA_FROM_DEVICE);
- spi_unmap_buf(master, tx_dev, &xfer->tx_sg, DMA_TO_DEVICE);
+ if (xfer->rx_sg_core_mapped) {
+ spi_unmap_buf(master, rx_dev, &xfer->rx_sg,
+ DMA_FROM_DEVICE);
+ xfer->rx_sg.nents = 0;
+ }
+ if (xfer->tx_sg_core_mapped) {
+ spi_unmap_buf(master, tx_dev, &xfer->tx_sg,
+ DMA_TO_DEVICE);
+ xfer->tx_sg.nents = 0;
+ }
}
return 0;
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 4b743ac..f27fda6 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -682,6 +682,8 @@ extern void spi_res_release(struct spi_master *master,
* @transfer_list: transfers are sequenced through @spi_message.transfers
* @tx_sg: Scatterlist for transmit, currently not for client use
* @rx_sg: Scatterlist for receive, currently not for client use
+ * @tx_sg_core_mapped: Scatterlist has been mapped by spi core
+ * @rx_sg_core_mapped: Scatterlist has been mapped by spi core
*
* SPI transfers always write the same number of bytes as they read.
* Protocol drivers should always provide @rx_buf and/or @tx_buf.
@@ -751,6 +753,8 @@ struct spi_transfer {
dma_addr_t rx_dma;
struct sg_table tx_sg;
struct sg_table rx_sg;
+ booltx_sg_core_mapped;
+ boolrx_sg_core_mapped;
unsignedcs_change:1;
unsignedtx_nbits:3;
--
2.10.2
[RFC 3/6] dma-buf: Support generic userspace allocations
Add a generic way for userspace to allocate dma-buf's for SPI transfers.
Signed-off-by: Noralf Trønnes
---
drivers/dma-buf/Makefile | 2 +-
drivers/dma-buf/dev.c| 211 +++
include/uapi/linux/dma-buf-dev.h | 35 +++
3 files changed, 247 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/dev.c
create mode 100644 include/uapi/linux/dma-buf-dev.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 210a10b..ec867f7 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,3 +1,3 @@
-obj-y := dma-buf.o fence.o reservation.o seqno-fence.o fence-array.o
+obj-y := dma-buf.o fence.o reservation.o seqno-fence.o fence-array.o dev.o
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
diff --git a/drivers/dma-buf/dev.c b/drivers/dma-buf/dev.c
new file mode 100644
index 000..536d9bf
--- /dev/null
+++ b/drivers/dma-buf/dev.c
@@ -0,0 +1,211 @@
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct dma_buf_dev_object {
+ struct device *dev;
+ unsigned long attrs;
+ dma_addr_t dma_addr;
+ void *vaddr;
+ size_t size;
+};
+
+static struct sg_table *
+dma_buf_dev_map_dma_buf(struct dma_buf_attachment *attach,
+ enum dma_data_direction dir)
+{
+ struct dma_buf_dev_object *obj = attach->dmabuf->priv;
+ struct sg_table *sgt;
+ int ret;
+
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt)
+ return ERR_PTR(-ENOMEM);
+
+ ret = dma_get_sgtable(obj->dev, sgt, obj->vaddr,
+ obj->dma_addr, obj->size);
+ if (ret < 0)
+ goto err_free;
+
+ if (!dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir)) {
+ ret = -ENOMEM;
+ goto err_free_table;
+ }
+
+ return sgt;
+
+err_free_table:
+ sg_free_table(sgt);
+err_free:
+ kfree(sgt);
+
+ return ERR_PTR(ret);
+}
+
+static void dma_buf_dev_unmap_dma_buf(struct dma_buf_attachment *attach,
+ struct sg_table *sgt,
+ enum dma_data_direction dir)
+{
+ dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+ sg_free_table(sgt);
+ kfree(sgt);
+}
+
+static void dma_buf_dev_release(struct dma_buf *dma_buf)
+{
+ struct dma_buf_dev_object *obj = dma_buf->priv;
+
+/* FIXME remove */
+pr_info("%s()\n", __func__);
+ dma_free_attrs(obj->dev, obj->size, obj->vaddr, obj->dma_addr,
+ obj->attrs);
+ kfree(obj);
+}
+
+static void *dma_buf_dev_kmap(struct dma_buf *dma_buf, unsigned long page_num)
+{
+ struct dma_buf_dev_object *obj = dma_buf->priv;
+
+ return obj->vaddr + page_num * PAGE_SIZE;
+}
+
+static void *dma_buf_dev_vmap(struct dma_buf *dma_buf)
+{
+ struct dma_buf_dev_object *obj = dma_buf->priv;
+
+ return obj->vaddr;
+}
+
+static int dma_buf_dev_mmap(struct dma_buf *dma_buf,
+ struct vm_area_struct *vma)
+{
+ struct dma_buf_dev_object *obj = dma_buf->priv;
+ int ret;
+
+ vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
+
+ ret = dma_mmap_attrs(obj->dev, vma, obj->vaddr, obj->dma_addr,
+vma->vm_end - vma->vm_start, obj->attrs);
+
+ return ret;
+}
+
+static const struct dma_buf_ops dma_buf_dev_ops = {
+ .map_dma_buf = dma_buf_dev_map_dma_buf,
+ .unmap_dma_buf = dma_buf_dev_unmap_dma_buf,
+ .release = dma_buf_dev_release,
+ .kmap_atomic = dma_buf_dev_kmap,
+ .kmap = dma_buf_dev_kmap,
+ .vmap = dma_buf_dev_vmap,
+ .mmap = dma_buf_dev_mmap,
+};
+
+struct dma_buf *dma_buf_dev_alloc_attrs(struct device *dev, size_t size,
+ unsigned long attrs, int flags)
+{
+ DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ struct dma_buf_dev_object *obj;
+ struct dma_buf *dmabuf;
+ int ret;
+
+ if (flags & ~(O_CLOEXEC | O_ACCMODE))
+ return ERR_PTR(-EINVAL);
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ obj->dev = dev;
+ obj->size = size;
+ obj->attrs = attrs;
+
+ obj->vaddr = dma_alloc_attrs(dev, size, &obj->dma_addr, GFP_KERNEL,
attrs);
+ if (!obj->vaddr) {
+ ret = -ENOMEM;
+ goto err_free_obj;
+ }
+
+ exp_info.ops = &dma_buf_dev_ops;
+ exp_info.size = obj->size;
+ exp_info.flags = flags;
+ exp_info.priv = obj;
[RFC 2/6] drm: Add support for userspace drivers
Add support for writing drm userspace drivers.
Userspace driver usage:
Open /dev/udrm
Ioctl create drm driver/device passing in mode, formats and optional
dma-buf as transfer buffer
Read/poll for events:
framebuffer: create, destroy, dirty
pipe: enable, disable
Write back status value from the event execution
Closing file will delete the drm driver.
The reason for doing buffer copy in the kernel is that on a Raspberry Pi
copying (actually reading) a mmap'ed 150k dma-buf in userspace took 32ms
while in-kernel was 13ms.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/udrm/Kconfig | 9 +
drivers/gpu/drm/udrm/Makefile| 4 +
drivers/gpu/drm/udrm/udrm-dev.c | 276 +
drivers/gpu/drm/udrm/udrm-drv.c | 324 ++
drivers/gpu/drm/udrm/udrm-fb.c | 369 +++
drivers/gpu/drm/udrm/udrm-pipe.c | 170 ++
drivers/gpu/drm/udrm/udrm.h | 84 +
include/uapi/drm/udrm.h | 78 +
10 files changed, 1317 insertions(+)
create mode 100644 drivers/gpu/drm/udrm/Kconfig
create mode 100644 drivers/gpu/drm/udrm/Makefile
create mode 100644 drivers/gpu/drm/udrm/udrm-dev.c
create mode 100644 drivers/gpu/drm/udrm/udrm-drv.c
create mode 100644 drivers/gpu/drm/udrm/udrm-fb.c
create mode 100644 drivers/gpu/drm/udrm/udrm-pipe.c
create mode 100644 drivers/gpu/drm/udrm/udrm.h
create mode 100644 include/uapi/drm/udrm.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 483059a..b351798 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -223,6 +223,8 @@ source "drivers/gpu/drm/hisilicon/Kconfig"
source "drivers/gpu/drm/mediatek/Kconfig"
+source "drivers/gpu/drm/udrm/Kconfig"
+
# Keep legacy drivers last
menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 25c7204..29175bc 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -86,3 +86,4 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
obj-$(CONFIG_DRM_ARCPGU)+= arc/
obj-y += hisilicon/
+obj-y += udrm/
diff --git a/drivers/gpu/drm/udrm/Kconfig b/drivers/gpu/drm/udrm/Kconfig
new file mode 100644
index 000..41faa4b
--- /dev/null
+++ b/drivers/gpu/drm/udrm/Kconfig
@@ -0,0 +1,9 @@
+config DRM_USER
+ tristate "Support for userspace DRM drivers"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select VIDEOMODE_HELPERS
+ help
+ Choose this option if you have a userspace DRM driver.
+ If M is selected the module will be called tinydrm.
diff --git a/drivers/gpu/drm/udrm/Makefile b/drivers/gpu/drm/udrm/Makefile
new file mode 100644
index 000..9eb8c27
--- /dev/null
+++ b/drivers/gpu/drm/udrm/Makefile
@@ -0,0 +1,4 @@
+ccflags-y += -I$(src)/include
+
+udrm-y := udrm-dev.o udrm-drv.o udrm-fb.o udrm-pipe.o
+obj-$(CONFIG_DRM_USER) += udrm.o
diff --git a/drivers/gpu/drm/udrm/udrm-dev.c b/drivers/gpu/drm/udrm/udrm-dev.c
new file mode 100644
index 000..eb19b7b
--- /dev/null
+++ b/drivers/gpu/drm/udrm/udrm-dev.c
@@ -0,0 +1,276 @@
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "udrm.h"
+
+static struct miscdevice udrm_misc;
+
+int udrm_send_event(struct udrm_device *udev, void *ev_in)
+{
+ struct udrm_event *ev = ev_in;
+ unsigned long time_left;
+ int ret = 0;
+
+ mutex_lock(&udev->dev_lock);
+
+ DRM_DEBUG("IN ev->type=%u, ev->length=%u\n", ev->type, ev->length);
+
+ if (!udev->initialized) {
+ DRM_ERROR("Not initialized\n");
+ ret = -ENODEV;
+ goto out_unlock;
+ }
+
+ ev = kmemdup(ev, ev->length, GFP_KERNEL);
+ if (!ev) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
+
+ reinit_completion(&udev->completion);
+
+ ret = mutex_lock_interruptible(&udev->mutex);
+ if (ret) {
+ kfree(ev);
+ goto out_unlock;
+ }
+ udev->ev = ev;
+ mutex_unlock(&udev->mutex);
+
+ wake_up_interruptible(&udev->waitq);
+
+ time_left = wait_for_completion_timeout(&udev->completion, 5 * HZ);
+ ret = udev->event_ret;
+ if (!time_left) {
+ DRM_ERROR("timeout waiting for reply\n");
+ ret = -ETIMEDOUT;
+ }
+
+out_unlock:
+ mutex_unlock(&udev->dev_lock);
+
+ DRM_DEBUG("OUT ret=%d, event_ret=%d\n", r
[RFC 1/6] drm/modes: Export drm_mode_convert_umode()
Export drm_mode_convert_umode() for the benefit of udrm. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_modes.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 53f07ac..97cf51f 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1555,3 +1555,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out, out: return ret; } +EXPORT_SYMBOL(drm_mode_convert_umode); -- 2.10.2
[RFC 0/6] drm: Add support for userspace drivers
Hi, I was previously working on tinydrm as a replacement for staging/fbtft. During a break from that work, I started to think about if it would be possible to move the drivers to userspace instead. No point in having them in the kernel if it's not necessary. This patchset includes all the pieces necessary to get a userspace driver[1] working that is compatible with the fbtft/fb_ili9341 driver. It is tested with a SPI interfaced display hat/shield for the Raspberry Pi, which has an eeprom with a Device Tree fragment on it (merged by the bootloader). With the help of udev and systemd, the driver is able to autoload when the display is connected. Performance wise, the kernel driver can do ~19fps on a 320x240 spi at 32MHz display, whereas the userspace version does ~18fps. So performance is not an argument to keep the driver in the kernel. What do you think about this approach? Note: This patchset is based on 4.9 [1] https://github.com/notro/udrm Noralf. Noralf Trønnes (6): drm/modes: Export drm_mode_convert_umode() drm: Add support for userspace drivers dma-buf: Support generic userspace allocations spi: Let clients do scatter/gather transfers spi: spidev: Add dma-buf support spi: spidev: Add userspace driver support drivers/dma-buf/Makefile | 2 +- drivers/dma-buf/dev.c| 211 ++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_modes.c | 1 + drivers/gpu/drm/udrm/Kconfig | 9 + drivers/gpu/drm/udrm/Makefile| 4 + drivers/gpu/drm/udrm/udrm-dev.c | 276 drivers/gpu/drm/udrm/udrm-drv.c | 324 drivers/gpu/drm/udrm/udrm-fb.c | 369 drivers/gpu/drm/udrm/udrm-pipe.c | 170 +++ drivers/gpu/drm/udrm/udrm.h | 84 drivers/spi/Kconfig | 1 + drivers/spi/spi.c| 24 ++- drivers/spi/spidev.c | 447 ++- include/linux/spi/spi.h | 4 + include/uapi/drm/udrm.h | 78 +++ include/uapi/linux/dma-buf-dev.h | 35 +++ include/uapi/linux/spi/spidev.h | 8 + 19 files changed, 2032 insertions(+), 18 deletions(-) create mode 100644 drivers/dma-buf/dev.c create mode 100644 drivers/gpu/drm/udrm/Kconfig create mode 100644 drivers/gpu/drm/udrm/Makefile create mode 100644 drivers/gpu/drm/udrm/udrm-dev.c create mode 100644 drivers/gpu/drm/udrm/udrm-drv.c create mode 100644 drivers/gpu/drm/udrm/udrm-fb.c create mode 100644 drivers/gpu/drm/udrm/udrm-pipe.c create mode 100644 drivers/gpu/drm/udrm/udrm.h create mode 100644 include/uapi/drm/udrm.h create mode 100644 include/uapi/linux/dma-buf-dev.h -- 2.10.2
[PATCH] drm: nouveau: fix build when LEDS_CLASS=m
On 01/04/17 11:29, Jani Nikula wrote: > On Wed, 04 Jan 2017, Daniel Vetter wrote: >> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote: >>> From: Randy Dunlap >>> >>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and >>> CONFIG_DRM_NOUVEAU=y. >>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the same >>> kconfig value as LEDS_CLASS. >>> >>> drivers/built-in.o: In function `nouveau_do_suspend': >>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend' >>> drivers/built-in.o: In function `nouveau_do_resume': >>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume' >>> drivers/built-in.o: In function `nouveau_drm_unload': >>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini' >>> drivers/built-in.o: In function `nouveau_drm_load': >>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init' >>> >>> BTW, this line in Kbuild: >>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o >>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y. >>> >>> Signed-off-by: Randy Dunlap >>> Reported-by: kbuild test robot >>> Cc: Martin Peres >>> Cc: Ben Skeggs >> >> Thrown into drm-misc, thanks. > > Randy, this results in the following recursive dependency using the > attached config. > Hi, Please drop the patch for now. If there is an alternative patch, that's good. Otherwise I'll look for a solution. Thanks. > BR, > Jani. > > > drivers/usb/Kconfig:39:error: recursive dependency detected! > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/input/Kconfig:8: symbol INPUT is selected by VT > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/tty/Kconfig:12: symbol VT is selected by FB_STI > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/video/fbdev/Kconfig:678: symbol FB_STI depends on FB > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/video/fbdev/Kconfig:5:symbol FB is selected by > DRM_KMS_FB_HELPER > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by > DRM_KMS_CMA_HELPER > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/Kconfig:128: symbol DRM_KMS_CMA_HELPER is selected by > DRM_HDLCD > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/arm/Kconfig:6:symbol DRM_HDLCD depends on COMMON_CLK > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by X86_INTEL_QUARK > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > arch/x86/Kconfig:554: symbol X86_INTEL_QUARK depends on X86_PLATFORM_DEVICES > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/platform/x86/Kconfig:5: symbol X86_PLATFORM_DEVICES is selected > by DRM_NOUVEAU > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/gpu/drm/nouveau/Kconfig:1:symbol DRM_NOUVEAU depends on LEDS_CLASS > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/leds/Kconfig:16: symbol LEDS_CLASS is selected by ATH9K_HTC > For a resolution refer to Documentation/kbuild/kconfig-language.txt > subsection "Kconfig recursive dependency limitations" > drivers/net/wireless/ath/ath9k/Kconfig:158: symbol ATH9K_HTC depends on USB > warning: (DRM_NOUVEAU && DRM_I915 && DRM_GMA500) selects ACPI_VIDEO which has > unmet direct dependencies (ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT) -- ~Randy
[PATCH 3/3] dma-fence: Introduce drm_fence_set_error() helper
The dma_fence.error field (formerly known as dma_fence.status) is an
optional field that may be set by drivers before calling
dma_fence_signal(). The field can be used to indicate that the fence was
completed in err rather than with success, and is visible to other
consumers of the fence and to userspace via sync_file.
This patch renames the field from status to error so that its meaning is
hopefully more clear (and distinct from dma_fence_get_status() which is
a composite between the error state and signal state) and adds a helper
that validates the preconditions of when it is suitable to adjust the
error field.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence.c | 2 +-
include/linux/dma-fence.h | 30 +-
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 7d936d19e659..ee82f36cb25e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -559,7 +559,7 @@ dma_fence_init(struct dma_fence *fence, const struct
dma_fence_ops *ops,
fence->context = context;
fence->seqno = seqno;
fence->flags = 0UL;
- fence->status = 0;
+ fence->error = 0;
trace_dma_fence_init(fence);
}
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 19f7af905182..6048fa404e57 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -47,7 +47,7 @@ struct dma_fence_cb;
* can be compared to decide which fence would be signaled later.
* @flags: A mask of DMA_FENCE_FLAG_* defined below
* @timestamp: Timestamp when the fence was signaled.
- * @status: Optional, only valid if < 0, must be set before calling
+ * @error: Optional, only valid if < 0, must be set before calling
* dma_fence_signal, indicates that the fence has completed with an error.
*
* the flags member must be manipulated and read using the appropriate
@@ -79,7 +79,7 @@ struct dma_fence {
unsigned seqno;
unsigned long flags;
ktime_t timestamp;
- int status;
+ int error;
};
enum dma_fence_flag_bits {
@@ -133,7 +133,7 @@ struct dma_fence_cb {
* or some failure occurred that made it impossible to enable
* signaling. True indicates successful enabling.
*
- * fence->status may be set in enable_signaling, but only when false is
+ * fence->error may be set in enable_signaling, but only when false is
* returned.
*
* Calling dma_fence_signal before enable_signaling is called allows
@@ -145,7 +145,7 @@ struct dma_fence_cb {
* the second time will be a noop since it was already signaled.
*
* Notes on signaled:
- * May set fence->status if returning true.
+ * May set fence->error if returning true.
*
* Notes on wait:
* Must not be NULL, set to dma_fence_default_wait for default implementation.
@@ -395,13 +395,33 @@ static inline struct dma_fence *dma_fence_later(struct
dma_fence *f1,
static inline int dma_fence_get_status_locked(struct dma_fence *fence)
{
if (dma_fence_is_signaled_locked(fence))
- return fence->status < 0 ? fence->status : 1;
+ return fence->error ?: 1;
else
return 0;
}
int dma_fence_get_status(struct dma_fence *fence);
+/**
+ * dma_fence_set_error - flag an error condition on the fence
+ * @fence: [in]the dma_fence
+ * @error: [in]the error to store
+ *
+ * Drivers can supply an optional error status condition before they signal
+ * the fence, to indicate that the fence was completed due to an error
+ * rather than success. This must be set before signaling (so that the value
+ * is visible before any waiters on the signal callback are woken). This
+ * helper exists to help catching erroneous setting of #dma_fence.error.
+ */
+static inline void dma_fence_set_error(struct dma_fence *fence,
+ int error)
+{
+ BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
+ BUG_ON(error >= 0 || error < -MAX_ERRNO);
+
+ fence->error = error;
+}
+
signed long dma_fence_wait_timeout(struct dma_fence *,
bool intr, signed long timeout);
signed long dma_fence_wait_any_timeout(struct dma_fence **fences,
--
2.11.0
[PATCH 2/3] dma-fence: Wrap querying the fence->status
The fence->status is an optional field that is only valid once the fence
has been signaled. (Driver may fill the fence->status with an error code
prior to calling dma_fence_signal().) Given the restriction upon its
validity, wrap querying of the fence->status into a helper
dma_fence_get_status().
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence.c | 25 +
drivers/dma-buf/sync_debug.c | 17 -
drivers/dma-buf/sync_file.c | 6 ++
include/linux/dma-fence.h| 24
4 files changed, 59 insertions(+), 13 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 9130f790ebf3..7d936d19e659 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -275,6 +275,31 @@ int dma_fence_add_callback(struct dma_fence *fence, struct
dma_fence_cb *cb,
EXPORT_SYMBOL(dma_fence_add_callback);
/**
+ * dma_fence_get_status - returns the status upon completion
+ * @fence: [in]the dma_fence to query
+ *
+ * This wraps dma_fence_get_status_locked() to return the error status
+ * condition on a signaled fence. See dma_fence_get_status_locked() for more
+ * details.
+ *
+ * Returns 0 if the fence has not yet been signaled, 1 if the fence has
+ * been signaled without an error condition, or a negative error code
+ * if the fence has been completed in err.
+ */
+int dma_fence_get_status(struct dma_fence *fence)
+{
+ unsigned long flags;
+ int status;
+
+ spin_lock_irqsave(fence->lock, flags);
+ status = dma_fence_get_status_locked(fence);
+ spin_unlock_irqrestore(fence->lock, flags);
+
+ return status;
+}
+EXPORT_SYMBOL(dma_fence_get_status);
+
+/**
* dma_fence_remove_callback - remove a callback from the signaling list
* @fence: [in]the fence to wait on
* @cb:[in]the callback to remove
diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index 48b20e34fb6d..c769dc653b34 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -62,30 +62,29 @@ void sync_file_debug_remove(struct sync_file *sync_file)
static const char *sync_status_str(int status)
{
- if (status == 0)
- return "signaled";
+ if (status < 0)
+ return "error";
if (status > 0)
- return "active";
+ return "signaled";
- return "error";
+ return "active";
}
static void sync_print_fence(struct seq_file *s,
struct dma_fence *fence, bool show)
{
- int status = 1;
struct sync_timeline *parent = dma_fence_parent(fence);
+ int status;
- if (dma_fence_is_signaled_locked(fence))
- status = fence->status;
+ status = dma_fence_get_status_locked(fence);
seq_printf(s, " %s%sfence %s",
show ? parent->name : "",
show ? "_" : "",
sync_status_str(status));
- if (status <= 0) {
+ if (status) {
struct timespec64 ts64 =
ktime_to_timespec64(fence->timestamp);
@@ -136,7 +135,7 @@ static void sync_print_sync_file(struct seq_file *s,
int i;
seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
- sync_status_str(!dma_fence_is_signaled(sync_file->fence)));
+ sync_status_str(dma_fence_get_status(sync_file->fence)));
if (dma_fence_is_array(sync_file->fence)) {
struct dma_fence_array *array =
to_dma_fence_array(sync_file->fence);
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 07cb9b908f30..2321035f6204 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -373,10 +373,8 @@ static void sync_fill_fence_info(struct dma_fence *fence,
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
sizeof(info->driver_name));
- if (dma_fence_is_signaled(fence))
- info->status = fence->status >= 0 ? 1 : fence->status;
- else
- info->status = 0;
+
+ info->status = dma_fence_get_status(fence);
info->timestamp_ns = ktime_to_ns(fence->timestamp);
}
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index d51a7d23c358..19f7af905182 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -378,6 +378,30 @@ static inline struct dma_fence *dma_fence_later(struct
dma_fence *f1,
return dma_fence_is_signaled(f2) ? NULL : f2;
}
+/**
+ * dma_fence_get_status_locked - returns the status upon completion
+ * @fence: [in]the dma_fence to query
+ *
+ * Drivers can supply an optional error status condition before they signal
+ * the fence (to indicate whether the fence was completed due to an error
+ * rather than success). The value of the status condition is only valid
+ * if
[PATCH 1/3] dma-fence: Clear fence->status during dma_fence_init()
As the fence->status is an optional field that may be set before dma_fence_signal() is called to convey that the fence completed with an error, we have to ensure that it is always set to zero on initialisation so that the typical use (i.e. unset) always flags a successful completion. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/dma-buf/dma-fence.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 3444f293ad4a..9130f790ebf3 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, fence->context = context; fence->seqno = seqno; fence->flags = 0UL; + fence->status = 0; trace_dma_fence_init(fence); } -- 2.11.0
[PATCH] drm/omap: panel-sony-acx565akm.c: Add MODULE_ALIAS
Hi,
On 27/12/16 22:12, Jarkko Nikula wrote:
> Add module alias for Sony ACX565AKM LCD panel. This makes it probe on Nokia
> N900 when panel driver is built as a module.
>
> Signed-off-by: Jarkko Nikula
> ---
> This is on top of linux-next next-20161224.
> ---
> drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
> b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
> index 746cb8d9cba1..5ab39e0060f2 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c
> @@ -909,6 +909,7 @@ static struct spi_driver acx565akm_driver = {
>
> module_spi_driver(acx565akm_driver);
>
> +MODULE_ALIAS("spi:sony,acx565akm");
> MODULE_AUTHOR("Nokia Corporation");
> MODULE_DESCRIPTION("acx565akm LCD Driver");
> MODULE_LICENSE("GPL");
>
Thanks, queued for 4.11.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/f6564bfb/attachment.sig>
Static code analyzer annotations in driver code?
Hi! What is the general opinion about out-of-tree static analyzer annotations in drm driver code, for example comments like /* coverity[missing_lock] */ which typically squelches false positives in constructors or destructors of refcounted structs that contain members that are elsewhere protected by locks. Thanks, Thomas
[PATCH] omap drm: fix compile errors where the conversion from omap_timing to videomode was not perfect
Hi, On 26/12/16 21:23, H. Nikolaus Schaller wrote: > Signed-off-by: H. Nikolaus Schaller > --- > drivers/gpu/drm/omapdrm/dss/dsi.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) Thanks, I picked this up (after improving the subject and desc). Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170104/527b8165/attachment.sig>
