[Bug 97305] Gallium: TBOs and images set the offset in elements, not bytes
https://bugs.freedesktop.org/show_bug.cgi?id=97305 --- Comment #15 from Marek Olšák --- I'm working on it. -- 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/20160812/2de0bc93/attachment.html>
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #7 from Jimi --- I should mention at this point, I think there are 2 different bugs going on. One bug is making it impossible to unbind any cards from the driver, and another bug is making X immediately bind itself to an amdgpu card the instant it becomes available and crash. The former is definitely something wrong with amdgpu in the kernel, but the latter could be X's fault--I don't know. Just in case, I've filed a report for X, too: https://bugs.freedesktop.org/show_bug.cgi?id=97313 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #8 from Jimi --- Created attachment 228441 --> https://bugzilla.kernel.org/attachment.cgi?id=228441&action=edit dmesg log (amdgpu-pro) And here's the dmesg log from testing this with amdgpu-pro (without X running), with the crash starting at [137.003975]. amdgpu-pro exhibited almost exactly the same behavior. The only difference was instead of getting a segfault after a few seconds, the terminal session that unbound the card was immediately spammed with the dmesg stack trace in this attached file. -- You are receiving this mail because: You are watching the assignee of the bug.
[v10.1 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Hi Chris Looks good for me only tiny problem comment inline. Thanks. On 2016å¹´08æ11æ¥ 07:32, Chris Zhong wrote: > Add support for cdn DP controller which is embedded in the rk3399 > SoCs. The DP is compliant with DisplayPort Specification, > Version 1.3, This IP is compatible with the rockchip type-c PHY IP. > There is a uCPU in DP controller, it need a firmware to work, > please put the firmware file to /lib/firmware/rockchip/dptx.bin. The > uCPU in charge of aux communication and link training, the host use > mailbox to communicate with the ucpu. > The dclk pin_pol of vop must not be invert for DP. > > Signed-off-by: Chris Zhong > Reviewed-by: Sean Paul > Acked-by: Mark Yao > > --- > > Changes in v10.1: > - support read sink count from DPCD > > Changes in v10: > - control the grf_clk in DP > > Changes in v9: > - do not need reset the phy before power_on > - add a orientation information for set_capability > - retry to read dpcd in 10 seconds > > Changes in v8: > - optimization the err log > > Changes in v7: > - support firmware standby when no dptx connection > - optimization the calculation of tu size and valid symbol > > Changes in v6: > - add a port struct > - select SND_SOC_HDMI_CODEC > - force reset the phy when hpd detected > > Changes in v5: > - alphabetical order > - do not use long, use u32 or u64 > - return MODE_CLOCK_HIGH when requested > actual > - Optimized Coding Style > - add a formula to get better tu size and symbol value. > - modify according to Sean Paul's comments > - fixed the fw_wait always 0 > > Changes in v4: > - use phy framework to control DP phy > - support 2 phys > > Changes in v3: > - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state. > - reset spdif before config it > - modify the firmware clk to 100Mhz > - retry load firmware if fw file is requested too early > > Changes in v2: > - Alphabetic order > - remove excess error message > - use define clk_rate > - check all return value > - remove dev_set_name(dp->dev, "cdn-dp"); > - use schedule_delayed_work > - remove never-called functions > - remove some unnecessary () > > Changes in v1: > - use extcon API > - use hdmi-codec for the DP Asoc > - do not initialize the "ret" > - printk a err log when drm_of_encoder_active_endpoint_id > - modify the dclk pin_pol to a single line > > drivers/gpu/drm/rockchip/Kconfig| 10 + > drivers/gpu/drm/rockchip/Makefile | 1 + > drivers/gpu/drm/rockchip/cdn-dp-core.c | 937 > +++ > drivers/gpu/drm/rockchip/cdn-dp-core.h | 104 +++ > drivers/gpu/drm/rockchip/cdn-dp-reg.c | 959 > > drivers/gpu/drm/rockchip/cdn-dp-reg.h | 482 ++ > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +- > drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 9 + > drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + > 9 files changed, 2514 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c > create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h > create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c > create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h > > diff --git a/drivers/gpu/drm/rockchip/Kconfig > b/drivers/gpu/drm/rockchip/Kconfig > index d30bdc3..20aaafe 100644 > --- a/drivers/gpu/drm/rockchip/Kconfig > +++ b/drivers/gpu/drm/rockchip/Kconfig > @@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP > for the Analogix Core DP driver. If you want to enable DP > on RK3288 based SoC, you should selet this option. > > +config ROCKCHIP_CDN_DP > +tristate "Rockchip cdn DP" > +depends on DRM_ROCKCHIP > + select SND_SOC_HDMI_CODEC if SND_SOC > +help > + This selects support for Rockchip SoC specific extensions > + for the cdn DP driver. If you want to enable Dp on > + RK3399 based SoC, you should select this > + option. > + > config ROCKCHIP_DW_HDMI > tristate "Rockchip specific extensions for Synopsys DW HDMI" > depends on DRM_ROCKCHIP > diff --git a/drivers/gpu/drm/rockchip/Makefile > b/drivers/gpu/drm/rockchip/Makefile > index 05d0713..abdecd5 100644 > --- a/drivers/gpu/drm/rockchip/Makefile > +++ b/drivers/gpu/drm/rockchip/Makefile > @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ > rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o > > obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o > +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o > obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o > obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o > obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o > diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c > b/drivers/gpu/drm/rockchip/cdn-dp-core.c > new file mode 100644 > index 000..f9a5afb > --- /dev/null > +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c > @@ -0,0 +1,937 @@ > +/* > + * Copyright (C) Fuzhou
[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"
https://bugs.freedesktop.org/show_bug.cgi?id=90481 --- Comment #19 from Daniel Scharrer --- I also still get hangs, but they seem to be less frequent than they used to be. However, the framerate seems to be a bit lower compared to the last time I tested - ~70 vs. (iirc) 80+ FPS in the menu - so maybe it's just that. Both the game and glamor were using the updated Mesa version. Curiously, the first freeze I got when testing didn't look like a GPU lockup but rather a (partial) X server lockup: all blocks were at 0% in radeontop and I was able to switch to a different VT using Ctrl+Alt+F1, and while switching back to X blocked further VT switches I was able to restart the X server normally (the log indicated a clean shutdown) and everything including OpenGL seemed to work fine after that. The freeze lockup I got was a proper GPU lockup though - Event Engine and Texture Adresser at 0%, everything else at 100%, unable to switch VTs even with chvt over ssh. Kernel: 4.7.0-gentoo Mesa: git-50b49d2 LLVM: r278309 -- 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/20160812/b88e7eb0/attachment.html>
[PATCH] drm: drop DRIVER_HAVE_IRQ flag for some drivers
The drm driver feature flag DRIVER_HAVE_IRQ is used to indicates whether
the driver has an IRQ handler managed by the DRM core. Some drivers,
armada, etnaviv, kirin and sti, set this flag without .irq_handler setup
in drm_driver. These drivers manage IRQ handler by themselves and the
flag DRIVER_HAVE_IRQ makes no sense there.
Drop the flag for these drivers to avoid confusion.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/armada/armada_drv.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +--
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +-
drivers/gpu/drm/sti/sti_drv.c | 2 +-
4 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index f5ebdd681445..1e0e68f608e4 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -211,7 +211,7 @@ static struct drm_driver armada_drm_driver = {
.desc = "Armada SoC DRM",
.date = "20120730",
.driver_features= DRIVER_GEM | DRIVER_MODESET |
- DRIVER_HAVE_IRQ | DRIVER_PRIME,
+ DRIVER_PRIME,
.ioctls = armada_ioctls,
.fops = &armada_drm_fops,
};
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index ffd1b32caa8d..fd0ed61565f3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -488,8 +488,7 @@ static const struct file_operations fops = {
};
static struct drm_driver etnaviv_drm_driver = {
- .driver_features= DRIVER_HAVE_IRQ |
- DRIVER_GEM |
+ .driver_features= DRIVER_GEM |
DRIVER_PRIME |
DRIVER_RENDER,
.open = etnaviv_open,
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 1edd9bc80294..1fc2f502d20d 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -169,7 +169,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file *file,
static struct drm_driver kirin_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
+ DRIVER_ATOMIC,
.fops = &kirin_drm_fops,
.gem_free_object_unlocked = drm_gem_cma_free_object,
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 96bd3d08b2d4..f8311b2bc84e 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -282,7 +282,7 @@ static const struct file_operations sti_driver_fops = {
};
static struct drm_driver sti_driver = {
- .driver_features = DRIVER_HAVE_IRQ | DRIVER_MODESET |
+ .driver_features = DRIVER_MODESET |
DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
--
1.9.1
[PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"
> Initial testing says that the change below must precede the change > to the definition of lockless_dereference(), so the two should go > together. Indeed. > If my upcoming testing of the two changes together pans out, I will > give you a Tested-by -- I am guessing that you don't want to wait > until the next merge window for these changes. I don't mind hugely since I have a fix now, but this one actually causes >1K warnings (including some "too many warnings!") for my build (net/wireless and net/mac80211 only!) and drowns out the real ones... I'm sure other parts of the tree are similarly affected. johannes
[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup
Hi Jon! On 11 August 2016 at 20:06, Jonathan Corbet wrote: > On Thu, 11 Aug 2016 16:17:56 +0530 > Sumit Semwal wrote: > >> Convert dma-buf documentation over to sphinx; also cleanup to >> address sphinx warnings. >> >> While at that, convert dma-buf-sharing.txt as well, and make it the >> dma-buf API guide. > > Thanks for working to improve the documentation! I do have a few overall > comments... > Thank you for your review, and comments; my responses are inline. > - The two comment fixes are a separate thing that should go straight to >the dma-buf maintainer, who is ... ... evidently somebody >familiar to you :) I assume you'll merge those two directly? > Yes, of course :) - I will merge them directly, and will remove them from v2 of this series. > - It looks like you create a new RST document but leave the old one in >place. Having two copies of the document around can only lead to >confusion, so I think the old one should go. > Agreed on this as well; will correct it. > - I really wonder if we want to start carving pieces out of >device-drivers.tmpl in this way. I guess I would rather see the >conversion of that book and the better integration of the other docs >*into* it. One of the goals of this whole thing is to unify our >documentation, not to reinforce the silos. > I should've mentioned it in the cover letter - my intention of taking the dma-buf pieces out was to focus on these first while moving to sphinx. My proposal would be, if all the device driver section owners could take the relevant pieces, convert them to sphinx (ironing out warnings etc in the process), then we can again 'bind' them together into the device drivers book in rst format. This breaks the documentation conversion task into manageable pieces that can be handled independently, and gives everyone flexibility to work on their schedules. This should also help in a good technical re-look at the content by subsystem developers, and make any documentation updates as required. The beauty of sphinx should allow us this, I think? Just my 2 cents. > Does that make sense? > I do hope that my proposal above finds some merit with everyone. > Thanks, > > jon BR, Sumit.
[GIT PULL] drm/mediatek: randconfig build fixes
Hi Dave, This tag contains three patches for -rc that fix mediatek-drm build failures in randconfig builds. regards Philipp The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-fixes-2016-08-12 for you to fetch changes up to 306d674a2ddd565adde7d9d6703157105c8444a6: drm/mediatek: add ARM_SMCCC dependency (2016-08-11 08:42:01 +0200) mediatek-drm build dependency fixes - add COMMON_CLK dependency for mipi-tx PLL - add OF dependency for mtk_drm_drv - add ARM_SMCCC dependency for mtk-hdmi Arnd Bergmann (3): drm/mediatek: add COMMON_CLK dependency drm/mediatek: add CONFIG_OF dependency drm/mediatek: add ARM_SMCCC dependency drivers/gpu/drm/mediatek/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
[GIT PULL] drm/mediatek: maintainer entry and gamma support
Hi Dave, Please consider merging this tag, which adds CK Hu and me as maintainers for the mediatek-drm driver and adds gamma correction support. The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://git.pengutronix.de/git/pza/linux.git tags/mediatek-drm-next-2016-08-12 for you to fetch changes up to 7216436420414144646f5d8343d061355fd23483: drm/mediatek: set mt8173 dithering function (2016-08-11 10:52:23 +0200) mediatek-drm maintainers and gamma correction - add MAINTAINERS entry for mediatek-drm driver - add support for AAL and GAMMA engines - hook up gamma correction LUT - add support for temporal dithering to OD and GAMMA engines Bibby Hsieh (4): drm/mediatek: Add AAL engine basic function drm/mediatek: Add GAMMA engine basic function drm/mediatek: Add gamma correction. drm/mediatek: set mt8173 dithering function CK Hu (1): drm: mediatek: add Maintainers entry for Mediatek DRM drivers MAINTAINERS | 8 ++ drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 3 +- drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 3 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 28 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 151 ++-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 18 +++- 7 files changed, 196 insertions(+), 18 deletions(-)
[GIT PULL] imx-drm: updates and encoder atomic_mode_set helper callback
Hi Dave, this tag adds a new encoder callback "atomic_mode_set" that can be used in place of the encoder "mode_set" callback for encoder drivers that need to access the connector during mode_set. Instead of just the modes, it passes the crtc and connector state - like atomic_check. It is used in imx-ldb to replace the connector walk to find the display_info containing the LVDS output bus format. Also included: a patch to allow to configuring DE and pixel clock polarity via DT display timing bindings for boards that don't use the panel driver yet, support for bridges connected to the LVDS output, and some more fixes and preparation for capture support in the ipu-v3 driver. And some trivial functions are replaced with direct calls. regards Philipp The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc: Linux 4.8-rc1 (2016-08-07 18:18:00 -0700) are available in the git repository at: git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2016-08-12 for you to fetch changes up to dc80d7038883feca2abd08975165bc0d83c84762: drm/imx-ldb: Add support to drm-bridge (2016-08-11 11:34:22 +0200) imx-drm updates and encoder atomic_mode_set helper callback - add pixel clock and DE polarity configuration from device tree using display timing bindings for parallel and LVDS output - cleanup/remove trivial functions - cleanup and fixes in preparation for capture support - add atomic_mode_set helper and use it in imx-ldb - this is an alternative to the encoder mode_set callback that passes the crtc and connector state instead of just the mode. It allows drivers to get information from the attached connector without having to iterate over all connectors - add drm_bridge support to imx-ldb, for bridges attached via LVDS Liu Ying (3): drm/imx: Remove imx_drm_crtc_vblank_get/_put() drm/imx: Remove imx_drm_crtc_id() drm/imx: Remove imx_drm_handle_vblank() Lothar WaÃmann (2): drm: add a helper function to extract 'de-active' and 'pixelclk-active' from DT drm/imx: convey the pixelclk-active and de-active flags from DT to the ipu-di driver Peter Senna Tschudin (1): drm/imx-ldb: Add support to drm-bridge Philipp Zabel (3): gpu: ipu-v3: Add missing IDMAC channel names drm/atomic-helper: Add atomic_mode_set helper callback drm/imx: imx-ldb: use encoder atomic_mode_set callback Steve Longerbeam (8): gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset() gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize() gpu: ipu-v3: Add ipu_get_num() gpu: ipu-v3: Add VDI input IDMAC channels gpu: ipu-v3: set correct full sensor frame for PAL/NTSC gpu: ipu-v3: Fix CSI data format for 16-bit media bus formats gpu: ipu-v3: Fix IRT usage gpu: ipu-v3: rename CSI client device drivers/gpu/drm/drm_atomic_helper.c | 6 +- drivers/gpu/drm/drm_modes.c | 20 +++- drivers/gpu/drm/imx/imx-drm-core.c | 24 - drivers/gpu/drm/imx/imx-drm.h| 6 -- drivers/gpu/drm/imx/imx-ldb.c| 151 --- drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +- drivers/gpu/drm/imx/parallel-display.c | 10 +- drivers/gpu/ipu-v3/ipu-common.c | 12 ++- drivers/gpu/ipu-v3/ipu-cpmem.c | 13 +++ drivers/gpu/ipu-v3/ipu-csi.c | 26 +++--- drivers/gpu/ipu-v3/ipu-ic.c | 40 ++-- drivers/gpu/ipu-v3/ipu-prv.h | 1 + include/drm/drm_modes.h | 5 +- include/drm/drm_modeset_helper_vtables.h | 29 ++ include/video/imx-ipu-v3.h | 18 15 files changed, 247 insertions(+), 116 deletions(-)
[RFC 2/3] drm: Add panic handling
On Thu, Aug 11, 2016 at 10:46:53PM +0200, Noralf Trønnes wrote:
>
> Den 10.08.2016 11:15, skrev Daniel Vetter:
> > On Tue, Aug 09, 2016 at 07:45:41PM +0200, Noralf Trønnes wrote:
> > > This adds support for outputting kernel messages on panic().
> > > The drivers that supports it, provides a framebuffer that the
> > > messages can be rendered on.
> > >
> > > Signed-off-by: Noralf Trønnes
> > Thinking about how we should implement this in a full-blown driver, I
> > think we will need a bit more than this. Here's the additional
> > requirements I've come up that a driver more complex than sdrm would need
> > for reliable panic handling:
> >
> > - Multiple outputs, with multiple framebuffer (or one framebuffer and
> >multiple offsets within). And since one display might be dead we should
> >try really hard to show the oops on all of them. Consequence: I think we
> >need to also loop over all drm_crtc in a drm_device, to be able to
> >support them all.
>
> How about this:
>
> /*
> * The panic() function makes sure that only one CPU is allowed to run it's
> * code. So this handler is only called once.
> *
> * Prior to calling the panic handlers, panic() calls smp_send_stop(). If
> * that went well, there's only one CPU running, but this is no guarantee.
> */
> static int drm_panic_handler(struct notifier_block *this, unsigned long ev,
> void *ptr)
> {
>
>
> drm_for_each_device(drm, id) {
> if (!drm->driver ||
> !(drm->driver->driver_features & DRIVER_ATOMIC))
> continue;
>
> drm_for_each_crtc(crtc, drm) {
> crtc_locked = ww_mutex_trylock(&crtc->mutex.mutex);
If you cant get the lock you must skip. Most likely someone else is
tampering with the crtc right now.
>
> if (!crtc->enabled || !crtc->primary)
> goto crtc_unlock;
>
> if (!crtc->state || !crtc->state->active ||
> !crtc->state->state)
> goto crtc_unlock;
>
> state = crtc->state->state;
> plane = crtc->primary;
> plane_locked =
> ww_mutex_trylock(&plane->mutex.mutex);
>
> plane_state =
Same here with the planes.
> drm_atomic_get_existing_plane_state(state, plane);
> if (!plane_state || !plane_state->visible)
> goto plane_unlock;
>
> fb = plane->fb;
>
> if (!fb || !fb->funcs || !fb->funcs->panic_vmap)
> goto plane_unlock;
>
> /* only 8-bit wide fonts are supported */
> font = get_default_font(fb->width, fb->height,
> BIT(7), -1);
> if (!font)
> goto plane_unlock;
>
> vmap = fb->funcs->panic_vmap(fb);
> if (!vmap)
> goto plane_unlock;
>
> /*
> * How do I find the actual width/height from the plane
> state
> * as you mention further down?
> */
> width = ??
> height = ??
plane_state->src contains the clipped source rectangle in 16.16 fixed
point (on latest drm-misc, soon also in drm-next). Everything outside of
that area is not visible (on this plane/crtc combo).
>
> pfb = &drm_panic_fbs[fbs++];
> pfb->fb = fb;
> pfb->vmap = vmap;
> pfb->font = font;
> pfb->cols = width / font->width;
> pfb->rows = height / font->height;
>
> /*
> * how to unlock?
> * ww_mutex_unlock() doc says:
> * This function must not be used in interrupt context
It /should/ work, probably a copypaste error from ww_mutex_lock (that one
can't be used from interrupt context). Just try and then test this with
full CONFIG_PROVE_LOCKING enabled, that should catch any issue (if there
is one).
> */
> plane_unlock:
> if (plane_locked)
> somehow_unlock();
> crtc_unlock:
> if (crtc_locked)
> somehow_unlock();
> }
> }
>
> drm_panic_active = true;
> }
>
>
>
> > - With desktop gpus you pretty much always end up with a tiled
> >framebuffer. And from an oops context it's going to be impossible to
> >detile that quickly. I think for this we need a helper to draw x/y
> >pixels (it's going to be dead slow, but meh), with a default
> >implementation
[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup
On Fri, Aug 12, 2016 at 12:05:04PM +0530, Sumit Semwal wrote: > Hi Jon! > > On 11 August 2016 at 20:06, Jonathan Corbet wrote: > > On Thu, 11 Aug 2016 16:17:56 +0530 > > Sumit Semwal wrote: > > > >> Convert dma-buf documentation over to sphinx; also cleanup to > >> address sphinx warnings. > >> > >> While at that, convert dma-buf-sharing.txt as well, and make it the > >> dma-buf API guide. > > > > Thanks for working to improve the documentation! I do have a few overall > > comments... > > > Thank you for your review, and comments; my responses are inline. > > > - The two comment fixes are a separate thing that should go straight to > >the dma-buf maintainer, who is ... ... evidently somebody > >familiar to you :) I assume you'll merge those two directly? > > > Yes, of course :) - I will merge them directly, and will remove them > from v2 of this series. > > > - It looks like you create a new RST document but leave the old one in > >place. Having two copies of the document around can only lead to > >confusion, so I think the old one should go. > > > Agreed on this as well; will correct it. > > > - I really wonder if we want to start carving pieces out of > >device-drivers.tmpl in this way. I guess I would rather see the > >conversion of that book and the better integration of the other docs > >*into* it. One of the goals of this whole thing is to unify our > >documentation, not to reinforce the silos. > > > I should've mentioned it in the cover letter - my intention of taking > the dma-buf pieces out was to focus on these first while moving to > sphinx. > > My proposal would be, if all the device driver section owners could > take the relevant pieces, convert them to sphinx (ironing out warnings > etc in the process), then we can again 'bind' them together into the > device drivers book in rst format. > This breaks the documentation conversion task into manageable pieces > that can be handled independently, and gives everyone flexibility to > work on their schedules. > > This should also help in a good technical re-look at the content by > subsystem developers, and make any documentation updates as required. > The beauty of sphinx should allow us this, I think? Just my 2 cents. I already tried to trick Sumit into converting the entire device-drivers.tmpl, but he didn't take the bait ;-) I think just extracting dma-buf stuff (dma_buf, fence, reservation and all that) is ok though, it is a fairly stand-alone topic. -Daniel > > > Does that make sense? > > > I do hope that my proposal above finds some merit with everyone. > > > Thanks, > > > > jon > > BR, > Sumit. > ___ > 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 0/5] build fixes to make fbdev optional
On Wed, Aug 10, 2016 at 02:33:52PM -0400, Alex Deucher wrote: > On Wed, Aug 10, 2016 at 12:52 PM, Daniel Vetter > wrote: > > 0-day has been annoying me lately with a constant trickle of build failures > > with > > a few drivers when DRM_FBDEV_EMULATION is not set. This series here should > > fix > > them all I hope. > > -Daniel > > > > Daniel Vetter (5): > > drm/fb-helper: Add a dummy remove_conflicting_framebuffers > > drm: Remove superflous linux/fb.h includes > > drm/vmwgfx: select CONFIG_FB > > drm/radeon|amgpu: Make fbdev emulation optional > > drm: Protect fb_defio in drivers with CONFIG_KMS_FBDEV_EMULATION > > For the series: > Reviewed-by: Alex Deucher Thanks for the review, all applied to drm-misc. -Daniel > > > > > drivers/gpu/drm/Kconfig| 8 > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 2 +- > > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 1 - > > drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c | 1 - > > drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 1 - > > drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c | 1 - > > drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 1 - > > .../gpu/drm/amd/powerplay/hwmgr/tonga_processpptables.c| 1 - > > drivers/gpu/drm/armada/armada_fbdev.c | 1 - > > drivers/gpu/drm/ast/ast_fb.c | 1 - > > drivers/gpu/drm/bochs/bochs.h | 1 - > > drivers/gpu/drm/bochs/bochs_drv.c | 3 ++- > > drivers/gpu/drm/bridge/parade-ps8622.c | 1 - > > drivers/gpu/drm/cirrus/cirrus_drv.c| 2 +- > > drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 -- > > drivers/gpu/drm/drm_fb_helper.c| 1 - > > drivers/gpu/drm/gma500/accel_2d.c | 1 - > > drivers/gpu/drm/gma500/framebuffer.c | 1 - > > drivers/gpu/drm/gma500/psb_intel_modes.c | 1 - > > drivers/gpu/drm/i915/i915_drv.c| 2 +- > > drivers/gpu/drm/i915/intel_fbdev.c | 1 - > > drivers/gpu/drm/i915/intel_modes.c | 1 - > > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > > drivers/gpu/drm/imx/ipuv3-crtc.c | 1 - > > drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +- > > drivers/gpu/drm/mgag200/mgag200_fb.c | 2 -- > > drivers/gpu/drm/mgag200/mgag200_main.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_fbcon.c| 1 - > > drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c| 1 - > > drivers/gpu/drm/omapdrm/displays/panel-nec-nl8048hl11.c| 1 - > > drivers/gpu/drm/omapdrm/displays/panel-sony-acx565akm.c| 1 - > > drivers/gpu/drm/qxl/qxl_fb.c | 5 - > > drivers/gpu/drm/radeon/radeon_drv.c| 3 ++- > > drivers/gpu/drm/radeon/radeon_fb.c | 3 +-- > > drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++- > > drivers/gpu/drm/udl/udl_fb.c | 4 > > drivers/gpu/drm/vc4/vc4_drv.c | 3 ++- > > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 3 ++- > > drivers/gpu/drm/vmwgfx/Kconfig | 1 + > > include/drm/drm_fb_helper.h| 14 > > ++ > > 41 files changed, 40 insertions(+), 48 deletions(-) > > > > -- > > 2.8.1 > > > > ___ > > 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 2/4] dma-buf/fence: kerneldoc: remove spurious section header
On Thu, Aug 11, 2016 at 04:17:58PM +0530, Sumit Semwal wrote:
> Commit e941759c74a44d6ac2eed21bb0a38b21fe4559e2 ("fence: dma-buf
> cross-device synchronization (v18)") had a spurious kerneldoc section
> header that caused Sphinx to complain. Fix it.
>
> Fixes: e941759c74a4 ("fence: dma-buf cross-device synchronization (v18)")
>
> Signed-off-by: Sumit Semwal
On patches 1&2 Reviewed-by: Daniel Vetter
> ---
> include/linux/fence.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/fence.h b/include/linux/fence.h
> index 5aa95eb886f7..5de89dab0013 100644
> --- a/include/linux/fence.h
> +++ b/include/linux/fence.h
> @@ -60,7 +60,7 @@ struct fence_cb;
> * implementer of the fence for its own purposes. Can be used in different
> * ways by different fence implementers, so do not rely on this.
> *
> - * *) Since atomic bitops are used, this is not guaranteed to be the case.
> + * Since atomic bitops are used, this is not guaranteed to be the case.
> * Particularly, if the bit was set, but fence_signal was called right
> * before this bit was set, it would have been able to set the
> * FENCE_FLAG_SIGNALED_BIT, before enable_signaling was called.
> --
> 2.7.4
>
> ___
> 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] drm: don't warn unconditionally in drm_vblank_cleanup about enabled vblanks
On drivers without immediate vblank disabling drm_vblank_cleanup() may be
called before the delayed vblank disable timer has fired. Instead of spitting
out a warning unconditionally in this case, run the vblank disable function
immediately.
Only warn if vblanks are still enabled and there was no timer pending to
disable them.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/drm_irq.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 77f357b2c386..e6eb5024341d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -335,10 +335,15 @@ void drm_vblank_cleanup(struct drm_device *dev)
for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
- WARN_ON(vblank->enabled &&
- drm_core_check_feature(dev, DRIVER_MODESET));
-
- del_timer_sync(&vblank->disable_timer);
+ if (del_timer_sync(&vblank->disable_timer))
+ /*
+* If we deactivated a pending timer, make sure to
+* disable the vblank now.
+*/
+ vblank_disable_fn((unsigned long)vblank);
+ else
+ WARN_ON(vblank->enabled &&
+ drm_core_check_feature(dev, DRIVER_MODESET));
}
kfree(dev->vblank);
--
2.8.1
[PATCH] drm/atomic-helper: add unlocked disable all outputs helper
This adds the unlocked variant of drm_atomic_helper_disable_all(),
which takes all the required modeset locks itself. This is intended
to be used when shutting down the driver, without retaining any
state.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/drm_atomic_helper.c | 43 +
include/drm/drm_atomic_helper.h | 1 +
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 99365087645b..6673021ab21e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2435,6 +2435,49 @@ free:
EXPORT_SYMBOL(drm_atomic_helper_disable_all);
/**
+ * drm_atomic_helper_disable_all_unlocked - disable all currently active
+ * outputs taking the modeset locks itself
+ * @dev: DRM device
+ *
+ * Loops through all connectors, finding those that aren't turned off and then
+ * turns them off by setting their DPMS mode to OFF and deactivating the CRTC
+ * that they are connected to.
+ *
+ * This is used for example when shutting down the DRM device.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_atomic_helper_disable_all_unlocked(struct drm_device *dev)
+{
+ struct drm_modeset_acquire_ctx ctx;
+ int err;
+
+ drm_modeset_acquire_init(&ctx, 0);
+
+retry:
+ err = drm_modeset_lock_all_ctx(dev, &ctx);
+ if (err < 0)
+ goto unlock;
+
+ err = drm_atomic_helper_disable_all(dev, &ctx);
+ if (err < 0)
+ goto unlock;
+
+unlock:
+ if (err == -EDEADLK) {
+ drm_modeset_backoff(&ctx);
+ goto retry;
+ }
+
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+
+ return err;
+}
+EXPORT_SYMBOL(drm_atomic_helper_disable_all_unlocked);
+
+/**
* drm_atomic_helper_suspend - subsystem-level suspend helper
* @dev: DRM device
*
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index d86ae5dcd7b4..104d310c2c70 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -99,6 +99,7 @@ int __drm_atomic_helper_set_config(struct drm_mode_set *set,
int drm_atomic_helper_disable_all(struct drm_device *dev,
struct drm_modeset_acquire_ctx *ctx);
+int drm_atomic_helper_disable_all_unlocked(struct drm_device *dev);
struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev);
int drm_atomic_helper_resume(struct drm_device *dev,
struct drm_atomic_state *state);
--
2.8.1
[PATCH] drm/imx: imx-ldb: detach existing panels when unbinding the driver
We should detach existing panels when unbinding the driver since
they are attached at the binding stage, otherwise, the attaching
function would return the -EBUSY value when the ldb driver module
is installed again.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/imx-ldb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 4eed3a6..a22c6f7 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -757,6 +757,9 @@ static void imx_ldb_unbind(struct device *dev, struct
device *master,
for (i = 0; i < 2; i++) {
struct imx_ldb_channel *channel = &imx_ldb->channel[i];
+ if (channel->panel)
+ drm_panel_detach(channel->panel);
+
if (!channel->connector.funcs)
continue;
--
2.7.4
[PATCH 1/1] Revert "gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle"
On Thu, Aug 11, 2016 at 7:00 AM, Tomi Valkeinen
wrote:
> On 11/08/16 13:56, Sean Paul wrote:
>> On Thu, Aug 11, 2016 at 5:44 AM, Peter Chen wrote:
>>> This reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f.
>>>
>>> The of_get_next_parent will drop refcount on the passed node, so the
>>> reverted
>>> patch is wrong, thanks for Tomi Valkeinen points it.
>>>
>>
>> Indeed it is. Tomi, are you going to pick this up in your tree, or
>> would you like it to go through -misc?
>>
>> Reviewed-by: Sean Paul
>
> Acked-by: Tomi Valkeinen
>
> I don't have any other fixes at the moment, so I'm fine with it going
> via some other tree, or picked directly to drm-fixes.
>
Applied to drm-misc
Sean
> Tomi
>
>>> Cc: Tomi Valkeinen
>>> Signed-off-by: Peter Chen
>>> ---
>>> drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 +++
>>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>>> b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>>> index e256d87..dfd4e96 100644
>>> --- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
>>> +++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
>>> @@ -125,16 +125,15 @@ u32 dss_of_port_get_port_number(struct device_node
>>> *port)
>>>
>>> static struct device_node *omapdss_of_get_remote_port(const struct
>>> device_node *node)
>>> {
>>> - struct device_node *np, *np_parent;
>>> + struct device_node *np;
>>>
>>> np = of_parse_phandle(node, "remote-endpoint", 0);
>>> if (!np)
>>> return NULL;
>>>
>>> - np_parent = of_get_next_parent(np);
>>> - of_node_put(np);
>>> + np = of_get_next_parent(np);
>>>
>>> - return np_parent;
>>> + return np;
>>> }
>>>
>>> struct device_node *
>>> --
>>> 1.9.1
>>>
>
[PATCH v11 1/7] drm/i915/gen6+: Return -EINVAL on invalid pcode commands
On Thu, Aug 11, 2016 at 03:54:30PM -0400, Lyude wrote:
> In order to add proper support for the SAGV, we need to be able to know
> what the cause of a failure to change the SAGV through the pcode mailbox
> was. The reasoning for this is that some very early pre-release Skylake
> machines don't actually allow you to control the SAGV on them, and
> indicate an invalid mailbox command was sent.
>
> This also might come in handy in the future for debugging.
>
> Signed-off-by: Lyude
> Cc: Matt Roper
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index da82744..73b3d4d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7121,6 +7121,7 @@ enum {
> #define VLV_MEDIA_C0_COUNT _MMIO(0x13811C)
>
> #define GEN6_PCODE_MAILBOX _MMIO(0x138124)
> +#define GEN6_PCODE_INVALID_CMD (1<<0)
It doesn't work quite like that. Instead the low 8 bits will contian
the error code, iff pcode has cleared the "READY" bit:
snb-ivb docs say:
00h MAILBOX_GTDRIVER_CC_SUCCESS
01h MAILBOX_GTDRIVER_CC_ILLEGAL_CMD
02h MAILBOX_GTDRIVER_CC_MIN_FREQUENCY_TABLE_GT_RATIO_OUT_OF_RANGE
03h MAILBOX_GTDRIVER_CC_TIMEOUT
FFh MAILBOX_GTDRIVER_CC_UNIMPLEMENTED_CMD
hsw-bdw docs say:
00h SUCCESS
01h ILLEGAL_CMD
02h TIMEOUT
03h ILLEGAL_DATA
10h MIN_FREQUENCY_TABLE_GT_RATIO_OUT_OF_RANGE
skl docs say:
00h SUCCESS
01h ILLEGAL_CMD
02h TIMEOUT
03h ILLEGAL_DATA
So looks like 02h and 03h will need to be interpreted in two different
ways depending on the platform. Assuming we want to decode the error
into a a human readable form for dmesg.
> #define GEN6_PCODE_READY (1<<31)
> #defineGEN6_PCODE_WRITE_RC6VIDS 0x4
> #defineGEN6_PCODE_READ_RC6VIDS 0x5
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 99014d7..8752730 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7674,6 +7674,11 @@ int sandybridge_pcode_read(struct drm_i915_private
> *dev_priv, u32 mbox, u32 *val
> *val = I915_READ_FW(GEN6_PCODE_DATA);
> I915_WRITE_FW(GEN6_PCODE_DATA, 0);
>
> + if (I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_INVALID_CMD) {
> + DRM_DEBUG_DRIVER("warning: pcode (read) mailbox access
> indicated invalid command\n");
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
> @@ -7704,6 +7709,11 @@ int sandybridge_pcode_write(struct drm_i915_private
> *dev_priv,
>
> I915_WRITE_FW(GEN6_PCODE_DATA, 0);
>
> + if (I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_INVALID_CMD) {
> + DRM_DEBUG_DRIVER("warning: pcode (write) mailbox access
> indicated invalid command\n");
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
> --
> 2.7.4
--
Ville Syrjälä
Intel OTC
[PATCH v11 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs
On Thu, Aug 11, 2016 at 03:54:31PM -0400, Lyude wrote: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from this however, is the mysterious issue of > underruns causing full system hangs. An easy way to reproduce this with > a skylake system: > > - Get a laptop with a skylake GPU, and hook up two external monitors to > it > - Move the cursor from the built-in LCD to one of the external displays > as quickly as you can > - You'll get a few pipe underruns, and eventually the entire system will > just freeze. > > After doing a lot of investigation and reading through the bspec, I > found the existence of the SAGV, which is responsible for adjusting the > system agent voltage and clock frequencies depending on how much power > we need. According to the bspec: > > "The display engine access to system memory is blocked during the > adjustment time. SAGV defaults to enabled. Software must use the > GT-driver pcode mailbox to disable SAGV when the display engine is not > able to tolerate the blocking time." > > The rest of the bspec goes on to explain that software can simply leave > the SAGV enabled, and disable it when we use interlaced pipes/have more > then one pipe active. > > Sure enough, with this patchset the system hangs resulting from pipe > underruns on Skylake have completely vanished on my T460s. Additionally, > the bspec mentions turning off the SAGV with more then one pipe enabled > as a workaround for display underruns. While this patch doesn't entirely > fix that, it looks like it does improve the situation a little bit so > it's likely this is going to be required to make watermarks on Skylake > fully functional. > > Changes since v10: > - Apparently sandybridge_pcode_read actually writes values and reads >them back, despite it's misleading function name. This means we've >been doing this mostly wrong and have been writing garbage to the >SAGV control. Because of this, we no longer attempt to read the SAGV >status during initialization (since there are no helpers for this). > - mlankhorst noticed that this patch was breaking on some very early >pre-release Skylake machines, which apparently don't allow you to >disable the SAGV. To prevent machines from failing tests due to SAGV >errors, if the first time we try to control the SAGV results in the >mailbox indicating an invalid command, we just disable future attempts >to control the SAGV state by setting dev_priv->skl_sagv_status to >I915_SKL_SAGV_NOT_CONTROLLED and make a note of it in dmesg. > - Move mutex_unlock() a little higher in skl_enable_sagv(). This >doesn't actually fix anything, but lets us release the lock a little >sooner since we're finished with it. > Changes since v9: > - Only enable/disable sagv on Skylake > Changes since v8: > - Add intel_state->modeset guard to the conditional for >skl_enable_sagv() > Changes since v7: > - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's >all we use it for anyway) > - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification > - Fix a styling error that snuck past me > Changes since v6: > - Protect skl_enable_sagv() with intel_state->modeset conditional in >intel_atomic_commit_tail() > Changes since v5: > - Don't use is_power_of_2. Makes things confusing > - Don't use the old state to figure out whether or not to >enable/disable the sagv, use the new one > - Split the loop in skl_disable_sagv into it's own function > - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail() > Changes since v4: > - Use is_power_of_2 against active_crtcs to check whether we have > 1 >pipe enabled > - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0 >enabled > - Call skl_sagv_enable/disable() from pre/post-plane updates > Changes since v3: > - Use time_before() to compare timeout to jiffies > Changes since v2: > - Really apply minor style nitpicks to patch this time > Changes since v1: > - Added comments about this probably being one of the requirements to >fixing Skylake's watermark issues > - Minor style nitpicks from Matt Roper > - Disable these functions on Broxton, since it doesn't have an SAGV > > Signed-off-by: Lyude > Cc: Matt Roper > Cc: Maarten Lankhorst > Cc: Daniel Vetter > Cc: Ville Syrjälä > Cc: stable at vger.kernel.org > --- > drivers/gpu/drm/i915/i915_drv.h | 7 +++ > drivers/gpu/drm/i915/i915_reg.h | 4 ++ > drivers/gpu/drm/i915/intel_display.c | 12 + > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_pm.c | 89 > > 5 files changed, 114 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 7971c76..d7
[PATCH v11 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates
On Thu, Aug 11, 2016 at 03:54:33PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them won't take effect until said registers are
> "armed", which is done by writing to the PLANE_SURF (or in the case of
> cursor planes, the CURBASE register) register.
>
> With this in mind, up until now we've been updating watermarks on skl
> like this:
>
> non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
> - intel_pre_plane_update:
> - intel_update_watermarks()
> - {vblank happens; new watermarks + old plane values => underrun }
> - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
> }
>
> or
>
> modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
> - crtc_enable:
> - intel_update_watermarks()
> - {vblank happens; new watermarks + old plane values => underrun }
> - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
> }
>
> Now we update watermarks atomically like this:
>
> non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
> - intel_pre_plane_update:
> - intel_update_watermarks() (wm values aren't written yet)
> - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - write new wm values
> - end vblank evasion
> }
>
> modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
> - crtc_enable:
> - intel_update_watermarks() (actual wm values aren't written
> yet)
> - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - write new wm values
> - end vblank evasion
> }
>
> So this patch moves all of the watermark writes into the right place;
> inside of the vblank evasion where we update all of the registers for
> each plane. While this patch doesn't fix everything, it does allow us to
> update the watermark values in the way the hardware expects us to.
>
> Changes since original patch series:
> - Remove mutex_lock/mutex_unlock since they don't do anything and we're
>not touching global state
> - Move skl_write_cursor_wm/skl_write_plane_wm functions into
>intel_pm.c, make externally visible
> - Add skl_write_plane_wm calls to skl_update_plane
> - Fix conditional for for loop in skl_write_plane_wm (level < max_level
>should be level <= max_level)
> - Make diagram in commit more accurate to what's actually happening
> - Add Fixes:
>
> Changes since v1:
> - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
>then just Skylake
> - Update description to make it clear this patch doesn't fix everything
> - Check if pipes were actually changed before writing watermarks
>
> Changes since v2:
> - Write PIPE_WM_LINETIME during vblank evasion
>
> Changes since v3:
> - Rebase against new SAGV patch changes
>
> Changes since v4:
> - Add a parameter to choose what skl_wm_values struct to use when
>writing new plane watermarks
>
> Changes since v5:
> - Remove cursor ddb entry write in skl_write_cursor_wm(), defer until
>patch 6
> - Write WM_LINETIME in intel_begin_crtc_commit()
>
> Changes since v6:
> - Remove redundant dirty_pipes check in skl_write_plane_wm (we check
>this in all places where we call this function, and it was supposed
>to have been removed earlier anyway)
> - In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of
>IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this
>needs to be done for gen10 as well
>
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
> Signed-off-by: Lyude
> Reviewed-by: Matt Roper
> Cc: stable at vger.kernel.org
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakrishna Sripada
> Cc: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_display.c | 17 +++-
> drivers/gpu/drm/i915/intel_drv.h | 5
> drivers/gpu/drm/i915/intel_pm.c | 50
>
> drivers/gpu/drm/i915/intel_sprite.c | 7 +
> 4 files changed, 62 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 35bdd67..b2f8e24 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3386,6 +3386,8 @@ static void skylake_update_primary_plane(struct
> drm_plane *plane,
> struct drm_i915_private *dev_priv = to_i915(dev);
> stru
[Intel-gfx] [PATCH 1/2] A Helper function that returns available link bandwidth
On Thu, 2016-08-11 at 16:41 -0700, Anusha Srivatsa wrote:
> drm/dp/mst
>
> Signed-off-by: Anusha Srivatsa
>
> Add a function that returns the available link bandwidth for
> MST port so that we can accurately determine whether a new
> mode is valid for the link or not.
>
The Signed-off line should follow the explanation body.
> Cc: dri-devel at lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 12
> include/drm/drm_dp_mst_helper.h | 1 +
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 04e4571..7a239f6 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -43,6 +43,8 @@ static bool dump_dp_payload_table(struct
> drm_dp_mst_topology_mgr *mgr,
> char *buf);
> static int test_calc_pbn_mode(void);
>
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct
> drm_dp_mst_port *port);
> +
> static void drm_dp_put_port(struct drm_dp_mst_port *port);
>
> static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> @@ -2730,6 +2732,16 @@ static int test_calc_pbn_mode(void)
> return 0;
> }
>
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct
> drm_dp_mst_port *port)
> +{
> +port = drm_dp_get_validated_port_ref(mgr,port);
> +if (port)
> +return port->available_pbn;
> +
> +return -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_dp_mst_get_avail_pbn);
> +
> /* we want to kick the TX after we've ack the up/down IRQs. */
> static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr)
> {
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 0032076..74dc4ab 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -576,6 +576,7 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
> *connector, struct drm_dp_
>
> int drm_dp_calc_pbn_mode(int clock, int bpp);
>
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct
> drm_dp_mst_port *port);
>
> bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct
> drm_dp_mst_port *port, int pbn, int *slots);
>
[PATCH v11 7/7] drm/i915/skl: Update DDB values atomically with wms/plane attrs
On Thu, Aug 11, 2016 at 03:54:36PM -0400, Lyude wrote:
> Now that we can hook into update_crtcs and control the order in which we
> update CRTCs at each modeset, we can finish the final step of fixing
> Skylake's watermark handling by performing DDB updates at the same time
> as plane updates and watermark updates.
>
> The first major change in this patch is skl_update_crtcs(), which
> handles ensuring that we order each CRTC update in our atomic commits
> properly so that they honor the DDB flush order.
>
> The second major change in this patch is the order in which we flush the
> pipes. While the previous order may have worked, it can't be used in
> this approach since it no longer will do the right thing. For example,
> using the old ddb flush order:
>
> We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
> allocation looks like this:
>
> | A | B |xxx|
>
> Since we're performing the ddb updates after performing any CRTC
> disablements in intel_atomic_commit_tail(), the space to the right of
> pipe B is unallocated.
>
> 1. Flush pipes with new allocation contained into old space. None
>apply, so we skip this
> 2. Flush pipes having their allocation reduced, but overlapping with a
>previous allocation. None apply, so we also skip this
> 3. Flush pipes that got more space allocated. This applies to A and B,
>giving us the following update order: A, B
>
> This is wrong, since updating pipe A first will cause it to overlap with
> B and potentially burst into flames. Our new order (see the code
> comments for details) would update the pipes in the proper order: B, A.
>
> As well, we calculate the order for each DDB update during the check
> phase, and reference it later in the commit phase when we hit
> skl_update_crtcs().
>
> This long overdue patch fixes the rest of the underruns on Skylake.
>
> Changes since v1:
> - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
> Changes since v2:
> - Use the method for updating CRTCs that Ville suggested
> - In skl_update_wm(), only copy the watermarks for the crtc that was
>passed to us
> Changes since v3:
> - Small comment fix in skl_ddb_allocation_overlaps()
>
> Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
> Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
> [omitting CC for stable, since this patch will need to be changed for
> such backports first]
>
> Testcase: kms_cursor_legacy
> Signed-off-by: Lyude
> Reviewed-by: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Radhakrishna Sripada
> Cc: Hans de Goede
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_display.c | 100 +++--
> drivers/gpu/drm/i915/intel_drv.h | 7 ++
> drivers/gpu/drm/i915/intel_pm.c | 207
> +--
> 3 files changed, 144 insertions(+), 170 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 61a45f1..68fdbf0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13348,16 +13348,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
> hw_entry->start, hw_entry->end);
> }
>
> - /* cursor */
> - hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
> - sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
> -
> - if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
> - DRM_ERROR("mismatch in DDB state pipe %c cursor "
> - "(expected (%u,%u), found (%u,%u))\n",
> - pipe_name(pipe),
> - sw_entry->start, sw_entry->end,
> - hw_entry->start, hw_entry->end);
> + /*
> + * cursor
> + * If the cursor plane isn't active, we may not have updated it's ddb
> + * allocation. In that case since the ddb allocation will be updated
> + * once the plane becomes visible, we can skip this check
> + */
> + if (intel_crtc->cursor_addr) {
> + hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
> + sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
> +
> + if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
> + DRM_ERROR("mismatch in DDB state pipe %c cursor "
> + "(expected (%u,%u), found (%u,%u))\n",
> + pipe_name(pipe),
> + sw_entry->start, sw_entry->end,
> + hw_entry->start, hw_entry->end);
> + }
> }
> }
>
> @@ -14109,6 +14116,72 @@ static void intel_update_crtcs(struct
> drm_atomic_state *state,
> }
> }
>
> +static void skl_update_crtcs(struct drm_atomic_state *state,
> + unsigned int *crtc_vblank_mask)
> +{
> + struct drm_device *dev = state->dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct intel_atomic_state
[PATCH] drm: edid: HDMI 2.0 HF-VSDB block parsing
On Wed, Aug 10, 2016 at 04:29:21PM +0100, Jose Abreu wrote:
> Adds parsing for HDMI 2.0 'HDMI Forum Vendor
> Specific Data Block'. This block is present in
> some HDMI 2.0 EDID's and gives information about
> scrambling support, SCDC, 3D Views, and others.
>
> Parsed parameters are stored in drm_connector
> structure.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
Thierry not in cc? Is this based on his SCDC work [1] or did we have
multiple people implementing the same thing, partially at least?
[1] https://lists.freedesktop.org/archives/dri-devel/2015-September/090929.html
> ---
> drivers/gpu/drm/drm_edid.c | 49
> ++
> include/drm/drm_crtc.h | 12
> include/drm/drm_edid.h | 5 +
> include/linux/hdmi.h | 1 +
> 4 files changed, 67 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7df26d4..bcacf11 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3160,6 +3160,21 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> return hdmi_id == HDMI_IEEE_OUI;
> }
>
> +static bool cea_db_is_hdmi_hf_vsdb(const u8 *db)
IIRC I asked Thierry to spell out the hdmi forum to avoid having this
look like alphabet soup. But now that I've read the spec, I do see it
being referred as hdmi-hf there as well, so I suppose it's fine.
> +{
> + int hdmi_id;
> +
> + if (cea_db_tag(db) != VENDOR_BLOCK)
> + return false;
> +
> + if (cea_db_payload_len(db) < 7)
> + return false;
> +
> + hdmi_id = db[1] | (db[2] << 8) | (db[3] << 16);
> +
> + return hdmi_id == HDMI_IEEE_OUI_HF;
> +}
> +
> #define for_each_cea_db(cea, i, start, end) \
> for ((i) = (start); (i) < (end) && (i) +
> cea_db_payload_len(&(cea)[(i)]) < (end); (i) +=
> cea_db_payload_len(&(cea)[(i)]) + 1)
>
> @@ -3287,6 +3302,37 @@ parse_hdmi_vsdb(struct drm_connector *connector, const
> u8 *db)
> }
>
> static void
> +parse_hdmi_hf_vsdb(struct drm_connector *connector, const u8 *db)
> +{
> + u8 len = cea_db_payload_len(db);
> +
> + if (len < 7)
> + return;
> +
> + if (db[4] != 1)
> + return; /* invalid version */
> +
> + connector->max_tmds_char = db[5] * 5;
We already have the max_tmds_clock. Also I was just trying move some of
the junk out from the connector into display_info [2].
[2] https://lists.freedesktop.org/archives/dri-devel/2016-August/114634.html
> + connector->scdc_present = db[6] & (1 << 7);
> + connector->rr_capable = db[6] & (1 << 6);
> + connector->flags_3d = db[6] & 0x7;
> + connector->supports_scramble = connector->scdc_present &&
> + (db[6] & (1 << 3));
Do we have actual users for all these? I don't like adding stuff into
core structures just for the purposes of immediately printing it out.
For the stereo flags, I guess someone would have to figure put how they
relate to the 3d flags in the other vsdb, and how to convert to drm mode
flags.
> +
> + DRM_DEBUG_KMS("HDMI v2: max TMDS char %d, "
> + "scdc %s, "
> + "rr %s, "
> + "3D flags 0x%x, "
> + "scramble %s\n",
> + connector->max_tmds_char,
> + connector->scdc_present ? "available" : "not available",
> + connector->rr_capable ? "capable" : "not capable",
> + connector->flags_3d,
> + connector->supports_scramble ?
> + "supported" : "not supported");
> +}
> +
> +static void
> monitor_name(struct detailed_timing *t, void *data)
> {
> if (t->data.other_data.type == EDID_DETAIL_MONITOR_NAME)
> @@ -3403,6 +3449,9 @@ void drm_edid_to_eld(struct drm_connector *connector,
> struct edid *edid)
> /* HDMI Vendor-Specific Data Block */
> if (cea_db_is_hdmi_vsdb(db))
> parse_hdmi_vsdb(connector, db);
> + /* HDMI Forum Vendor-Specific Data Block */
> + else if (cea_db_is_hdmi_hf_vsdb(db))
> + parse_hdmi_hf_vsdb(connector, db);
Wasn't there some priority scheme between these two? Or was it just
about the infoframes? I'd have to dig through the spec to find out.
> break;
> default:
> break;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b618b50..eca57d2 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1279,6 +1279,11 @@ struct drm_encoder {
> * @audio_latency: audio latency info from ELD, if found
> * @null_edid_counter: track sinks that give us all zeros for
[Bug 97099] Regression in 9ef8537e6 "drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled" (RV620)
https://bugs.freedesktop.org/show_bug.cgi?id=97099 --- Comment #3 from Christian König --- I've noticed this bug, I'm just not sure what to do about it. Essentially disabling fractional dividers for spread spectrum fixes the output for some people while it broke it for others. I will prepare a patch to only apply it for RS780 and RS880 for now, cause those seem to be the most problematic ones. -- 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/20160812/353696a3/attachment.html>
[PATCH RFC 1/5] video: add HDMI state notifier support
Add support for HDMI hotplug and EDID notifiers, which is used to convey
information from HDMI drivers to their CEC and audio counterparts.
Acked-by: Philipp Zabel
Signed-off-by: Russell King
---
drivers/video/Kconfig | 3 +++
drivers/video/Makefile| 1 +
drivers/video/hdmi-notifier.c | 61 +++
include/linux/hdmi-notifier.h | 44 +++
4 files changed, 109 insertions(+)
create mode 100644 drivers/video/hdmi-notifier.c
create mode 100644 include/linux/hdmi-notifier.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af999893..1ee7b9f9bb25 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
config HDMI
bool
+config HDMI_NOTIFIERS
+ bool
+
if VT
source "drivers/video/console/Kconfig"
endif
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17d6456..65f564906fb4 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_VGASTATE)+= vgastate.o
obj-$(CONFIG_HDMI)+= hdmi.o
+obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
obj-$(CONFIG_VT) += console/
obj-$(CONFIG_LOGO) += logo/
diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
new file mode 100644
index ..f3b16552b0fe
--- /dev/null
+++ b/drivers/video/hdmi-notifier.c
@@ -0,0 +1,61 @@
+#include
+#include
+#include
+#include
+
+static BLOCKING_NOTIFIER_HEAD(hdmi_notifier);
+
+int hdmi_register_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&hdmi_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(hdmi_register_notifier);
+
+int hdmi_unregister_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&hdmi_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(hdmi_unregister_notifier);
+
+void hdmi_event_connect(struct device *dev)
+{
+ struct hdmi_event_base base;
+
+ base.source = dev;
+
+ blocking_notifier_call_chain(&hdmi_notifier, HDMI_CONNECTED, &base);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_connect);
+
+void hdmi_event_disconnect(struct device *dev)
+{
+ struct hdmi_event_base base;
+
+ base.source = dev;
+
+ blocking_notifier_call_chain(&hdmi_notifier, HDMI_DISCONNECTED, &base);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
+
+void hdmi_event_new_edid(struct device *dev, const void *edid, size_t size)
+{
+ struct hdmi_event_new_edid new_edid;
+
+ new_edid.base.source = dev;
+ new_edid.edid = edid;
+ new_edid.size = size;
+
+ blocking_notifier_call_chain(&hdmi_notifier, HDMI_NEW_EDID, &new_edid);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
+
+void hdmi_event_new_eld(struct device *dev, const u8 eld[128])
+{
+ struct hdmi_event_new_eld new_eld;
+
+ new_eld.base.source = dev;
+ memcpy(new_eld.eld, eld, sizeof(new_eld.eld));
+
+ blocking_notifier_call_chain(&hdmi_notifier, HDMI_NEW_ELD, &new_eld);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
new file mode 100644
index ..5fb710e5d68a
--- /dev/null
+++ b/include/linux/hdmi-notifier.h
@@ -0,0 +1,44 @@
+#ifndef LINUX_HDMI_NOTIFIER_H
+#define LINUX_HDMI_NOTIFIER_H
+
+#include
+
+enum {
+ HDMI_CONNECTED,
+ HDMI_DISCONNECTED,
+ HDMI_NEW_EDID,
+ HDMI_NEW_ELD,
+};
+
+struct hdmi_event_base {
+ struct device *source;
+};
+
+struct hdmi_event_new_edid {
+ struct hdmi_event_base base;
+ const void *edid;
+ size_t size;
+};
+
+struct hdmi_event_new_eld {
+ struct hdmi_event_base base;
+ unsigned char eld[128];
+};
+
+union hdmi_event {
+ struct hdmi_event_base base;
+ struct hdmi_event_new_edid edid;
+ struct hdmi_event_new_eld eld;
+};
+
+struct notifier_block;
+
+int hdmi_register_notifier(struct notifier_block *nb);
+int hdmi_unregister_notifier(struct notifier_block *nb);
+
+void hdmi_event_connect(struct device *dev);
+void hdmi_event_disconnect(struct device *dev);
+void hdmi_event_new_edid(struct device *dev, const void *edid, size_t size);
+void hdmi_event_new_eld(struct device *dev, const u8 eld[128]);
+
+#endif
--
2.1.0
[PATCH RFC 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions
We don't need the CEC engine register definitions, so let's remove them. Signed-off-by: Russell King --- drivers/gpu/drm/bridge/dw-hdmi.h | 45 1 file changed, 45 deletions(-) diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h index fc9a560429d6..26d6845efad6 100644 --- a/drivers/gpu/drm/bridge/dw-hdmi.h +++ b/drivers/gpu/drm/bridge/dw-hdmi.h @@ -478,51 +478,6 @@ #define HDMI_A_PRESETUP 0x501A #define HDMI_A_SRM_BASE 0x5020 -/* CEC Engine Registers */ -#define HDMI_CEC_CTRL 0x7D00 -#define HDMI_CEC_STAT 0x7D01 -#define HDMI_CEC_MASK 0x7D02 -#define HDMI_CEC_POLARITY 0x7D03 -#define HDMI_CEC_INT0x7D04 -#define HDMI_CEC_ADDR_L 0x7D05 -#define HDMI_CEC_ADDR_H 0x7D06 -#define HDMI_CEC_TX_CNT 0x7D07 -#define HDMI_CEC_RX_CNT 0x7D08 -#define HDMI_CEC_TX_DATA0 0x7D10 -#define HDMI_CEC_TX_DATA1 0x7D11 -#define HDMI_CEC_TX_DATA2 0x7D12 -#define HDMI_CEC_TX_DATA3 0x7D13 -#define HDMI_CEC_TX_DATA4 0x7D14 -#define HDMI_CEC_TX_DATA5 0x7D15 -#define HDMI_CEC_TX_DATA6 0x7D16 -#define HDMI_CEC_TX_DATA7 0x7D17 -#define HDMI_CEC_TX_DATA8 0x7D18 -#define HDMI_CEC_TX_DATA9 0x7D19 -#define HDMI_CEC_TX_DATA10 0x7D1a -#define HDMI_CEC_TX_DATA11 0x7D1b -#define HDMI_CEC_TX_DATA12 0x7D1c -#define HDMI_CEC_TX_DATA13 0x7D1d -#define HDMI_CEC_TX_DATA14 0x7D1e -#define HDMI_CEC_TX_DATA15 0x7D1f -#define HDMI_CEC_RX_DATA0 0x7D20 -#define HDMI_CEC_RX_DATA1 0x7D21 -#define HDMI_CEC_RX_DATA2 0x7D22 -#define HDMI_CEC_RX_DATA3 0x7D23 -#define HDMI_CEC_RX_DATA4 0x7D24 -#define HDMI_CEC_RX_DATA5 0x7D25 -#define HDMI_CEC_RX_DATA6 0x7D26 -#define HDMI_CEC_RX_DATA7 0x7D27 -#define HDMI_CEC_RX_DATA8 0x7D28 -#define HDMI_CEC_RX_DATA9 0x7D29 -#define HDMI_CEC_RX_DATA10 0x7D2a -#define HDMI_CEC_RX_DATA11 0x7D2b -#define HDMI_CEC_RX_DATA12 0x7D2c -#define HDMI_CEC_RX_DATA13 0x7D2d -#define HDMI_CEC_RX_DATA14 0x7D2e -#define HDMI_CEC_RX_DATA15 0x7D2f -#define HDMI_CEC_LOCK 0x7D30 -#define HDMI_CEC_WKUPCTRL 0x7D31 - /* I2C Master Registers (E-DDC) */ #define HDMI_I2CM_SLAVE 0x7E00 #define HDMI_I2CM_ADDRESS 0x7E01 -- 2.1.0
[PATCH RFC 3/5] drm/bridge: dw_hdmi: add HDMI notifier support
Add HDMI notifiers to the HDMI bridge driver.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/Kconfig | 1 +
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8f7423f18da5..6d97d9f2b164 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -20,6 +20,7 @@ config DRM_ANALOGIX_ANX78XX
config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
+ select HDMI_NOTIFIERS
config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsis Designware AHB Audio interface"
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index c9d941283d30..cb6e03efbebf 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1447,9 +1448,11 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
drm_mode_connector_update_edid_property(connector, edid);
+ hdmi_event_new_edid(hdmi->dev, edid, 0);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
drm_edid_to_eld(connector, edid);
+ hdmi_event_new_eld(hdmi->dev, connector->eld);
kfree(edid);
} else {
dev_dbg(hdmi->dev, "failed to get edid\n");
@@ -1601,6 +1604,12 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
dw_hdmi_update_phy_mask(hdmi);
}
mutex_unlock(&hdmi->mutex);
+
+ if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
+ hdmi_event_disconnect(hdmi->dev);
+ else if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) ==
+(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_PHY_HPD))
+ hdmi_event_connect(hdmi->dev);
}
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
--
2.1.0
[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code
Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
implementation.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/Kconfig| 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/dw-hdmi-cec.c | 344 ++
drivers/gpu/drm/bridge/dw-hdmi.c | 64 +-
include/linux/platform_data/dw_hdmi-cec.h | 16 ++
5 files changed, 421 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 6d97d9f2b164..3ad19d16f4ca 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -33,6 +33,13 @@ config DRM_DW_HDMI_AHB_AUDIO
Designware HDMI block. This is used in conjunction with
the i.MX6 HDMI driver.
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI && MEDIA_CEC
+ help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
+
config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 96b13b30e6ab..4869441d35f4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-cec.c
b/drivers/gpu/drm/bridge/dw-hdmi-cec.c
new file mode 100644
index ..9d6b8daa584d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw-hdmi-cec.c
@@ -0,0 +1,344 @@
+/* http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/
+ * tree/drivers/mxc/hdmi-cec/mxc_hdmi-cec.c?h=imx_3.0.35_4.1.0 */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#define DEV_NAME "mxc_hdmi_cec"
+
+enum {
+ HDMI_IH_CEC_STAT0 = 0x0106,
+ HDMI_IH_MUTE_CEC_STAT0 = 0x0186,
+
+ HDMI_CEC_CTRL = 0x7d00,
+ CEC_CTRL_START = BIT(0),
+ CEC_CTRL_NORMAL = 1 << 1,
+
+ HDMI_CEC_STAT = 0x7d01,
+ CEC_STAT_DONE = BIT(0),
+ CEC_STAT_EOM= BIT(1),
+ CEC_STAT_NACK = BIT(2),
+ CEC_STAT_ARBLOST= BIT(3),
+ CEC_STAT_ERROR_INIT = BIT(4),
+ CEC_STAT_ERROR_FOLL = BIT(5),
+ CEC_STAT_WAKEUP = BIT(6),
+
+ HDMI_CEC_MASK = 0x7d02,
+ HDMI_CEC_POLARITY = 0x7d03,
+ HDMI_CEC_INT= 0x7d04,
+ HDMI_CEC_ADDR_L = 0x7d05,
+ HDMI_CEC_ADDR_H = 0x7d06,
+ HDMI_CEC_TX_CNT = 0x7d07,
+ HDMI_CEC_RX_CNT = 0x7d08,
+ HDMI_CEC_TX_DATA0 = 0x7d10,
+ HDMI_CEC_RX_DATA0 = 0x7d20,
+ HDMI_CEC_LOCK = 0x7d30,
+ HDMI_CEC_WKUPCTRL = 0x7d31,
+};
+
+struct dw_hdmi_cec {
+ void __iomem *base;
+ u32 addresses;
+ struct cec_adapter *adap;
+ struct cec_msg rx_msg;
+ unsigned int tx_status;
+ bool tx_done;
+ bool rx_done;
+ const struct dw_hdmi_cec_ops *ops;
+ void *ops_data;
+ int retries;
+ int irq;
+ struct notifier_block nb;
+};
+
+static int dw_hdmi_cec_log_addr(struct cec_adapter *adap, u8 logical_addr)
+{
+ struct dw_hdmi_cec *cec = adap->priv;
+ u32 addresses;
+
+ if (logical_addr == CEC_LOG_ADDR_INVALID)
+ addresses = cec->addresses = BIT(15);
+ else
+ addresses = cec->addresses |= BIT(logical_addr);
+
+ writeb_relaxed(addresses & 255, cec->base + HDMI_CEC_ADDR_L);
+ writeb_relaxed(addresses >> 8, cec->base + HDMI_CEC_ADDR_H);
+
+ return 0;
+}
+
+static int dw_hdmi_cec_transmit(struct cec_adapter *adap, u8 attempts,
+ u32 signal_free_time, struct cec_msg *msg)
+{
+ struct dw_hdmi_cec *cec = adap->priv;
+ unsigned i;
+
+ cec->retries = attempts;
+
+ for (i = 0; i < msg->len; i++)
+ writeb_relaxed(msg->msg[i], cec->base + HDMI_CEC_TX_DATA0 + i);
+
+ writeb_relaxed(msg->len, cec->base + HDMI_CEC_TX_CNT);
+ writeb_relaxed(CEC_CTRL_NORMAL | CEC_CTRL_START, cec->base +
HDMI_CEC_CTRL);
+
+ return 0;
+}
+
+static irqreturn_t dw_hdmi_cec_hardirq(int irq, void *data)
+{
+ struct cec_adapter *adap = data;
+ struct dw_hdmi_cec *cec = adap->priv;
+ unsigned stat = readb_relaxed(cec->base + HDMI_IH_
[Bug 97099] Regression in 9ef8537e6 "drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled" (RV620)
https://bugs.freedesktop.org/show_bug.cgi?id=97099 Christian König changed: What|Removed |Added Attachment #125352|0 |1 is obsolete|| --- Comment #4 from Christian König --- Created attachment 125738 --> https://bugs.freedesktop.org/attachment.cgi?id=125738&action=edit Possible fix -- 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/20160812/38c545b9/attachment.html>
[PATCH v2 11/13] gpu: ipu-ic: Add complete image conversion support with tiling
Am Mittwoch, den 03.08.2016, 17:18 -0700 schrieb Steve Longerbeam: > On 08/01/2016 02:29 AM, Philipp Zabel wrote: > > Am Donnerstag, den 28.07.2016, 16:09 -0700 schrieb Steve Longerbeam: > >>> Now split the frame in half and suddenly pixel x' = 640 is the start of > >>> a new tile, so it is sampled at x = 160, and pixel x' = 1279 will be > >>> sampled at x = 160 + (1279 - 640) * 8192/32846. = 319.37, reading over > >>> the edge of the source image. > >> Here's where we part. > >> > >> The 320x200 --> 1280x800 conversion is split into two 160x200 --> > >> 640x800 conversions. The DMA controller and ipu_ic_task_init() are given > >> those width/height dimensions, not the dimensions of the original images. > >> So this is simply two separate 160x200 --> 640x800 conversions. The only > >> difference from a true 160x200 --> 640x800 image conversion is that the DMA > >> controller must be given the stride lengths of the original 320x200 and > >> 1280x800 > >> images. > >> > >> The rsc for the 160x200 --> 640x800 conversions is > >> > >> x = x' * (160-1)/(640-1) = x' * 8192/rsc, so rsc = 32923 > >> > >> > >> So original horizontal position 640 is really x' = 0 of the second > >> conversion, > >> which is sampled at x = 0 of the second conversion. And the pixel at x' > >> = 1279 > >> is really x' = 639 of the second conversion, which is sampled at x = 639 > >> * 8192/32923 > >> = 158.98, which does not read over the edge of the source tile. > > My bad, I somehow thought that the scaling factor is calculated per > > image (as it IMHO should be), not just per tile. > > > > Of course in that case you won't ever read over the edge, but on the > > other hand the visual problems are worse because you underestimate the > > scaling factor and introduce a sharp edge at the center: even if the > > source pixel step per target pixel step is a fraction, between pixels > > width/2-1 and width/2 there's always a whole source pixel step. > > > > Take the extreme example of scaling 32x32 to 1080x1080 pixels. The ideal > > source pixels for x' = 519 and 520 should be x = 14.911 and 14.939, > > respectively. Due to tiling they will be x = 15 and 16, introducing a > > sharp seam in the otherwise blurry mess. > > I think you mean at x' = 539 and x' = 540. > > But yes I agree. Due to tiling, at x' = 539, the input pixel is sampled at x > = 15. > If the interpolation were to contnue (no tiling), at x' = 540, the input pixel > would be sampled at (31/1079)*540 = 15.514. Instead, because of tiling, > there is a discontinuity in the interpolation (it is reset), beginning again > at > x' = 0 (540), which is sampled at x = 0 (16). > > The only way I can think of to resolve this problem is to add some width > to the output tiles such that the interpolation completes a full span between > input position w - 2 and w - 1. That is, add to w' until floor(F*w') > increments > to the next whole integer, where F = (w-1)/(w'-1) is the scaling factor. > > But that will likely cause the next tile DMA addrs to fail to fall on the > IDMAC > 8 byte alignment. I always wanted to have a look at the scroll feature, maybe SX can be used to start at odd pixels? regards Philipp
[Bug 117151] amdgpu: Fails to initialize R7 260x (Bonaire)
https://bugzilla.kernel.org/show_bug.cgi?id=117151 Parker Reed changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #7 from Parker Reed --- This is fixed as of compiling linux-git 4.8rc1.r121.g4b9eaf3-1 Initializes correctly and even the Pro stack works on top of the amdgpu driver. -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] [PATCH 07/15] drm/omap: Use per-plane rotation property
On Thu, Aug 11, 2016 at 04:33:32PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 02:32:44PM +0300, Tomi Valkeinen wrote:
> > Hi,
> >
> > On 22/07/16 16:43, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > The global mode_config.rotation_property is going away, switch over to
> > > per-plane rotation_property.
> > >
> > > Not sure I got the annoying crtc rotation_property handling right.
> > > Might work, or migth not.
> >
> > I think something is funny with this patch or the series. I fetched your
> > branch, and with your series, it looks like the primary planes lose all
> > their props. modetest says:
> >
> > could not get plane 26 properties: Invalid argument
> > could not get plane 30 properties: Invalid argument
>
> Hmm. Weird. Is it really the get props ioctl that fails?
>
> The first EINVAL I can spot there is
> if (!obj->properties) {
> ret = -EINVAL;
> goto out_unref;
> }
> which definitely makes no sense since this is assigned
> as plane->base.properties = &plane->properties. So can't be that unless
> we manage to clear the pointer somehow after the init.
>
> The only other direct EINVAL I see there is if
> drm_object_property_get_value(obj->properties->properties[i])
> fails to find the passed prop in the properties array. Which clearly
> can't happen since we got it from the array in the first place. Also,
> clearly that code is rather inefficient, perhaps someone should rewrite
> it a bit.
>
> Can't quite see how this could fail for the plane in other ways. But I
> might be blind.
I tried to think on this a bit more, and the only think I came up with was
that we end up doing the drm_plane_create_rotation_property() twice for the
primary planes. I tried that on i915 but it'd didn't result in anything bad
AFAICS. Would leak a bit, but so what :P
Dunno, I guess you could try something like:
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -211,11 +211,12 @@ void omap_plane_install_properties(struct drm_plane
*plane,
struct omap_drm_private *priv = dev->dev_private;
if (priv->has_dmm) {
- drm_plane_create_rotation_property(plane,
- BIT(DRM_ROTATE_0),
- BIT(DRM_ROTATE_0) |
BIT(DRM_ROTATE_90) |
- BIT(DRM_ROTATE_180) |
BIT(DRM_ROTATE_270) |
- BIT(DRM_REFLECT_X) |
BIT(DRM_REFLECT_Y));
+ if (!plane->rotation_property)
+ drm_plane_create_rotation_property(plane,
+ BIT(DRM_ROTATE_0),
+ BIT(DRM_ROTATE_0) |
BIT(DRM_ROTATE_90) |
+ BIT(DRM_ROTATE_180)
| BIT(DRM_ROTATE_270) |
+ BIT(DRM_REFLECT_X) |
BIT(DRM_REFLECT_Y));
>
> >
> > and
> >
> > Planes:
> > id crtcfb CRTC x,yx,y gamma size possible
> > crtcs
> > 26 28 55 0,0 0,0 0 0x0001
> > formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24
> > no properties found
> > 30 0 0 0,0 0,0 0 0x0002
> > formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24
> > NV12 YUYV UYVY
> > no properties found
> >
> > I didn't look closer yet.
> >
> > Tomi
> >
>
>
>
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH 0/2] Introduce DRM_DEV_* logging
This patch set refactors some of the logging functions and introduces a new class of DRM_DEV_* messages which print the device name along with the other drm goodness. Note that the ERROR message format remains the same (with the *ERROR* prefix), however INFO messages now include the function name, e.g. instead of "[drm] My info message", it is now "[drm:my_function] My info message". The second patch updates rockchip vop to use the new log messages. This is tested on rockchip and compiled on i915/multi-v7/tegra/exynos/drm-misc Sean Paul (2): drm: Introduce DRM_DEV_* log messages drm/rockchip: Use DRM_DEV_ERROR in vop drivers/gpu/drm/drm_drv.c | 31 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 24 ++--- include/drm/drmP.h | 133 +++- 3 files changed, 96 insertions(+), 92 deletions(-) -- 2.8.0.rc3.226.g39d4020
[PATCH 1/2] drm: Introduce DRM_DEV_* log messages
This patch consolodates all the various log functions/macros into
one uber function, drm_log. It also introduces some new DRM_DEV_*
variants that print the device name to delineate multiple devices
of the same type.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_drv.c | 31 +--
include/drm/drmP.h| 133 --
2 files changed, 82 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 57ce973..e8595f0 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -63,37 +63,30 @@ static struct idr drm_minors_idr;
static struct dentry *drm_debugfs_root;
-void drm_err(const char *format, ...)
+void drm_log(const struct device *dev, const char *level, unsigned int
category,
+const char *function_name, const char *prefix,
+const char *format, ...)
{
struct va_format vaf;
va_list args;
- va_start(args, format);
-
- vaf.fmt = format;
- vaf.va = &args;
-
- printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
- __builtin_return_address(0), &vaf);
-
- va_end(args);
-}
-EXPORT_SYMBOL(drm_err);
-
-void drm_ut_debug_printk(const char *function_name, const char *format, ...)
-{
- struct va_format vaf;
- va_list args;
+ if (category != DRM_UT_NONE && !(drm_debug & category))
+ return;
va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
- printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
+ if (dev)
+ printk("%s%s [" DRM_NAME ":%s]%s %pV", level,
+ dev_name(dev), function_name, prefix, &vaf);
+ else
+ printk("%s[" DRM_NAME ":%s]%s %pV", level, function_name,
+ prefix, &vaf);
va_end(args);
}
-EXPORT_SYMBOL(drm_ut_debug_printk);
+EXPORT_SYMBOL(drm_log);
/*
* DRM Minors
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f8e87fd..9a6ace2 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -127,6 +127,7 @@ struct dma_buf_attachment;
* run-time by echoing the debug value in its sysfs node:
* # echo 0xf > /sys/module/drm/parameters/debug
*/
+#define DRM_UT_NONE0x00
#define DRM_UT_CORE0x01
#define DRM_UT_DRIVER 0x02
#define DRM_UT_KMS 0x04
@@ -134,11 +135,10 @@ struct dma_buf_attachment;
#define DRM_UT_ATOMIC 0x10
#define DRM_UT_VBL 0x20
-extern __printf(2, 3)
-void drm_ut_debug_printk(const char *function_name,
-const char *format, ...);
-extern __printf(1, 2)
-void drm_err(const char *format, ...);
+extern __printf(6, 7)
+void drm_log(const struct device *dev, const char *level, unsigned int
category,
+const char *function_name, const char *prefix,
+const char *format, ...);
/***/
/** \name DRM template customization defaults */
@@ -169,8 +169,10 @@ void drm_err(const char *format, ...);
* \param fmt printf() like format string.
* \param arg arguments
*/
-#define DRM_ERROR(fmt, ...)\
- drm_err(fmt, ##__VA_ARGS__)
+#define DRM_DEV_ERROR(dev, fmt, ...) \
+ drm_log(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt, \
+ ##__VA_ARGS__)
+#define DRM_ERROR(fmt, ...) DRM_DEV_ERROR(NULL, fmt, ##__VA_ARGS__)
/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
@@ -178,21 +180,31 @@ void drm_err(const char *format, ...);
* \param fmt printf() like format string.
* \param arg arguments
*/
-#define DRM_ERROR_RATELIMITED(fmt, ...)\
+#define DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) \
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
DEFAULT_RATELIMIT_INTERVAL, \
DEFAULT_RATELIMIT_BURST); \
\
if (__ratelimit(&_rs)) \
- drm_err(fmt, ##__VA_ARGS__);\
+ DRM_DEV_ERROR(dev, fmt, ##__VA_ARGS__); \
})
+#define DRM_ERROR_RATELIMITED(fmt, ...)\
+ DRM_DEV_ERROR_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
-#define DRM_INFO(fmt, ...) \
- printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
+#define DRM_DEV_INFO(dev, fmt, ...)\
+ drm_log(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
+#define DRM_INFO(fmt, ...) DRM_DEV_INFO(NULL, fmt, ##__VA_ARGS__)
-#define DRM_INFO_ONCE(fmt, ...)
[PATCH 2/2] drm/rockchip: Use DRM_DEV_ERROR in vop
Since we can have multiple vops, use DRM_DEV_ERROR to
make logs easier to process.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 31744fe..ec8ad00 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -238,7 +238,7 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_NV24:
return VOP_FMT_YUV444SP;
default:
- DRM_ERROR("unsupport format[%08x]\n", format);
+ DRM_ERROR("unsupported format[%08x]\n", format);
return -EINVAL;
}
}
@@ -315,7 +315,7 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const
struct vop_win_data *win,
int vskiplines = 0;
if (dst_w > 3840) {
- DRM_ERROR("Maximum destination width (3840) exceeded\n");
+ DRM_DEV_ERROR(vop->dev, "Maximum dst width (3840) exceeded\n");
return;
}
@@ -353,11 +353,11 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const
struct vop_win_data *win,
VOP_SCL_SET_EXT(vop, win, lb_mode, lb_mode);
if (lb_mode == LB_RGB_3840X2) {
if (yrgb_ver_scl_mode != SCALE_NONE) {
- DRM_ERROR("ERROR : not allow yrgb ver scale\n");
+ DRM_DEV_ERROR(vop->dev, "not allow yrgb ver scale\n");
return;
}
if (cbcr_ver_scl_mode != SCALE_NONE) {
- DRM_ERROR("ERROR : not allow cbcr ver scale\n");
+ DRM_DEV_ERROR(vop->dev, "not allow cbcr ver scale\n");
return;
}
vsu_mode = SCALE_UP_BIL;
@@ -970,7 +970,8 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, mipi_en, 1);
break;
default:
- DRM_ERROR("unsupport connector_type[%d]\n", s->output_type);
+ DRM_DEV_ERROR(vop->dev, "unsupported connector_type [%d]\n",
+ s->output_type);
}
VOP_CTRL_SET(vop, out_mode, s->output_mode);
@@ -1154,7 +1155,8 @@ static irqreturn_t vop_isr(int irq, void *data)
/* Unhandled irqs are spurious. */
if (active_irqs)
- DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs);
+ DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
+ active_irqs);
return ret;
}
@@ -1189,7 +1191,8 @@ static int vop_create_crtc(struct vop *vop)
win_data->phy->nformats,
win_data->type, NULL);
if (ret) {
- DRM_ERROR("failed to initialize plane\n");
+ DRM_DEV_ERROR(vop->dev, "failed to init plane %d\n",
+ ret);
goto err_cleanup_planes;
}
@@ -1227,7 +1230,8 @@ static int vop_create_crtc(struct vop *vop)
win_data->phy->nformats,
win_data->type, NULL);
if (ret) {
- DRM_ERROR("failed to initialize overlay plane\n");
+ DRM_DEV_ERROR(vop->dev, "failed to init overlay %d\n",
+ ret);
goto err_cleanup_crtc;
}
drm_plane_helper_add(&vop_win->base, &plane_helper_funcs);
@@ -1235,8 +1239,8 @@ static int vop_create_crtc(struct vop *vop)
port = of_get_child_by_name(dev->of_node, "port");
if (!port) {
- DRM_ERROR("no port node found in %s\n",
- dev->of_node->full_name);
+ DRM_DEV_ERROR(vop->dev, "no port node found in %s\n",
+ dev->of_node->full_name);
ret = -ENOENT;
goto err_cleanup_crtc;
}
--
2.8.0.rc3.226.g39d4020
[PATCH] drm: don't warn unconditionally in drm_vblank_cleanup about enabled vblanks
On Fri, Aug 12, 2016 at 11:04:38AM +0200, Lucas Stach wrote:
> On drivers without immediate vblank disabling drm_vblank_cleanup() may be
> called before the delayed vblank disable timer has fired. Instead of spitting
> out a warning unconditionally in this case, run the vblank disable function
> immediately.
>
> Only warn if vblanks are still enabled and there was no timer pending to
> disable them.
>
> Signed-off-by: Lucas Stach
I think this needs a Fixes: line + Cc: of the people who broke things?
-Daniel
> ---
> drivers/gpu/drm/drm_irq.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 77f357b2c386..e6eb5024341d 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -335,10 +335,15 @@ void drm_vblank_cleanup(struct drm_device *dev)
> for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
>
> - WARN_ON(vblank->enabled &&
> - drm_core_check_feature(dev, DRIVER_MODESET));
> -
> - del_timer_sync(&vblank->disable_timer);
> + if (del_timer_sync(&vblank->disable_timer))
> + /*
> + * If we deactivated a pending timer, make sure to
> + * disable the vblank now.
> + */
> + vblank_disable_fn((unsigned long)vblank);
> + else
> + WARN_ON(vblank->enabled &&
> + drm_core_check_feature(dev, DRIVER_MODESET));
> }
>
> kfree(dev->vblank);
> --
> 2.8.1
>
> ___
> 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 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 01:00:53PM -0400, Sean Paul wrote:
> This patch consolodates all the various log functions/macros into
> one uber function, drm_log. It also introduces some new DRM_DEV_*
> variants that print the device name to delineate multiple devices
> of the same type.
> +void drm_log(const struct device *dev, const char *level, unsigned int
> category,
> + const char *function_name, const char *prefix,
> + const char *format, ...)
> {
> + if (dev)
> + printk("%s%s [" DRM_NAME ":%s]%s %pV", level,
> +dev_name(dev), function_name, prefix, &vaf);
> + else
> + printk("%s[" DRM_NAME ":%s]%s %pV", level, function_name,
> +prefix, &vaf);
My hope was that we would migrate towards dev_printk so that our log
messages would have better conformity, especially between our messages
and those printed by subsystems on our behalf (using our struct device).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PULL] topic/drm-misc
Hi Dave,
- more fence destaging and cleanup (Gustavo&Sumit)
- DRIVER_LEGACY to untangle from DRIVER_MODESET
- drm_mm refactor (Chris)
- fbdev-less compile fies
- clipped plane src/dst rects (Ville)
- + a few mediatek patches that build on top of that (Bibby+Daniel)
- small stuff all over really
Cheers, Daniel
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-08-12
for you to fetch changes up to 3590d50e2313644cd192ff55e83df76dea232319:
dma-buf/fence: kerneldoc: remove spurious section header (2016-08-12 20:32:14
+0530)
Bibby Hsieh (2):
drm/mediatek: Use drm_atomic destroy_state helpers
drm/mediatek: Fix mtk_atomic_complete for runtime_pm
Chris Wilson (4):
drm: Track drm_mm nodes with an interval tree
drm: Convert drm_vma_manager to embedded interval-tree in drm_mm
drm: Skip initialising the drm_mm_node->hole_stack
drm: Declare that create drm_mm nodes with size 0 is illegal
Daniel Kurtz (5):
drm/mediatek: Remove mtk_drm_crtc_check_flush
drm/mediatek: plane: Remove plane zpos/index
drm/mediatek: Remove mtk_drm_plane
drm/mediatek: plane: Merge mtk_plane_enable into mtk_plane_atomic_update
drm/mediatek: plane: Use FB's format's cpp to compute x offset
Daniel Vetter (8):
drm: Mark up legacy/dri1 drivers with DRM_LEGACY
drm: Used DRM_LEGACY for all legacy functions
drm: Make sure drm_vblank_no_hw_counter isn't abused
drm/fb-helper: Add a dummy remove_conflicting_framebuffers
drm: Remove superflous linux/fb.h includes
drm/vmwgfx: select CONFIG_FB
drm/radeon|amgpu: Make fbdev emulation optional
drm: Protect fb_defio in drivers with CONFIG_KMS_FBDEV_EMULATION
David Herrmann (1):
drm: rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY
Gustavo Padovan (5):
dma-buf/fence-array: add fence_is_array()
dma-buf/sync_file: refactor fence storage in struct sync_file
dma-buf/sync_file: add sync_file_get_fence()
Documentation: add doc for sync_file_get_fence()
dma-buf/sync_file: only enable fence signalling on poll()
Joonas Lahtinen (1):
drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?
Keith Packard (1):
drm: Don't prepare or cleanup unchanging frame buffers [v3]
Lyude (3):
drm: Add ratelimited versions of the DRM_DEBUG* macros
drm/dp_helper: Print first error received on failure in
drm_dp_dpcd_access()
drm/dp_helper: Rate limit timeout errors from drm_dp_i2c_do_msg()
Peter Chen (1):
Revert "gpu: drm: omapdrm: dss-of: add missing of_node_put after calling
of_parse_phandle"
Rodrigo Vivi (1):
drm: Avoid printing negative values for unsigned variables.
Sumit Semwal (2):
dma-buf/fence: kerneldoc: remove unused struct members
dma-buf/fence: kerneldoc: remove spurious section header
Ville Syrjälä (9):
drm: Warn about negative sizes when calculating scale factor
drm: Store clipped src/dst coordinatee in drm_plane_state
drm/plane-helper: Add drm_plane_helper_check_state()
drm/i915: Use drm_plane_state.{src,dst,visible}
drm/i915: Use drm_plane_helper_check_state()
drm/rockchip: Use drm_plane_state.{src, dst}
drm/rockchip: Use drm_plane_helper_check_state()
drm/mediatek: Use drm_plane_helper_check_state()
drm/simple_kms_helper: Use drm_plane_helper_check_state()
Documentation/gpu/drm-internals.rst| 9 +-
Documentation/sync_file.txt| 14 ++
drivers/dma-buf/fence-array.c | 1 +
drivers/dma-buf/sync_file.c| 204 ++---
drivers/gpu/drm/Kconfig| 8 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 1 -
drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c | 1 -
.../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 1 -
drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c | 1 -
drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 1 -
.../amd/powerplay/hwmgr/tonga_processpptables.c| 1 -
drivers/gpu/drm/arm/malidp_drv.h | 2 +-
drivers/gpu/drm/arm/malidp_planes.c| 20 +-
drivers/gpu/drm/armada/armada_fbdev.c | 1 -
drivers/gpu/drm/armada/armada_overlay.c| 2 +-
drivers/gpu/drm/ast/ast_fb.c | 1 -
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 22 +--
drivers/gpu/drm/bochs/bochs.h | 1 -
drivers/gpu/drm/bochs/bochs_drv.c | 3 +-
drivers/gpu/drm/bridge/parade-ps8622.c | 1 -
drivers/gpu/drm/cirrus/cirrus_drv.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_fbdev.c
[PULL] drm-intel-next
Hi Dave, drm-intel-next-2016-08-08: - refactor ddi buffer programming a bit (Ville) - large-scale renaming to untangle naming in the gem code (Chris) - rework vma/active tracking for accurately reaping idle mappings of shared objects (Chris) - misc dp sst/mst probing corner case fixes (Ville) - tons of cleanup&tunings all around in gem - lockless (rcu-protected) request lookup, plus use it everywhere for non(b)locking waits (Chris) - pipe crc debugfs fixes (Rodrigo) - random fixes all over drm-intel-next-2016-07-25: - more engine code unification (Tvrtko) - reorganize rps&rc6 setup (Chris Wilson) - hotplug polling when in deep rpm states, especially fixes vls (Lyude) - mocs fix for bxt (Imre) - convert i915 request to use dma fences (Chris) - prep work for lockless i915 requests/fences (needed for full sync integration) from Chris Wilson - wait for external rendering/fences attached to dma_bufs (Chris) - tons of small bugfixes all over Note also contains a backmerge (git got confused), but when you've pulled in all pending pulls (there's a few now) I want to do another backmerge to get at the latest fences stuff from Gustavo. Cheers, Daniel The following changes since commit 1cf915d305b6e1d57db6c35c208016f9747ba3c6: Merge tag 'imx-drm-fixes-2016-07-27' of git://git.pengutronix.de/git/pza/linux into drm-next (2016-07-30 05:45:30 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-08-08 for you to fetch changes up to c5b7e97b27db4f8a8ffe1072506620679043f006: drm/i915: Update DRIVER_DATE to 20160808 (2016-08-08 09:37:31 +0200) - refactor ddi buffer programming a bit (Ville) - large-scale renaming to untangle naming in the gem code (Chris) - rework vma/active tracking for accurately reaping idle mappings of shared objects (Chris) - misc dp sst/mst probing corner case fixes (Ville) - tons of cleanup&tunings all around in gem - lockless (rcu-protected) request lookup, plus use it everywhere for non(b)locking waits (Chris) - pipe crc debugfs fixes (Rodrigo) - random fixes all over Akash Goel (1): drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info Bob Paauwe (1): drm/i915: Set legacy properties when using legacy gamma set IOCTL. (v2) Chris Wilson (152): drm/i915/breadcrumbs: Queue hangcheck before sleeping drm/i915: Kick hangcheck from retire worker drm/i915: Remove temporary RPM wakeref assert disables drm/i915: Update ifdeffery for mutex->owner drm/i915: Provide argument names for static stubs drm/i915: Flush GT idle status upon reset drm/i915: Preserve current RPS frequency across init drm/i915: Perform static RPS frequency setup before userspace drm/i915: Move overclocking detection to alongside RPS frequency detection drm/i915: Define a separate variable and control for RPS waitboost frequency drm/i915: Remove superfluous powersave work flushing drm/i915: Defer enabling rc6 til after we submit the first batch/context drm/i915: Hide gen6_update_ring_freq() drm/i915/fbdev: Drain the suspend worker on retiring drm/i915/fbdev: Check for the framebuffer before use drm/i915/evict: Always switch away from the current context drm/i915: Flush logical context image out to memory upon suspend drm/i915: Handle ENOSPC after failing to insert a mappable node drm/i915: Move GEM request routines to i915_gem_request.c drm/i915: Retire oldest completed request before allocating next drm/i915: Mark all current requests as complete before resetting them drm/i915: Derive GEM requests from dma-fence drm/i915: Disable waitboosting for fence_wait() drm/i915: Disable waitboosting for mmioflips/semaphores drm/i915: Mark imported dma-buf objects as being coherent drm/i915: Wait on external rendering for GEM objects drm/i915: Rename request reference/unreference to get/put drm/i915: Rename i915_gem_context_reference/unreference() drm/i915: Wrap drm_gem_object_lookup in i915_gem_object_lookup drm/i915: Wrap drm_gem_object_reference in i915_gem_object_get drm/i915: Rename drm_gem_object_unreference in preparation for lockless free drm/i915: Rename drm_gem_object_unreference_unlocked in preparation for lockless free drm/i915: Treat ringbuffer writes as write to normal memory drm/i915: Rename ring->virtual_start as ring->vaddr drm/i915: Convert i915_semaphores_is_enabled over to early sanitize drm/i915: Enable RC6 immediately Revert "drm/i915: Enable RC6 immediately" drm/i915: Drop racy markup of missed-irqs from idle-worker drm/i915: Update the breadcrumb interrupt counter before enabling drm/i915: Reduce breadcrumb lock coverage for intel_engine
[PATCH 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 1:13 PM, Chris Wilson
wrote:
> On Fri, Aug 12, 2016 at 01:00:53PM -0400, Sean Paul wrote:
>> This patch consolodates all the various log functions/macros into
>> one uber function, drm_log. It also introduces some new DRM_DEV_*
>> variants that print the device name to delineate multiple devices
>> of the same type.
>
>> +void drm_log(const struct device *dev, const char *level, unsigned int
>> category,
>> + const char *function_name, const char *prefix,
>> + const char *format, ...)
>> {
>> + if (dev)
>> + printk("%s%s [" DRM_NAME ":%s]%s %pV", level,
>> +dev_name(dev), function_name, prefix, &vaf);
>> + else
>> + printk("%s[" DRM_NAME ":%s]%s %pV", level, function_name,
>> +prefix, &vaf);
>
> My hope was that we would migrate towards dev_printk so that our log
> messages would have better conformity, especially between our messages
> and those printed by subsystems on our behalf (using our struct device).
Yep, that makes sense, v2 incoming.
Sean
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
[Bug 97025] flip queue failed: Device or resource busy
https://bugs.freedesktop.org/show_bug.cgi?id=97025 --- Comment #12 from Bernd Steinhauser --- It does prevent the vblank messages in dmesg, I don't know if it'll prevent the freeze. -- 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/20160812/f40bf1be/attachment.html>
[PATCH v2 1/2] drm: Introduce DRM_DEV_* log messages
This patch consolidates all the various log functions/macros into
one uber function, drm_log. It also introduces some new DRM_DEV_*
variants that print the device name to delineate multiple devices
of the same type.
Signed-off-by: Sean Paul
---
Changes in v2:
- Use dev_printk for the dev variant (Chris Wilson)
drivers/gpu/drm/drm_drv.c | 31 +--
include/drm/drmP.h| 133 --
2 files changed, 82 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 57ce973..edd3291 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -63,37 +63,30 @@ static struct idr drm_minors_idr;
static struct dentry *drm_debugfs_root;
-void drm_err(const char *format, ...)
+void drm_log(const struct device *dev, const char *level, unsigned int
category,
+const char *function_name, const char *prefix,
+const char *format, ...)
{
struct va_format vaf;
va_list args;
- va_start(args, format);
-
- vaf.fmt = format;
- vaf.va = &args;
-
- printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
- __builtin_return_address(0), &vaf);
-
- va_end(args);
-}
-EXPORT_SYMBOL(drm_err);
-
-void drm_ut_debug_printk(const char *function_name, const char *format, ...)
-{
- struct va_format vaf;
- va_list args;
+ if (category != DRM_UT_NONE && !(drm_debug & category))
+ return;
va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
- printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
+ if (dev)
+ dev_printk(level, dev, "[" DRM_NAME ":%s]%s %pV", function_name,
+ prefix, &vaf);
+ else
+ printk("%s[" DRM_NAME ":%s]%s %pV", level, function_name,
+ prefix, &vaf);
va_end(args);
}
-EXPORT_SYMBOL(drm_ut_debug_printk);
+EXPORT_SYMBOL(drm_log);
/*
* DRM Minors
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f8e87fd..9a6ace2 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -127,6 +127,7 @@ struct dma_buf_attachment;
* run-time by echoing the debug value in its sysfs node:
* # echo 0xf > /sys/module/drm/parameters/debug
*/
+#define DRM_UT_NONE0x00
#define DRM_UT_CORE0x01
#define DRM_UT_DRIVER 0x02
#define DRM_UT_KMS 0x04
@@ -134,11 +135,10 @@ struct dma_buf_attachment;
#define DRM_UT_ATOMIC 0x10
#define DRM_UT_VBL 0x20
-extern __printf(2, 3)
-void drm_ut_debug_printk(const char *function_name,
-const char *format, ...);
-extern __printf(1, 2)
-void drm_err(const char *format, ...);
+extern __printf(6, 7)
+void drm_log(const struct device *dev, const char *level, unsigned int
category,
+const char *function_name, const char *prefix,
+const char *format, ...);
/***/
/** \name DRM template customization defaults */
@@ -169,8 +169,10 @@ void drm_err(const char *format, ...);
* \param fmt printf() like format string.
* \param arg arguments
*/
-#define DRM_ERROR(fmt, ...)\
- drm_err(fmt, ##__VA_ARGS__)
+#define DRM_DEV_ERROR(dev, fmt, ...) \
+ drm_log(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt, \
+ ##__VA_ARGS__)
+#define DRM_ERROR(fmt, ...) DRM_DEV_ERROR(NULL, fmt, ##__VA_ARGS__)
/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
@@ -178,21 +180,31 @@ void drm_err(const char *format, ...);
* \param fmt printf() like format string.
* \param arg arguments
*/
-#define DRM_ERROR_RATELIMITED(fmt, ...)\
+#define DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) \
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
DEFAULT_RATELIMIT_INTERVAL, \
DEFAULT_RATELIMIT_BURST); \
\
if (__ratelimit(&_rs)) \
- drm_err(fmt, ##__VA_ARGS__);\
+ DRM_DEV_ERROR(dev, fmt, ##__VA_ARGS__); \
})
+#define DRM_ERROR_RATELIMITED(fmt, ...)\
+ DRM_DEV_ERROR_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
-#define DRM_INFO(fmt, ...) \
- printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
+#define DRM_DEV_INFO(dev, fmt, ...)\
+ drm_log(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt, ##__VA_ARGS__)
+#define DRM_INFO(fmt, ...) DRM_DEV_INFO(NULL, fmt, #
[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"
https://bugs.freedesktop.org/show_bug.cgi?id=90481 Daniel Scharrer changed: What|Removed |Added Attachment #124508|0 |1 is obsolete|| --- Comment #20 from Daniel Scharrer --- Created attachment 125752 --> https://bugs.freedesktop.org/attachment.cgi?id=125752&action=edit GALLIUM_DDEBUG="pipelined 1" dump I played more of the game with GALLIUM_DDEBUG="pipelined 1" and was able to eventually catch a lockup. Fewer blocks busy this time. -- 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/20160812/8401b3a8/attachment.html>
[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"
https://bugs.freedesktop.org/show_bug.cgi?id=90481 --- Comment #21 from Daniel Scharrer --- The game also segfaulted a few times while playing - still need to get a backtrace of that. -- 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/20160812/49c6a457/attachment-0001.html>
[PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"
On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote: > If my upcoming testing of the two changes together pans out, I will > give you a Tested-by -- I am guessing that you don't want to wait > until the next merge window for these changes. I was planning to stuff them in tip/locking/urgent, so they'd end up in this release.
[PATCH v2 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 01:30:00PM -0400, Sean Paul wrote:
> This patch consolidates all the various log functions/macros into
> one uber function, drm_log. It also introduces some new DRM_DEV_*
> variants that print the device name to delineate multiple devices
> of the same type.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Use dev_printk for the dev variant (Chris Wilson)
>
>
> drivers/gpu/drm/drm_drv.c | 31 +--
> include/drm/drmP.h| 133
> --
> 2 files changed, 82 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 57ce973..edd3291 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -63,37 +63,30 @@ static struct idr drm_minors_idr;
>
> static struct dentry *drm_debugfs_root;
>
> -void drm_err(const char *format, ...)
> +void drm_log(const struct device *dev, const char *level, unsigned int
> category,
I would have called this drm_printk() to match the function it wraps.
> + const char *function_name, const char *prefix,
> + const char *format, ...)
> {
> struct va_format vaf;
> va_list args;
>
> - va_start(args, format);
> -
> - vaf.fmt = format;
> - vaf.va = &args;
> -
> - printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
> -__builtin_return_address(0), &vaf);
> -
> - va_end(args);
> -}
> -EXPORT_SYMBOL(drm_err);
> -
> -void drm_ut_debug_printk(const char *function_name, const char *format, ...)
> -{
> - struct va_format vaf;
> - va_list args;
> + if (category != DRM_UT_NONE && !(drm_debug & category))
> + return;
>
> va_start(args, format);
> vaf.fmt = format;
> vaf.va = &args;
>
> - printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
> + if (dev)
> + dev_printk(level, dev, "[" DRM_NAME ":%s]%s %pV", function_name,
> +prefix, &vaf);
> + else
> + printk("%s[" DRM_NAME ":%s]%s %pV", level, function_name,
> +prefix, &vaf);
lgtm.
> -#define DRM_ERROR(fmt, ...) \
> - drm_err(fmt, ##__VA_ARGS__)
> +#define DRM_DEV_ERROR(dev, fmt, ...) \
> + drm_log(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt, \
> + ##__VA_ARGS__)
> +#define DRM_ERROR(fmt, ...) DRM_DEV_ERROR(NULL, fmt, ##__VA_ARGS__)
And these look like a reasonable solution given the constraints.
Out of curiosity, how much did the kernel build grow by adding a NULL
parameter everywhere?
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH v2 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 2:39 PM, Chris Wilson
wrote:
> On Fri, Aug 12, 2016 at 01:30:00PM -0400, Sean Paul wrote:
>> This patch consolidates all the various log functions/macros into
>> one uber function, drm_log. It also introduces some new DRM_DEV_*
>> variants that print the device name to delineate multiple devices
>> of the same type.
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v2:
>> - Use dev_printk for the dev variant (Chris Wilson)
>>
>>
>> drivers/gpu/drm/drm_drv.c | 31 +--
>> include/drm/drmP.h| 133
>> --
>> 2 files changed, 82 insertions(+), 82 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 57ce973..edd3291 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -63,37 +63,30 @@ static struct idr drm_minors_idr;
>>
>> static struct dentry *drm_debugfs_root;
>>
>> -void drm_err(const char *format, ...)
>> +void drm_log(const struct device *dev, const char *level, unsigned int
>> category,
>
> I would have called this drm_printk() to match the function it wraps.
>
>> + const char *function_name, const char *prefix,
>> + const char *format, ...)
>> {
>> struct va_format vaf;
>> va_list args;
>>
>> - va_start(args, format);
>> -
>> - vaf.fmt = format;
>> - vaf.va = &args;
>> -
>> - printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
>> -__builtin_return_address(0), &vaf);
>> -
>> - va_end(args);
>> -}
>> -EXPORT_SYMBOL(drm_err);
>> -
>> -void drm_ut_debug_printk(const char *function_name, const char *format, ...)
>> -{
>> - struct va_format vaf;
>> - va_list args;
>> + if (category != DRM_UT_NONE && !(drm_debug & category))
>> + return;
>>
>> va_start(args, format);
>> vaf.fmt = format;
>> vaf.va = &args;
>>
>> - printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
>> + if (dev)
>> + dev_printk(level, dev, "[" DRM_NAME ":%s]%s %pV",
>> function_name,
>> +prefix, &vaf);
>> + else
>> + printk("%s[" DRM_NAME ":%s]%s %pV", level, function_name,
>> +prefix, &vaf);
>
> lgtm.
>
>> -#define DRM_ERROR(fmt, ...) \
>> - drm_err(fmt, ##__VA_ARGS__)
>> +#define DRM_DEV_ERROR(dev, fmt, ...) \
>> + drm_log(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt, \
>> + ##__VA_ARGS__)
>> +#define DRM_ERROR(fmt, ...) DRM_DEV_ERROR(NULL, fmt, ##__VA_ARGS__)
>
> And these look like a reasonable solution given the constraints.
>
> Out of curiosity, how much did the kernel build grow by adding a NULL
> parameter everywhere?
uncompressed vmlinux is 8286 bytes larger on my i915 build, 34832 on exynos
bzImage on i915 build is 2912 bytes larger and zImage on exynos is
6752 bytes larger
Sean
>
> Reviewed-by: Chris Wilson
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"
https://bugs.freedesktop.org/show_bug.cgi?id=90481 --- Comment #22 from Daniel Scharrer --- Created attachment 125754 --> https://bugs.freedesktop.org/attachment.cgi?id=125754&action=edit Another GALLIUM_DDEBUG="pipelined 1" dump -- 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/20160812/1e53e623/attachment.html>
[PATCH v2 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 07:39:38PM +0100, Chris Wilson wrote: > On Fri, Aug 12, 2016 at 01:30:00PM -0400, Sean Paul wrote: > > This patch consolidates all the various log functions/macros into > > one uber function, drm_log. It also introduces some new DRM_DEV_* > > variants that print the device name to delineate multiple devices > > of the same type. > > > > Signed-off-by: Sean Paul > > --- > > > > Changes in v2: > > - Use dev_printk for the dev variant (Chris Wilson) > > > > > > drivers/gpu/drm/drm_drv.c | 31 +-- > > include/drm/drmP.h| 133 > > -- > > 2 files changed, 82 insertions(+), 82 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > index 57ce973..edd3291 100644 > > --- a/drivers/gpu/drm/drm_drv.c > > +++ b/drivers/gpu/drm/drm_drv.c > > @@ -63,37 +63,30 @@ static struct idr drm_minors_idr; > > > > static struct dentry *drm_debugfs_root; > > > > -void drm_err(const char *format, ...) > > +void drm_log(const struct device *dev, const char *level, unsigned int > > category, > > I would have called this drm_printk() to match the function it wraps. lxr.free-electrons.com says dev_info() is used in 2056 files whereas dev_printk() is only used in 90 files. And dev_log() doesn't exist. So drm_info() would arguably make the most sense. Best regards, Lukas
[PATCH v2 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 09:26:32PM +0200, Lukas Wunner wrote: > On Fri, Aug 12, 2016 at 07:39:38PM +0100, Chris Wilson wrote: > > On Fri, Aug 12, 2016 at 01:30:00PM -0400, Sean Paul wrote: > > > This patch consolidates all the various log functions/macros into > > > one uber function, drm_log. It also introduces some new DRM_DEV_* > > > variants that print the device name to delineate multiple devices > > > of the same type. > > > > > > Signed-off-by: Sean Paul > > > --- > > > > > > Changes in v2: > > > - Use dev_printk for the dev variant (Chris Wilson) > > > > > > > > > drivers/gpu/drm/drm_drv.c | 31 +-- > > > include/drm/drmP.h| 133 > > > -- > > > 2 files changed, 82 insertions(+), 82 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > > index 57ce973..edd3291 100644 > > > --- a/drivers/gpu/drm/drm_drv.c > > > +++ b/drivers/gpu/drm/drm_drv.c > > > @@ -63,37 +63,30 @@ static struct idr drm_minors_idr; > > > > > > static struct dentry *drm_debugfs_root; > > > > > > -void drm_err(const char *format, ...) > > > +void drm_log(const struct device *dev, const char *level, unsigned int > > > category, > > > > I would have called this drm_printk() to match the function it wraps. > > lxr.free-electrons.com says dev_info() is used in 2056 files whereas > dev_printk() is only used in 90 files. And dev_log() doesn't exist. > So drm_info() would arguably make the most sense. dev_printk is the underlying mechanism, dev_log() is a curry function calling dev_printk with some parameters already provided. Speaking of which, if we did separate drm_printk() and drm_dev_printk(), if drm_printk just called drm_dev_printk(NULL, ...) we would barely grow the build. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v2 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 3:44 PM, Chris Wilson wrote: > On Fri, Aug 12, 2016 at 09:26:32PM +0200, Lukas Wunner wrote: >> On Fri, Aug 12, 2016 at 07:39:38PM +0100, Chris Wilson wrote: >> > On Fri, Aug 12, 2016 at 01:30:00PM -0400, Sean Paul wrote: >> > > This patch consolidates all the various log functions/macros into >> > > one uber function, drm_log. It also introduces some new DRM_DEV_* >> > > variants that print the device name to delineate multiple devices >> > > of the same type. >> > > >> > > Signed-off-by: Sean Paul >> > > --- >> > > >> > > Changes in v2: >> > > - Use dev_printk for the dev variant (Chris Wilson) >> > > >> > > >> > > drivers/gpu/drm/drm_drv.c | 31 +-- >> > > include/drm/drmP.h| 133 >> > > -- >> > > 2 files changed, 82 insertions(+), 82 deletions(-) >> > > >> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c >> > > index 57ce973..edd3291 100644 >> > > --- a/drivers/gpu/drm/drm_drv.c >> > > +++ b/drivers/gpu/drm/drm_drv.c >> > > @@ -63,37 +63,30 @@ static struct idr drm_minors_idr; >> > > >> > > static struct dentry *drm_debugfs_root; >> > > >> > > -void drm_err(const char *format, ...) >> > > +void drm_log(const struct device *dev, const char *level, unsigned int >> > > category, >> > >> > I would have called this drm_printk() to match the function it wraps. >> >> lxr.free-electrons.com says dev_info() is used in 2056 files whereas >> dev_printk() is only used in 90 files. And dev_log() doesn't exist. >> So drm_info() would arguably make the most sense. > > dev_printk is the underlying mechanism, dev_log() is a curry function > calling dev_printk with some parameters already provided. > > Speaking of which, if we did separate drm_printk() and drm_dev_printk(), > if drm_printk just called drm_dev_printk(NULL, ...) we would barely grow > the build. Thanks for the suggestion, will revise. Sean > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
[PATCH v2 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 08:44:38PM +0100, Chris Wilson wrote: > On Fri, Aug 12, 2016 at 09:26:32PM +0200, Lukas Wunner wrote: > > On Fri, Aug 12, 2016 at 07:39:38PM +0100, Chris Wilson wrote: > > > On Fri, Aug 12, 2016 at 01:30:00PM -0400, Sean Paul wrote: > > > > This patch consolidates all the various log functions/macros into > > > > one uber function, drm_log. It also introduces some new DRM_DEV_* > > > > variants that print the device name to delineate multiple devices > > > > of the same type. > > > > > > > > Signed-off-by: Sean Paul > > > > --- > > > > > > > > Changes in v2: > > > > - Use dev_printk for the dev variant (Chris Wilson) > > > > > > > > > > > > drivers/gpu/drm/drm_drv.c | 31 +-- > > > > include/drm/drmP.h| 133 > > > > -- > > > > 2 files changed, 82 insertions(+), 82 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > > > index 57ce973..edd3291 100644 > > > > --- a/drivers/gpu/drm/drm_drv.c > > > > +++ b/drivers/gpu/drm/drm_drv.c > > > > @@ -63,37 +63,30 @@ static struct idr drm_minors_idr; > > > > > > > > static struct dentry *drm_debugfs_root; > > > > > > > > -void drm_err(const char *format, ...) > > > > +void drm_log(const struct device *dev, const char *level, unsigned int > > > > category, > > > > > > I would have called this drm_printk() to match the function it wraps. > > > > lxr.free-electrons.com says dev_info() is used in 2056 files whereas > > dev_printk() is only used in 90 files. And dev_log() doesn't exist. > > So drm_info() would arguably make the most sense. > > dev_printk is the underlying mechanism, dev_log() is a curry function > calling dev_printk with some parameters already provided. Ugh, sorry, I misread the code. You're right, drm_printk() would seem more logical. Thanks, Lukas
[Bug 97260] [bisected] R9 290 low performance in Linux 4.7
https://bugs.freedesktop.org/show_bug.cgi?id=97260 Kai changed: What|Removed |Added Keywords||bisected CC||michel at daenzer.net Summary|R9 290 low performance in |[bisected] R9 290 low |Linux 4.7 |performance in Linux 4.7 --- Comment #12 from Kai --- Ok, after 14 steps of bisection I identified the first bad commit as: c63dd758589b1f7e8398841d1f443f06ebfbcefc is the first bad commit commit c63dd758589b1f7e8398841d1f443f06ebfbcefc Author: Michel Dänzer Date: Fri Apr 1 18:51:34 2016 +0900 drm/radeon: Support DRM_MODE_PAGE_FLIP_ASYNC When this flag is set, we program the hardware to execute the flip during horizontal blank (i.e. for the next scanline) instead of during vertical blank (i.e. for the next frame). Currently this is only supported on ASICs which have a page flip completion interrupt (>= R600), and only if the use_pflipirq parameter has value 2 (the default). Reviewed-by: Christian König Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher :04 04 2f3d8295e7fa2809a3546a23c64da33311e624b9 6cd9fd9b53df0942efab559295e4c11fc6cc0463 M drivers An additional build of 4.7.0 with c63dd758589b1f7e8398841d1f443f06ebfbcefc reverted maintains the performance level of 4.6.x. Adding Michel to the CC list of this bug, since he authored the offending commit. Let me know, if you need anything else. -- 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/20160812/5f242e5a/attachment.html>
[Bug 97260] [bisected] R9 290 low performance in Linux 4.7
https://bugs.freedesktop.org/show_bug.cgi?id=97260 --- Comment #13 from Kai --- Created attachment 125755 --> https://bugs.freedesktop.org/attachment.cgi?id=125755&action=edit git bisect log output for the bisection run leading to c63dd758589b1f7e8398841d1f443f06ebfbcefc -- 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/20160812/5cf297e2/attachment.html>
[PATCH 11/20] drm: Extract drm_framebuffer.[hc]
On Wed, Aug 10, 2016 at 10:48:20AM -0400, Sean Paul wrote:
> On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter
> wrote:
> >
> > -/**
> > - * drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
> > - * @dev: DRM device whose CRTCs to turn off
> > - *
> > - * Drivers may want to call this on unload to ensure that all displays are
> > - * unlit and the GPU is in a consistent, low power state. Takes modeset
> > locks.
> > - *
> > - * Returns:
> > - * Zero on success, error code on failure.
> > - */
> > -int drm_crtc_force_disable_all(struct drm_device *dev)
> > -{
> > - struct drm_crtc *crtc;
> > - int ret = 0;
> > -
> > - drm_modeset_lock_all(dev);
> > - drm_for_each_crtc(crtc, dev)
> > - if (crtc->enabled) {
> > - ret = drm_crtc_force_disable(crtc);
> > - if (ret)
> > - goto out;
> > - }
> > -out:
> > - drm_modeset_unlock_all(dev);
> > - return ret;
> > -}
> > -EXPORT_SYMBOL(drm_crtc_force_disable_all);
>
>
> I'm not so sure about moving this one. If it's going to be declared in
> drm_crtc.h, it should stay here (with force_disable). Alternatively,
> assuming no one else is using this (didn't check), move it to
> drm_framebuffer and make it a static helper function there (removing
> the declaration from drm_crtc.h).
This shouldn't be moved, accidentally overselected. Will fix.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PATCH 12/20] drm/doc: Update drm_framebuffer docs
On Wed, Aug 10, 2016 at 06:15:56PM +0300, Ville Syrjälä wrote: > On Tue, Aug 09, 2016 at 03:41:23PM +0200, Daniel Vetter wrote: > > - Move the intro section into a DOC comment, and update it slightly. > > - kernel-doc for struct drm_framebuffer! > > > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-kms.rst | 26 +-- > > drivers/gpu/drm/drm_framebuffer.c | 35 +++ > > include/drm/drm_framebuffer.h | 94 > > +-- > > 3 files changed, 118 insertions(+), 37 deletions(-) > > > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > > index 8264a88a8695..d244e03658cc 100644 > > --- a/Documentation/gpu/drm-kms.rst > > +++ b/Documentation/gpu/drm-kms.rst > > @@ -39,30 +39,8 @@ Atomic Mode Setting Function Reference > > Frame Buffer Abstraction > > > > > > -Frame buffers are abstract memory objects that provide a source of > > -pixels to scanout to a CRTC. Applications explicitly request the > > -creation of frame buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls > > -and receive an opaque handle that can be passed to the KMS CRTC control, > > -plane configuration and page flip functions. > > - > > -Frame buffers rely on the underneath memory manager for low-level memory > > -operations. When creating a frame buffer applications pass a memory > > -handle (or a list of memory handles for multi-planar formats) through > > -the ``drm_mode_fb_cmd2`` argument. For drivers using GEM as their > > -userspace buffer management interface this would be a GEM handle. > > -Drivers are however free to use their own backing storage object > > -handles, e.g. vmwgfx directly exposes special TTM handles to userspace > > -and so expects TTM handles in the create ioctl and not GEM handles. > > - > > -The lifetime of a drm framebuffer is controlled with a reference count, > > -drivers can grab additional references with > > -:c:func:`drm_framebuffer_reference()`and drop them again with > > -:c:func:`drm_framebuffer_unreference()`. For driver-private > > -framebuffers for which the last reference is never dropped (e.g. for the > > -fbdev framebuffer when the struct :c:type:`struct drm_framebuffer > > -` is embedded into the fbdev helper struct) > > -drivers can manually clean up a framebuffer at module unload time with > > -:c:func:`drm_framebuffer_unregister_private()`. > > +.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c > > + :doc: overview > > > > Frame Buffer Functions Reference > > > > diff --git a/drivers/gpu/drm/drm_framebuffer.c > > b/drivers/gpu/drm/drm_framebuffer.c > > index c7a8a623b336..f2f4928c7262 100644 > > --- a/drivers/gpu/drm/drm_framebuffer.c > > +++ b/drivers/gpu/drm/drm_framebuffer.c > > @@ -28,6 +28,41 @@ > > #include "drm_crtc_internal.h" > > > > /** > > + * DOC: overview > > + * > > + * Frame buffers are abstract memory objects that provide a source of > > pixels to > > + * scanout to a CRTC. Applications explicitly request the creation of frame > > + * buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls and receive an opaque > > + * handle that can be passed to the KMS CRTC control, plane configuration > > and > > + * page flip functions. > > + * > > + * Frame buffers rely on the underlying memory manager for allocating > > backing > > + * storage. When creating a frame buffer applications pass a memory handle > > + * (or a list of memory handles for multi-planar formats) through the > > + * struct &drm_mode_fb_cmd2 argument. For drivers using GEM as their > > userspace > > + * buffer management interface this would be a GEM handle. Drivers are > > however > > + * free to use their own backing storage object handles, e.g. vmwgfx > > directly > > + * exposes special TTM handles to userspace and so expects TTM handles in > > the > > + * create ioctl and not GEM handles. > > + * > > + * Framebuffers are tracked with struct &drm_framebuffer. They are > > published > > + * using drm_framebuffer_init() - after calling that function userspace > > can use > > + * and access the framebuffer object. The helper function > > + * drm_helper_mode_fill_fb_struct() can be used to pre-fill the required > > + * metadata fields. > > + * > > + * The lifetime of a drm framebuffer is controlled with a reference count, > > + * drivers can grab additional references with drm_framebuffer_reference() > > and > > + * drop them again with drm_framebuffer_unreference(). For driver-private > > + * framebuffers for which the last reference is never dropped (e.g. for the > > + * fbdev framebuffer when the struct struct &drm_framebuffer is embedded > > into > > + * the fbdev helper struct) drivers can manually clean up a framebuffer at > > + * module unload time with drm_framebuffer_unregister_private(). But doing > > this > > + * is not recommended, and it's better to have a normal free-standing > > struct > > + * &drm_framebuffer. > > + */ > > +
[Intel-gfx] [PATCH 14/20] drm: Extract drm_connector.[hc]
On Wed, Aug 10, 2016 at 11:06:07AM -0400, Sean Paul wrote:
> On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter
> wrote:
> > Pulls in quite a lot of connector related structures (cmdline mode,
> > force/status enums, display info), but I think that all makes perfect
> > sense.
> >
> > Also had to move a few more core kms object stuff into drm_modeset.h.
> >
> > And as a first cleanup remove the kerneldoc for the 2 connector IOCTL
> > - DRM core docs are aimed at drivers, no point documenting internal in
> > excruciating detail.
> >
> > v2: And also pull in all the connector property code.
> >
>
> \o/
>
> I picked a few nits below, but nothing functional and nothing that
> wasn't already existing in drm_crtc.c. I twitched at a few other
> really small things while I was reading, so I'll post a follow-on
> cleanup patch for drm_connector. Feel free to disregard my nits below
> and I'll scoop them up later.
I'd like to not change code it code-motion patches. I've added the typo
fix to the drm_connector doc update patch, and will gladly leave the nits
to you in a follow-up.
-Daniel
>
> Sean
>
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/gpu/drm-kms.rst |9 +
> > drivers/gpu/drm/Makefile|2 +-
> > drivers/gpu/drm/drm_connector.c | 1058
> > +
> > drivers/gpu/drm/drm_crtc.c | 1110
> > +--
> > drivers/gpu/drm/drm_crtc_internal.h | 26 +-
> > include/drm/drm_connector.h | 644
> > include/drm/drm_crtc.h | 601 +--
> > include/drm/drm_modes.h | 16 +-
> > include/drm/drm_modeset.h | 36 +-
> > 9 files changed, 1773 insertions(+), 1729 deletions(-)
> > create mode 100644 drivers/gpu/drm/drm_connector.c
> > create mode 100644 include/drm/drm_connector.h
> >
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index d244e03658cc..449acc2517c7 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -110,6 +110,15 @@ Display Modes Function Reference
> > .. kernel-doc:: drivers/gpu/drm/drm_modes.c
> > :export:
> >
> > +Connector Display Sink Abstraction
> > +==
> > +
> > +.. kernel-doc:: include/drm/drm_connector.h
> > + :internal:
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > + :export:
> > +
> > KMS Initialization and Cleanup
> > ==
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index c71ec42ce511..2eff1a33ab63 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -13,7 +13,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
> > drm_trace_points.o drm_global.o drm_prime.o \
> > drm_rect.o drm_vma_manager.o drm_flip_work.o \
> > drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> > - drm_framebuffer.o
> > + drm_framebuffer.o drm_connector.o
> >
> > drm-$(CONFIG_COMPAT) += drm_ioc32.o
> > drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > new file mode 100644
> > index ..99ece6758061
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -0,0 +1,1058 @@
> > +/*
> > + * Copyright (c) 2016 Intel Corporation
> > + *
> > + * Permission to use, copy, modify, distribute, and sell this software and
> > its
> > + * documentation for any purpose is hereby granted without fee, provided
> > that
> > + * the above copyright notice appear in all copies and that both that
> > copyright
> > + * notice and this permission notice appear in supporting documentation,
> > and
> > + * that the name of the copyright holders not be used in advertising or
> > + * publicity pertaining to distribution of the software without specific,
> > + * written prior permission. The copyright holders make no representations
> > + * about the suitability of this software for any purpose. It is provided
> > "as
> > + * is" without express or implied warranty.
> > + *
> > + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> > SOFTWARE,
> > + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> > + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> > + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> > USE,
> > + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> > + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> > PERFORMANCE
> > + * OF THIS SOFTWARE.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include "drm_crtc_internal.h"
> > +#include "drm_internal.h"
> > +
> > +struct drm_conn_prop_enum_list {
> > + int type;
> > + const char *name;
> > +
[PATCH v3 1/2] drm: Introduce DRM_DEV_* log messages
This patch consolidates all the various log functions/macros into
one uber function, drm_printk. It also introduces some new DRM_DEV_*
variants that use dev_printk to print the device name, which helps
delineate multiple devices of the same type.
Signed-off-by: Sean Paul
---
Changes in v2:
- Use dev_printk for the dev variant (Chris Wilson)
Changes in v3:
- Rename drm_log to drm_dev_printk (Chris Wilson)
- Break out drm_printk from drm_dev_printk to reduce
image growth due to passing NULL around (Chris Wilson)
drivers/gpu/drm/drm_drv.c | 25 ++---
include/drm/drmP.h| 140 +++---
2 files changed, 101 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 57ce973..e141ead 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -63,37 +63,46 @@ static struct idr drm_minors_idr;
static struct dentry *drm_debugfs_root;
-void drm_err(const char *format, ...)
+void drm_dev_printk(const struct device *dev, const char *level,
+ unsigned int category, const char *function_name,
+ const char *prefix, const char *format, ...)
{
struct va_format vaf;
va_list args;
- va_start(args, format);
+ if (category != DRM_UT_NONE && !(drm_debug & category))
+ return;
+ va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
- printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
- __builtin_return_address(0), &vaf);
+ dev_printk(level, dev, "[" DRM_NAME ":%s]%s %pV", function_name, prefix,
+ &vaf);
va_end(args);
}
-EXPORT_SYMBOL(drm_err);
+EXPORT_SYMBOL(drm_dev_printk);
-void drm_ut_debug_printk(const char *function_name, const char *format, ...)
+void drm_printk(const char *level, unsigned int category,
+ const char *function_name, const char *prefix,
+ const char *format, ...)
{
struct va_format vaf;
va_list args;
+ if (category != DRM_UT_NONE && !(drm_debug & category))
+ return;
+
va_start(args, format);
vaf.fmt = format;
vaf.va = &args;
- printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
+ printk("%s[" DRM_NAME ":%s]%s %pV", level, function_name, prefix, &vaf);
va_end(args);
}
-EXPORT_SYMBOL(drm_ut_debug_printk);
+EXPORT_SYMBOL(drm_printk);
/*
* DRM Minors
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f8e87fd..94eb138 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -127,6 +127,7 @@ struct dma_buf_attachment;
* run-time by echoing the debug value in its sysfs node:
* # echo 0xf > /sys/module/drm/parameters/debug
*/
+#define DRM_UT_NONE0x00
#define DRM_UT_CORE0x01
#define DRM_UT_DRIVER 0x02
#define DRM_UT_KMS 0x04
@@ -134,11 +135,15 @@ struct dma_buf_attachment;
#define DRM_UT_ATOMIC 0x10
#define DRM_UT_VBL 0x20
-extern __printf(2, 3)
-void drm_ut_debug_printk(const char *function_name,
-const char *format, ...);
-extern __printf(1, 2)
-void drm_err(const char *format, ...);
+extern __printf(6, 7)
+void drm_dev_printk(const struct device *dev, const char *level,
+ unsigned int category, const char *function_name,
+ const char *prefix, const char *format, ...);
+
+extern __printf(5, 6)
+void drm_printk(const char *level, unsigned int category,
+ const char *function_name, const char *prefix,
+ const char *format, ...);
/***/
/** \name DRM template customization defaults */
@@ -169,8 +174,12 @@ void drm_err(const char *format, ...);
* \param fmt printf() like format string.
* \param arg arguments
*/
-#define DRM_ERROR(fmt, ...)\
- drm_err(fmt, ##__VA_ARGS__)
+#define DRM_DEV_ERROR(dev, fmt, ...) \
+ drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
+ fmt, ##__VA_ARGS__)
+#define DRM_ERROR(fmt, ...)\
+ drm_printk(KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*", fmt,\
+ ##__VA_ARGS__)
/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
@@ -178,21 +187,33 @@ void drm_err(const char *format, ...);
* \param fmt printf() like format string.
* \param arg arguments
*/
-#define DRM_ERROR_RATELIMITED(fmt, ...)\
+#define DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) \
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
DEFAULT_RATELIMIT_INTERVAL
[PATCH 01/21] drm/doc: Fix more kerneldoc/sphinx warnings
These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...
Cc: Markus Heiser
Cc: Jonathan Corbet
Cc: linux-doc at vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 4 ++--
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_irq.c | 8 +++
drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
drivers/gpu/drm/i915/i915_vgpu.c| 42 -
drivers/gpu/drm/i915/intel_audio.c | 6 ++---
drivers/gpu/drm/i915/intel_guc_fwif.h | 5 ++--
include/drm/drm_crtc.h | 8 +++
include/drm/drm_gem.h | 4 ++--
9 files changed, 41 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c31298f0bb0e..4cb8f4b49d8b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1272,7 +1272,7 @@ static unsigned int drm_num_planes(struct drm_device *dev)
* @plane: plane object to init
* @possible_crtcs: bitmask of possible CRTCs
* @funcs: callbacks for the new plane
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
* @format_count: number of elements in @formats
* @type: type of plane (overlay, primary, cursor)
* @name: printf style format string for the plane name, or NULL for default
name
@@ -1387,7 +1387,7 @@ static void drm_plane_unregister_all(struct drm_device
*dev)
* @plane: plane object to init
* @possible_crtcs: bitmask of possible CRTCs
* @funcs: callbacks for the new plane
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
* @format_count: number of elements in @formats
* @is_primary: plane type (primary vs overlay)
*
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index aed79d31930c..c0d1066ea419 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2193,7 +2193,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
* @fb_helper: the drm_fb_helper
*
* Scan the connectors attached to the fb_helper and try to put together a
- * setup after *notification of a change in output configuration.
+ * setup after notification of a change in output configuration.
*
* Called at runtime, takes the mode config locks to be able to check/change
the
* modeset configuration. Must be run from process context (which usually means
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9bdce1cb6c5c..10611a936059 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -713,10 +713,10 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
* Negative value on error, failure or if not supported in current
* video mode:
*
- * -EINVAL - Invalid CRTC.
- * -EAGAIN - Temporary unavailable, e.g., called before initial modeset.
- * -ENOTSUPP - Function not supported in current display mode.
- * -EIO - Failed, e.g., due to failed scanout position query.
+ * -EINVALInvalid CRTC.
+ * -EAGAINTemporary unavailable, e.g., called before initial modeset.
+ * -ENOTSUPP Function not supported in current display mode.
+ * -EIO Failed, e.g., due to failed scanout position query.
*
* Returns or'ed positive status flags on success:
*
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 0a02efe978ee..bada17166512 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -137,7 +137,7 @@ static const struct drm_plane_funcs
drm_simple_kms_plane_funcs = {
* @dev: DRM device
* @pipe: simple display pipe object to initialize
* @funcs: callbacks for the display pipe (optional)
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
* @format_count: number of elements in @formats
* @connector: connector to attach and register
*
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 142bac976919..ca2e91259948 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -156,27 +156,27 @@ static int vgt_balloon_space(struct drm_mm *mm,
* host point of view, the graphic address space is partitioned by multiple
* vGPUs in different VMs. ::
*
- *vGPU1 view Host view
- * 0 --> +---+ +---+
- * ^ |###| | vGPU3 |
- * | |###| +---+
- * | |###| | vGPU2 |
- * | +---+ +---+
- *mappable GM| available | ==> | vGPU1 |
- * | +---+ +---+
- *
[PATCH 02/21] drm/doc: Light drm-kms-helper.rst cleanup
- Move the common vtable stuff to the top - Move "Tile Group" to a more appropriate heading level - Throw away the old intro for the crtc helpers (it's entirely stale, e.g. helpers have become modular years ago), and replace it with a general intro about the motivation behind helpers. - Reorder helpers to group them together a bit better, and explain that grouping in the intro. - Make sure the introductory DOC section is always first. v2: - Remove bogus files accidentally added (Sean). - Spelling fixes (Sean). Cc: Sean Paul Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms-helpers.rst | 208 +- Documentation/gpu/drm-uapi.rst| 3 + 2 files changed, 107 insertions(+), 104 deletions(-) diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 0b302fedf1af..34f755bc9133 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -2,38 +2,45 @@ Mode Setting Helper Functions = -The plane, CRTC, encoder and connector functions provided by the drivers -implement the DRM API. They're called by the DRM core and ioctl handlers -to handle device state changes and configuration request. As -implementing those functions often requires logic not specific to -drivers, mid-layer helper functions are available to avoid duplicating -boilerplate code. - -The DRM core contains one mid-layer implementation. The mid-layer -provides implementations of several plane, CRTC, encoder and connector -functions (called from the top of the mid-layer) that pre-process -requests and call lower-level functions provided by the driver (at the -bottom of the mid-layer). For instance, the -:c:func:`drm_crtc_helper_set_config()` function can be used to -fill the :c:type:`struct drm_crtc_funcs ` -set_config field. When called, it will split the set_config operation -in smaller, simpler operations and call the driver to handle them. - -To use the mid-layer, drivers call -:c:func:`drm_crtc_helper_add()`, -:c:func:`drm_encoder_helper_add()` and -:c:func:`drm_connector_helper_add()` functions to install their -mid-layer bottom operations handlers, and fill the :c:type:`struct -drm_crtc_funcs `, :c:type:`struct -drm_encoder_funcs ` and :c:type:`struct -drm_connector_funcs ` structures with -pointers to the mid-layer top API functions. Installing the mid-layer -bottom operation handlers is best done right after registering the -corresponding KMS object. - -The mid-layer is not split between CRTC, encoder and connector -operations. To use it, a driver must provide bottom functions for all of -the three KMS entities. +The DRM subsystem aims for a strong separation between core code and helper +libraries. Core code takes care of general setup and teardown and decoding +userspace requests to kernel internal objects. Everything else is handled by a +large set of helper libraries, which can be combined freely to pick and choose +for each driver what fits, and avoid shared code where special behaviour is +needed. + +This distinction between core code and helpers is especially strong in the +modesetting code, where there's a shared userspace ABI for all drivers. This is +in contrast to the render side, where pretty much everything (with very few +exceptions) can be considered optional helper code. + +There are a few areas these helpers can grouped into: + +* Helpers to implement modesetting. The important ones here are the atomic + helpers. Old drivers still often use the legacy CRTC helpers. They both share + the same set of common helper vtables. For really simple drivers (anything + that would have been a great fit in the deprecated fbdev subsystem) there's + also the simple display pipe helpers. + +* There's a big pile of helpers for handling outputs. First the generic bridge + helpers for handling encoder and transcoder IP blocks. Second the panel helpers + for handling panel-related information and logic. Plus then a big set of + helpers for the various sink standards (DisplayPort, HDMI, MIPI DSI). Finally + there's also generic helpers for handling output probing, and for dealing with + EDIDs. + +* The last group of helpers concerns itself with the frontend side of a display + pipeline: Planes, handling rectangles for visibility checking and scissoring, + flip queues and assorted bits. + +Modeset Helper Reference for Common Vtables +=== + +.. kernel-doc:: include/drm/drm_modeset_helper_vtables.h + :internal: + +.. kernel-doc:: include/drm/drm_modeset_helper_vtables.h + :doc: overview Atomic Modeset Helper Functions Reference = @@ -62,33 +69,27 @@ Atomic State Reset and Initialization .. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c :export: -Modeset Helper Reference for Common Vtables -=== - -.. kernel-doc:: include/drm/drm_modeset_helper
[PATCH 03/21] drm/kms-helpers: Extract drm_modeset_helper.[hc]
While reviewing docs I spotted that we have a few functions that
really just don't fit into their containing helper library section.
Extract them and shovel them all into a new library for random one-off
aux stuff.
v2: Remove wrongly added files for real.
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 9 ++
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_crtc_helper.c | 56 -
drivers/gpu/drm/drm_modeset_helper.c | 153 ++
drivers/gpu/drm/drm_plane_helper.c| 66 ---
include/drm/drm_atomic_helper.h | 2 +
include/drm/drm_crtc_helper.h | 6 +-
include/drm/drm_modeset_helper.h | 36
include/drm/drm_plane_helper.h| 4 +-
9 files changed, 203 insertions(+), 131 deletions(-)
create mode 100644 drivers/gpu/drm/drm_modeset_helper.c
create mode 100644 include/drm/drm_modeset_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 34f755bc9133..59fa3c11efab 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -258,3 +258,12 @@ Tile group
.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
:doc: Tile group
+
+Auxiliary Modeset Helpers
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c
+ :doc: aux kms helpers
+
+.. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c
+ :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0238bf8bc8c3..a5824d926dc9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -24,7 +24,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
- drm_simple_kms_helper.o drm_blend.o
+ drm_simple_kms_helper.o drm_blend.o drm_modeset_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 604d3ef72ffa..5d2cb138eba6 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -75,35 +75,6 @@
*/
/**
- * drm_helper_move_panel_connectors_to_head() - move panels to the front in the
- * connector list
- * @dev: drm device to operate on
- *
- * Some userspace presumes that the first connected connector is the main
- * display, where it's supposed to display e.g. the login screen. For
- * laptops, this should be the main panel. Use this function to sort all
- * (eDP/LVDS) panels to the front of the connector list, instead of
- * painstakingly trying to initialize them in the right order.
- */
-void drm_helper_move_panel_connectors_to_head(struct drm_device *dev)
-{
- struct drm_connector *connector, *tmp;
- struct list_head panel_list;
-
- INIT_LIST_HEAD(&panel_list);
-
- list_for_each_entry_safe(connector, tmp,
-&dev->mode_config.connector_list, head) {
- if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS ||
- connector->connector_type == DRM_MODE_CONNECTOR_eDP)
- list_move_tail(&connector->head, &panel_list);
- }
-
- list_splice(&panel_list, &dev->mode_config.connector_list);
-}
-EXPORT_SYMBOL(drm_helper_move_panel_connectors_to_head);
-
-/**
* drm_helper_encoder_in_use - check if a given encoder is in use
* @encoder: encoder to check
*
@@ -913,33 +884,6 @@ int drm_helper_connector_dpms(struct drm_connector
*connector, int mode)
EXPORT_SYMBOL(drm_helper_connector_dpms);
/**
- * drm_helper_mode_fill_fb_struct - fill out framebuffer metadata
- * @fb: drm_framebuffer object to fill out
- * @mode_cmd: metadata from the userspace fb creation request
- *
- * This helper can be used in a drivers fb_create callback to pre-fill the fb's
- * metadata fields.
- */
-void drm_helper_mode_fill_fb_struct(struct drm_framebuffer *fb,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- int i;
-
- fb->width = mode_cmd->width;
- fb->height = mode_cmd->height;
- for (i = 0; i < 4; i++) {
- fb->pitches[i] = mode_cmd->pitches[i];
- fb->offsets[i] = mode_cmd->offsets[i];
- fb->modifier[i] = mode_cmd->modifier[i];
- }
- drm_fb_get_bpp_depth(mode_cmd->pixel_format, &fb->depth,
- &fb->bits_per_pixel);
- fb->pixel_format = mode_cmd->pixel_format;
- fb->flags = mode_cmd->flags;
-}
-EXPORT_SYMBOL(drm_helper_mode_fill_fb_struct);
-
-/**
* drm_helper_resume_force_mode - force-restore mode setting configuration
* @dev: drm
[PATCH 04/21] drm/doc: Reorg drm-mm.rst
- Readjust headings - we lost one level through the extraction into a separate .rst file. - Merge helper reference sections with the helper documentation - that split was just an artifact of the docbook toolchain sucking at too deep nesting levels. No such problems with sphinx. - Move the cma helpers in with the gem documentation, since they're helpers to implement gem using CMA/dma memory as a backend. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-mm.rst | 58 ++-- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 59f9822fecd0..bca808535dfd 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -26,12 +26,12 @@ TTM, but has no video RAM management capabilities and is thus limited to UMA devices. The Translation Table Manager (TTM) +=== TTM design background and information belongs here. TTM initialization -~~ +-- **Warning** @@ -77,7 +77,7 @@ object, ttm_global_item_ref() is used to create an initial reference count for the TTM, which will call your initialization function. The Graphics Execution Manager (GEM) - + The GEM design approach has resulted in a memory manager that doesn't provide full coverage of all (or even all common) use cases in its @@ -114,7 +114,7 @@ read & write, mapping, and domain ownership transfers are left to driver-specific ioctls. GEM Initialization -~~ +-- Drivers that use GEM must set the DRIVER_GEM bit in the struct :c:type:`struct drm_driver ` driver_features @@ -132,7 +132,7 @@ typically not managed by GEM, and must be initialized separately into its own DRM MM object. GEM Objects Creation - + GEM splits creation of GEM objects and allocation of the memory that backs them in two distinct operations. @@ -173,7 +173,7 @@ a call to :c:func:`drm_gem_private_object_init()` instead of must be managed by drivers. GEM Objects Lifetime - + All GEM objects are reference-counted by the GEM core. References can be acquired and release by :c:func:`calling @@ -196,7 +196,7 @@ resources created by the GEM core, which need to be released with :c:func:`drm_gem_object_release()`. GEM Objects Naming -~~ +-- Communication between userspace and the kernel refers to GEM objects using local handles, global names or, more recently, file descriptors. @@ -245,7 +245,7 @@ Furthermore PRIME also allows cross-device buffer sharing since it is based on dma-bufs. GEM Objects Mapping -~~~ +--- Because mapping operations are fairly heavyweight GEM favours read/write-like access to buffers, implemented through driver-specific @@ -304,7 +304,7 @@ Drivers that want to map the GEM object upfront instead of handling page faults can implement their own mmap file operation handler. Memory Coherency - + When mapped to the device or used in a command buffer, backing pages for an object are flushed to memory and marked write combined so as to be @@ -320,7 +320,7 @@ blocks the client and waits for rendering to complete before performing any necessary flushing operations). Command Execution -~ +- Perhaps the most important GEM function for GPU devices is providing a command execution interface to clients. Client programs construct @@ -348,8 +348,20 @@ GEM Function Reference .. kernel-doc:: include/drm/drm_gem.h :internal: +GEM CMA Helper Functions Reference +-- + +.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c + :doc: cma helpers + +.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c + :export: + +.. kernel-doc:: include/drm/drm_gem_cma_helper.h + :internal: + VMA Offset Manager --- +== .. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c :doc: vma offset manager @@ -361,14 +373,14 @@ VMA Offset Manager :internal: PRIME Buffer Sharing - + PRIME is the cross device buffer sharing framework in drm, originally created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME buffers are dma-buf based file descriptors. Overview and Driver Interface -~ +- Similar to GEM global names, PRIME file descriptors are also used to share buffer objects across processes. They offer additional security: @@ -406,7 +418,7 @@ struct drm_gem_object \*obj, int flags); struct drm_gem_object \* support PRIME. PRIME Helper Functions -~~ +-
[PATCH 05/21] drm/doc: Reorg for drm-kms.rst
- Again adjust headings a bit, and don't mix up the initialization sections with other stuff. - Remove the doc for output polling, that vfunc is now properly documented in the vfunc reference sections. - Move the grab-bag with all the core stuff (i.e. drm_crtc.[hc]) to the front for a more prominent place. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 50 --- 1 file changed, 19 insertions(+), 31 deletions(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 8dfa4b214b96..c92afa82b130 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -2,9 +2,6 @@ Kernel Mode Setting (KMS) = -Mode Setting - - Drivers must initialize the mode setting core by calling :c:func:`drm_mode_config_init()` on the DRM device. The function initializes the :c:type:`struct drm_device ` @@ -18,17 +15,20 @@ be setup by initializing the following fields. - struct drm_mode_config_funcs \*funcs; Mode setting functions. -Display Modes Function Reference - +KMS Data Structures +=== -.. kernel-doc:: include/drm/drm_modes.h +.. kernel-doc:: include/drm/drm_crtc.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_modes.c +KMS API Functions += + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c :export: Atomic Mode Setting Function Reference --- +== .. kernel-doc:: drivers/gpu/drm/drm_atomic.c :export: @@ -37,7 +37,7 @@ Atomic Mode Setting Function Reference :internal: Frame Buffer Abstraction - + Frame buffers are abstract memory objects that provide a source of pixels to scanout to a CRTC. Applications explicitly request the @@ -65,13 +65,13 @@ drivers can manually clean up a framebuffer at module unload time with :c:func:`drm_framebuffer_unregister_private()`. DRM Format Handling +=== .. kernel-doc:: drivers/gpu/drm/drm_fourcc.c :export: Dumb Buffer Objects +=== The KMS API doesn't standardize backing storage object creation and leaves it to driver-specific ioctls. Furthermore actually creating a @@ -114,14 +114,14 @@ Note that dumb objects may not be used for gpu acceleration, as has been attempted on some ARM embedded platforms. Such drivers really must have a hardware-specific ioctl to allocate suitable buffer objects. -Output Polling --- +Display Modes Function Reference + + +.. kernel-doc:: include/drm/drm_modes.h + :internal: -void (\*output_poll_changed)(struct drm_device \*dev); -This operation notifies the driver that the status of one or more -connectors has changed. Drivers that use the fb helper can just call the -:c:func:`drm_fb_helper_hotplug_event()` function to handle this -operation. +.. kernel-doc:: drivers/gpu/drm/drm_modes.c + :export: KMS Initialization and Cleanup == @@ -463,20 +463,8 @@ created for fetching EDID data and performing monitor detection. Once the process is complete, the new connector is registered with sysfs to make its properties available to applications. -KMS API Functions -- - -.. kernel-doc:: drivers/gpu/drm/drm_crtc.c - :export: - -KMS Data Structures - -.. kernel-doc:: include/drm/drm_crtc.h - :internal: - KMS Locking +=== .. kernel-doc:: drivers/gpu/drm/drm_modeset_lock.c :doc: kms locking -- 2.8.1
[PATCH 07/21] drm/hisilicon: Don't set drm_device->platformdev
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus points for implementing abstraction, and then storing the vfunc
in a global variable.
Cc: Xinliang Liu
Cc: Xinwei Kong
Cc: Archit Taneja
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 +-
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 6 ++
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 ++--
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index c3707d47cd89..34c22823e5c2 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -987,9 +987,9 @@ static int ade_dts_parse(struct platform_device *pdev,
struct ade_hw_ctx *ctx)
return 0;
}
-static int ade_drm_init(struct drm_device *dev)
+static int ade_drm_init(struct platform_device *pdev)
{
- struct platform_device *pdev = dev->platformdev;
+ struct drm_device *drm_dev = platform_get_drvdata(dev);
struct ade_data *ade;
struct ade_hw_ctx *ctx;
struct ade_crtc *acrtc;
@@ -1048,9 +1048,9 @@ static int ade_drm_init(struct drm_device *dev)
return 0;
}
-static void ade_drm_cleanup(struct drm_device *dev)
+static void ade_drm_cleanup(struct platform_device *pdev)
{
- struct platform_device *pdev = dev->platformdev;
+ struct drm_device *drm_dev = platform_get_drvdata(dev);
struct ade_data *ade = platform_get_drvdata(pdev);
struct drm_crtc *crtc = &ade->acrtc.base;
@@ -1060,4 +1060,4 @@ static void ade_drm_cleanup(struct drm_device *dev)
const struct kirin_dc_ops ade_dc_ops = {
.init = ade_drm_init,
.cleanup = ade_drm_cleanup
-};
+;
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 1edd9bc80294..a31016af9b61 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -41,7 +41,7 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
#endif
drm_kms_helper_poll_fini(dev);
drm_vblank_cleanup(dev);
- dc_ops->cleanup(dev);
+ dc_ops->cleanup(to_platform_device(dev->dev));
drm_mode_config_cleanup(dev);
devm_kfree(dev->dev, priv);
dev->dev_private = NULL;
@@ -103,7 +103,7 @@ static int kirin_drm_kms_init(struct drm_device *dev)
kirin_drm_mode_config_init(dev);
/* display controller init */
- ret = dc_ops->init(dev);
+ ret = dc_ops->init(to_platform_device(dev));
if (ret)
goto err_mode_config_cleanup;
@@ -210,8 +210,6 @@ static int kirin_drm_bind(struct device *dev)
if (!drm_dev)
return -ENOMEM;
- drm_dev->platformdev = to_platform_device(dev);
-
ret = kirin_drm_kms_init(drm_dev);
if (ret)
goto err_drm_dev_unref;
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 1a07caf8e7f4..a0bb217c4c64 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -15,8 +15,8 @@
/* display controller init/cleanup ops */
struct kirin_dc_ops {
- int (*init)(struct drm_device *dev);
- void (*cleanup)(struct drm_device *dev);
+ int (*init)(struct platform_device *pdev);
+ void (*cleanup)(struct platform_device *pdev);
};
struct kirin_drm_private {
--
2.8.1
[PATCH 06/21] drm/etnaviv: Don't set drm_device->platformdev
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index ffd1b32caa8d..0c00947d15f2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -533,8 +533,6 @@ static int etnaviv_bind(struct device *dev)
if (!drm)
return -ENOMEM;
- drm->platformdev = to_platform_device(dev);
-
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
dev_err(dev, "failed to allocate private data\n");
--
2.8.1
[PATCH 09/21] drm/kms: Nuke dirty_info property
It was added way back together with the dirty_fb ioctl, but neither
generic xfree86-modesetting nor the vmware driver use it. Everyone is
supposed to just unconditionally call the dirtyfb when they do
frontbuffer rendering.
And since unused uabi is bad uabi (there's reasons we require open
source userspace for everything) let's nuke this.
For reference see
commit 884840aa3ce3214259e69557be5b4ce0d781ffa4
Author: Jakob Bornecrantz
Date: Thu Dec 3 23:25:47 2009 +
drm: Add dirty ioctl and property
Cc: Jakob Bornecrantz
Cc: Dave Airlie
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Acked-by: Thomas Hellstrom
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 31 ---
drivers/gpu/drm/udl/udl_connector.c | 3 ---
drivers/gpu/drm/udl/udl_modeset.c| 2 --
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 9 -
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 11 ---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 7 ---
include/drm/drm_crtc.h | 7 ---
7 files changed, 70 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4cb8f4b49d8b..49cdac1f5a3d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -136,12 +136,6 @@ static const struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
-static const struct drm_prop_enum_list drm_dirty_info_enum_list[] = {
- { DRM_MODE_DIRTY_OFF, "Off" },
- { DRM_MODE_DIRTY_ON, "On" },
- { DRM_MODE_DIRTY_ANNOTATE, "Annotate" },
-};
-
struct drm_conn_prop_enum_list {
int type;
const char *name;
@@ -1894,31 +1888,6 @@ int drm_mode_create_aspect_ratio_property(struct
drm_device *dev)
EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
/**
- * drm_mode_create_dirty_property - create dirty property
- * @dev: DRM device
- *
- * Called by a driver the first time it's needed, must be attached to desired
- * connectors.
- */
-int drm_mode_create_dirty_info_property(struct drm_device *dev)
-{
- struct drm_property *dirty_info;
-
- if (dev->mode_config.dirty_info_property)
- return 0;
-
- dirty_info =
- drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
- "dirty",
- drm_dirty_info_enum_list,
- ARRAY_SIZE(drm_dirty_info_enum_list));
- dev->mode_config.dirty_info_property = dirty_info;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
-
-/**
* drm_mode_create_suggested_offset_properties - create suggests offset
properties
* @dev: DRM device
*
diff --git a/drivers/gpu/drm/udl/udl_connector.c
b/drivers/gpu/drm/udl/udl_connector.c
index 4709b54c204c..d2f57c52f7db 100644
--- a/drivers/gpu/drm/udl/udl_connector.c
+++ b/drivers/gpu/drm/udl/udl_connector.c
@@ -150,8 +150,5 @@ int udl_connector_init(struct drm_device *dev, struct
drm_encoder *encoder)
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
- drm_object_attach_property(&connector->base,
- dev->mode_config.dirty_info_property,
- 1);
return 0;
}
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index f92ea9579674..73695127c573 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -441,8 +441,6 @@ int udl_modeset_init(struct drm_device *dev)
dev->mode_config.funcs = &udl_mode_funcs;
- drm_mode_create_dirty_info_property(dev);
-
udl_crtc_init(dev);
encoder = udl_encoder_init(dev);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 63ccd9871ec9..23ec673d5e16 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -377,9 +377,6 @@ static int vmw_ldu_init(struct vmw_private *dev_priv,
unsigned unit)
drm_mode_crtc_set_gamma_size(crtc, 256);
drm_object_attach_property(&connector->base,
- dev->mode_config.dirty_info_property,
- 1);
- drm_object_attach_property(&connector->base,
dev_priv->hotplug_mode_update_property, 1);
drm_object_attach_property(&connector->base,
dev->mode_config.suggested_x_property, 0);
@@ -421,10 +418,6 @@ int vmw_kms_ldu_init_display(struct vmw_private *dev_priv)
if (ret != 0)
goto err_free;
- ret = drm_mode_create_dirty_info_property(dev);
- if (ret != 0)
- goto err_vblank_cleanup;
-
vmw_kms_create_implicit_placement_property(dev_priv, true);
if (dev_priv->capabil
[PATCH 10/21] drm/doc: Include drm_atomic.h
Accidentally the wrong file. Oops. Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index c92afa82b130..3ae4c12aca08 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -33,7 +33,7 @@ Atomic Mode Setting Function Reference .. kernel-doc:: drivers/gpu/drm/drm_atomic.c :export: -.. kernel-doc:: drivers/gpu/drm/drm_atomic.c +.. kernel-doc:: include/drm/drm_atomic.h :internal: Frame Buffer Abstraction -- 2.8.1
[PATCH 08/21] drm/doc: Remove outdated FIXME for the page_flip callback
Since the drm_event cleanup work (as prep for fence support) drivers
don't need to bother themselves any more with this, the drm event core
takes care of that.
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 194eebb2f9d7..410175be4c6a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -547,16 +547,6 @@ struct drm_crtc_funcs {
* counter and timestamp tracking though, e.g. if they have accurate
* timestamp registers in hardware.
*
-* FIXME:
-*
-* Up to that point drivers need to manage events themselves and can use
-* even->base.list freely for that. Specifically they need to ensure
-* that they don't send out page flip (or vblank) events for which the
-* corresponding drm file has been closed already. The drm core
-* unfortunately does not (yet) take care of that. Therefore drivers
-* currently must clean up and release pending events in their
-* ->preclose driver function.
-*
* This callback is optional.
*
* NOTE:
--
2.8.1
[PATCH 12/21] drm/doc: Update drm_framebuffer docs
- Move the intro section into a DOC comment, and update it slightly.
- kernel-doc for struct drm_framebuffer!
v2:
- Copypaste fail (Sean).
- Explain the linear @offsets clearer (Ville).
Cc: Sean Paul
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 26 +-
drivers/gpu/drm/drm_framebuffer.c | 35 +
include/drm/drm_framebuffer.h | 106 +-
3 files changed, 130 insertions(+), 37 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 8264a88a8695..d244e03658cc 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -39,30 +39,8 @@ Atomic Mode Setting Function Reference
Frame Buffer Abstraction
-Frame buffers are abstract memory objects that provide a source of
-pixels to scanout to a CRTC. Applications explicitly request the
-creation of frame buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls
-and receive an opaque handle that can be passed to the KMS CRTC control,
-plane configuration and page flip functions.
-
-Frame buffers rely on the underneath memory manager for low-level memory
-operations. When creating a frame buffer applications pass a memory
-handle (or a list of memory handles for multi-planar formats) through
-the ``drm_mode_fb_cmd2`` argument. For drivers using GEM as their
-userspace buffer management interface this would be a GEM handle.
-Drivers are however free to use their own backing storage object
-handles, e.g. vmwgfx directly exposes special TTM handles to userspace
-and so expects TTM handles in the create ioctl and not GEM handles.
-
-The lifetime of a drm framebuffer is controlled with a reference count,
-drivers can grab additional references with
-:c:func:`drm_framebuffer_reference()`and drop them again with
-:c:func:`drm_framebuffer_unreference()`. For driver-private
-framebuffers for which the last reference is never dropped (e.g. for the
-fbdev framebuffer when the struct :c:type:`struct drm_framebuffer
-` is embedded into the fbdev helper struct)
-drivers can manually clean up a framebuffer at module unload time with
-:c:func:`drm_framebuffer_unregister_private()`.
+.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c
+ :doc: overview
Frame Buffer Functions Reference
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 19478a25ac20..34e3c4acbc8a 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -28,6 +28,41 @@
#include "drm_crtc_internal.h"
/**
+ * DOC: overview
+ *
+ * Frame buffers are abstract memory objects that provide a source of pixels to
+ * scanout to a CRTC. Applications explicitly request the creation of frame
+ * buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls and receive an opaque
+ * handle that can be passed to the KMS CRTC control, plane configuration and
+ * page flip functions.
+ *
+ * Frame buffers rely on the underlying memory manager for allocating backing
+ * storage. When creating a frame buffer applications pass a memory handle
+ * (or a list of memory handles for multi-planar formats) through the
+ * struct &drm_mode_fb_cmd2 argument. For drivers using GEM as their userspace
+ * buffer management interface this would be a GEM handle. Drivers are however
+ * free to use their own backing storage object handles, e.g. vmwgfx directly
+ * exposes special TTM handles to userspace and so expects TTM handles in the
+ * create ioctl and not GEM handles.
+ *
+ * Framebuffers are tracked with struct &drm_framebuffer. They are published
+ * using drm_framebuffer_init() - after calling that function userspace can use
+ * and access the framebuffer object. The helper function
+ * drm_helper_mode_fill_fb_struct() can be used to pre-fill the required
+ * metadata fields.
+ *
+ * The lifetime of a drm framebuffer is controlled with a reference count,
+ * drivers can grab additional references with drm_framebuffer_reference() and
+ * drop them again with drm_framebuffer_unreference(). For driver-private
+ * framebuffers for which the last reference is never dropped (e.g. for the
+ * fbdev framebuffer when the struct struct &drm_framebuffer is embedded into
+ * the fbdev helper struct) drivers can manually clean up a framebuffer at
+ * module unload time with drm_framebuffer_unregister_private(). But doing this
+ * is not recommended, and it's better to have a normal free-standing struct
+ * &drm_framebuffer.
+ */
+
+/**
* drm_mode_addfb - add an FB to the graphics configuration
* @dev: drm device for the ioctl
* @data: data pointer for the ioctl
diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
index 46abdace8fa5..50deb40d3bfd 100644
--- a/include/drm/drm_framebuffer.h
+++ b/include/drm/drm_framebuffer.h
@@ -92,37 +92,117 @@ struct drm_framebuffer_funcs {
unsigned num_clips);
};
+/**
+ * struct drm_frame
[PATCH 13/21] drm: Export drm_property_replace_global_blob
It's really part of the core blob interface, and the drm_connector.c
extraction needs it too.
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 13 +++--
include/drm/drm_crtc.h | 6 ++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index daa1e54134ba..1f79f629de52 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3754,12 +3754,12 @@ EXPORT_SYMBOL(drm_property_lookup_blob);
* a completely atomic update. The access to path_blob_ptr is protected by the
* caller holding a lock on the connector.
*/
-static int drm_property_replace_global_blob(struct drm_device *dev,
-struct drm_property_blob **replace,
-size_t length,
-const void *data,
-struct drm_mode_object
*obj_holds_id,
-struct drm_property *prop_holds_id)
+int drm_property_replace_global_blob(struct drm_device *dev,
+struct drm_property_blob **replace,
+size_t length,
+const void *data,
+struct drm_mode_object *obj_holds_id,
+struct drm_property *prop_holds_id)
{
struct drm_property_blob *new_blob = NULL;
struct drm_property_blob *old_blob = NULL;
@@ -3798,6 +3798,7 @@ err_created:
drm_property_unreference_blob(new_blob);
return ret;
}
+EXPORT_SYMBOL(drm_property_replace_global_blob);
/**
* drm_mode_getblob_ioctl - get the contents of a blob property value
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 0119161cad57..f4d041800551 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2808,6 +2808,12 @@ struct drm_property_blob
*drm_property_create_blob(struct drm_device *dev,
const void *data);
struct drm_property_blob *drm_property_lookup_blob(struct drm_device *dev,
uint32_t id);
+int drm_property_replace_global_blob(struct drm_device *dev,
+struct drm_property_blob **replace,
+size_t length,
+const void *data,
+struct drm_mode_object *obj_holds_id,
+struct drm_property *prop_holds_id);
struct drm_property_blob *drm_property_reference_blob(struct drm_property_blob
*blob);
void drm_property_unreference_blob(struct drm_property_blob *blob);
extern void drm_property_destroy(struct drm_device *dev, struct drm_property
*property);
--
2.8.1
[PATCH 11/21] drm: Extract drm_framebuffer.[hc]
Also start with drm_modeset.h with the core bits, since we need
to untangle this mess somehow. That allows us to move the drm_modes.h
include to the right spot, except for the temporary connector status
enum. That will get fixed as soon as drm_connector.h exists.
v2: Rebase.
v3: Move drm_crtc_force_disable_all back again, that wasn't meant to
be moved (Sean).
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 9 +
drivers/gpu/drm/Makefile| 3 +-
drivers/gpu/drm/drm_crtc.c | 804 +---
drivers/gpu/drm/drm_crtc_internal.h | 40 +-
drivers/gpu/drm/drm_framebuffer.c | 799 +++
include/drm/drm_crtc.h | 162 +---
include/drm/drm_framebuffer.h | 170
include/drm/drm_modes.h | 2 +
include/drm/drm_modeset.h | 50 +++
9 files changed, 1078 insertions(+), 961 deletions(-)
create mode 100644 drivers/gpu/drm/drm_framebuffer.c
create mode 100644 include/drm/drm_framebuffer.h
create mode 100644 include/drm/drm_modeset.h
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 3ae4c12aca08..8264a88a8695 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -64,6 +64,15 @@ fbdev framebuffer when the struct :c:type:`struct
drm_framebuffer
drivers can manually clean up a framebuffer at module unload time with
:c:func:`drm_framebuffer_unregister_private()`.
+Frame Buffer Functions Reference
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c
+ :export:
+
+.. kernel-doc:: include/drm/drm_framebuffer.h
+ :internal:
+
DRM Format Handling
===
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a5824d926dc9..c71ec42ce511 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,8 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o drm_atomic.o drm_bridge.o
+ drm_modeset_lock.o drm_atomic.o drm_bridge.o \
+ drm_framebuffer.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 49cdac1f5a3d..daa1e54134ba 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,15 +40,11 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
-static struct drm_framebuffer *
-internal_framebuffer_create(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *r,
- struct drm_file *file_priv);
-
/* Avoid boilerplate. I'm tired of typing. */
#define DRM_ENUM_NAME_FN(fnname, list) \
const char *fnname(int val) \
@@ -238,11 +234,11 @@ EXPORT_SYMBOL(drm_get_subpixel_order_name);
* Internal function to assign a slot in the object idr and optionally
* register the object into the idr.
*/
-static int drm_mode_object_get_reg(struct drm_device *dev,
- struct drm_mode_object *obj,
- uint32_t obj_type,
- bool register_obj,
- void (*obj_free_cb)(struct kref *kref))
+int drm_mode_object_get_reg(struct drm_device *dev,
+ struct drm_mode_object *obj,
+ uint32_t obj_type,
+ bool register_obj,
+ void (*obj_free_cb)(struct kref *kref))
{
int ret;
@@ -285,8 +281,8 @@ int drm_mode_object_get(struct drm_device *dev,
return drm_mode_object_get_reg(dev, obj, obj_type, true, NULL);
}
-static void drm_mode_object_register(struct drm_device *dev,
-struct drm_mode_object *obj)
+void drm_mode_object_register(struct drm_device *dev,
+ struct drm_mode_object *obj)
{
mutex_lock(&dev->mode_config.idr_mutex);
idr_replace(&dev->mode_config.crtc_idr, obj, obj->id);
@@ -315,8 +311,8 @@ void drm_mode_object_unregister(struct drm_device *dev,
mutex_unlock(&dev->mode_config.idr_mutex);
}
-static struct drm_mode_object *_object_find(struct drm_device *dev,
- uint32_t id, uint32_t type)
+struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev,
+ uint32_t id, uint32_t type)
{
struct drm_mode_object *obj = NULL;
@@ -351,7 +347,7 @@ struct drm_mode_object *drm_mode_object_find(struct
drm_device *dev,
{
struct drm_mode_object *obj = NULL;
- obj = _obj
[PATCH 15/21] drm/doc: Include new drm_blend.c
There's not much point in kerneldoc if it's not included:
- It won't show up in the pretty html pages.
- The comments itself won't get parsed, which means 0day won't pick up
changes, resulting in stale docs fast.
Also, uapi really should be core, not helpers, so move drm_blend.c to
that. That also means that the zpos normilize function loses it's
helper status (and we might as well call it always). For that,
EXPORT_SYMBOL. Just spotted while integrating docs and noticing that
one was missing.
With sphinx there's really no excuse any more to not build the docs
and make sure it's all nice!
$ make DOCBOOKS="" htmldocs
Cc: Marek Szyprowski
Cc: Benjamin Gaignard
Cc: Laurent Pinchart
Cc: Ville Syrjälä
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/Makefile| 4 ++--
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_blend.c | 8
drivers/gpu/drm/drm_crtc_internal.h | 4 ++--
5 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 449acc2517c7..6e7ab57924f0 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -559,6 +559,12 @@ connector and plane objects by calling the
pointer to the target object, a pointer to the previously created
property and an initial instance value.
+Blending and Z-Position properties
+--
+
+.. kernel-doc:: drivers/gpu/drm/drm_blend.c
+ :export:
+
Existing KMS Properties
---
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2eff1a33ab63..193ff2d09479 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,7 +13,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
- drm_framebuffer.o drm_connector.o
+ drm_framebuffer.o drm_connector.o drm_blend.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
@@ -25,7 +25,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
- drm_simple_kms_helper.o drm_blend.o drm_modeset_helper.o
+ drm_simple_kms_helper.o drm_modeset_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f59e8c00624f..4d4b0fa7384c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -594,7 +594,7 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;
- ret = drm_atomic_helper_normalize_zpos(dev, state);
+ ret = drm_atomic_normalize_zpos(dev, state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index f3c0942bd756..0813b7e021be 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -193,8 +193,7 @@ done:
}
/**
- * drm_atomic_helper_normalize_zpos - calculate normalized zpos values for all
- * crtcs
+ * drm_atomic_normalize_zpos - calculate normalized zpos values for all crtcs
* @dev: DRM device
* @state: atomic state of DRM device
*
@@ -205,8 +204,8 @@ done:
* RETURNS
* Zero for success or -errno
*/
-int drm_atomic_helper_normalize_zpos(struct drm_device *dev,
-struct drm_atomic_state *state)
+int drm_atomic_normalize_zpos(struct drm_device *dev,
+ struct drm_atomic_state *state)
{
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
@@ -236,3 +235,4 @@ int drm_atomic_helper_normalize_zpos(struct drm_device *dev,
}
return 0;
}
+EXPORT_SYMBOL(drm_atomic_normalize_zpos);
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 7725d0fa7877..97b00312a3cf 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -161,5 +161,5 @@ int drm_modeset_register_all(struct drm_device *dev);
void drm_modeset_unregister_all(struct drm_device *dev);
/* drm_blend.c */
-int drm_atomic_helper_normalize_zpos(struct drm_device *dev,
-struct drm_atomic_state *state);
+int drm_atomic_normalize_zpos(struct drm_device *dev,
+ struct drm_atomic_state *state);
--
2.8.1
[PATCH 16/21] drm: Don't export dp-aux devnode functions
They're only used internally within the dp helpers. Also nuke the
kerneldoc (we only document the driver interface in the drm shared
functions). And move the header file from the public include/
directory to the source files into drm_crtc_helper_internal.h, similar
to how we already have drm_crtc_internal.h.
While at it also move drm_fb_helper_modinit since that belongs in
there, too.
I noticed this all since I spotted kerneldoc which wasn't pulled into
the rst templates.
v2: Update Copyright date.
Cc: Sean Paul
Cc: Rafael Antognolli
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper_internal.h | 58
drivers/gpu/drm/drm_dp_aux_dev.c | 19 ++---
drivers/gpu/drm/drm_dp_helper.c| 3 +-
drivers/gpu/drm/drm_kms_helper_common.c| 3 +-
include/drm/drm_dp_aux_dev.h | 62 --
include/drm/drm_fb_helper.h| 1 -
6 files changed, 65 insertions(+), 81 deletions(-)
create mode 100644 drivers/gpu/drm/drm_crtc_helper_internal.h
delete mode 100644 include/drm/drm_dp_aux_dev.h
diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
b/drivers/gpu/drm/drm_crtc_helper_internal.h
new file mode 100644
index ..4e6b57ae7188
--- /dev/null
+++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * This header file contains mode setting related functions and definitions
+ * which are only used within the drm kms helper module as internal
+ * implementation details and are not exported to drivers.
+ */
+
+#include
+
+/* drm_fb_helper.c */
+int drm_fb_helper_modinit(void);
+
+/* drm_dp_aux_dev.c */
+#ifdef CONFIG_DRM_DP_AUX_CHARDEV
+int drm_dp_aux_dev_init(void);
+void drm_dp_aux_dev_exit(void);
+int drm_dp_aux_register_devnode(struct drm_dp_aux *aux);
+void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux);
+#else
+static inline int drm_dp_aux_dev_init(void)
+{
+ return 0;
+}
+
+static inline void drm_dp_aux_dev_exit(void)
+{
+}
+
+static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
+{
+ return 0;
+}
+
+static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
+{
+}
+#endif
diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 734f86a345f6..ec1ed94b2390 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -36,6 +36,8 @@
#include
#include
+#include "drm_crtc_helper_internal.h"
+
struct drm_dp_aux_dev {
unsigned index;
struct drm_dp_aux *aux;
@@ -283,12 +285,7 @@ static int auxdev_wait_atomic_t(atomic_t *p)
schedule();
return 0;
}
-/**
- * drm_dp_aux_unregister_devnode() - unregister a devnode for this aux channel
- * @aux: DisplayPort AUX channel
- *
- * Returns 0 on success or a negative error code on failure.
- */
+
void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
{
struct drm_dp_aux_dev *aux_dev;
@@ -314,14 +311,7 @@ void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
DRM_DEBUG("drm_dp_aux_dev: aux [%s] unregistering\n", aux->name);
kref_put(&aux_dev->refcount, release_drm_dp_aux_dev);
}
-EXPORT_SYMBOL(drm_dp_aux_unregister_devnode);
-/**
- * drm_dp_aux_register_devnode() - register a devnode for this aux channel
- * @aux: DisplayPort AUX channel
- *
- * Returns 0 on success or a negative error code on failure.
- */
int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
{
struct drm_dp_aux_dev *aux_dev;
@@ -347,7 +337,6 @@ error:
drm_dp_aux_unregister_devnode(aux);
return res;
}
-EXPORT_SYMBOL(drm_dp_aux_register_devnode);
int drm_dp_aux_dev_init(void)
{
@@ -369,11 +358,9 @@ out:
class_destroy(drm_dp_aux_dev_class);
return res;
}
-EXPORT_SYMBOL(drm_dp_aux_dev_init);
void drm_dp_aux_dev_exit(
[PATCH 14/21] drm: Extract drm_connector.[hc]
Pulls in quite a lot of connector related structures (cmdline mode,
force/status enums, display info), but I think that all makes perfect
sense.
Also had to move a few more core kms object stuff into drm_modeset.h.
And as a first cleanup remove the kerneldoc for the 2 connector IOCTL
- DRM core docs are aimed at drivers, no point documenting internal in
excruciating detail.
v2: And also pull in all the connector property code.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst |9 +
drivers/gpu/drm/Makefile|2 +-
drivers/gpu/drm/drm_connector.c | 1058 +
drivers/gpu/drm/drm_crtc.c | 1110 +--
drivers/gpu/drm/drm_crtc_internal.h | 26 +-
include/drm/drm_connector.h | 644
include/drm/drm_crtc.h | 601 +--
include/drm/drm_modes.h | 16 +-
include/drm/drm_modeset.h | 36 +-
9 files changed, 1773 insertions(+), 1729 deletions(-)
create mode 100644 drivers/gpu/drm/drm_connector.c
create mode 100644 include/drm/drm_connector.h
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index d244e03658cc..449acc2517c7 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -110,6 +110,15 @@ Display Modes Function Reference
.. kernel-doc:: drivers/gpu/drm/drm_modes.c
:export:
+Connector Display Sink Abstraction
+==
+
+.. kernel-doc:: include/drm/drm_connector.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+ :export:
+
KMS Initialization and Cleanup
==
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index c71ec42ce511..2eff1a33ab63 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -13,7 +13,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
- drm_framebuffer.o
+ drm_framebuffer.o drm_connector.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
new file mode 100644
index ..99ece6758061
--- /dev/null
+++ b/drivers/gpu/drm/drm_connector.c
@@ -0,0 +1,1058 @@
+/*
+ * Copyright (c) 2016 Intel Corporation
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+#include
+#include
+#include
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
+
+struct drm_conn_prop_enum_list {
+ int type;
+ const char *name;
+ struct ida ida;
+};
+
+/*
+ * Connector and encoder types.
+ */
+static struct drm_conn_prop_enum_list drm_connector_enum_list[] = {
+ { DRM_MODE_CONNECTOR_Unknown, "Unknown" },
+ { DRM_MODE_CONNECTOR_VGA, "VGA" },
+ { DRM_MODE_CONNECTOR_DVII, "DVI-I" },
+ { DRM_MODE_CONNECTOR_DVID, "DVI-D" },
+ { DRM_MODE_CONNECTOR_DVIA, "DVI-A" },
+ { DRM_MODE_CONNECTOR_Composite, "Composite" },
+ { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO" },
+ { DRM_MODE_CONNECTOR_LVDS, "LVDS" },
+ { DRM_MODE_CONNECTOR_Component, "Component" },
+ { DRM_MODE_CONNECTOR_9PinDIN, "DIN" },
+ { DRM_MODE_CONNECTOR_DisplayPort, "DP" },
+ { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A" },
+ { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
+ { DRM_MODE_CONNECTOR_TV, "TV" },
+ { DRM_MODE_CONNECTOR_eDP, "eDP" },
+ { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
+ { DRM_MODE_CONNECTOR_DSI, "DSI" },
+ { DRM_MODE_CONNECTOR_DPI, "DPI" },
+};
+
+void drm_connector_ida_init(void)
+{
+ int i;
+
+ for (i = 0; i < ARRA
[PATCH 17/21] drm: Update connector documentation
- Shuffle docs from drm-kms.rst into the structure docs where it makes sense. - Put the remaining bits into a new overview section. One thing I've changed is around probing: Old docs says that you _must_ use the probe helpers, which isn't correct. Helpers are always optional. v2: Review from Sean. Cc: Sean Paul Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 170 ++-- drivers/gpu/drm/drm_connector.c | 33 +++- include/drm/drm_connector.h | 57 +- 3 files changed, 94 insertions(+), 166 deletions(-) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 6e7ab57924f0..fa948b4e029b 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -110,8 +110,14 @@ Display Modes Function Reference .. kernel-doc:: drivers/gpu/drm/drm_modes.c :export: -Connector Display Sink Abstraction -== +Connector Abstraction += + +.. kernel-doc:: drivers/gpu/drm/drm_connector.c + :doc: overview + +Connector Functions Reference +- .. kernel-doc:: include/drm/drm_connector.h :internal: @@ -232,166 +238,6 @@ encoders unattached at initialization time. Applications (or the fbdev compatibility layer when implemented) are responsible for attaching the encoders they want to use to a CRTC. -Connectors (:c:type:`struct drm_connector `) - -A connector is the final destination for pixel data on a device, and -usually connects directly to an external display device like a monitor -or laptop panel. A connector can only be attached to one encoder at a -time. The connector is also the structure where information about the -attached display is kept, so it contains fields for display data, EDID -data, DPMS & connection status, and information about modes supported on -the attached displays. - -Connector Initialization - - -Finally a KMS driver must create, initialize, register and attach at -least one :c:type:`struct drm_connector ` -instance. The instance is created as other KMS objects and initialized -by setting the following fields. - -interlace_allowed -Whether the connector can handle interlaced modes. - -doublescan_allowed -Whether the connector can handle doublescan. - -display_info -Display information is filled from EDID information when a display -is detected. For non hot-pluggable displays such as flat panels in -embedded systems, the driver should initialize the -display_info.width_mm and display_info.height_mm fields with the -physical size of the display. - -polled -Connector polling mode, a combination of - -DRM_CONNECTOR_POLL_HPD -The connector generates hotplug events and doesn't need to be -periodically polled. The CONNECT and DISCONNECT flags must not -be set together with the HPD flag. - -DRM_CONNECTOR_POLL_CONNECT -Periodically poll the connector for connection. - -DRM_CONNECTOR_POLL_DISCONNECT -Periodically poll the connector for disconnection. - -Set to 0 for connectors that don't support connection status -discovery. - -The connector is then registered with a call to -:c:func:`drm_connector_init()` with a pointer to the connector -functions and a connector type, and exposed through sysfs with a call to -:c:func:`drm_connector_register()`. - -Supported connector types are - -- DRM_MODE_CONNECTOR_VGA -- DRM_MODE_CONNECTOR_DVII -- DRM_MODE_CONNECTOR_DVID -- DRM_MODE_CONNECTOR_DVIA -- DRM_MODE_CONNECTOR_Composite -- DRM_MODE_CONNECTOR_SVIDEO -- DRM_MODE_CONNECTOR_LVDS -- DRM_MODE_CONNECTOR_Component -- DRM_MODE_CONNECTOR_9PinDIN -- DRM_MODE_CONNECTOR_DisplayPort -- DRM_MODE_CONNECTOR_HDMIA -- DRM_MODE_CONNECTOR_HDMIB -- DRM_MODE_CONNECTOR_TV -- DRM_MODE_CONNECTOR_eDP -- DRM_MODE_CONNECTOR_VIRTUAL - -Connectors must be attached to an encoder to be used. For devices that -map connectors to encoders 1:1, the connector should be attached at -initialization time with a call to -:c:func:`drm_mode_connector_attach_encoder()`. The driver must -also set the :c:type:`struct drm_connector ` -encoder field to point to the attached encoder. - -Finally, drivers must initialize the connectors state change detection -with a call to :c:func:`drm_kms_helper_poll_init()`. If at least -one connector is pollable but can't generate hotplug interrupts -(indicated by the DRM_CONNECTOR_POLL_CONNECT and -DRM_CONNECTOR_POLL_DISCONNECT connector flags), a delayed work will -automatically be queued to periodically poll for changes. Connectors -that can generate hotplug interrupts must be marked with the -DRM_CONNECTOR_POLL_HPD flag instead, and their interrupt handler must -call :c:func:`drm_helper_hpd_irq_event()`. The function will -queue a delayed work to check the state of all connectors, but no -periodic polling will be done. - -Conne
[PATCH 19/21] drm: document drm_display_info
We seem to have a bit a mess in how to describe the bus formats, with
a multitude of competing ways. Might be best to consolidate it all and
use MEDIA_BUS_FMT_ also for the hdmi color formats and high color
modes.
Also move all the display_info related functions into drm_connector.c
(there's only one) to group it all together. I did decided against
also moving the edid related display info functions, they seem to fit
better in drm_edid.c. Instead sprinkle a few cross references around.
While at that reduce the kerneldoc for static functions, there's not
point in documenting internals with that much detail really.
v2: Fix typo and move misplaced hunk (Sean).
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 34 ++
drivers/gpu/drm/drm_crtc.c | 34 --
drivers/gpu/drm/drm_edid.c | 23 +++
include/drm/drm_connector.h | 63 ++---
include/drm/drm_crtc.h | 4 ---
5 files changed, 97 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 6a0551744d13..26bb78c76481 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -506,6 +506,40 @@ static const struct drm_prop_enum_list
drm_dpms_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
+/**
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @formats: array containing the supported bus formats
+ * @num_formats: the number of entries in the fmts array
+ *
+ * Store the supported bus formats in display info structure.
+ * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
+ * a full list of available formats.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info,
+const u32 *formats,
+unsigned int num_formats)
+{
+ u32 *fmts = NULL;
+
+ if (!formats && num_formats)
+ return -EINVAL;
+
+ if (formats && num_formats) {
+ fmts = kmemdup(formats, sizeof(*formats) * num_formats,
+ GFP_KERNEL);
+ if (!fmts)
+ return -ENOMEM;
+ }
+
+ kfree(info->bus_formats);
+ info->bus_formats = fmts;
+ info->num_bus_formats = num_formats;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
/* Optional connector properties. */
static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_NONE, "None" },
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 07eba82a9998..d228c41b572b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -419,40 +419,6 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
}
EXPORT_SYMBOL(drm_crtc_cleanup);
-/**
- * drm_display_info_set_bus_formats - set the supported bus formats
- * @info: display info to store bus formats in
- * @formats: array containing the supported bus formats
- * @num_formats: the number of entries in the fmts array
- *
- * Store the supported bus formats in display info structure.
- * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
- * a full list of available formats.
- */
-int drm_display_info_set_bus_formats(struct drm_display_info *info,
-const u32 *formats,
-unsigned int num_formats)
-{
- u32 *fmts = NULL;
-
- if (!formats && num_formats)
- return -EINVAL;
-
- if (formats && num_formats) {
- fmts = kmemdup(formats, sizeof(*formats) * num_formats,
- GFP_KERNEL);
- if (!fmts)
- return -ENOMEM;
- }
-
- kfree(info->bus_formats);
- info->bus_formats = fmts;
- info->num_bus_formats = num_formats;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_display_info_set_bus_formats);
-
static int drm_encoder_register_all(struct drm_device *dev)
{
struct drm_encoder *encoder;
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c071bd635160..9b1ec64d579a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3732,14 +3732,7 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
}
EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
-/**
- * drm_assign_hdmi_deep_color_info - detect whether monitor supports
- * hdmi deep color modes and update drm_display_info if so.
- * @edid: monitor EDID information
- * @info: Updated with maximum supported deep color bpc and color format
- *if deep color supported.
- * @connector: DRM connector, used only for debug output
- *
+/*
* Parse the CEA extension according to CEA-861-B.
* Return true if HDMI deep color supported, false if not or unknown.
[PATCH 20/21] vgaarbiter: rst-ifiy and polish kerneldoc
Move the documentation into Documentation/gpu, link it up and pull in
the kernel doc.
No actual text changes except that I did polish the kerneldoc a bit,
especially for vga_client_register().
v2: Remove some rst from vga-switcheroo.rst that I don't understand,
but which seems to be the reason why the new vgaarbiter.rst sometimes
drops out of the sidebar index.
v3: Drop one level of headings and clarify the vgaarb one a bit.
v4: Fix some typos (Sean).
Cc: Jonathan Corbet
Cc: linux-doc at vger.kernel.org
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/vga-switcheroo.rst | 2 -
Documentation/gpu/vgaarbiter.rst | 191 ++
Documentation/vgaarbiter.txt | 192 ---
drivers/gpu/vga/vgaarb.c | 110 +++-
include/linux/vgaarb.h | 128 +++
6 files changed, 316 insertions(+), 308 deletions(-)
create mode 100644 Documentation/gpu/vgaarbiter.rst
delete mode 100644 Documentation/vgaarbiter.txt
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index fcac0fa72056..ba92f45abb76 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -12,3 +12,4 @@ Linux GPU Driver Developer's Guide
drm-uapi
i915
vga-switcheroo
+ vgaarbiter
diff --git a/Documentation/gpu/vga-switcheroo.rst
b/Documentation/gpu/vga-switcheroo.rst
index cbbdb994f1dd..463a74fc40d1 100644
--- a/Documentation/gpu/vga-switcheroo.rst
+++ b/Documentation/gpu/vga-switcheroo.rst
@@ -1,5 +1,3 @@
-.. _vga_switcheroo:
-
==
VGA Switcheroo
==
diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst
new file mode 100644
index ..0b41b051d021
--- /dev/null
+++ b/Documentation/gpu/vgaarbiter.rst
@@ -0,0 +1,191 @@
+===
+VGA Arbiter
+===
+
+Graphic devices are accessed through ranges in I/O or memory space. While most
+modern devices allow relocation of such ranges, some "Legacy" VGA devices
+implemented on PCI will typically have the same "hard-decoded" addresses as
+they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994
+Standard for Boot (Initialization Configuration) Firmware Revision 2.1"
+Section 7, Legacy Devices.
+
+The Resource Access Control (RAC) module inside the X server [0] existed for
+the legacy VGA arbitration task (besides other bus management tasks) when more
+than one legacy device co-exists on the same machine. But the problem happens
+when these devices are trying to be accessed by different userspace clients
+(e.g. two server in parallel). Their address assignments conflict. Moreover,
+ideally, being a userspace application, it is not the role of the X server to
+control bus resources. Therefore an arbitration scheme outside of the X server
+is needed to control the sharing of these resources. This document introduces
+the operation of the VGA arbiter implemented for the Linux kernel.
+
+vgaarb kernel/userspace ABI
+---
+
+The vgaarb is a module of the Linux Kernel. When it is initially loaded, it
+scans all PCI devices and adds the VGA ones inside the arbitration. The
+arbiter then enables/disables the decoding on different devices of the VGA
+legacy instructions. Devices which do not want/need to use the arbiter may
+explicitly tell it by calling vga_set_legacy_decoding().
+
+The kernel exports a char device interface (/dev/vga_arbiter) to the clients,
+which has the following semantics:
+
+open
+Opens a user instance of the arbiter. By default, it's attached to the
+default VGA device of the system.
+
+close
+Close a user instance. Release locks made by the user
+
+read
+Return a string indicating the status of the target like:
+
+",decodes=,owns=,locks= (ic,mc)"
+
+An IO state string is of the form {io,mem,io+mem,none}, mc and
+ic are respectively mem and io lock counts (for debugging/
+diagnostic only). "decodes" indicate what the card currently
+decodes, "owns" indicates what is currently enabled on it, and
+"locks" indicates what is locked by this card. If the card is
+unplugged, we get "invalid" then for card_ID and an -ENODEV
+error is returned for any command until a new card is targeted.
+
+
+write
+Write a command to the arbiter. List of commands:
+
+target
+switch target to card (see below)
+lock
+acquires locks on target ("none" is an invalid io_state)
+trylock
+non-blocking acquire locks on target (returns EBUSY if
+unsuccessful)
+unlock
+release locks on target
+unlock all
+release all locks on target held by this user (not implemented
+yet)
+decodes
+set the legacy decodi
[PATCH 18/21] drm: Remove display_info->min/max_(h|v)max
No one looks at it, only i915/gma500 lvds even bother to fill it
out. I guess a very old plan was to use this for filtering modes,
but that's already done within the edid parser.
v2: Move misplaced hunk to this patch.
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 8
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 5 -
drivers/gpu/drm/gma500/psb_intel_lvds.c | 9 -
drivers/gpu/drm/i915/intel_lvds.c | 11 ---
include/drm/drm_connector.h | 3 ---
5 files changed, 36 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 38dc89083148..ea733ab5b1e0 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -415,14 +415,6 @@ static int cdv_intel_lvds_get_modes(struct drm_connector
*connector)
if (ret)
return ret;
- /* Didn't get an EDID, so
-* Set wide sync ranges so we get all modes
-* handed to valid_mode for checking
-*/
- connector->display_info.min_vfreq = 0;
- connector->display_info.max_vfreq = 200;
- connector->display_info.min_hfreq = 0;
- connector->display_info.max_hfreq = 200;
if (mode_dev->panel_fixed_mode != NULL) {
struct drm_display_mode *mode =
drm_mode_duplicate(dev, mode_dev->panel_fixed_mode);
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 907cb51795c3..acb3848ef1c9 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -335,11 +335,6 @@ static int mdfld_dsi_connector_get_modes(struct
drm_connector *connector)
struct drm_display_mode *dup_mode = NULL;
struct drm_device *dev = connector->dev;
- connector->display_info.min_vfreq = 0;
- connector->display_info.max_vfreq = 200;
- connector->display_info.min_hfreq = 0;
- connector->display_info.max_hfreq = 200;
-
if (fixed_mode) {
dev_dbg(dev->dev, "fixed_mode %dx%d\n",
fixed_mode->hdisplay, fixed_mode->vdisplay);
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index e55733ca46d2..fd7c91254841 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -530,15 +530,6 @@ static int psb_intel_lvds_get_modes(struct drm_connector
*connector)
if (ret)
return ret;
- /* Didn't get an EDID, so
-* Set wide sync ranges so we get all modes
-* handed to valid_mode for checking
-*/
- connector->display_info.min_vfreq = 0;
- connector->display_info.max_vfreq = 200;
- connector->display_info.min_hfreq = 0;
- connector->display_info.max_hfreq = 200;
-
if (mode_dev->panel_fixed_mode != NULL) {
struct drm_display_mode *mode =
drm_mode_duplicate(dev, mode_dev->panel_fixed_mode);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 668eabb0ba1b..52d6ed6f6966 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -1113,17 +1113,6 @@ void intel_lvds_init(struct drm_device *dev)
}
lvds_connector->base.edid = edid;
- if (IS_ERR_OR_NULL(edid)) {
- /* Didn't get an EDID, so
-* Set wide sync ranges so we get all modes
-* handed to valid_mode for checking
-*/
- connector->display_info.min_vfreq = 0;
- connector->display_info.max_vfreq = 200;
- connector->display_info.min_hfreq = 0;
- connector->display_info.max_hfreq = 200;
- }
-
list_for_each_entry(scan, &connector->probed_modes, head) {
if (scan->type & DRM_MODE_TYPE_PREFERRED) {
DRM_DEBUG_KMS("using preferred mode from EDID: ");
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3537b7d8259b..bc88a5575792 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -94,9 +94,6 @@ struct drm_display_info {
unsigned int width_mm;
unsigned int height_mm;
- /* Clock limits FIXME: storage format */
- unsigned int min_vfreq, max_vfreq;
- unsigned int min_hfreq, max_hfreq;
unsigned int pixel_clock;
unsigned int bpc;
--
2.8.1
[PATCH 21/21] drm: Fix kerneldoc in drm_plane_helper.c
Ville ocd'ed the parameter name, but forgot to update the docs!
Fixes: df86af9133b4 ("drm/plane-helper: Add drm_plane_helper_check_state()")
Cc: Sean Paul
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 50b9c1bfc6f6..7899fc1dcdb0 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -199,7 +199,7 @@ EXPORT_SYMBOL(drm_plane_helper_check_state);
* @crtc: owning CRTC of owning plane
* @fb: framebuffer to flip onto plane
* @src: source coordinates in 16.16 fixed point
- * @dest: integer destination coordinates
+ * @dst: integer destination coordinates
* @clip: integer clipping coordinates
* @rotation: plane rotation
* @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
--
2.8.1
[PATCH v3 1/2] drm: Introduce DRM_DEV_* log messages
On Fri, Aug 12, 2016 at 04:29:37PM -0400, Sean Paul wrote:
> This patch consolidates all the various log functions/macros into
> one uber function, drm_printk. It also introduces some new DRM_DEV_*
> variants that use dev_printk to print the device name, which helps
> delineate multiple devices of the same type.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Use dev_printk for the dev variant (Chris Wilson)
>
> Changes in v3:
> - Rename drm_log to drm_dev_printk (Chris Wilson)
> - Break out drm_printk from drm_dev_printk to reduce
> image growth due to passing NULL around (Chris Wilson)
>
> drivers/gpu/drm/drm_drv.c | 25 ++---
> include/drm/drmP.h| 140
> +++---
> 2 files changed, 101 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 57ce973..e141ead 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -63,37 +63,46 @@ static struct idr drm_minors_idr;
>
> static struct dentry *drm_debugfs_root;
>
> -void drm_err(const char *format, ...)
> +void drm_dev_printk(const struct device *dev, const char *level,
> + unsigned int category, const char *function_name,
> + const char *prefix, const char *format, ...)
> {
> struct va_format vaf;
> va_list args;
>
> - va_start(args, format);
> + if (category != DRM_UT_NONE && !(drm_debug & category))
> + return;
>
> + va_start(args, format);
> vaf.fmt = format;
> vaf.va = &args;
>
> - printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
> -__builtin_return_address(0), &vaf);
> + dev_printk(level, dev, "[" DRM_NAME ":%s]%s %pV", function_name, prefix,
> +&vaf);
dev_printk does handle NULL dev, that's a relief!
>
> va_end(args);
> }
> -EXPORT_SYMBOL(drm_err);
> +EXPORT_SYMBOL(drm_dev_printk);
>
> -void drm_ut_debug_printk(const char *function_name, const char *format, ...)
> +void drm_printk(const char *level, unsigned int category,
> + const char *function_name, const char *prefix,
> + const char *format, ...)
> {
> struct va_format vaf;
> va_list args;
>
> + if (category != DRM_UT_NONE && !(drm_debug & category))
> + return;
> +
> va_start(args, format);
> vaf.fmt = format;
> vaf.va = &args;
>
> - printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
> + printk("%s[" DRM_NAME ":%s]%s %pV", level, function_name, prefix, &vaf);
Ok, I just tried to make a common drm_dev_printk_emit() and made a right
mess. A pair of functions is definitely better.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH v2 2/2] drm/mst: A Helper function that returns available link bandwidth
Add a function that returns the available link bandwidth for
MST port so that we can accurately determine whether a new
mode is valid for the link or not.
v2: Put the Signed-off to the end of commit message
Cc: dri-devel at lists.freedesktop.org
Cc: dhinakaran.pandiyan at intel.com
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/drm_dp_mst_topology.c | 12
include/drm/drm_dp_mst_helper.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 04e4571..7a239f6 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -43,6 +43,8 @@ static bool dump_dp_payload_table(struct
drm_dp_mst_topology_mgr *mgr,
char *buf);
static int test_calc_pbn_mode(void);
+int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct
drm_dp_mst_port *port);
+
static void drm_dp_put_port(struct drm_dp_mst_port *port);
static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
@@ -2730,6 +2732,16 @@ static int test_calc_pbn_mode(void)
return 0;
}
+int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct
drm_dp_mst_port *port)
+{
+port = drm_dp_get_validated_port_ref(mgr,port);
+if (port)
+return port->available_pbn;
+
+return -EINVAL;
+}
+EXPORT_SYMBOL(drm_dp_mst_get_avail_pbn);
+
/* we want to kick the TX after we've ack the up/down IRQs. */
static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr)
{
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 0032076..74dc4ab 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -576,6 +576,7 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
*connector, struct drm_dp_
int drm_dp_calc_pbn_mode(int clock, int bpp);
+int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct
drm_dp_mst_port *port);
bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct
drm_dp_mst_port *port, int pbn, int *slots);
--
2.7.4
[PATCH] drm/rockchip: Don't continue trying to enable crtc on failure
If vop_enable fails, don't continue on, it causes system hangs.
Signed-off-by: Sean Paul
---
This patch uses the new DRM_DEV_ERROR logging, so it should be applied on
top of "[PATCH 2/2] drm/rockchip: Use DRM_DEV_ERROR in vop".
Sean
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ec8ad00..d0ffe59 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -428,7 +428,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
spin_unlock_irqrestore(&vop->irq_lock, flags);
}
-static void vop_enable(struct drm_crtc *crtc)
+static int vop_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
int ret;
@@ -436,13 +436,13 @@ static void vop_enable(struct drm_crtc *crtc)
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
- return;
+ goto err_put_pm_runtime;
}
ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
- return;
+ goto err_put_pm_runtime;
}
ret = clk_enable(vop->dclk);
@@ -485,7 +485,7 @@ static void vop_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);
- return;
+ return 0;
err_disable_aclk:
clk_disable(vop->aclk);
@@ -493,6 +493,9 @@ err_disable_dclk:
clk_disable(vop->dclk);
err_disable_hclk:
clk_disable(vop->hclk);
+err_put_pm_runtime:
+ pm_runtime_put_sync(vop->dev);
+ return ret;
}
static void vop_crtc_disable(struct drm_crtc *crtc)
@@ -912,10 +915,16 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
u16 vact_st = adjusted_mode->vtotal - adjusted_mode->vsync_start;
u16 vact_end = vact_st + vdisplay;
uint32_t val;
+ int ret;
WARN_ON(vop->event);
- vop_enable(crtc);
+ ret = vop_enable(crtc);
+ if (ret) {
+ DRM_DEV_ERROR(vop->dev, "Failed to enable vop (%d)\n", ret);
+ return;
+ }
+
/*
* If dclk rate is zero, mean that scanout is stop,
* we don't need wait any more.
--
2.8.0.rc3.226.g39d4020
[PATCH v11 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to /lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The dclk pin_pol of vop must not be invert for DP. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Acked-by: Mark Yao --- Changes in v11: - add best_encoder back, since it required by drm_atomic_helper_check Changes in v10: - remove best_encoder ops - support read sink count from DPCD - control the grf_clk in DP Changes in v9: - do not need reset the phy before power_on - add a orientation information for set_capability - retry to read dpcd in 10 seconds Changes in v8: - optimization the err log Changes in v7: - support firmware standby when no dptx connection - optimization the calculation of tu size and valid symbol Changes in v6: - add a port struct - select SND_SOC_HDMI_CODEC - force reset the phy when hpd detected Changes in v5: - alphabetical order - do not use long, use u32 or u64 - return MODE_CLOCK_HIGH when requested > actual - Optimized Coding Style - add a formula to get better tu size and symbol value. - modify according to Sean Paul's comments - fixed the fw_wait always 0 Changes in v4: - use phy framework to control DP phy - support 2 phys Changes in v3: - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state. - reset spdif before config it - modify the firmware clk to 100Mhz - retry load firmware if fw file is requested too early Changes in v2: - Alphabetic order - remove excess error message - use define clk_rate - check all return value - remove dev_set_name(dp->dev, "cdn-dp"); - use schedule_delayed_work - remove never-called functions - remove some unnecessary () Changes in v1: - use extcon API - use hdmi-codec for the DP Asoc - do not initialize the "ret" - printk a err log when drm_of_encoder_active_endpoint_id - modify the dclk pin_pol to a single line drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/cdn-dp-core.c | 935 +++ drivers/gpu/drm/rockchip/cdn-dp-core.h | 104 +++ drivers/gpu/drm/rockchip/cdn-dp-reg.c | 959 drivers/gpu/drm/rockchip/cdn-dp-reg.h | 482 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 9 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + 9 files changed, 2512 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index d30bdc3..20aaafe 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP for the Analogix Core DP driver. If you want to enable DP on RK3288 based SoC, you should selet this option. +config ROCKCHIP_CDN_DP +tristate "Rockchip cdn DP" +depends on DRM_ROCKCHIP + select SND_SOC_HDMI_CODEC if SND_SOC +help + This selects support for Rockchip SoC specific extensions + for the cdn DP driver. If you want to enable Dp on + RK3399 based SoC, you should select this + option. + config ROCKCHIP_DW_HDMI tristate "Rockchip specific extensions for Synopsys DW HDMI" depends on DRM_ROCKCHIP diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 9746365..6a07809 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c new file mode 100644 index 000..34f9253 --- /dev/null +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -0,0 +1,935 @@ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: Chris Zhong + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distr
[RESEND PATCH v11 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to /lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The dclk pin_pol of vop must not be invert for DP. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Acked-by: Mark Yao --- Changes in v11: - add best_encoder back, since it required by drm_atomic_helper_check Changes in v10: - remove best_encoder ops - support read sink count from DPCD - control the grf_clk in DP Changes in v9: - do not need reset the phy before power_on - add a orientation information for set_capability - retry to read dpcd in 10 seconds Changes in v8: - optimization the err log Changes in v7: - support firmware standby when no dptx connection - optimization the calculation of tu size and valid symbol Changes in v6: - add a port struct - select SND_SOC_HDMI_CODEC - force reset the phy when hpd detected Changes in v5: - alphabetical order - do not use long, use u32 or u64 - return MODE_CLOCK_HIGH when requested > actual - Optimized Coding Style - add a formula to get better tu size and symbol value. - modify according to Sean Paul's comments - fixed the fw_wait always 0 Changes in v4: - use phy framework to control DP phy - support 2 phys Changes in v3: - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state. - reset spdif before config it - modify the firmware clk to 100Mhz - retry load firmware if fw file is requested too early Changes in v2: - Alphabetic order - remove excess error message - use define clk_rate - check all return value - remove dev_set_name(dp->dev, "cdn-dp"); - use schedule_delayed_work - remove never-called functions - remove some unnecessary () Changes in v1: - use extcon API - use hdmi-codec for the DP Asoc - do not initialize the "ret" - printk a err log when drm_of_encoder_active_endpoint_id - modify the dclk pin_pol to a single line drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/cdn-dp-core.c | 935 +++ drivers/gpu/drm/rockchip/cdn-dp-core.h | 104 +++ drivers/gpu/drm/rockchip/cdn-dp-reg.c | 959 drivers/gpu/drm/rockchip/cdn-dp-reg.h | 482 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 9 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + 9 files changed, 2512 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index d30bdc3..20aaafe 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP for the Analogix Core DP driver. If you want to enable DP on RK3288 based SoC, you should selet this option. +config ROCKCHIP_CDN_DP +tristate "Rockchip cdn DP" +depends on DRM_ROCKCHIP + select SND_SOC_HDMI_CODEC if SND_SOC +help + This selects support for Rockchip SoC specific extensions + for the cdn DP driver. If you want to enable Dp on + RK3399 based SoC, you should select this + option. + config ROCKCHIP_DW_HDMI tristate "Rockchip specific extensions for Synopsys DW HDMI" depends on DRM_ROCKCHIP diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 9746365..6a07809 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c new file mode 100644 index 000..34f9253 --- /dev/null +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -0,0 +1,935 @@ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: Chris Zhong + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distr
[PATCH] drm: drop DRIVER_HAVE_IRQ flag for some drivers
On Fri, Aug 12, 2016 at 01:15:37PM +0800, Shawn Guo wrote: > The drm driver feature flag DRIVER_HAVE_IRQ is used to indicates whether > the driver has an IRQ handler managed by the DRM core. Some drivers, > armada, etnaviv, kirin and sti, set this flag without .irq_handler setup > in drm_driver. These drivers manage IRQ handler by themselves and the > flag DRIVER_HAVE_IRQ makes no sense there. It's worth noting that DRIVER_HAVE_IRQ was required prior to: commit 4984979b9b9025a1cb9a9bea089d31a3e01ccff1 Author: Daniel Vetter Date: Wed Aug 28 15:02:37 2013 +0200 drm/irq: simplify irq checks in drm_wait_vblank to have working vblank. As this is no longer the case, this change looks sane. > > Drop the flag for these drivers to avoid confusion. > > Signed-off-by: Shawn Guo > --- > drivers/gpu/drm/armada/armada_drv.c | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +-- For both of these, Acked-by: Russell King -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code
On 08/12/2016 04:15 PM, Russell King wrote: > Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC That's Verkuil :-) BTW, since cec is part of the media subsystem please include linux-media for the next round. Regards, Hans
[PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
On 08/12/2016 04:15 PM, Russell King wrote:
> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
> The TDA9950 contains a command processor which handles retransmissions
> and the low level bus protocol. The driver just has to read and write
> the messages, and handle error conditions.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/i2c/Kconfig | 5 +
> drivers/gpu/drm/i2c/Makefile | 1 +
> drivers/gpu/drm/i2c/tda9950.c | 514
> ++
> include/linux/platform_data/tda9950.h | 15 +
> 4 files changed, 535 insertions(+)
> create mode 100644 drivers/gpu/drm/i2c/tda9950.c
> create mode 100644 include/linux/platform_data/tda9950.h
>
> +static int tda9950_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
> +{
> + struct tda9950_priv *priv = adap->priv;
> + u16 addresses;
> + u8 buf[2];
> +
> + if (addr == CEC_LOG_ADDR_INVALID)
> + addresses = priv->addresses = BIT(15);
I saw this in patch 4/5 as well: why set bit 15? I would expect that this
is just set to 0. And priv->addresses doesn't seem to be used anywhere.
> + else
> + addresses = priv->addresses |= BIT(addr);
> +
> + /* TDA9950 doesn't want address 15 set */
> + addr &= 0x7fff;
> + buf[0] = addresses >> 8;
> + buf[1] = addresses;
> +
> + return tda9950_write_range(priv->client, REG_ACKH, buf, 2);
> +}
> +
> +static int tda9950_cec_adap_enable(struct cec_adapter *adap, bool enable)
> +{
> + struct tda9950_priv *priv = adap->priv;
> +
> + if (!enable) {
> + tda9950_release(priv);
> + return 0;
> + } else {
Nitpick: no need for 'else' here since the 'if' always returns.
> + return tda9950_open(priv);
> + }
> +}
Regards,
Hans
[PATCH RFC 1/5] video: add HDMI state notifier support
On 08/12/2016 04:14 PM, Russell King wrote:
> Add support for HDMI hotplug and EDID notifiers, which is used to convey
> information from HDMI drivers to their CEC and audio counterparts.
>
> Acked-by: Philipp Zabel
I still don't really like the void *, but not enough to block this, so:
Acked-by: Hans Verkuil
Regards,
Hans
> Signed-off-by: Russell King
> ---
> drivers/video/Kconfig | 3 +++
> drivers/video/Makefile| 1 +
> drivers/video/hdmi-notifier.c | 61
> +++
> include/linux/hdmi-notifier.h | 44 +++
> 4 files changed, 109 insertions(+)
> create mode 100644 drivers/video/hdmi-notifier.c
> create mode 100644 include/linux/hdmi-notifier.h
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af999893..1ee7b9f9bb25 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
> config HDMI
> bool
>
> +config HDMI_NOTIFIERS
> + bool
> +
> if VT
> source "drivers/video/console/Kconfig"
> endif
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 9ad3c17d6456..65f564906fb4 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_VGASTATE)+= vgastate.o
> obj-$(CONFIG_HDMI)+= hdmi.o
> +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
>
> obj-$(CONFIG_VT) += console/
> obj-$(CONFIG_LOGO) += logo/
> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> new file mode 100644
> index ..f3b16552b0fe
> --- /dev/null
> +++ b/drivers/video/hdmi-notifier.c
> @@ -0,0 +1,61 @@
> +#include
> +#include
> +#include
> +#include
> +
> +static BLOCKING_NOTIFIER_HEAD(hdmi_notifier);
> +
> +int hdmi_register_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&hdmi_notifier, nb);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_register_notifier);
> +
> +int hdmi_unregister_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(&hdmi_notifier, nb);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_unregister_notifier);
> +
> +void hdmi_event_connect(struct device *dev)
> +{
> + struct hdmi_event_base base;
> +
> + base.source = dev;
> +
> + blocking_notifier_call_chain(&hdmi_notifier, HDMI_CONNECTED, &base);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> +
> +void hdmi_event_disconnect(struct device *dev)
> +{
> + struct hdmi_event_base base;
> +
> + base.source = dev;
> +
> + blocking_notifier_call_chain(&hdmi_notifier, HDMI_DISCONNECTED, &base);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> +
> +void hdmi_event_new_edid(struct device *dev, const void *edid, size_t size)
> +{
> + struct hdmi_event_new_edid new_edid;
> +
> + new_edid.base.source = dev;
> + new_edid.edid = edid;
> + new_edid.size = size;
> +
> + blocking_notifier_call_chain(&hdmi_notifier, HDMI_NEW_EDID, &new_edid);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> +
> +void hdmi_event_new_eld(struct device *dev, const u8 eld[128])
> +{
> + struct hdmi_event_new_eld new_eld;
> +
> + new_eld.base.source = dev;
> + memcpy(new_eld.eld, eld, sizeof(new_eld.eld));
> +
> + blocking_notifier_call_chain(&hdmi_notifier, HDMI_NEW_ELD, &new_eld);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> new file mode 100644
> index ..5fb710e5d68a
> --- /dev/null
> +++ b/include/linux/hdmi-notifier.h
> @@ -0,0 +1,44 @@
> +#ifndef LINUX_HDMI_NOTIFIER_H
> +#define LINUX_HDMI_NOTIFIER_H
> +
> +#include
> +
> +enum {
> + HDMI_CONNECTED,
> + HDMI_DISCONNECTED,
> + HDMI_NEW_EDID,
> + HDMI_NEW_ELD,
> +};
> +
> +struct hdmi_event_base {
> + struct device *source;
> +};
> +
> +struct hdmi_event_new_edid {
> + struct hdmi_event_base base;
> + const void *edid;
> + size_t size;
> +};
> +
> +struct hdmi_event_new_eld {
> + struct hdmi_event_base base;
> + unsigned char eld[128];
> +};
> +
> +union hdmi_event {
> + struct hdmi_event_base base;
> + struct hdmi_event_new_edid edid;
> + struct hdmi_event_new_eld eld;
> +};
> +
> +struct notifier_block;
> +
> +int hdmi_register_notifier(struct notifier_block *nb);
> +int hdmi_unregister_notifier(struct notifier_block *nb);
> +
> +void hdmi_event_connect(struct device *dev);
> +void hdmi_event_disconnect(struct device *dev);
> +void hdmi_event_new_edid(struct device *dev, const void *edid, size_t size);
> +void hdmi_event_new_eld(struct device *dev, const u8 eld[128]);
> +
> +#endif
>
[PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
On 08/12/2016 05:29 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 12, 2016 at 05:16:41PM +0200, Hans Verkuil wrote:
>> On 08/12/2016 04:38 PM, Hans Verkuil wrote:
>>> On 08/12/2016 04:15 PM, Russell King wrote:
Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
The TDA9950 contains a command processor which handles retransmissions
and the low level bus protocol. The driver just has to read and write
the messages, and handle error conditions.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/Kconfig | 5 +
drivers/gpu/drm/i2c/Makefile | 1 +
drivers/gpu/drm/i2c/tda9950.c | 514
++
include/linux/platform_data/tda9950.h | 15 +
4 files changed, 535 insertions(+)
create mode 100644 drivers/gpu/drm/i2c/tda9950.c
create mode 100644 include/linux/platform_data/tda9950.h
>>>
>>>
>>>
+static int tda9950_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
+{
+struct tda9950_priv *priv = adap->priv;
+u16 addresses;
+u8 buf[2];
+
+if (addr == CEC_LOG_ADDR_INVALID)
+addresses = priv->addresses = BIT(15);
>>>
>>> I saw this in patch 4/5 as well: why set bit 15? I would expect that this
>>> is just set to 0. And priv->addresses doesn't seem to be used anywhere.
>>
>> Yeah, you are right, priv->addresses is used. I've been reviewing too many
>> patches today.
>>
>> The whole BIT(15) part remains weird. If log_addr is called with
>> LOG_ADDR_INVALID as argument, then the intention is that no more
>> messages are to be received (unless the hardware is in snooping mode).
>> So there is no need to receive broadcast messages either.
>
> What about hardware where you can't stop it receiving broadcast
> addresses? Should drivers manually check for this in their
> interrupt handler?
>
>> That said, I now realize that if userspace wants to configure the CEC
>> device as 'Unregistered', then adap_log_addr is never called, which
>> would be required if the hardware has to enable support to receive
>> broadcast messages.
>
> I don't see how that could possibly work. The CEC specification
> requires that we receive broadcast addressed messages so that (eg)
> the current source can be tracked. Being present on the bus, and
> participating as an active source requires the reception of
> broadcast messages so that you know when you stop being an active
> source.
>
> Nothing (afaics) enables broadcast address reception in the kernel
> side, nor using cec-ctl in userspace.
There are three possible 'states' of a CEC adapter w.r.t. logical addresses:
1) There is no physical address or no logical addresses have been set
by the application (CEC_ADAP_S_LOG_ADDRS): in that case the device
will not participate on the bus, it doesn't care about receiving messages
let alone replying to them. The only exception is if the device can
snoop messages, that is allowed even if CEC_ADAP_S_LOG_ADDRS is never
called. That is ideal to have a 'neutral' observer of the bus that just
listens but never participates. Not all hardware supports snooping, though.
2) CEC_ADAP_S_LOG_ADDRS is called and the device becomes an 'Unregistered'
device (i.e. it gets logical address 15). In that case it should receive
broadcast messages and be able to transmit messages.
3) CEC_ADAP_S_LOG_ADDRS is called and the device claims one or more logical
addresses in the range 0-14. Then it can receive broadcast and directed
messages, and of course transmit messages.
From the point of view of the hardware state 1 is selected if adap_log_addr
is called with LOG_ADDR_INVALID. Some hardware might still receive broadcast
messages (because they can't turn that off) and those should be filtered out
by the CEC framework. But I think that doesn't happen, which would be a bug.
I'll verify that tomorrow.
State 2 is a problem for hardware that has to enable support to receive
broadcast messages since adap_log_addr is never called with
LOG_ADDR_UNREGISTERED as argument. I missed that, since the hardware I tested
with always accepts broadcast messages. I'll look into this tomorrow as well.
It should be easy to fix.
State 3 works OK.
So for the dw-hdmi cec driver that means that for state 1 you set 'addresses'
to 0, for state 2 you set it to BIT(15) and for state 3 you always
OR with BIT(15). At least, as I understand your hardware.
BTW, if either the tda or dw-hdmi supports snooping mode, then I strongly
recommend supporting that. It's great for debugging.
Regards,
Hans
>
+else
+addresses = priv->addresses |= BIT(addr);
+
+/* TDA9950 doesn't want address 15 set */
+addr &= 0x7fff;
>>
>> Shouldn't this be 'addresses' instead of 'addr'? 'addr' makes no sense here.
>>
>> And if so, then I still don't understand setting BIT(15), since that bit is
>> removed by the &=.
>
> You're right in this case, but
[PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
On Fri, Aug 12, 2016 at 05:53:17PM +0200, Hans Verkuil wrote: > There are three possible 'states' of a CEC adapter w.r.t. logical addresses: > > 1) There is no physical address or no logical addresses have been set > by the application (CEC_ADAP_S_LOG_ADDRS): in that case the device > will not participate on the bus, it doesn't care about receiving messages > let alone replying to them. The only exception is if the device can > snoop messages, that is allowed even if CEC_ADAP_S_LOG_ADDRS is never > called. That is ideal to have a 'neutral' observer of the bus that just > listens but never participates. Not all hardware supports snooping, though. > > 2) CEC_ADAP_S_LOG_ADDRS is called and the device becomes an 'Unregistered' > device (i.e. it gets logical address 15). In that case it should receive > broadcast messages and be able to transmit messages. > > 3) CEC_ADAP_S_LOG_ADDRS is called and the device claims one or more logical > addresses in the range 0-14. Then it can receive broadcast and directed > messages, and of course transmit messages. > > From the point of view of the hardware state 1 is selected if adap_log_addr > is called with LOG_ADDR_INVALID. Some hardware might still receive broadcast > messages (because they can't turn that off) and those should be filtered out > by the CEC framework. But I think that doesn't happen, which would be a bug. > I'll verify that tomorrow. > > State 2 is a problem for hardware that has to enable support to receive > broadcast messages since adap_log_addr is never called with > LOG_ADDR_UNREGISTERED as argument. I missed that, since the hardware I tested > with always accepts broadcast messages. I'll look into this tomorrow as well. > It should be easy to fix. > > State 3 works OK. > > So for the dw-hdmi cec driver that means that for state 1 you set 'addresses' > to 0, for state 2 you set it to BIT(15) and for state 3 you always > OR with BIT(15). At least, as I understand your hardware. Thanks, I think that needs documenting in Documentation/cec.txt. > BTW, if either the tda or dw-hdmi supports snooping mode, then I strongly > recommend supporting that. It's great for debugging. Neither do. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"
On Fri, Aug 12, 2016 at 08:25:43PM +0200, Peter Zijlstra wrote: > On Thu, Aug 11, 2016 at 11:26:47AM -0700, Paul E. McKenney wrote: > > If my upcoming testing of the two changes together pans out, I will > > give you a Tested-by -- I am guessing that you don't want to wait > > until the next merge window for these changes. > > I was planning to stuff them in tip/locking/urgent, so they'd end up in > this release. They seem to work fine for me, so for both: Tested-by: Paul E. McKenney Thanx, Paul
[RESEND PATCH v11 PATCH 0/5] Rockchip Type-C and DisplayPort driver
Sorry, forgot to add the reviewed-by and tested-by tags, so resend Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. The Type-C cable orientation detection and Power Delivery (PD) is accomplished using a PD PHY or a exernal PD chip. The DP controller is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file[0] rockchip/dptx.bin to /lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The DP contoller has register a notification with extcon API, to get the alt mode from PD, the PD driver need call the devm_extcon_dev_allocate to create a extcon device and use extcon_set_state to notify DP controller. And call extcon_set_cable_property to set orientation. About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF. We can reference them in simple-card. This series is based on Mark Yao's branch[1] and Chanwoo Choi's extcon-next branch[2], and the Heiko's clk patch[3]. I test this patches on the rk3399-evb board, with a fusb302 driver, this branch has no rk3399.dtsi, so the patch about dts is not included in this series. >From V9, the Type-C PHY is split into two PHYs: DP and USB3. The PHY will be init, no matter which PHY be power_on. The DP module will enter A2 mode (standby mode) after phy_init, if DP PHY is powered on, the DP module will enter to A0 mode(running mode). Then if DP PHY is powered off, DP module will back to A2 mode. If everything is un-plugged, phy will be deinit. [0] kernel/git/firmware/linux-firmware.git [1] https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23 [2] https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git extcon-next [3] https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git /commit/?h=v4.9-clk/next&id=54479449c801e46ee2b6ba08e2f19cd810f74f94 https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git /commit/?h=v4.8-clk/fixes&id=a3f457d9636b3f5ae4fc6502cb0c95f60f5e342b Changes in v11: - make a clearer emarcation between usb phy and dp phy - make a clearer demarcation between usb phy and dp phy. - split the dp-phy and usb3-phy to 2 child-node - refer dp phy - add best_encoder back, since it required by drm_atomic_helper_check Changes in v10: - remove rockchip,uphy-dp-sel property - do not control dp select and hpd config in phy driver - remove rockchip,uphy-dp-sel property - add pclk_vio_grf clock - remove best_encoder ops - support read sink count from DPCD - control the grf_clk in DP Changes in v9: - change #phy-cells to 1 - the new_mode should be int not u8 - move mutex_lock(&tcphy->lock); to earlier place. in rockchip_usb3_phy_power_off - better mutex lock for phy mode and flip - split the Type-C PHY into two PHYs: USB3 and DP - change #phy-cells to 1 - modify the reference phy = <&tcphy0 0>, <&tcphy1 0>; - do not need reset the phy before power_on - add a orientation information for set_capability - retry to read dpcd in 10 seconds Changes in v8: - set the default cable id to EXTCON_USB_HOST - optimization Error log - optimization the err log Changes in v7: - support new API of extcon - support firmware standby when no dptx connection - optimization the calculation of tu size and valid symbol Changes in v6: - add assigned-clocks and assigned-clock-rates - delete the support of PIN_ASSIGN_A/B - set the default mode to MODE_DFP_USB - disable DP PLL at USB3 only mode - add assigned-clocks and assigned-clock-rates - add power-domains - add a port struct - select SND_SOC_HDMI_CODEC - force reset the phy when hpd detected Changes in v5: - support get property from extcon - remove PIN ASSIGN A/B support - alphabetical order - do not use long, use u32 or u64 - return MODE_CLOCK_HIGH when requested > actual - Optimized Coding Style - add a formula to get better tu size and symbol value. - modify according to Sean Paul's comments - fixed the fw_wait always 0 Changes in v4: - add a #phy-cells node - select EXTCON - use phy framework to control the USB3 and DP function - rename PIN_MAP_ to PIN_ASSIGN_ - add a reset node - support 2 phys - use phy framework to control DP phy - support 2 phys Changes in v3: - use compatible: rockchip,rk3399-typec-phy - use dashes instead of underscores. - remove the phy framework(Kishon Vijay Abraham I) - add parentheses around the macro - use a single space between type and name - add spaces after opening and before closing braces. - use u16 for register value - remove type-c phy header file - CodingStyle optimization - use some cable extcon to get type-c port information -
[PATCH RFC 0/5] CEC drivers for iMX6 and TDA9950
This series adds CEC drivers for the dw-hdmi and TDA9950 devices. dw-hdmi integrates a CEC engine in the same device as the video and audio blocks, and so shares the IO space and IRQ with the main video driver. The TDA9950 is not only a separate CEC device in its own right, but can also be found on the TDA998x family of HDMI encoders as a separate I2C device from the main TDA998x device. The drivers are placed along-side their HDMI encoder drivers to keep the code for these drivers nearby. However, if there's a better location (eg, a CEC drivers subdirectory) then that would probably be a better location for these. Both sets of drivers rely on the hdmi-notifier code, hence why they're part of the same patch series. drivers/gpu/drm/bridge/Kconfig| 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/dw-hdmi-cec.c | 344 drivers/gpu/drm/bridge/dw-hdmi.c | 73 - drivers/gpu/drm/bridge/dw-hdmi.h | 45 --- drivers/gpu/drm/i2c/Kconfig | 5 + drivers/gpu/drm/i2c/Makefile | 1 + drivers/gpu/drm/i2c/tda9950.c | 514 ++ drivers/video/Kconfig | 3 + drivers/video/Makefile| 1 + drivers/video/hdmi-notifier.c | 61 include/linux/hdmi-notifier.h | 44 +++ include/linux/platform_data/dw_hdmi-cec.h | 16 + include/linux/platform_data/tda9950.h | 15 + 14 files changed, 1075 insertions(+), 56 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
The TDA9950 contains a command processor which handles retransmissions
and the low level bus protocol. The driver just has to read and write
the messages, and handle error conditions.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/Kconfig | 5 +
drivers/gpu/drm/i2c/Makefile | 1 +
drivers/gpu/drm/i2c/tda9950.c | 514 ++
include/linux/platform_data/tda9950.h | 15 +
4 files changed, 535 insertions(+)
create mode 100644 drivers/gpu/drm/i2c/tda9950.c
create mode 100644 include/linux/platform_data/tda9950.h
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed63a001..f4af13203993 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -31,4 +31,9 @@ config DRM_I2C_NXP_TDA998X
help
Support for NXP Semiconductors TDA998X HDMI encoders.
+config DRM_I2C_NXP_TDA9950
+ tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
+ depends on MEDIA_CEC
+ select HDMI_NOTIFIERS
+
endmenu
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 2c72eb584ab7..07bed58410e9 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
tda998x-y := tda998x_drv.o
obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
new file mode 100644
index ..2a792067f3b2
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda9950.c
@@ -0,0 +1,514 @@
+/*
+ * TDA9950 Consumer Electronics Control driver
+ *
+ * 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.
+ *
+ * The NXP TDA9950 implements the HDMI Consumer Electronics Control
+ * interface. The host interface is similar to a mailbox: the data
+ * registers starting at REG_CDR0 are written to send a command to the
+ * internal CPU, and replies are read from these registers.
+ *
+ * As the data registers represent a mailbox, they must be accessed
+ * as a single I2C transaction. See the TDA9950 data sheet for details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ REG_CSR = 0x00,
+ CSR_BUSY = BIT(7),
+ CSR_INT = BIT(6),
+ CSR_ERR = BIT(5),
+
+ REG_CER = 0x01,
+
+ REG_CVR = 0x02,
+
+ REG_CCR = 0x03,
+ CCR_RESET = BIT(7),
+ CCR_ON= BIT(6),
+
+ REG_ACKH = 0x04,
+ REG_ACKL = 0x05,
+
+ REG_CCONR = 0x06,
+ CCONR_ENABLE_ERROR = BIT(4),
+
+ REG_CDR0 = 0x07,
+
+ CDR1_REQ = 0x00,
+ CDR1_CNF = 0x01,
+ CDR1_IND = 0x81,
+ CDR1_ERR = 0x82,
+ CDR1_IER = 0x83,
+
+ CDR2_CNF_SUCCESS= 0x00,
+ CDR2_CNF_OFF_STATE = 0x80,
+ CDR2_CNF_BAD_REQ= 0x81,
+ CDR2_CNF_CEC_ACCESS = 0x82,
+ CDR2_CNF_ARB_ERROR = 0x83,
+ CDR2_CNF_BAD_TIMING = 0x84,
+ CDR2_CNF_NACK_ADDR = 0x85,
+ CDR2_CNF_NACK_DATA = 0x86,
+};
+
+struct tda9950_priv {
+ struct i2c_client *client;
+ struct device *hdmi;
+ struct cec_adapter *adap;
+ struct tda9950_glue *glue;
+ u16 addresses;
+ struct cec_msg rx_msg;
+ struct notifier_block nb;
+ bool open;
+};
+
+static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, int
cnt)
+{
+ struct i2c_msg msg;
+ u8 buf[cnt + 1];
+ int ret;
+
+ buf[0] = addr;
+ memcpy(buf + 1, p, cnt);
+
+ msg.addr = client->addr;
+ msg.flags = 0;
+ msg.len = cnt + 1;
+ msg.buf = buf;
+
+ dev_dbg(&client->dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
+
+ ret = i2c_transfer(client->adapter, &msg, 1);
+ if (ret < 0)
+ dev_err(&client->dev, "Error %d writing to cec:0x%x\n", ret,
addr);
+ return ret < 0 ? ret : 0;
+}
+
+static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
+{
+ tda9950_write_range(client, addr, &val, 1);
+}
+
+static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int
cnt)
+{
+ struct i2c_msg msg[2];
+ int ret;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].len = 1;
+ msg[0].buf = &addr;
+ msg[1].addr = client->addr;
+ msg[1].flags = I2C_M_RD;
+ msg[1].len = cnt;
+ msg[1].buf = p;
+
+ ret = i2c_transfer(client->adapter, msg, 2);
+ if (ret < 0)
+ dev_err(&client->dev, "Error %d reading from cec:0x%x\n", ret,
addr);
+
+ dev_dbg(&client->dev, "rd 0x%02x: %*ph\n", addr, cnt, p);
+
+ return ret;
+}
+
+static u8 tda9950_read(struct i2c_client *client, u8 addr)
+{
+ int ret;
+ u8 va
[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code
On Fri, Aug 12, 2016 at 04:25:02PM +0200, Hans Verkuil wrote: > On 08/12/2016 04:15 PM, Russell King wrote: > >Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC > > That's Verkuil :-) Oops, sorry about that. > BTW, since cec is part of the media subsystem please include linux-media > for the next round. I can't guarantee that, I'm quite forgetful. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
On Fri, Aug 12, 2016 at 04:38:04PM +0200, Hans Verkuil wrote:
> On 08/12/2016 04:15 PM, Russell King wrote:
> >Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
> >The TDA9950 contains a command processor which handles retransmissions
> >and the low level bus protocol. The driver just has to read and write
> >the messages, and handle error conditions.
> >
> >Signed-off-by: Russell King
> >---
> > drivers/gpu/drm/i2c/Kconfig | 5 +
> > drivers/gpu/drm/i2c/Makefile | 1 +
> > drivers/gpu/drm/i2c/tda9950.c | 514
> > ++
> > include/linux/platform_data/tda9950.h | 15 +
> > 4 files changed, 535 insertions(+)
> > create mode 100644 drivers/gpu/drm/i2c/tda9950.c
> > create mode 100644 include/linux/platform_data/tda9950.h
> >
>
>
>
> >+static int tda9950_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
> >+{
> >+struct tda9950_priv *priv = adap->priv;
> >+u16 addresses;
> >+u8 buf[2];
> >+
> >+if (addr == CEC_LOG_ADDR_INVALID)
> >+addresses = priv->addresses = BIT(15);
>
> I saw this in patch 4/5 as well: why set bit 15? I would expect that this
> is just set to 0. And priv->addresses doesn't seem to be used anywhere.
It's needed to be set so that the hardware receives messages sent
to the broadcast (15) address.
> >+else
> >+addresses = priv->addresses |= BIT(addr);
For the second point, read this line, paying close attention to the |=.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
On 08/12/2016 04:38 PM, Hans Verkuil wrote:
> On 08/12/2016 04:15 PM, Russell King wrote:
>> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
>> The TDA9950 contains a command processor which handles retransmissions
>> and the low level bus protocol. The driver just has to read and write
>> the messages, and handle error conditions.
>>
>> Signed-off-by: Russell King
>> ---
>> drivers/gpu/drm/i2c/Kconfig | 5 +
>> drivers/gpu/drm/i2c/Makefile | 1 +
>> drivers/gpu/drm/i2c/tda9950.c | 514
>> ++
>> include/linux/platform_data/tda9950.h | 15 +
>> 4 files changed, 535 insertions(+)
>> create mode 100644 drivers/gpu/drm/i2c/tda9950.c
>> create mode 100644 include/linux/platform_data/tda9950.h
>>
>
>
>
>> +static int tda9950_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
>> +{
>> +struct tda9950_priv *priv = adap->priv;
>> +u16 addresses;
>> +u8 buf[2];
>> +
>> +if (addr == CEC_LOG_ADDR_INVALID)
>> +addresses = priv->addresses = BIT(15);
>
> I saw this in patch 4/5 as well: why set bit 15? I would expect that this
> is just set to 0. And priv->addresses doesn't seem to be used anywhere.
Yeah, you are right, priv->addresses is used. I've been reviewing too many
patches today.
The whole BIT(15) part remains weird. If log_addr is called with
LOG_ADDR_INVALID
as argument, then the intention is that no more messages are to be received
(unless
the hardware is in snooping mode). So there is no need to receive broadcast
messages
either.
That said, I now realize that if userspace wants to configure the CEC device as
'Unregistered', then adap_log_addr is never called, which would be required if
the
hardware has to enable support to receive broadcast messages.
In addition cec_received_msg should ignore received messages if log_addr_mask of
struct cec_log_addrs is 0. I think it will just pass on messages right now, and
that's not right.
I will look at this tomorrow when my brain isn't fried and do some more testing
with 'Unregistered' scenarios.
>
>> +else
>> +addresses = priv->addresses |= BIT(addr);
>> +
>> +/* TDA9950 doesn't want address 15 set */
>> +addr &= 0x7fff;
Shouldn't this be 'addresses' instead of 'addr'? 'addr' makes no sense here.
And if so, then I still don't understand setting BIT(15), since that bit is
removed by the &=.
>> +buf[0] = addresses >> 8;
>> +buf[1] = addresses;
>> +
>> +return tda9950_write_range(priv->client, REG_ACKH, buf, 2);
>> +}
>> +
Regards,
Hans
[PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
On Fri, Aug 12, 2016 at 05:16:41PM +0200, Hans Verkuil wrote:
> On 08/12/2016 04:38 PM, Hans Verkuil wrote:
> >On 08/12/2016 04:15 PM, Russell King wrote:
> >>Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
> >>The TDA9950 contains a command processor which handles retransmissions
> >>and the low level bus protocol. The driver just has to read and write
> >>the messages, and handle error conditions.
> >>
> >>Signed-off-by: Russell King
> >>---
> >> drivers/gpu/drm/i2c/Kconfig | 5 +
> >> drivers/gpu/drm/i2c/Makefile | 1 +
> >> drivers/gpu/drm/i2c/tda9950.c | 514
> >> ++
> >> include/linux/platform_data/tda9950.h | 15 +
> >> 4 files changed, 535 insertions(+)
> >> create mode 100644 drivers/gpu/drm/i2c/tda9950.c
> >> create mode 100644 include/linux/platform_data/tda9950.h
> >>
> >
> >
> >
> >>+static int tda9950_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
> >>+{
> >>+struct tda9950_priv *priv = adap->priv;
> >>+u16 addresses;
> >>+u8 buf[2];
> >>+
> >>+if (addr == CEC_LOG_ADDR_INVALID)
> >>+addresses = priv->addresses = BIT(15);
> >
> >I saw this in patch 4/5 as well: why set bit 15? I would expect that this
> >is just set to 0. And priv->addresses doesn't seem to be used anywhere.
>
> Yeah, you are right, priv->addresses is used. I've been reviewing too many
> patches today.
>
> The whole BIT(15) part remains weird. If log_addr is called with
> LOG_ADDR_INVALID as argument, then the intention is that no more
> messages are to be received (unless the hardware is in snooping mode).
> So there is no need to receive broadcast messages either.
What about hardware where you can't stop it receiving broadcast
addresses? Should drivers manually check for this in their
interrupt handler?
> That said, I now realize that if userspace wants to configure the CEC
> device as 'Unregistered', then adap_log_addr is never called, which
> would be required if the hardware has to enable support to receive
> broadcast messages.
I don't see how that could possibly work. The CEC specification
requires that we receive broadcast addressed messages so that (eg)
the current source can be tracked. Being present on the bus, and
participating as an active source requires the reception of
broadcast messages so that you know when you stop being an active
source.
Nothing (afaics) enables broadcast address reception in the kernel
side, nor using cec-ctl in userspace.
> >>+else
> >>+addresses = priv->addresses |= BIT(addr);
> >>+
> >>+/* TDA9950 doesn't want address 15 set */
> >>+addr &= 0x7fff;
>
> Shouldn't this be 'addresses' instead of 'addr'? 'addr' makes no sense here.
>
> And if so, then I still don't understand setting BIT(15), since that bit is
> removed by the &=.
You're right in this case, but for dw-hdmi, bit 15 must be set for
broadcast messages to be received.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
