[PATCH v1] drm/nouveau/clk: avoid potential null-dereference
On Wed, Jan 7, 2015 at 11:32 PM, Vince Hsu wrote: > > On 01/08/2015 10:45 AM, Ilia Mirkin wrote: >> >> On Wed, Jan 7, 2015 at 5:29 PM, Andy Shevchenko >> wrote: >>> >>> We have to check pointer before usage. >>> >>> Reported-by: Andrey Karpov >>> Signed-off-by: Andy Shevchenko >>> --- >>> drivers/gpu/drm/nouveau/core/subdev/clock/base.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c >>> b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c >>> index e51b72d..2e84436 100644 >>> --- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c >>> +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c >>> @@ -322,7 +322,6 @@ nouveau_pstate_new(struct nouveau_clock *clk, int >>> idx) >>> return 0; >>> >>> pstate = kzalloc(sizeof(*pstate), GFP_KERNEL); >>> - cstate = &pstate->base; >> >> What's wrong with this line? If pstate == NULL, &pstate->base == NULL >> as well and we return. > > If pstate == NULL (kzalloc returned NULL), pstate->base triggers a null > pointer > deference error? Where do you see "pstate->base"? I only see "&pstate->base" which merely computes an offset into a structure... No reason to dereference pstate. -ilia
[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart
https://bugs.freedesktop.org/show_bug.cgi?id=88183 Bug ID: 88183 Summary: radeonsi: R9 280X hangs with SuperTuxKart Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: alexandre.f.demers at gmail.com In SuperTuxKart, upon loading the first track of the story mode, the display freezes. The GPU resets but when it comes back everything is messed up and it keeps resetting continuously. I'm using latest kernel 3.19-rc3 with the "drm/radeon: fix VM flush..." patches (also tested without it), latest mesa from git, latest drm from git. I'll see a journald dump outputs something interesting. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/7e222d7e/attachment.html>
回复：[PATCH 0/3] dw_hdmi allmodconfig fixups
An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/1011b21e/attachment-0001.html>
"EDID checksum is invalid"
Linus Torvalds writes: > I'm assuming even the hdmi +5V line is under sw control at least for > power management reasons. Maybe dpms off turns it off, and shouldn't? > My monitor actually says "No HDMI (HML) Cable" when I do "xset dpms > force off". Maybe that's normal, but maybe that's indicative of dpms > turning things a bit *too* off? How about getting a breakout cable so we can actually check the +5V line to see when it turns off? Total Phase makes one, although they only have the DVI ones in stock. A couple of HDMI to DVI converters would let you use this. http://www.totalphase.com/products/video-dvi/ I've even got an i2c protocol sniffer if you want to see what's going on the DDC bus directly. -- -keith -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 810 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/38c256c0/attachment.sig>
[Bug 80584] XCOM: Enemy Unknown incorrect hair rendering
https://bugs.freedesktop.org/show_bug.cgi?id=80584 --- Comment #9 from dex+fdobugzilla at dragonslave.de --- With llvm SVN Rev 225358 and mesa from git ge28f9d0 as of today hair is rendered correctly on R270X :) Can anyone of the other reporters confirm this? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/6b6f9aad/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #55 from Tom Stellard --- I have this working for some simple cases, can you test these mesa and llvm trees together: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=vgpr-spilling-Jan07-2014 http://cgit.freedesktop.org/~tstellar/mesa/log/?h=vgpr-spilling-Jan07-2014 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/99accb31/attachment.html>
[Bug 88170] 32 bits opengl apps crash with latest llvm 3.6 git / mesa git / radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=88170 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Tom Stellard --- Fixed in git by e28f9d0e60468db429e75a27443f7df52da224a2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/d88eb440/attachment.html>
[PATCH v1] drm/nouveau/clk: avoid potential null-dereference
On Wed, Jan 7, 2015 at 5:29 PM, Andy Shevchenko wrote: > We have to check pointer before usage. > > Reported-by: Andrey Karpov > Signed-off-by: Andy Shevchenko > --- > drivers/gpu/drm/nouveau/core/subdev/clock/base.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c > b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c > index e51b72d..2e84436 100644 > --- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c > +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c > @@ -322,7 +322,6 @@ nouveau_pstate_new(struct nouveau_clock *clk, int idx) > return 0; > > pstate = kzalloc(sizeof(*pstate), GFP_KERNEL); > - cstate = &pstate->base; What's wrong with this line? If pstate == NULL, &pstate->base == NULL as well and we return. > if (!pstate) > return -ENOMEM; > > @@ -330,6 +329,9 @@ nouveau_pstate_new(struct nouveau_clock *clk, int idx) > > pstate->pstate = perfE.pstate; > pstate->fanspeed = perfE.fanspeed; > + > + cstate = &pstate->base; > + > cstate->voltage = perfE.voltage; > cstate->domain[nv_clk_src_core] = perfE.core; > cstate->domain[nv_clk_src_shader] = perfE.shader; > -- > 1.8.3.101.g727a46b > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #75 from Alex Deucher --- Pushed a 3.20 wip branch with Oleg's patches plus some minor fixes and support for SI. http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.20-wip -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/401c7458/attachment.html>
"EDID checksum is invalid"
On Wed, Jan 7, 2015 at 6:51 PM, Linus Torvalds wrote: > On Tue, Jan 6, 2015 at 11:32 PM, Daniel Vetter wrote: >> >> Yeah if the edid probe fails userspace will get a hotplug and >> autodisable the output. With a failsafe X session (just a dumb >> terminal) we can avoid that to check that dpms on itself would work or >> whether the edid probe fail here is just indicative of more trouble. >> Also please boot with drm.debug=0xe, repro and grab dmesg, that might >> shed some more light on what's failing. > > Here is an annotated attachment with the dpms off output witj drm.debug=0xe. > > It turns out the real failure case doesn't seem to be when the bad > EDID happens. See my notes interspersed with the dmesg output. Yeah some interesting stuff in there, but no idea why your screen is ragequitting. - The edid fail is indeed transiet. There's a bunch of hpd flip-flop and some screaming (looks like crappy hw booting), but eventually the kernel gets the full edid and mode list when you kick your hdmi screen. But ofc the kernel doesn't do modeset since that's already done. Have you tried whether a force full modeset with xrandr --off/--auto fixes anything? - There's nothing different for the deep-sleep dpms cycle that fails to light up on the sink side - no errors from the modeset and no hpd from the screen. - But there is a difference on what userspace does: Somehow an additionl very fast dpms off/on sneaks in when waking things up. Dunno where that's from, but fickle screens tend to get upset by that. Maybe try with the UXA backend in xorg.conf (which has a slightly different dpms handling): Section "Device" Identifier "igd" Driver "intel" Option "AccelMethod" "UXA" EndSection Otherwise I draw a blank. For the record do you know the old/new bios versions, in case I can get hold of them and get a real changelog? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 0/7] imx-drm: ipuv3-crtc: Implement mode_fixup
Am Donnerstag, den 18.12.2014, 18:00 -0800 schrieb Steve Longerbeam: > This patchset implements ->mode_fixup() in the imx ipuv3-crtc driver, > using a new support function ipu_di_adjust_videomode(). This new > function needs to be subsystem independent, so it accepts a video > mode as a 'struct videomode'. Hence ipu-crtc ->mode_fixup() needs > another support function to convert a drm_display_mode to a videomode > before passing the mode to ipu_di_adjust_videomode() for fixup. > > Also some related code cleanup: 'struct ipu_di_signal_cfg' should > use 'struct videomode' for mode timings. Alright, I have applied the series with s/videomode_from_drm_display_mode/drm_display_mode_to_videomode/ thanks Philipp
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #74 from !evil --- Created attachment 111927 --> https://bugs.freedesktop.org/attachment.cgi?id=111927&action=edit !evil's venture for manual fan speed control I tried to adjust Chernovsky Oleg's code such that it uses the disabled functions in 3.19 rc3. But it didn't work out for me. On my system the 'power_fan_speed' file (which should be named pwm..) is not created. Maybe my setup is broken and the code never gets executed. dmesg does however state: dpm initialized. Anyways, if this would work, I would come up with some dummy automatic fan speed regulator, most probably written in python. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/d97c4f84/attachment.html>
[PATCH v9 3/4] ASoC: tda998x: add a codec to the HDMI transmitter
On Wed, 7 Jan 2015 15:41:38 +
Russell King - ARM Linux wrote:
> On Wed, Jan 07, 2015 at 03:10:47PM +, Andrew Jackson wrote:
> > On 01/07/15 10:51, Jean-Francois Moine wrote:
> > > diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> > > index 22c7ed6..24fc975 100644
> > > --- a/drivers/gpu/drm/i2c/Kconfig
> > > +++ b/drivers/gpu/drm/i2c/Kconfig
> > > @@ -28,6 +28,7 @@ config DRM_I2C_SIL164
> > > config DRM_I2C_NXP_TDA998X
> > > tristate "NXP Semiconductors TDA998X HDMI encoder"
> > > default m if DRM_TILCDC
> > > + select SND_SOC_TDA998X
> >
> > Do you need this since sound/soc/codecs/Kconfig conditionally brings in the
> > CODEC driver?
For SND_SOC_ALL_CODECS only.
> More importantly, it's broken, because it'll cause Kconfig to complain
> if you enable DRM_I2C_NXP_TDA998X, but have ASoC disabled.
>
> Moreover, if you decide you want the sound and ASoC built as a module,
> but want to build in DRM and TDA998x support (so you can get video
> output working on boot before initramfs/rootfs), Kconfig may well
> complain.
select SND_SOC_TDA998X if SND_SOC
should work in all cases.
> > > +static int __init tda998x_codec_init(void)
> > > +{
> > > + return 0;
> > > +}
> > > +static void __exit tda998x_codec_exit(void)
> > > +{
> > > +}
> > > +module_init(tda998x_codec_init);
> > > +module_exit(tda998x_codec_exit);
>
> There's no need for these if they remain as the above. Modules can have
> both init/exit functions, or neither, and they are still unloadable.
> Only modules which provide only an init function get locked in on load.
Thanks.
--
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
[Bug 88170] 32 bits opengl apps crash with latest llvm 3.6 git / mesa git / radeonsi
const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x468735D: UserInterface::parse(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x4687989: UserInterface::parse_vbox(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x46871DA: UserInterface::parse(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x4687DBD: UserInterface::parse_window(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041== ==8041== Conditional jump or move depends on uninitialised value(s) ==8041==at 0x46E272E: WidgetVScroll::setValue(int) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x46E2E6D: WidgetVScroll::WidgetVScroll(Gui*, int, int, int, int) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x46A90C8: WidgetScrollBox::WidgetScrollBox(Gui*, int, int) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x4686EC2: UserInterface::parse_scrollbox(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x4687340: UserInterface::parse(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x4687989: UserInterface::parse_vbox(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x46871DA: UserInterface::parse(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x4688152: UserInterface::parse_tabbox(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x468735D: UserInterface::parse(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x4687989: UserInterface::parse_vbox(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x46871DA: UserInterface::parse(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041==by 0x4687DBD: UserInterface::parse_window(Xml const*, UserInterface::UIWidget*) (in /home/groo/.phoronix-test-suite/installed-tests/pts/unigine-tropics-1.5.3/tropics/bin/libUnigine_x86.so) ==8041== Loading "demos/tropics/locale/unigine.en" dictionary Loading "core/materials/unigine_post.mat" 12 materials 12 shaders 72ms Loading "core/materials/unigine_render.mat" 34 materials 77 shaders 298ms Loading "core/materials/unigine_meshes.mat" 16 materials 9350 shaders 1370ms Loading "core/materials/unigine_terrains.mat" 1 material 293 shaders 61ms Loading "core/materials/unigine_grass.mat" 1 material 81 shaders 126ms Loading "core/materials/unigine_particles.mat" 1 material 43 shaders 97ms Loading "core/materials/unigine_billboards.mat" 1 material 33 shaders 115ms Loading "core/materials/unigine_volumes.mat" 5 materials 29 shaders 184ms Loading "core/materials/unigine_guis.mat" 1 material 24 shaders 42ms Loading "core/materials/unigine_water.mat" 1 material 63 shaders 203ms Loading "core/materials/unigine_skies.mat" 1 material 19 shaders 223ms Loading "core/materials/unigine_decals.mat" 1 material 69 shaders 142ms Loading "core/properties/unigine.prop" 2 properties 51ms Killed -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/b71bb0c9/attachment-0001.html>
"EDID checksum is invalid"
On Wed, Jan 7, 2015 at 6:07 PM, Linus Torvalds wrote: > On Tue, Jan 6, 2015 at 10:21 PM, Robert Morell wrote: >> >> FWIW, I've seen that exact symptom on some monitors when the +5V pin on >> the DVI or HDMI cable from the GPU isn't enabled (or isn't providing >> enough current). Some monitors power the i2c/edid/DDC logic from that >> +5V either exclusively or when in the DPMS off state, and the i2c chip >> will just stop responding after a few cycles if not provided sufficient >> power. > > That makes a ton of sense, especially the "when in DPMS off state" case. > > I'll do the drm.debug=0xe thing, and maybe Daniel can make more sense > of the details. Maybe the i2c driver ends up powering down too soon > (or maybe it needs to power up a bit earlier)? > > This is a bog-standard intel motherboard (DH87RL), but I actually > needed to update the BIOS for it to get it to POST reliably with this > monitor. I was blaming that on the odd 3840x2160 at 30Hz mode, but maybe > it's related to the EDID being finicky wrt i2c power. > > I'm assuming even the hdmi +5V line is under sw control at least for > power management reasons. Maybe dpms off turns it off, and shouldn't? > My monitor actually says "No HDMI (HML) Cable" when I do "xset dpms > force off". Maybe that's normal, but maybe that's indicative of dpms > turning things a bit *too* off? Not sure whether that'd be the same voltage rails, but i915.disable_power_wells=0 disable all the runtime pm we do (which does kick in for dpms off and shut down the entire display block and a bunch more). Maybe we just need to detect that the chip dropped off the bus and retry after 50ms (to give the caps some time to charge). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/msm: Initial add eDP support in msm drm driver (V4)
This change adds a new eDP connector in msm drm driver. With this
change, eDP panel can work with msm platform under drm framework.
V1: Initial change
V2: Address Rob's comments
Use generated header file for register definitions
Change to devm_* APIs
V3: Address Thierry's comments and rebase on top of atomic changes
Remove edp_bridge_mode_fixup
Remove backlight control code and rely on pwm-backlight
Remove continuous splash screen support for now
Change to gpiod_* APIs
V4: Fix kbuild test issue
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/Makefile|6 +
drivers/gpu/drm/msm/edp/edp.c | 208 +
drivers/gpu/drm/msm/edp/edp.h | 84 ++
drivers/gpu/drm/msm/edp/edp_aux.c | 268 ++
drivers/gpu/drm/msm/edp/edp_bridge.c| 124 +++
drivers/gpu/drm/msm/edp/edp_connector.c | 161
drivers/gpu/drm/msm/edp/edp_ctrl.c | 1390 +++
drivers/gpu/drm/msm/edp/edp_phy.c | 106 +++
drivers/gpu/drm/msm/msm_drv.h |6 +
9 files changed, 2353 insertions(+)
create mode 100644 drivers/gpu/drm/msm/edp/edp.c
create mode 100644 drivers/gpu/drm/msm/edp/edp.h
create mode 100644 drivers/gpu/drm/msm/edp/edp_aux.c
create mode 100644 drivers/gpu/drm/msm/edp/edp_bridge.c
create mode 100644 drivers/gpu/drm/msm/edp/edp_connector.c
create mode 100644 drivers/gpu/drm/msm/edp/edp_ctrl.c
create mode 100644 drivers/gpu/drm/msm/edp/edp_phy.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 143d988..e5464a0 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -16,6 +16,12 @@ msm-y := \
hdmi/hdmi_phy_8960.o \
hdmi/hdmi_phy_8x60.o \
hdmi/hdmi_phy_8x74.o \
+ edp/edp.o \
+ edp/edp_aux.o \
+ edp/edp_bridge.o \
+ edp/edp_connector.o \
+ edp/edp_ctrl.o \
+ edp/edp_phy.o \
mdp/mdp_format.o \
mdp/mdp_kms.o \
mdp/mdp4/mdp4_crtc.o \
diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c
new file mode 100644
index 000..5ca2d46
--- /dev/null
+++ b/drivers/gpu/drm/msm/edp/edp.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include "edp.h"
+
+static irqreturn_t edp_irq(int irq, void *dev_id)
+{
+ struct msm_edp *edp = dev_id;
+
+ /* Process eDP irq */
+ return msm_edp_ctrl_irq(edp->ctrl);
+}
+
+static void edp_destroy(struct platform_device *pdev)
+{
+ struct msm_edp *edp = platform_get_drvdata(pdev);
+
+ if (!edp)
+ return;
+
+ if (edp->ctrl) {
+ msm_edp_ctrl_destroy(edp->ctrl);
+ edp->ctrl = NULL;
+ }
+
+ platform_set_drvdata(pdev, NULL);
+}
+
+/* construct eDP at bind/probe time, grab all the resources. */
+static struct msm_edp *edp_init(struct platform_device *pdev)
+{
+ struct msm_edp *edp = NULL;
+ int ret;
+
+ if (!pdev) {
+ pr_err("no eDP device\n");
+ ret = -ENXIO;
+ goto fail;
+ }
+
+ edp = devm_kzalloc(&pdev->dev, sizeof(*edp), GFP_KERNEL);
+ if (!edp) {
+ ret = -ENOMEM;
+ goto fail;
+ }
+ DBG("eDP probed=%p", edp);
+
+ edp->pdev = pdev;
+ platform_set_drvdata(pdev, edp);
+
+ ret = msm_edp_ctrl_init(edp);
+ if (ret)
+ goto fail;
+
+ return edp;
+
+fail:
+ if (edp)
+ edp_destroy(pdev);
+
+ return ERR_PTR(ret);
+}
+
+static int edp_bind(struct device *dev, struct device *master, void *data)
+{
+ struct drm_device *drm = dev_get_drvdata(master);
+ struct msm_drm_private *priv = drm->dev_private;
+ struct msm_edp *edp;
+
+ DBG("");
+ edp = edp_init(to_platform_device(dev));
+ if (IS_ERR(edp))
+ return PTR_ERR(edp);
+ priv->edp = edp;
+
+ return 0;
+}
+
+static void edp_unbind(struct device *dev, struct device *master, void *data)
+{
+ struct drm_device *drm = dev_get_drvdata(master);
+ struct msm_drm_private *priv = drm->dev_private;
+
+ DBG("");
+ if (priv->edp) {
+ edp_destroy(to_platform_device(dev));
+ priv->edp = NULL;
+ }
+}
+
+static const struct component_ops edp_ops = {
+ .bind = edp_bind,
+ .unbind = edp_unbind,
+};
+
+static int edp_dev_probe(struct platform_device *pdev)
+{
+ DBG("");
[Bug 88170] 32 bits opengl apps crash with latest llvm 3.6 git / mesa git / radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=88170 Alex Deucher changed: What|Removed |Added Component|Driver/Radeon |Drivers/Gallium/radeonsi Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Product|xorg|Mesa QA Contact|xorg-team at lists.x.org | --- Comment #2 from Alex Deucher --- Can you bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/f7513bde/attachment.html>
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Wed, 07 Jan 2015 14:39:13 + Andrew Jackson wrote: > > + - audio-ports: must contain one or two values selecting the source > > + in the audio port. > > + The source type is given by the corresponding entry in > > + the audio-port-names property. > > I think that this entry might benefit from a little more explanation. > The value specified here selects which pins on the chip provide the > audio input doesn't it? In the outline datasheet that I have these are > listed in table 17: > > Audio portInput configuration > S/PDIF I2S-bus > AP0 - WS (word select) > AP1 S/PDIF inputI2S-bus channel 0 > AP2 S/PDIF inputI2S-bus channel 1 > AP3[1]I2S-bus channel 2 > AP4[1]I2S-bus channel 3 > ACLK - SCK (I2S-bus clock) > > [1] Depending on package. Your table is close to the one in the TDA9983B documentation I have, but the pins are not exactly the same: AP0 WS (word select) AP1 I2S-bus port 0 AP2 I2S-bus port 1 AP3 I2S-bus port 2 AP4 I2S-bus port 3 AP5 MCLK (master clock for S/PDIF) AP6 S/PDIF input AP7 AUX (internal test) ACLKSCK (I2S-bus clock) That's why I did not know clearly why I had to set AP2 for S/PDIF input and (AP0 + AP1) for I2S input in the Cubox. Then, the only more explanation I could give is "have a look at the audio input format and at the register 0x1e page 0 in the documentation of the TDA998x chip". BTW, the tda998x driver supports only the TDA9989, TDA19988 and TDA19989 chips. If the TDA9983B would be supported, the audio port definitions would be of no use. So, what would you see as an explanation? -- Ken ar c'hentañ| ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC
Hi Alexander, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit c08abf11900e19b14dd3a0cc3d105bd74519cd18 Author: Alex Deucher Date: Mon Jul 14 12:01:40 2014 -0400 drm/radeon: re-enable dpm by default on BTC The regression was introduced as of v3.17-rc1 and still exists in current mainline. It has also made it's way into the stable releases. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? Thanks, Joe [0] http://pad.lv/1386534
[PATCH] intel: Export GT config attributes
Link to the archived drm/i915 patches corresponding to this change: http://lists.freedesktop.org/archives/intel-gfx/2014-December/057817.html
[PATCH v9 3/4] ASoC: tda998x: add a codec to the HDMI transmitter
On Wed, Jan 07, 2015 at 03:10:47PM +, Andrew Jackson wrote: > On 01/07/15 10:51, Jean-Francois Moine wrote: > > This patch adds a CODEC to the NXP TDA998x HDMI transmitter. > > > > The CODEC handles both I2S and S/PDIF inputs. Please delete unneeded context from your messages, it makes it much easier to find any new content you've added. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/5091e983/attachment.sig>
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On Wed, Jan 07, 2015 at 05:18:20PM +, Andrew Jackson wrote: > I understand your difficulty! I was just wanting something to clarify the > meaning of the value without reference to the driver source. > You could add something like this to your existing explanation: "The value > describes which audio input pins are selected; this varies depending > on chip type so consult the section on audio port configuration in the > relevant datasheet.". This is commonly done by just saying that the value will be written into a given bitfield for such and such a purpose and then relying on the chip documentation for that; it's a more direct way of saying the above. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/8d7db0ad/attachment.sig>
[PATCH 26/29] drm/exynos: atomic phase 1: add atomic_begin()/atomic_flush()
2014-12-30 Inki Dae :
> On 2014ë
12ì 18ì¼ 22:58, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Add CRTC callbacks .atomic_begin() .atomic_flush(). On exynos they
> > unprotect the windows before the commit and protects it after based on
> > a plane mask tha store which plane will be updated.
>
> tha? Typo?
Okay.
>
> >
> > For that we create two new exynos_crtc callbacks: .win_protect() and
> > .win_unprotect(). The only driver that implement those now is FIMD.
> >
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 34 +++
> > drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +++
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 56
> > ++-
> > drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +++
> > 4 files changed, 82 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > index 74980c5..f231eb8 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> > @@ -156,6 +156,38 @@ static void exynos_drm_crtc_disable(struct drm_crtc
> > *crtc)
> > }
> > }
> >
> > +static void exynos_crtc_atomic_begin(struct drm_crtc *crtc)
> > +{
> > + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> > + struct drm_plane *plane;
> > + int index = 0;
> > +
>
> Isn't drm_modest_lock_all(dev) required? Or is this function atomic
> context? I didn't look into all codes yet so there may be my missing point.
the atomic code already protects it by calling drm_modeset_lock_all() so we
are running in a safe context.
Gustavo
[PATCH] drm/rockchip: fix dma_alloc_attrs() error check
dma_alloc_attrs() returns NULL if it cannot allocate a dma buffer (or
mapping), not a negative error code.
Rerported-by: Pawel Osciak
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index bc98a22..7ca8799e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -34,12 +34,9 @@ static int rockchip_gem_alloc_buf(struct rockchip_gem_object
*rk_obj)
rk_obj->kvaddr = dma_alloc_attrs(drm->dev, obj->size,
&rk_obj->dma_addr, GFP_KERNEL,
&rk_obj->dma_attrs);
- if (IS_ERR(rk_obj->kvaddr)) {
- int ret = PTR_ERR(rk_obj->kvaddr);
-
- DRM_ERROR("failed to allocate %#x byte dma buffer, %d",
- obj->size, ret);
- return ret;
+ if (!rk_obj->kvaddr) {
+ DRM_ERROR("failed to allocate %#x byte dma buffer", obj->size);
+ return -ENOMEM;
}
return 0;
--
2.2.0.rc0.207.ga3a616c
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On 01/07/15 17:08, Jean-Francois Moine wrote: > On Wed, 07 Jan 2015 14:39:13 + > Andrew Jackson wrote: > >>> + - audio-ports: must contain one or two values selecting the source >>> + in the audio port. >>> + The source type is given by the corresponding entry in >>> + the audio-port-names property. >> >> I think that this entry might benefit from a little more explanation. >> The value specified here selects which pins on the chip provide the >> audio input doesn't it? In the outline datasheet that I have these are >> listed in table 17: >> >> Audio port Input configuration >> S/PDIF I2S-bus >> AP0 - WS (word select) >> AP1 S/PDIF inputI2S-bus channel 0 >> AP2 S/PDIF inputI2S-bus channel 1 >> AP3[1] I2S-bus channel 2 >> AP4[1] I2S-bus channel 3 >> ACLK - SCK (I2S-bus clock) >> >> [1] Depending on package. > > Your table is close to the one in the TDA9983B documentation I have, > but the pins are not exactly the same: > > AP0 WS (word select) > AP1 I2S-bus port 0 > AP2 I2S-bus port 1 > AP3 I2S-bus port 2 > AP4 I2S-bus port 3 > AP5 MCLK (master clock for S/PDIF) > AP6 S/PDIF input > AP7 AUX (internal test) > ACLK SCK (I2S-bus clock) > > That's why I did not know clearly why I had to set AP2 for S/PDIF input > and (AP0 + AP1) for I2S input in the Cubox. > > Then, the only more explanation I could give is "have a look at the > audio input format and at the register 0x1e page 0 in the documentation > of the TDA998x chip". > > BTW, the tda998x driver supports only the TDA9989, TDA19988 and > TDA19989 chips. If the TDA9983B would be supported, the audio port > definitions would be of no use. > > So, what would you see as an explanation? > I understand your difficulty! I was just wanting something to clarify the meaning of the value without reference to the driver source. You could add something like this to your existing explanation: "The value describes which audio input pins are selected; this varies depending on chip type so consult the section on audio port configuration in the relevant datasheet.". Andrew
[PATCH 25/29] drm/exynos: atomic phase 1: use drm_plane_helper_disable()
2014-12-30 Inki Dae : > On 2014ë 12ì 18ì¼ 22:58, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > The atomic helper to disable planes also uses exynos_update_plane() to > > disable plane so we had to adapt it to both commit and disable planes. > > > > A check for NULL CRTC was added to exynos_plane_mode_set() since planes > > to be disabled have plane_state->crtc set to NULL. > > > > Also win_disable() callback uses plane->crtc as arg for the same reason. > > > > exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer. > > > > Signed-off-by: Gustavo Padovan > > --- > > drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +- > > drivers/gpu/drm/exynos/exynos_drm_plane.c | 24 ++-- > > 2 files changed, 19 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c > > b/drivers/gpu/drm/exynos/exynos_drm_fb.c > > index d346d1e..470456d 100644 > > --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c > > +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c > > @@ -136,7 +136,7 @@ unsigned int exynos_drm_fb_get_buf_cnt(struct > > drm_framebuffer *fb) > > > > exynos_fb = to_exynos_fb(fb); > > > > - return exynos_fb->buf_cnt; > > + return exynos_fb ? exynos_fb->buf_cnt : 0; > > This change isn't related with this patch. This patch will be reworked to use atomic_disable() as suggested by Daniel Vetter in the previous comment. Gustavo
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #17 from Johannes Hirte --- Ok, 3.18-rc1 is affected too. Searching for a good version to restart bisecting. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/5083632a/attachment-0001.html>
[RFC PATCH v4 4/4] tests/drv_module_reload: add ipvr support
From: Yao Cheng on vlv, if ipvr is installed, it need be manually unloaded before i915, otherwise user might run into use-after-free issue. v2: added this patch per Daniel's comment v3: no change Signed-off-by: Yao Cheng Signed-off-by: Sean V Kelley --- tests/drv_module_reload | 16 1 file changed, 16 insertions(+) diff --git a/tests/drv_module_reload b/tests/drv_module_reload index 5cbff89..82c67bd 100755 --- a/tests/drv_module_reload +++ b/tests/drv_module_reload @@ -24,6 +24,14 @@ rmmod snd_hda_intel &> /dev/null #ignore errors in ips - gen5 only rmmod intel_ips &> /dev/null + +# vlv only for now: +# due to platform device model limitation, need unload ipvr manually +if lsmod | grep ipvr &> /dev/null ; then + echo Need manually unload ipvr.ko. + rmmod ipvr +fi + rmmod i915 #ignore errors in intel-gtt, often built-in rmmod intel-gtt &> /dev/null @@ -31,6 +39,11 @@ rmmod intel-gtt &> /dev/null rmmod drm_kms_helper &> /dev/null rmmod drm &> /dev/null +if lsmod | grep ipvr &> /dev/null ; then + echo WARNING: ipvr.ko still loaded! + exit 1 +fi + if lsmod | grep i915 &> /dev/null ; then echo WARNING: i915.ko still loaded! exit 1 @@ -41,6 +54,9 @@ fi modprobe i915 echo 1 > /sys/class/vtconsole/vtcon1/bind +# for vlv, load VED driver +modprobe ipvr + modprobe snd_hda_intel # try to run something -- 2.1.0
[RFC PATCH v4 3/4] ipvr: user mode helper for ipvr drm driver
From: Yao Cheng add usermode helper for the ipvr kernel driver. test_ioctl: test kernel driver by directly ioctl v2: take Emil's comments - correctly align ipvr_drm.h v3: take Daniel Vetter and Daniel Stone's comments, and implement PRIME - correctly align ipvr_drm.h - use __u32 family in ipvr_drm.h - rip out explicit fence from libdrm_ipvr - implemented PRIME support - add relocation fixup implementation v4 bug fixing and add stress test tool - rename ipvr/test_ioctl.c to ipvr/test_ipvr.c - implement parallel ioctl stress test in test_ipvr.c - implement parallel libdrm stress test in test_ipvr.c - update ipvr_drm.h to keep consistent with kernel change - remove unused "buffer_ofs/alloc_size/ext_handle" from struct drm_ipvr_bo - remove unused arguments for some public functions - fix a few foolish copy-paste bugs - fix 32bit compiling issue Signed-off-by: Yao Cheng Signed-off-by: Sean V Kelley --- Makefile.am|6 +- Makefile.sources |1 + configure.ac | 26 +- include/drm/ipvr_drm.h | 259 +++ ipvr/Makefile.am | 57 +++ ipvr/Makefile.sources |5 + ipvr/ipvr_bufmgr.h | 132 ++ ipvr/ipvr_bufmgr_gem.c | 1188 ipvr/libdrm_ipvr.pc.in | 11 + ipvr/test_ipvr.c | 919 + 10 files changed, 2602 insertions(+), 2 deletions(-) create mode 100644 include/drm/ipvr_drm.h create mode 100644 ipvr/Makefile.am create mode 100644 ipvr/Makefile.sources create mode 100644 ipvr/ipvr_bufmgr.h create mode 100644 ipvr/ipvr_bufmgr_gem.c create mode 100644 ipvr/libdrm_ipvr.pc.in create mode 100644 ipvr/test_ipvr.c diff --git a/Makefile.am b/Makefile.am index 3cb516c..035d937 100644 --- a/Makefile.am +++ b/Makefile.am @@ -33,6 +33,10 @@ if HAVE_INTEL INTEL_SUBDIR = intel endif +if HAVE_IPVR +IPVR_SUBDIR = ipvr +endif + if HAVE_NOUVEAU NOUVEAU_SUBDIR = nouveau endif @@ -57,7 +61,7 @@ if HAVE_TEGRA TEGRA_SUBDIR = tegra endif -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) $(TEGRA_SUBDIR) tests man +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(IPVR_SUBDIR) $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) $(TEGRA_SUBDIR) tests man libdrm_la_LTLIBRARIES = libdrm.la libdrm_ladir = $(libdir) diff --git a/Makefile.sources b/Makefile.sources index 566f7b5..819a0cb 100644 --- a/Makefile.sources +++ b/Makefile.sources @@ -18,6 +18,7 @@ LIBDRM_INCLUDE_H_FILES := \ include/drm/drm_mode.h \ include/drm/drm_sarea.h \ include/drm/i915_drm.h \ + include/drm/ipvr_drm.h \ include/drm/mach64_drm.h \ include/drm/mga_drm.h \ include/drm/nouveau_drm.h \ diff --git a/configure.ac b/configure.ac index c88a1c5..9fea4db 100644 --- a/configure.ac +++ b/configure.ac @@ -68,6 +68,11 @@ AC_ARG_ENABLE(intel, [Enable support for intel's KMS API (default: auto)]), [INTEL=$enableval], [INTEL=auto]) +AC_ARG_ENABLE(ipvr, + AS_HELP_STRING([--disable-ipvr], + [Enable support for valeyview's IPVR hardware decode (default: auto)]), + [IPVR=$enableval], [IPVR=auto]) + AC_ARG_ENABLE(radeon, AS_HELP_STRING([--disable-radeon], [Enable support for radeon's KMS API (default: auto)]), @@ -209,7 +214,7 @@ if test "x$drm_cv_atomic_primitives" = "xlibatomic-ops"; then AC_DEFINE(HAVE_LIB_ATOMIC_OPS, 1, [Enable if you have libatomic-ops-dev installed]) fi -if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno"; then +if test "x$INTEL" != "xno" -o "x$IPVR" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno"; then if test "x$drm_cv_atomic_primitives" = "xnone"; then if test "x$INTEL" != "xauto"; then if test "x$INTEL" != "xno"; then @@ -219,6 +224,14 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno"; then AC_MSG_WARN([Disabling libdrm_intel. It depends on atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package.]) INTEL=no fi + if test "x$IPVR" != "xauto"; then + if test "x$IPVR" != "xno"; then + AC_MSG_ERROR([libdrm_ipvr depends upon atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package, or, failing both of those, disable support for IPVR by passing --disable-ipvr to ./configure]) + fi + else + AC_MSG_WARN([Disabling libdrm_ipvr. It depends on atomic opera
[RFC PATCH v4 2/4] drm/ipvr: drm driver for VED
From: Yao Cheng Probes VED and creates a new drm device for hardware accelerated video decoding. Currently support VP8 decoding on valleyview. v2: take David's comments - add mmap support and remove mmap_ioctl - remove postclose since it's deprecated - NULL set_busid v3: take David, Daniel and Jesse's comments and massive refine - use drm_dev_alloc+drm_dev_register to replace drm_platform_init - same as above in exit side - remove fd based explit fence - refine ipvr_drm.h, use __u32 series and refine paddings - add doc to describe ipvr/ved terminology - ioctl refine: remove unused code - use uintptr_t series for address/number conversion - runtime pm refine: guarantee get/put paring - add PRIME feature and remove USERPTR ioctl - implement relocation fixup in EXEC ioctl - call drm_gem_get_pages to replace my own implementation - code cleanup: remove unused code v4: bug fixing, - add missing unreference in ipvr_gem_fault() - add struct_mutex lock around drm_mm_insert_node_in_range_generic() - move ipvr_ctx_list from dev_priv to file_priv and add spinlock - check EAGAIN for pm_runtime_get/put and add lock - add mutex lock for do_execbuffer - put power on fence lockup - define all ioctls as DRM_AUTH|DRM_UNLOCKED - correctly set ved_busy - rename ipvr_misc_ioctl to ipvr_get_info_ioctl and remove unused code Signed-off-by: Yao Cheng Signed-off-by: Sean V Kelley --- Documentation/DocBook/drm.tmpl| 39 ++ drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ipvr/Kconfig |9 + drivers/gpu/drm/ipvr/Makefile | 18 + drivers/gpu/drm/ipvr/ipvr_bo.c| 543 + drivers/gpu/drm/ipvr/ipvr_bo.h| 80 +++ drivers/gpu/drm/ipvr/ipvr_debug.c | 335 +++ drivers/gpu/drm/ipvr/ipvr_debug.h | 76 +++ drivers/gpu/drm/ipvr/ipvr_drm.h | 259 drivers/gpu/drm/ipvr/ipvr_drv.c | 617 +++ drivers/gpu/drm/ipvr/ipvr_drv.h | 292 + drivers/gpu/drm/ipvr/ipvr_exec.c | 613 +++ drivers/gpu/drm/ipvr/ipvr_exec.h | 57 ++ drivers/gpu/drm/ipvr/ipvr_fence.c | 487 +++ drivers/gpu/drm/ipvr/ipvr_fence.h | 72 +++ drivers/gpu/drm/ipvr/ipvr_gem.c | 297 + drivers/gpu/drm/ipvr/ipvr_gem.h | 48 ++ drivers/gpu/drm/ipvr/ipvr_mmu.c | 752 +++ drivers/gpu/drm/ipvr/ipvr_mmu.h | 111 drivers/gpu/drm/ipvr/ipvr_trace.c | 11 + drivers/gpu/drm/ipvr/ipvr_trace.h | 333 ++ drivers/gpu/drm/ipvr/ved_cmd.c| 882 +++ drivers/gpu/drm/ipvr/ved_cmd.h| 70 +++ drivers/gpu/drm/ipvr/ved_fw.c | 1199 + drivers/gpu/drm/ipvr/ved_fw.h | 81 +++ drivers/gpu/drm/ipvr/ved_msg.h| 256 drivers/gpu/drm/ipvr/ved_pm.c | 335 +++ drivers/gpu/drm/ipvr/ved_pm.h | 36 ++ drivers/gpu/drm/ipvr/ved_reg.h| 561 + 30 files changed, 8472 insertions(+) create mode 100644 drivers/gpu/drm/ipvr/Kconfig create mode 100644 drivers/gpu/drm/ipvr/Makefile create mode 100644 drivers/gpu/drm/ipvr/ipvr_bo.c create mode 100644 drivers/gpu/drm/ipvr/ipvr_bo.h create mode 100644 drivers/gpu/drm/ipvr/ipvr_debug.c create mode 100644 drivers/gpu/drm/ipvr/ipvr_debug.h create mode 100644 drivers/gpu/drm/ipvr/ipvr_drm.h create mode 100644 drivers/gpu/drm/ipvr/ipvr_drv.c create mode 100644 drivers/gpu/drm/ipvr/ipvr_drv.h create mode 100644 drivers/gpu/drm/ipvr/ipvr_exec.c create mode 100644 drivers/gpu/drm/ipvr/ipvr_exec.h create mode 100644 drivers/gpu/drm/ipvr/ipvr_fence.c create mode 100644 drivers/gpu/drm/ipvr/ipvr_fence.h create mode 100644 drivers/gpu/drm/ipvr/ipvr_gem.c create mode 100644 drivers/gpu/drm/ipvr/ipvr_gem.h create mode 100644 drivers/gpu/drm/ipvr/ipvr_mmu.c create mode 100644 drivers/gpu/drm/ipvr/ipvr_mmu.h create mode 100644 drivers/gpu/drm/ipvr/ipvr_trace.c create mode 100644 drivers/gpu/drm/ipvr/ipvr_trace.h create mode 100644 drivers/gpu/drm/ipvr/ved_cmd.c create mode 100644 drivers/gpu/drm/ipvr/ved_cmd.h create mode 100644 drivers/gpu/drm/ipvr/ved_fw.c create mode 100644 drivers/gpu/drm/ipvr/ved_fw.h create mode 100644 drivers/gpu/drm/ipvr/ved_msg.h create mode 100644 drivers/gpu/drm/ipvr/ved_pm.c create mode 100644 drivers/gpu/drm/ipvr/ved_pm.h create mode 100644 drivers/gpu/drm/ipvr/ved_reg.h diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 9db989c..e9cadf6 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -4062,5 +4062,44 @@ int num_ioctls; !Cdrivers/gpu/drm/i915/i915_irq.c + +drm/ipvr Intel's driver for PowerVR video core + + The drm/ipvr driver intends to support the PowerVR video cores + integrated on I
[RFC PATCH V4 1/4] drm/i915: add i915_ved.c to setup bridge for VED
From: Yao Cheng
Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward the VED irqs.
VED driver (a standalone drm driver) probes the VED device and
creates a new dri card on install.
Currently only supports VED on valleyview.
Kerneldoc is updated for i915_ved.c.
v2:
take Daniel & Jani's comments
- extract change to new file i915_ved.c
- add kerneldoc
- change 'ipvr-ved' to 'ipvr-vlv-ved' for extensibility
- unregister platdev before irq_free_desc
- add WARN_ON(!intel_irqs_enabled) in irq init code
- remove unnecessary trace point
- remove unnecessary BUG_ON
v3:
take Ville's comments and VED PRIME support
- add HAS_VED() check
- add ved struct to make code neat
- no need to check platform in vlv_irq_handler
- i915_reg.h update
- no need to kmalloc for small amount of resource
- remove unnecessary REG resource
- follow vlv_display_irqs_install() to implement VED mask/unmask
- workaround nommu_map_sg issue by set dma_mask to support VED PRIME.
v4:
take Bob's comments
- add more detail on the use-after-free issue description
- mask VED irq before removing the child device
Signed-off-by: Yao Cheng
Signed-off-by: Sean V Kelley
---
Documentation/DocBook/drm.tmpl | 5 +
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_dma.c | 11 ++
drivers/gpu/drm/i915/i915_drv.h | 12 ++
drivers/gpu/drm/i915/i915_irq.c | 2 +
drivers/gpu/drm/i915/i915_reg.h | 4 +
drivers/gpu/drm/i915/i915_ved.c | 270
7 files changed, 307 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_ved.c
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 56e2a9b..9db989c 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3867,6 +3867,11 @@ int num_ioctls;
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
+
+VED video core integration
+!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
+!Idrivers/gpu/drm/i915/i915_ved.c
+
Display Hardware Handling
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e4083e4..7d0bbfa 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -84,6 +84,9 @@ i915-y += dvo_ch7017.o \
i915-y += i915_dma.o \
i915_ums.o
+# VED for VLV
+i915-y += i915_ved.o
+
obj-$(CONFIG_DRM_I915) += i915.o
CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 887d88f..cd96618 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -828,6 +828,13 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
if (IS_GEN5(dev))
intel_gpu_ips_init(dev_priv);
+ if (HAS_VED(dev)) {
+ ret = vlv_setup_ved(dev);
+ if (ret < 0) {
+ DRM_ERROR("failed to setup VED bridge: %d\n", ret);
+ }
+ }
+
intel_runtime_pm_enable(dev_priv);
return 0;
@@ -870,6 +877,10 @@ int i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
+ if (HAS_VED(dev)) {
+ vlv_teardown_ved(dev);
+ }
+
ret = i915_gem_suspend(dev);
if (ret) {
DRM_ERROR("failed to idle hardware: %d\n", ret);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 502a01b..aa39d47 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1773,6 +1773,12 @@ struct drm_i915_private {
uint32_t bios_vgacntr;
+ /* necessary resource sharing with ved driver. */
+ struct {
+ struct platform_device *platdev;
+ int irq;
+ } ved;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct {
int (*do_execbuf)(struct drm_device *dev, struct drm_file *file,
@@ -2305,6 +2311,7 @@ struct drm_i915_cmd_table {
IS_BROADWELL(dev) || IS_VALLEYVIEW(dev))
#define HAS_RC6(dev) (INTEL_INFO(dev)->gen >= 6)
#define HAS_RC6p(dev) (INTEL_INFO(dev)->gen == 6 || IS_IVYBRIDGE(dev))
+#define HAS_VED(dev) (INTEL_INFO(dev)->is_valleyview && IS_GEN7(dev))
#define INTEL_PCH_DEVICE_ID_MASK 0xff00
#define INTEL_PCH_IBX_DEVICE_ID_TYPE 0x3b00
@@ -2894,6 +2901,11 @@ void i915_restore_display_reg(struct drm_device *dev);
void i915_setup_sysfs(struct drm_device *dev_priv);
void i915_teardown_sysf
[RFC PATCH v4 0/4] drm driver for VED in Intel GPU
drm/ipvr is a new GEM driver for VED (PowerVR's VPU integrated in Intel GPU), which extends video capability. A new Kconfig added for building ipvr driver: CONFIG_DRM_IPVR: Build option for ipvr module The driver name "ipvr" means the PowerVR's core wrapped by Intel. The PowerVR VPUs are also integrated by non-i915 platforms such as GMA500, so we keep ipvr driver and i915 driver separated and independent to each other. To achieve this we do the minimum change in i915: i915_ved.c added for setting up the bridge between VED and i915, kerneldoc also updated. User mode drm helper "libdrm_ipvr.so" and simple ioctl/execute test is included. one test script "drv_module_reload" in i-g-t also updated to support ipvr loading and unloading. Due to restriction in Linux platform device model, we have to manually unload ipvr before unloading i915. Yao Cheng (4): [1/4] drm/i915: add i915_ved.c to setup bridge for VED [2/4] drm/ipvr: drm driver for VED [3/4] libdrm/ipvr: user mode helper for ipvr drm driver [4/4] i-g-t: tests/drv_module_reload: add ipvr support
[PATCH] drm/msm/mdp5: fix parameter type for mdp5_ctl_set_intf()
mdp5_ctl_set_intf()'s second argument should be "int", not "enum mdp5_intf".
The passed in value is "intf", not "intf_id".
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 2 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index dea4505..1511290 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -95,7 +95,7 @@ u32 ctl_read(struct mdp5_ctl *ctl, u32 reg)
}
-int mdp5_ctl_set_intf(struct mdp5_ctl *ctl, enum mdp5_intf intf)
+int mdp5_ctl_set_intf(struct mdp5_ctl *ctl, int intf)
{
unsigned long flags;
static const enum mdp5_intfnum intfnum[] = {
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
index 1018519..ad48788 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
@@ -34,7 +34,7 @@ void mdp5_ctlm_destroy(struct mdp5_ctl_manager *ctlm);
*/
struct mdp5_ctl *mdp5_ctlm_request(struct mdp5_ctl_manager *ctlm, struct
drm_crtc *crtc);
-int mdp5_ctl_set_intf(struct mdp5_ctl *ctl, enum mdp5_intf intf);
+int mdp5_ctl_set_intf(struct mdp5_ctl *ctl, int intf);
int mdp5_ctl_set_cursor(struct mdp5_ctl *ctl, bool enable);
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
[PATCH 3/3] drm/msm/hdmi: rework hdmi configurations, using dt_match[]
In the same idea mdp5_cfg was added, this change allows us to quickly
add new instances, such as apq8084's HDMI in this case.
Signed-off-by: Stephane Viau
---
Documentation/devicetree/bindings/drm/msm/hdmi.txt | 1 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 128 +++--
2 files changed, 71 insertions(+), 58 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
index c25d5aa..a29a55f 100644
--- a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
@@ -3,6 +3,7 @@ Qualcomm adreno/snapdragon hdmi output
Required properties:
- compatible: one of the following
* "qcom,hdmi-tx-8084"
+ * "qcom,hdmi-tx-8074"
* "qcom,hdmi-tx-8660"
* "qcom,hdmi-tx-8960"
- reg: Physical base address and length of the controller's registers
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index c2fe4fa..36a12ee 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (c) 2014 The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
*
@@ -291,6 +292,57 @@ fail:
#include
+#define HDMI_CFG(item, entry) \
+ .item ## _names = item ##_names_ ## entry, \
+ .item ## _cnt = ARRAY_SIZE(item ## _names_ ## entry)
+
+static struct hdmi_platform_config hdmi_tx_8660_config = {
+ .phy_init = hdmi_phy_8x60_init,
+};
+
+static const char *hpd_reg_names_8960[] = {"core-vdda", "hdmi-mux"};
+static const char *hpd_clk_names_8960[] = {"core_clk", "master_iface_clk",
"slave_iface_clk"};
+
+static struct hdmi_platform_config hdmi_tx_8960_config = {
+ .phy_init = hdmi_phy_8960_init,
+ HDMI_CFG(hpd_reg, 8960),
+ HDMI_CFG(hpd_clk, 8960),
+};
+
+static const char *pwr_reg_names_8x74[] = {"core-vdda", "core-vcc"};
+static const char *hpd_reg_names_8x74[] = {"hpd-gdsc", "hpd-5v"};
+static const char *pwr_clk_names_8x74[] = {"extp_clk", "alt_iface_clk"};
+static const char *hpd_clk_names_8x74[] = {"iface_clk", "core_clk",
"mdp_core_clk"};
+static unsigned long hpd_clk_freq_8x74[] = {0, 1920, 0};
+
+static struct hdmi_platform_config hdmi_tx_8074_config = {
+ .phy_init = hdmi_phy_8x74_init,
+ HDMI_CFG(pwr_reg, 8x74),
+ HDMI_CFG(hpd_reg, 8x74),
+ HDMI_CFG(pwr_clk, 8x74),
+ HDMI_CFG(hpd_clk, 8x74),
+ .hpd_freq = hpd_clk_freq_8x74,
+};
+
+static const char *hpd_reg_names_8084[] = {"hpd-gdsc", "hpd-5v", "hpd-5v-en"};
+
+static struct hdmi_platform_config hdmi_tx_8084_config = {
+ .phy_init = hdmi_phy_8x74_init,
+ HDMI_CFG(pwr_reg, 8x74),
+ HDMI_CFG(hpd_reg, 8084),
+ HDMI_CFG(pwr_clk, 8x74),
+ HDMI_CFG(hpd_clk, 8x74),
+ .hpd_freq = hpd_clk_freq_8x74,
+};
+
+static const struct of_device_id dt_match[] = {
+ { .compatible = "qcom,hdmi-tx-8084", .data = &hdmi_tx_8084_config },
+ { .compatible = "qcom,hdmi-tx-8074", .data = &hdmi_tx_8074_config },
+ { .compatible = "qcom,hdmi-tx-8960", .data = &hdmi_tx_8960_config },
+ { .compatible = "qcom,hdmi-tx-8660", .data = &hdmi_tx_8660_config },
+ {}
+};
+
#ifdef CONFIG_OF
static int get_gpio(struct device *dev, struct device_node *of_node, const
char *name)
{
@@ -314,63 +366,28 @@ static int hdmi_bind(struct device *dev, struct device
*master, void *data)
struct drm_device *drm = dev_get_drvdata(master);
struct msm_drm_private *priv = drm->dev_private;
static struct hdmi_platform_config config = {};
+ static struct hdmi_platform_config *hdmi_cfg;
struct hdmi *hdmi;
#ifdef CONFIG_OF
struct device_node *of_node = dev->of_node;
+ const struct of_device_id *match;
- if (of_device_is_compatible(of_node, "qcom,hdmi-tx-8074")) {
- static const char *hpd_reg_names[] = {"hpd-gdsc", "hpd-5v"};
- static const char *pwr_reg_names[] = {"core-vdda", "core-vcc"};
- static const char *hpd_clk_names[] = {"iface_clk", "core_clk",
"mdp_core_clk"};
- static unsigned long hpd_clk_freq[] = {0, 1920, 0};
- static const char *pwr_clk_names[] = {"extp_clk",
"alt_iface_clk"};
- config.phy_init = hdmi_phy_8x74_init;
- config.hpd_reg_names = hpd_reg_names;
- config.hpd_reg_cnt = ARRAY_SIZE(hpd_reg_names);
- config.pwr_reg_names = pwr_reg_names;
- config.pwr_reg_cnt = ARRAY_SIZE(pwr_reg_names);
- config.hpd_clk_names = hpd_clk_names;
- config.hpd_freq = hpd_clk_freq;
- config.hpd_clk_cnt = ARRAY_SIZE(hpd_clk_names);
- config.pwr_clk_names = pwr_clk_names;
- config.pwr_clk_cnt =
[PATCH 2/3] drm/msm/hdmi: Add HDMI platform config for apq8084
This change add the regulator/clock configuration for MDP5 v1.3.
This config is close to the one already existing for 8x74, except
that one more regulator is needed (hpd-5v-en).
Signed-off-by: Stephane Viau
---
Documentation/devicetree/bindings/drm/msm/hdmi.txt | 1 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
index aca917f..c25d5aa 100644
--- a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
@@ -2,6 +2,7 @@ Qualcomm adreno/snapdragon hdmi output
Required properties:
- compatible: one of the following
+ * "qcom,hdmi-tx-8084"
* "qcom,hdmi-tx-8660"
* "qcom,hdmi-tx-8960"
- reg: Physical base address and length of the controller's registers
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index a9092d6..c2fe4fa 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -334,6 +334,22 @@ static int hdmi_bind(struct device *dev, struct device
*master, void *data)
config.hpd_clk_cnt = ARRAY_SIZE(hpd_clk_names);
config.pwr_clk_names = pwr_clk_names;
config.pwr_clk_cnt = ARRAY_SIZE(pwr_clk_names);
+ } else if (of_device_is_compatible(of_node, "qcom,hdmi-tx-8084")) {
+ static const char *hpd_reg_names[] = {"hpd-gdsc", "hpd-5v",
"hpd-5v-en"};
+ static const char *pwr_reg_names[] = {"core-vdda", "core-vcc"};
+ static const char *hpd_clk_names[] = {"iface_clk", "core_clk",
"mdp_core_clk"};
+ static unsigned long hpd_clk_freq[] = {0, 1920, 0};
+ static const char *pwr_clk_names[] = {"extp_clk",
"alt_iface_clk"};
+ config.phy_init = hdmi_phy_8x74_init;
+ config.hpd_reg_names = hpd_reg_names;
+ config.hpd_reg_cnt = ARRAY_SIZE(hpd_reg_names);
+ config.pwr_reg_names = pwr_reg_names;
+ config.pwr_reg_cnt = ARRAY_SIZE(pwr_reg_names);
+ config.hpd_clk_names = hpd_clk_names;
+ config.hpd_freq = hpd_clk_freq;
+ config.hpd_clk_cnt = ARRAY_SIZE(hpd_clk_names);
+ config.pwr_clk_names = pwr_clk_names;
+ config.pwr_clk_cnt = ARRAY_SIZE(pwr_clk_names);
} else if (of_device_is_compatible(of_node, "qcom,hdmi-tx-8960")) {
static const char *hpd_clk_names[] = {"core_clk",
"master_iface_clk", "slave_iface_clk"};
static const char *hpd_reg_names[] = {"core-vdda", "hdmi-mux"};
@@ -439,6 +455,7 @@ static int hdmi_dev_remove(struct platform_device *pdev)
}
static const struct of_device_id dt_match[] = {
+ { .compatible = "qcom,hdmi-tx-8084" },
{ .compatible = "qcom,hdmi-tx-8074" },
{ .compatible = "qcom,hdmi-tx-8960" },
{ .compatible = "qcom,hdmi-tx-8660" },
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
[PATCH 1/3] drm/msm/hdmi: use dynamic allocation for hdmi resources
Instead of reporting BUG_ON when resources arrays are not
dimensioned correctly, this patch does a dynamic allocation of
these arrays. This is needed for the following patches that add a
regulator for a new target.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 33 +
drivers/gpu/drm/msm/hdmi/hdmi.h | 8
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 062c687..a9092d6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -65,6 +65,11 @@ static void hdmi_destroy(struct hdmi *hdmi)
if (hdmi->i2c)
hdmi_i2c_destroy(hdmi->i2c);
+ devm_kfree(&hdmi->pdev->dev, hdmi->pwr_clks);
+ devm_kfree(&hdmi->pdev->dev, hdmi->hpd_clks);
+ devm_kfree(&hdmi->pdev->dev, hdmi->pwr_regs);
+ devm_kfree(&hdmi->pdev->dev, hdmi->hpd_regs);
+
platform_set_drvdata(hdmi->pdev, NULL);
}
@@ -106,7 +111,12 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
goto fail;
}
- BUG_ON(config->hpd_reg_cnt > ARRAY_SIZE(hdmi->hpd_regs));
+ hdmi->hpd_regs = devm_kzalloc(&pdev->dev, sizeof(hdmi->hpd_regs[0]) *
+ config->hpd_reg_cnt, GFP_KERNEL);
+ if (!hdmi->hpd_regs) {
+ ret = -ENOMEM;
+ goto fail;
+ }
for (i = 0; i < config->hpd_reg_cnt; i++) {
struct regulator *reg;
@@ -122,7 +132,12 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
hdmi->hpd_regs[i] = reg;
}
- BUG_ON(config->pwr_reg_cnt > ARRAY_SIZE(hdmi->pwr_regs));
+ hdmi->pwr_regs = devm_kzalloc(&pdev->dev, sizeof(hdmi->pwr_regs[0]) *
+ config->pwr_reg_cnt, GFP_KERNEL);
+ if (!hdmi->pwr_regs) {
+ ret = -ENOMEM;
+ goto fail;
+ }
for (i = 0; i < config->pwr_reg_cnt; i++) {
struct regulator *reg;
@@ -138,7 +153,12 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
hdmi->pwr_regs[i] = reg;
}
- BUG_ON(config->hpd_clk_cnt > ARRAY_SIZE(hdmi->hpd_clks));
+ hdmi->hpd_clks = devm_kzalloc(&pdev->dev, sizeof(hdmi->hpd_clks[0]) *
+ config->hpd_clk_cnt, GFP_KERNEL);
+ if (!hdmi->hpd_clks) {
+ ret = -ENOMEM;
+ goto fail;
+ }
for (i = 0; i < config->hpd_clk_cnt; i++) {
struct clk *clk;
@@ -153,7 +173,12 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
hdmi->hpd_clks[i] = clk;
}
- BUG_ON(config->pwr_clk_cnt > ARRAY_SIZE(hdmi->pwr_clks));
+ hdmi->pwr_clks = devm_kzalloc(&pdev->dev, sizeof(hdmi->pwr_clks[0]) *
+ config->pwr_clk_cnt, GFP_KERNEL);
+ if (!hdmi->pwr_clks) {
+ ret = -ENOMEM;
+ goto fail;
+ }
for (i = 0; i < config->pwr_clk_cnt; i++) {
struct clk *clk;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 43e654f..9973e03 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -52,10 +52,10 @@ struct hdmi {
void __iomem *mmio;
- struct regulator *hpd_regs[2];
- struct regulator *pwr_regs[2];
- struct clk *hpd_clks[3];
- struct clk *pwr_clks[2];
+ struct regulator **hpd_regs;
+ struct regulator **pwr_regs;
+ struct clk **hpd_clks;
+ struct clk **pwr_clks;
struct hdmi_phy *phy;
struct i2c_adapter *i2c;
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
[PATCH 0/3] drm/msm: Add power supplies config for apq8084
The first patch makes it easier to have a different number of regulators depending on the target. It is followed by the addition of the apq8084's regulator config. Finally, the last patch makes things easier when a new device needs to be added, especially when they share the same information. Stephane Viau (3): drm/msm/hdmi: use dynamic allocation for hdmi resources drm/msm/hdmi: Add HDMI platform config for apq8084 drm/msm/hdmi: rework hdmi configurations, using dt_match[] Documentation/devicetree/bindings/drm/msm/hdmi.txt | 2 + drivers/gpu/drm/msm/hdmi/hdmi.c| 144 ++--- drivers/gpu/drm/msm/hdmi/hdmi.h| 8 +- 3 files changed, 105 insertions(+), 49 deletions(-) -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 3/3] drm: rockchip: export functions needed by rockchip dw_hdmi bridge driver
To build the rockchip dw_hdmi driver as a module, the
rockchip_drm_encoder_get_mux_id and rockchip_drm_crtc_mode_config
functions need to be exported.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index a798c7c..21a481b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -390,6 +390,7 @@ int rockchip_drm_encoder_get_mux_id(struct device_node
*node,
return -EINVAL;
}
+EXPORT_SYMBOL_GPL(rockchip_drm_encoder_get_mux_id);
static int compare_of(struct device *dev, void *data)
{
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index e7ca25b..9a5c571 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -735,6 +735,7 @@ int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
return 0;
}
+EXPORT_SYMBOL_GPL(rockchip_drm_crtc_mode_config);
static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
{
--
2.1.4
[PATCH 2/3] fixup! drm: bridge/dw_hdmi: add rockchip rk3288 support
Make the rockchip dw_hdmi driver buildable as a module. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/rockchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 6ebebe8..0d87bf6 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -17,7 +17,7 @@ config DRM_ROCKCHIP IP found on the SoC. config ROCKCHIP_DW_HDMI -bool "Rockchip specific extensions for Synopsys DW HDMI" +tristate "Rockchip specific extensions for Synopsys DW HDMI" depends on DRM_ROCKCHIP select DRM_DW_HDMI help -- 2.1.4
[PATCH 1/3] fixup! drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
Make dw_hdmi buildable as a module. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 4d822f0..b70f3c8 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -5,6 +5,6 @@ config DRM_PTN3460 ---help--- config DRM_DW_HDMI - bool + tristate depends on DRM select DRM_KMS_HELPER -- 2.1.4
[PATCH 0/3] dw_hdmi allmodconfig fixups
Hi Andy, to build the arm-allmodconfig, I had to add the following changes. Shall I squash the first two into their respective patches? regards Philipp Philipp Zabel (3): fixup! drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi fixup! drm: bridge/dw_hdmi: add rockchip rk3288 support drm: rockchip: export functions needed by rockchip dw_hdmi bridge driver drivers/gpu/drm/bridge/Kconfig | 2 +- drivers/gpu/drm/rockchip/Kconfig| 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 + 4 files changed, 4 insertions(+), 2 deletions(-) -- 2.1.4
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #224 from Gedalya --- Filed debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774784 Might need to file a separate bug for the linux package. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/cc63a40c/attachment.html>
[PULL] drm-exynos-next 2014-12-22
2014-12-26 Inki Dae : > On 2014ë 12ì 22ì¼ 22:04, Gustavo Padovan wrote: > > Hi Dave, > > > > Here goes a bunch of clean up for the exynos driver. I've posted this work > > in > > the mailing list twice but never got a review on it, first time was about a > > Never no. I already had a review and they - your first time patch set - > had been merged to exynos-drm-next-todo. I was moving them to > exynos-drm-next locally but one of your patch set was not reasonable to > me so I gave you one comment. After that, you posted next patch set > which include new changes and patches just 9 days ago. So they should > also be reviewed enough at least for two weeks. So please notify on the mailing list what you are doing. To me it looked that all patches but one didn't get any review. I have a lot of pending work to do on top of this pull request and review on them is quite important for me to keep working on new changes. > > Please, do not hurry. Such big changes should really be reviewed enough. > I will wait for other reviews and them merge them if reviewed enough. If > nobody have reviews then I will merge them. So please, don't worry about > that. It is been a way more than two weeks now, can you please merge all my patches but the 3 ones you had commented on? I'll send updated patches for those. Also can you add you tree to the linux-next build? Gustavo
[PATCH v18 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support
Rockchip RK3288 hdmi is compatible with dw_hdmi
Signed-off-by: Andy Yan
---
Changes in v18:
- fix two compile errors when build as module
Changes in v17:
- parse resource and irq in platform driver
Changes in v16: None
Changes in v15:
- remove THIS_MODULE in platform driver
Changes in v14: None
Changes in v13: None
Changes in v12:
- add comment for the depend on patch
Changes in v11: None
Changes in v10:
- add more display mode support mpll configuration for rk3288
Changes in v9:
- move some phy configuration to platform driver
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
drivers/gpu/drm/bridge/dw_hdmi.c| 3 +
drivers/gpu/drm/rockchip/Kconfig| 10 +
drivers/gpu/drm/rockchip/Makefile | 2 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 341
include/drm/bridge/dw_hdmi.h| 1 +
5 files changed, 357 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index cecc46a..01c95a8 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -852,6 +852,9 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
+ if (hdmi->dev_type == RK3288_HDMI)
+ dw_hdmi_phy_enable_spare(hdmi, 1);
+
/*Wait for PHY PLL lock */
msec = 5;
do {
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index ca9f085..6ebebe8 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -15,3 +15,13 @@ config DRM_ROCKCHIP
management to userspace. This driver does not provide
2D or 3D acceleration; acceleration is performed by other
IP found on the SoC.
+
+config ROCKCHIP_DW_HDMI
+bool "Rockchip specific extensions for Synopsys DW HDMI"
+depends on DRM_ROCKCHIP
+select DRM_DW_HDMI
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Synopsys DesignWare HDMI driver. If you want to
+ enable HDMI on RK3288 based SoC, you should selet this
+ option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 2cb0672..f3d8a19 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -5,4 +5,6 @@
rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \
rockchip_drm_gem.o
+obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
new file mode 100644
index 000..d236faa
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -0,0 +1,341 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define GRF_SOC_CON60x025c
+#define HDMI_SEL_VOP_LIT(1 << 4)
+
+struct rockchip_hdmi {
+ struct device *dev;
+ struct regmap *regmap;
+ struct drm_encoder encoder;
+};
+
+#define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
+
+static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
+ {
+ 2700, {
+ { 0x00b3, 0x},
+ { 0x2153, 0x},
+ { 0x40f3, 0x}
+ },
+ }, {
+ 3600, {
+ { 0x00b3, 0x},
+ { 0x2153, 0x},
+ { 0x40f3, 0x}
+ },
+ }, {
+ 4000, {
+ { 0x00b3, 0x},
+ { 0x2153, 0x},
+ { 0x40f3, 0x}
+ },
+ }, {
+ 5400, {
+ { 0x0072, 0x0001},
+ { 0x2142, 0x0001},
+ { 0x40a2, 0x0001},
+ },
+ }, {
+ 6500, {
+ { 0x0072, 0x0001},
+ { 0x2142, 0x0001},
+ { 0x40a2, 0x0001},
+ },
+ }, {
+ 6600, {
+ { 0x013e, 0x0003},
+ { 0x217e, 0x0002},
+
[PATCH v9 3/4] ASoC: tda998x: add a codec to the HDMI transmitter
On Wed, Jan 07, 2015 at 03:10:47PM +, Andrew Jackson wrote:
> On 01/07/15 10:51, Jean-Francois Moine wrote:
> > diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> > index 22c7ed6..24fc975 100644
> > --- a/drivers/gpu/drm/i2c/Kconfig
> > +++ b/drivers/gpu/drm/i2c/Kconfig
> > @@ -28,6 +28,7 @@ config DRM_I2C_SIL164
> > config DRM_I2C_NXP_TDA998X
> > tristate "NXP Semiconductors TDA998X HDMI encoder"
> > default m if DRM_TILCDC
> > + select SND_SOC_TDA998X
>
> Do you need this since sound/soc/codecs/Kconfig conditionally brings in the
> CODEC driver?
More importantly, it's broken, because it'll cause Kconfig to complain
if you enable DRM_I2C_NXP_TDA998X, but have ASoC disabled.
Moreover, if you decide you want the sound and ASoC built as a module,
but want to build in DRM and TDA998x support (so you can get video
output working on boot before initramfs/rootfs), Kconfig may well
complain.
> > +static int __init tda998x_codec_init(void)
> > +{
> > + return 0;
> > +}
> > +static void __exit tda998x_codec_exit(void)
> > +{
> > +}
> > +module_init(tda998x_codec_init);
> > +module_exit(tda998x_codec_exit);
There's no need for these if they remain as the above. Modules can have
both init/exit functions, or neither, and they are still unloadable.
Only modules which provide only an init function get locked in on load.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
[Bug 87489] GPU lockup - Sid Meyer's Beyond Earth
https://bugs.freedesktop.org/show_bug.cgi?id=87489 --- Comment #5 from oleid at mescharet.de --- I experience a crash using an 5770 & default settings, even when using LLVM 3.6(svn). The PC reboots during loading a game. I didn't write the kernel logs to a serial console, yet. What logs would be needed? System: ArchLinux AMD64 with mesa/git package repository. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/37257290/attachment.html>
[PATCH v18 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi
Hi Liu Ying , Philipp:
On 2015å¹´01æ07æ¥ 10:39, Liu Ying wrote:
>
> On 12/05/2014 02:22 PM, Andy Yan wrote:
>>
>> We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780
>> (Xburst/MIPS)
>> use the interface compatible Designware HDMI IP, but they also have some
>> lightly differences, such as phy pll configuration, register
>> width(imx hdmi
>> register is one byte, but rk3288 is 4 bytes width and can only be
>> accessed
>> by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and
>> HDMI2.0
>> support.
>>
>> To reuse the imx-hdmi driver, we make this patch set:
>> (1): fix some CodingStyle warning to make checkpatch happy
>> (2): convert imx-hdmi to drm_bridge
>> (3): split platform specific code
>> (4): move imx-hdmi to bridge/dw_hdmi
>> (5): extend dw_hdmi.c to support rk3288 hdmi
>> (6): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c
>>
>> Changes in v18:
>> - remove a multiple blank lines in imx-hdmi.c
>> - fix a checkpatch warning in imx-hdmi_pltfm.c
>> - add port bindings
>> - correct some spelling mistakes in dw_hdmi bindings doc
>> - correct some spelling mistakes in dw_hdmi-rockchip bindings doc
>>
>> Changes in v17:
>> - remove platform device stuff, adviced by Russell King
>> - remove prompt message of dw_hdmi, adviced by Russel King
>> - parse resource and irq in platform driver
>>
>> Changes in v16:
>> - use the common binding for the clocks
>> - describe ddc-i2c-bus as optional
>> - add common clocks bindings
>> - modify clocks bindings
>> - descrbie ddc-i2c-bus as optional
>>
>> Changes in v15:
>> - add prefix dw_hdmi/DW_HDMI for public used dw_hdmi structs
>>adviced by Philipp Zabel
>> - remove THIS_MODULE in platform driver
>> - remove unio of the multi-byte register access, adviced by Philipp
>> Zabel
>> - remove THIS_MODULE in platform driver
>>
>> Changes in v14:
>> - add defer probing, adviced by Philipp Zabel
>> - remove drm_connector_register, because imx-drm core has registered
>> connector
>>
>> Changes in v13:
>> - patch against drm-next
>> - split platform specific phy configuration
>> - split phy configuration from patch#4
>>
>> Changes in v12:
>> - refactor of_node_put(ddc_node)
>> - squash patch
>> - add comment for the depend on patch
>>
>> Changes in v11:
>> - squash patch
>>
>> Changes in v10:
>> - split generic dw_hdmi.c improvements from patch#11 (add rk3288
>> support)
>> - add more display mode support mpll configuration for rk3288
>>
>> Changes in v9:
>> - move some phy configuration to platform driver
>>
>> Changes in v8:
>> - correct some spelling mistake
>> - modify ddc-i2c-bus and interrupt description
>> - Add documentation for rockchip dw hdmi
>>
>> Changes in v7:
>> - remove unused variables from structure dw_hdmi
>> - remove a wrong modification
>> - add copyrights for dw_hdmi-imx.c
>>
>> Changes in v6:
>> - rearrange the patch order
>> - refactor register access without reg_shift
>>
>> Changes in v5:
>> - refactor reg-io-width
>>
>> Changes in v4:
>> - fix checkpatch CHECK
>> - defer probe ddc i2c adapter
>>
>> Changes in v3:
>> - split multi-register access to one indepent patch
>>
>> Andy Yan (12):
>>drm: imx: imx-hdmi: make checkpatch happy
>>drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter
>>drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
>>drm: imx: imx-hdmi: split phy configuration to platform driver
>>drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
>>dt-bindings: add document for dw_hdmi
>>drm: bridge/dw_hdmi: add support for multi-byte register width access
>>drm: bridge/dw_hdmi: add mode_valid support
>>drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in
>> hdmi_phy_wait_i2c_done
>>drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare
>>dt-bindings: Add documentation for rockchip dw hdmi
>>drm: bridge/dw_hdmi: add rockchip rk3288 support
>>
>> .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 50 ++
>> .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 46 ++
>> drivers/gpu/drm/bridge/Kconfig | 5 +
>> drivers/gpu/drm/bridge/Makefile| 1 +
>> .../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} | 717
>> ++---
>> .../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} | 4 +-
>> drivers/gpu/drm/imx/Kconfig| 1 +
>> drivers/gpu/drm/imx/Makefile | 2 +-
>> drivers/gpu/drm/imx/dw_hdmi-imx.c | 258
>> drivers/gpu/drm/rockchip/Kconfig | 10 +
>> drivers/gpu/drm/rockchip/Makefile | 2 +
>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 341 ++
>> include/drm/bridge/dw_hdmi.h | 61 ++
>> 13 files changed, insertions(+), 387 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> create mode 100644
>> Documentation/devicetree/bindings/video/dw_hdmi-rockchip.t
[PATCH v9 3/4] ASoC: tda998x: add a codec to the HDMI transmitter
On 01/07/15 10:51, Jean-Francois Moine wrote:
> This patch adds a CODEC to the NXP TDA998x HDMI transmitter.
>
> The CODEC handles both I2S and S/PDIF inputs.
> It maintains the audio format and rate constraints according
> to the HDMI device parameters (EDID) and sets dynamically the input
> ports in the TDA998x I2C driver on start/stop audio streaming.
>
> Signed-off-by: Jean-Francois Moine
> ---
> drivers/gpu/drm/i2c/Kconfig | 1 +
> drivers/gpu/drm/i2c/tda998x_drv.c | 139 --
> include/sound/tda998x.h | 23 +
> sound/soc/codecs/Kconfig | 4 +
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/tda998x.c| 175
> ++
> 6 files changed, 339 insertions(+), 5 deletions(-)
> create mode 100644 include/sound/tda998x.h
> create mode 100644 sound/soc/codecs/tda998x.c
>
> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> index 22c7ed6..24fc975 100644
> --- a/drivers/gpu/drm/i2c/Kconfig
> +++ b/drivers/gpu/drm/i2c/Kconfig
> @@ -28,6 +28,7 @@ config DRM_I2C_SIL164
> config DRM_I2C_NXP_TDA998X
> tristate "NXP Semiconductors TDA998X HDMI encoder"
> default m if DRM_TILCDC
> + select SND_SOC_TDA998X
Do you need this since sound/soc/codecs/Kconfig conditionally brings in the
CODEC driver?
> help
> Support for NXP Semiconductors TDA998X HDMI encoders.
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index ce1478d..a26a516 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -27,6 +27,11 @@
> #include
> #include
> #include
> +#include
> +
> +#if defined(CONFIG_SND_SOC_TDA998X) || defined(CONFIG_SND_SOC_TDA998X_MODULE)
> +#define WITH_CODEC 1
> +#endif
>
> #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>
> @@ -47,6 +52,10 @@ struct tda998x_priv {
> struct drm_encoder *encoder;
>
> u8 audio_ports[2];
> +#ifdef WITH_CODEC
> + u8 sad[3]; /* Short Audio Descriptor */
> + struct snd_pcm_hw_constraint_list rate_constraints;
> +#endif
> };
>
> #define to_tda998x_priv(x) ((struct tda998x_priv
> *)to_encoder_slave(x)->slave_priv)
> @@ -730,11 +739,109 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> tda998x_write_aif(priv, p);
> }
>
> +#ifdef WITH_CODEC
> +/* tda998x audio codec interface */
> +
> +/* return the audio parameters extracted from the last EDID */
> +static int tda998x_get_audio_var(struct device *dev,
> + u8 **sad,
> + struct snd_pcm_hw_constraint_list **rate_constraints)
> +{
> + struct tda998x_priv *priv = dev_get_drvdata(dev);
> +
> + if (!priv->encoder->crtc
> +|| !priv->is_hdmi_sink)
> + return -ENODEV;
> +
> + *sad = priv->sad;
> + *rate_constraints = &priv->rate_constraints;
> + return 0;
> +}
> +
> +/* switch the audio port and initialize the audio parameters for streaming */
> +static int tda998x_set_audio_input(struct device *dev,
> + int port_index,
> + unsigned sample_rate,
> + int sample_format)
> +{
> + struct tda998x_priv *priv = dev_get_drvdata(dev);
> + struct tda998x_encoder_params *p = &priv->params;
> +
> + if (!priv->encoder->crtc)
> + return -ENODEV;
> +
> + /* if no port, just disable the audio port */
> + if (port_index == PORT_NONE) {
> + reg_write(priv, REG_ENA_AP, 0);
> + return 0;
> + }
> +
> + /* if same audio parameters, just enable the audio port */
> + if (p->audio_cfg == priv->audio_ports[port_index] &&
> + p->audio_sample_rate == sample_rate) {
> + reg_write(priv, REG_ENA_AP, p->audio_cfg);
> + return 0;
> + }
> +
> + p->audio_format = port_index == PORT_SPDIF ? AFMT_SPDIF : AFMT_I2S;
> + p->audio_clk_cfg = port_index == PORT_SPDIF ? 0 : 1;
> + p->audio_cfg = priv->audio_ports[port_index];
> + p->audio_sample_rate = sample_rate;
> + tda998x_configure_audio(priv, &priv->encoder->crtc->hwmode, p);
> + return 0;
> +}
> +
> +/* get the audio capabilities from the EDID */
> +static void tda998x_get_audio_caps(struct tda998x_priv *priv,
> + struct drm_connector *connector)
> +{
> + u8 *eld = connector->eld;
> + u8 *sad;
> + int sad_count;
> + unsigned eld_ver, mnl;
> + u8 max_channels, rate_mask, fmt;
> +
> + /* adjust the hw params from the ELD (EDID) */
> + eld_ver = eld[0] >> 3;
> + if (eld_ver != 2 && eld_ver != 31)
> + return;
> +
> + mnl = eld[4] & 0x1f;
> + if (mnl > 16)
> + return;
> +
> + sad_count = eld[5] >> 4;
> + sad = eld + 20 +
[patch] drm/tegra: bad irqsave/restore in tegra_dc_finish_page_flip()
On Wed, Jan 07, 2015 at 02:01:26PM +0300, Dan Carpenter wrote: > We can't save two values to the IRQ flags at the same time so the IRQs > are not enabled at the end. This kind of bug is easy to miss in testing > if the function is normally called with IRQs disabled so we wouldn't > enable IRQs anyway. > > Signed-off-by: Dan Carpenter Good catch, applied. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/01701271/attachment.sig>
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
On 01/07/15 09:10, Jean-Francois Moine wrote:
> This patch permits the definition of the audio ports from the device tree.
>
> Signed-off-by: Jean-Francois Moine
> ---
> .../devicetree/bindings/drm/i2c/tda998x.txt| 18 +++
> drivers/gpu/drm/i2c/tda998x_drv.c | 60
> ++
> 2 files changed, 69 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> index e9e4bce..e50e7cd 100644
> --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> @@ -17,6 +17,20 @@ Optional properties:
>- video-ports: 24 bits value which defines how the video controller
> output is wired to the TDA998x input - default: <0x230145>
>
> + - audio-ports: must contain one or two values selecting the source
> + in the audio port.
> + The source type is given by the corresponding entry in
> + the audio-port-names property.
I think that this entry might benefit from a little more explanation.
The value specified here selects which pins on the chip provide the
audio input doesn't it? In the outline datasheet that I have these are
listed in table 17:
Audio port Input configuration
S/PDIF I2S-bus
AP0 - WS (word select)
AP1 S/PDIF inputI2S-bus channel 0
AP2 S/PDIF inputI2S-bus channel 1
AP3[1] I2S-bus channel 2
AP4[1] I2S-bus channel 3
ACLK- SCK (I2S-bus clock)
[1] Depending on package.
Andrew
> +
> + - audio-port-names: must contain entries matching the entries in
> + the audio-ports property.
> + Each value may be "i2s" or "spdif", giving the type of
> + the audio source.
> +
> + - #sound-dai-cells: must be set to <1> for use with the simple-card.
> + The TDA998x audio CODEC always defines two DAIs.
> + The DAI 0 is the S/PDIF input and the DAI 1 is the I2S input.
> +
> Example:
>
> tda998x: hdmi-encoder {
> @@ -26,4 +40,8 @@ Example:
> interrupts = <27 2>;/* falling edge */
> pinctrl-0 = <&pmx_camera>;
> pinctrl-names = "default";
> +
> + audio-ports = <0x04>, <0x03>;
> + audio-port-names = "spdif", "i2s";
> + #sound-dai-cells = <1>;
> };
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 70658af..9d9b072 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -44,6 +45,8 @@ struct tda998x_priv {
> wait_queue_head_t wq_edid;
> volatile int wq_edid_wait;
> struct drm_encoder *encoder;
> +
> + u8 audio_ports[2];
> };
>
> #define to_tda998x_priv(x) ((struct tda998x_priv
> *)to_encoder_slave(x)->slave_priv)
> @@ -1254,12 +1257,16 @@ static int tda998x_create(struct i2c_client *client,
> struct tda998x_priv *priv)
> {
> struct device_node *np = client->dev.of_node;
> u32 video;
> - int rev_lo, rev_hi, ret;
> + int i, rev_lo, rev_hi, ret;
> + const char *p;
>
> priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
> priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
> priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5);
>
> + priv->params.audio_frame[1] = 1;/* channels - 1 */
> + priv->params.audio_sample_rate = 48000; /* 48kHz */
> +
> priv->current_page = 0xff;
> priv->hdmi = client;
> priv->cec = i2c_new_dummy(client->adapter, 0x34);
> @@ -1351,15 +1358,50 @@ static int tda998x_create(struct i2c_client *client,
> struct tda998x_priv *priv)
> /* enable EDID read irq: */
> reg_set(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD);
>
> - if (!np)
> - return 0; /* non-DT */
> + /* get the device tree parameters */
> + if (np) {
> +
> + /* optional video properties */
> + ret = of_property_read_u32(np, "video-ports", &video);
> + if (ret == 0) {
> + priv->vip_cntrl_0 = video >> 16;
> + priv->vip_cntrl_1 = video >> 8;
> + priv->vip_cntrl_2 = video;
> + }
> +
> + /* optional audio properties */
> + for (i = 0; i < 2; i++) {
> + u32 port;
>
> - /* get the optional video properties */
> - ret = of_property_read_u32(np, "video-ports", &video);
> - if (ret == 0) {
> - priv->vip_cntrl_0 = video >> 16;
> - priv->vip_cntrl_1 = video >> 8;
> - priv->vip_cntrl_2 = video;
> + ret = of_property_read_u32
[PATCH] amdkfd: Drop interrupt SW ring buffer
Hi Michel,
So your patch is quite, hmm, *drastic* :)
Instead, could I suggest to only remove the calls to kfd_interrupt_init()
and kfd_interrupt_exit() ? It will also require a minor modification to the
logic in kgd2kfd_interrupt() but it is much less intrusive than what you are
suggesting.
Alternatively, we could take just this hunk:
> @@ -296,13 +286,5 @@ int kgd2kfd_resume(struct kfd_dev *kfd)
> /* This is called directly from KGD at ISR. */
> void kgd2kfd_interrupt(struct kfd_dev *kfd, const void *ih_ring_entry)
> {
> - if (kfd->init_complete) {
> - spin_lock(&kfd->interrupt_lock);
> -
> - if (kfd->interrupts_active
> - && enqueue_ih_ring_entry(kfd, ih_ring_entry))
> - schedule_work(&kfd->interrupt_work);
> -
> - spin_unlock(&kfd->interrupt_lock);
> - }
> + /* Process interrupts / schedule work as necessary */
> }
After all, we do need this feature eventually and most of it is fine, so I
don't want to take it all out. As I said, it is *drastic*.
Oded
On 01/07/2015 05:59 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The SW ring buffer was smaller than the corresponding hardware ring, so
> dmesg could get spammed by
>
> kfd kfd: Interrupt ring overflow, dropping interrupt.
>
> messages when running graphics apps.
>
> Since the SW ring buffer doesn't actually do anything at this point, just
> remove it for now. When actual interrupt processing code is added to
> amdkfd, it should try to do things immediately and only defer to work
> queues when necessary.
>
> Signed-off-by: Michel Dänzer
> ---
> drivers/gpu/drm/amd/amdkfd/Makefile| 3 +-
> drivers/gpu/drm/amd/amdkfd/kfd_device.c| 20 +---
> drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 176
> -
> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 15 ---
> 4 files changed, 2 insertions(+), 212 deletions(-)
> delete mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/Makefile
> b/drivers/gpu/drm/amd/amdkfd/Makefile
> index be6246d..307a309 100644
> --- a/drivers/gpu/drm/amd/amdkfd/Makefile
> +++ b/drivers/gpu/drm/amd/amdkfd/Makefile
> @@ -8,7 +8,6 @@ amdkfd-y := kfd_module.o kfd_device.o kfd_chardev.o
> kfd_topology.o \
> kfd_pasid.o kfd_doorbell.o kfd_flat_memory.o \
> kfd_process.o kfd_queue.o kfd_mqd_manager.o \
> kfd_kernel_queue.o kfd_packet_manager.o \
> - kfd_process_queue_manager.o kfd_device_queue_manager.o \
> - kfd_interrupt.o
> + kfd_process_queue_manager.o kfd_device_queue_manager.o
>
> obj-$(CONFIG_HSA_AMD)+= amdkfd.o
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> index 43884eb..633532a 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
> @@ -192,13 +192,6 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
> goto kfd_topology_add_device_error;
> }
>
> - if (kfd_interrupt_init(kfd)) {
> - dev_err(kfd_device,
> - "Error initializing interrupts for device (%x:%x)\n",
> - kfd->pdev->vendor, kfd->pdev->device);
> - goto kfd_interrupt_error;
> - }
> -
> if (!device_iommu_pasid_init(kfd)) {
> dev_err(kfd_device,
> "Error initializing iommuv2 for device (%x:%x)\n",
> @@ -237,8 +230,6 @@ dqm_start_error:
> device_queue_manager_error:
> amd_iommu_free_device(kfd->pdev);
> device_iommu_pasid_error:
> - kfd_interrupt_exit(kfd);
> -kfd_interrupt_error:
> kfd_topology_remove_device(kfd);
> kfd_topology_add_device_error:
> kfd2kgd->fini_sa_manager(kfd->kgd);
> @@ -254,7 +245,6 @@ void kgd2kfd_device_exit(struct kfd_dev *kfd)
> if (kfd->init_complete) {
> device_queue_manager_uninit(kfd->dqm);
> amd_iommu_free_device(kfd->pdev);
> - kfd_interrupt_exit(kfd);
> kfd_topology_remove_device(kfd);
> }
>
> @@ -296,13 +286,5 @@ int kgd2kfd_resume(struct kfd_dev *kfd)
> /* This is called directly from KGD at ISR. */
> void kgd2kfd_interrupt(struct kfd_dev *kfd, const void *ih_ring_entry)
> {
> - if (kfd->init_complete) {
> - spin_lock(&kfd->interrupt_lock);
> -
> - if (kfd->interrupts_active
> - && enqueue_ih_ring_entry(kfd, ih_ring_entry))
> - schedule_work(&kfd->interrupt_work);
> -
> - spin_unlock(&kfd->interrupt_lock);
> - }
> + /* Process interrupts / schedule work as necessary */
> }
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
> deleted file mode 100644
> index 5b99909..000
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
> +++ /dev/null
> @@ -1,176 +0,0 @@
> -/*
> - * Copyright 2014
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 Alex Deucher changed: What|Removed |Added Component|DRM/AMDgpu |Drivers/Gallium/r600 Version|XOrg git|unspecified Product|DRI |Mesa -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/7e9bbc24/attachment-0001.html>
[patch] drm/tegra: bad irqsave/restore in tegra_dc_finish_page_flip()
We can't save two values to the IRQ flags at the same time so the IRQs
are not enabled at the end. This kind of bug is easy to miss in testing
if the function is normally called with IRQs disabled so we wouldn't
enable IRQs anyway.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index ae26cc0..c746161 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -838,7 +838,7 @@ static void tegra_dc_finish_page_flip(struct tegra_dc *dc)
bo = tegra_fb_get_plane(crtc->primary->fb, 0);
- spin_lock_irqsave(&dc->lock, flags);
+ spin_lock(&dc->lock);
/* check if new start address has been latched */
tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
@@ -846,7 +846,7 @@ static void tegra_dc_finish_page_flip(struct tegra_dc *dc)
base = tegra_dc_readl(dc, DC_WINBUF_START_ADDR);
tegra_dc_writel(dc, 0, DC_CMD_STATE_ACCESS);
- spin_unlock_irqrestore(&dc->lock, flags);
+ spin_unlock(&dc->lock);
if (base == bo->paddr + crtc->primary->fb->offsets[0]) {
drm_crtc_send_vblank_event(crtc, dc->event);
[PATCH] imx: bridge/dw_hdmi: request interrupt only after initializing the mutes
Otherwise a spurious interrupt might trigger (and crash) the interrupt handler before probing finished. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/bridge/dw_hdmi.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c index 80bb512..4cc4569 100644 --- a/drivers/gpu/drm/bridge/dw_hdmi.c +++ b/drivers/gpu/drm/bridge/dw_hdmi.c @@ -1605,12 +1605,6 @@ int dw_hdmi_bind(struct device *dev, struct device *master, dev_dbg(hdmi->dev, "no ddc property found\n"); } - ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq, - dw_hdmi_irq, IRQF_SHARED, - dev_name(dev), hdmi); - if (ret) - return ret; - hdmi->regs = devm_ioremap_resource(dev, iores); if (IS_ERR(hdmi->regs)) return PTR_ERR(hdmi->regs); @@ -1651,6 +1645,12 @@ int dw_hdmi_bind(struct device *dev, struct device *master, initialize_hdmi_ih_mutes(hdmi); + ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq, + dw_hdmi_irq, IRQF_SHARED, + dev_name(dev), hdmi); + if (ret) + return ret; + /* * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator * N and cts values before enabling phy -- 2.1.4
[PATCH] amdkfd: Drop interrupt SW ring buffer
From: Michel Dänzer
The SW ring buffer was smaller than the corresponding hardware ring, so
dmesg could get spammed by
kfd kfd: Interrupt ring overflow, dropping interrupt.
messages when running graphics apps.
Since the SW ring buffer doesn't actually do anything at this point, just
remove it for now. When actual interrupt processing code is added to
amdkfd, it should try to do things immediately and only defer to work
queues when necessary.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdkfd/Makefile| 3 +-
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 20 +---
drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 176 -
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 15 ---
4 files changed, 2 insertions(+), 212 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
diff --git a/drivers/gpu/drm/amd/amdkfd/Makefile
b/drivers/gpu/drm/amd/amdkfd/Makefile
index be6246d..307a309 100644
--- a/drivers/gpu/drm/amd/amdkfd/Makefile
+++ b/drivers/gpu/drm/amd/amdkfd/Makefile
@@ -8,7 +8,6 @@ amdkfd-y:= kfd_module.o kfd_device.o kfd_chardev.o
kfd_topology.o \
kfd_pasid.o kfd_doorbell.o kfd_flat_memory.o \
kfd_process.o kfd_queue.o kfd_mqd_manager.o \
kfd_kernel_queue.o kfd_packet_manager.o \
- kfd_process_queue_manager.o kfd_device_queue_manager.o \
- kfd_interrupt.o
+ kfd_process_queue_manager.o kfd_device_queue_manager.o
obj-$(CONFIG_HSA_AMD) += amdkfd.o
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 43884eb..633532a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -192,13 +192,6 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
goto kfd_topology_add_device_error;
}
- if (kfd_interrupt_init(kfd)) {
- dev_err(kfd_device,
- "Error initializing interrupts for device (%x:%x)\n",
- kfd->pdev->vendor, kfd->pdev->device);
- goto kfd_interrupt_error;
- }
-
if (!device_iommu_pasid_init(kfd)) {
dev_err(kfd_device,
"Error initializing iommuv2 for device (%x:%x)\n",
@@ -237,8 +230,6 @@ dqm_start_error:
device_queue_manager_error:
amd_iommu_free_device(kfd->pdev);
device_iommu_pasid_error:
- kfd_interrupt_exit(kfd);
-kfd_interrupt_error:
kfd_topology_remove_device(kfd);
kfd_topology_add_device_error:
kfd2kgd->fini_sa_manager(kfd->kgd);
@@ -254,7 +245,6 @@ void kgd2kfd_device_exit(struct kfd_dev *kfd)
if (kfd->init_complete) {
device_queue_manager_uninit(kfd->dqm);
amd_iommu_free_device(kfd->pdev);
- kfd_interrupt_exit(kfd);
kfd_topology_remove_device(kfd);
}
@@ -296,13 +286,5 @@ int kgd2kfd_resume(struct kfd_dev *kfd)
/* This is called directly from KGD at ISR. */
void kgd2kfd_interrupt(struct kfd_dev *kfd, const void *ih_ring_entry)
{
- if (kfd->init_complete) {
- spin_lock(&kfd->interrupt_lock);
-
- if (kfd->interrupts_active
- && enqueue_ih_ring_entry(kfd, ih_ring_entry))
- schedule_work(&kfd->interrupt_work);
-
- spin_unlock(&kfd->interrupt_lock);
- }
+ /* Process interrupts / schedule work as necessary */
}
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
deleted file mode 100644
index 5b99909..000
--- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
+++ /dev/null
@@ -1,176 +0,0 @@
-/*
- * Copyright 2014 Advanced Micro Devices, Inc.
- *
- * 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.
- */
-
-/*
- * KFD Interrupts.
- *
- * AMD GPUs deliver interrupts by pushing an interrupt description onto the
- * interrupt
[PATCH v9 0/4] ASoC: tda998x: add a codec to the HDMI transmitter
Based on 3.19.0-rc3. v9: - back to a TDA998x specific CODEC - more comments - change magic values to constants v8: - change some comments about the patches v7: - remove the change of the K predivider (Jyri Sarha) - add S24_3LE and S32_LE as possible audio formats (Jyri Sarha) - don't move the struct priv2 definition and use the slave encoder private data as the device private data (Russell King) - remove the useless request_module (Russell King/Mark Brown) - don't lock the HDMI module (Russell King) - use platform_device_unregister to remove the codec (Russell King) v6: - extend the HDMI CODEC instead of using a specific CODEC v5: - use the TDA998x private data instead of a specific area for the CODEC interface - the CODEC is TDA998x specific (Mark Brown) v4: - remove all the TDA998x specific stuff from the CODEC - move the EDID scan from the CODEC to the TDA998x - move the CODEC to sound/soc (Mark Brown) - update the audio_sample_rate from the EDID (Andrew Jackson) v3: fix bad rate (Andrew Jackson) v2: check double stream start (Mark Brown) Jean-Francois Moine (4): drm/i2c: tda998x: Add DT support for audio drm/i2c: tda998x: Change drvdata for audio extension ASoC: tda998x: add a codec to the HDMI transmitter drm/i2c: tda998x: set cts_n according to the sample width .../devicetree/bindings/drm/i2c/tda998x.txt| 18 ++ drivers/gpu/drm/i2c/Kconfig| 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 213 +++-- include/sound/tda998x.h| 23 +++ sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tda998x.c | 175 + 7 files changed, 424 insertions(+), 12 deletions(-) create mode 100644 include/sound/tda998x.h create mode 100644 sound/soc/codecs/tda998x.c -- 2.1.4
[PATCH v9 4/4] drm/i2c: tda998x: set cts_n according to the sample width
With I2S input, the CTS_N predivider depends on the sample width.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index a26a516..8af84cd 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -50,6 +50,7 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+ int audio_sample_format;
u8 audio_ports[2];
#ifdef WITH_CODEC
@@ -671,7 +672,17 @@ tda998x_configure_audio(struct tda998x_priv *priv,
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
- cts_n = CTS_N_M(3) | CTS_N_K(3);
+
+ /* with I2S input, the CTS_N predivider depends on
+* the sample width */
+ switch (priv->audio_sample_format) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ cts_n = CTS_N_M(3) | CTS_N_K(1);
+ break;
+ default:
+ cts_n = CTS_N_M(3) | CTS_N_K(3);
+ break;
+ }
break;
default:
@@ -778,7 +789,8 @@ static int tda998x_set_audio_input(struct device *dev,
/* if same audio parameters, just enable the audio port */
if (p->audio_cfg == priv->audio_ports[port_index] &&
- p->audio_sample_rate == sample_rate) {
+ p->audio_sample_rate == sample_rate &&
+ priv->audio_sample_format == sample_format) {
reg_write(priv, REG_ENA_AP, p->audio_cfg);
return 0;
}
@@ -787,6 +799,7 @@ static int tda998x_set_audio_input(struct device *dev,
p->audio_clk_cfg = port_index == PORT_SPDIF ? 0 : 1;
p->audio_cfg = priv->audio_ports[port_index];
p->audio_sample_rate = sample_rate;
+ priv->audio_sample_format = sample_format;
tda998x_configure_audio(priv, &priv->encoder->crtc->hwmode, p);
return 0;
}
@@ -1388,6 +1401,7 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
priv->params.audio_frame[1] = 1;/* channels - 1 */
priv->params.audio_sample_rate = 48000; /* 48kHz */
+ priv->audio_sample_format = SNDRV_PCM_FORMAT_S24_LE;
priv->current_page = 0xff;
priv->hdmi = client;
--
2.1.4
[PATCH v9 3/4] ASoC: tda998x: add a codec to the HDMI transmitter
This patch adds a CODEC to the NXP TDA998x HDMI transmitter.
The CODEC handles both I2S and S/PDIF inputs.
It maintains the audio format and rate constraints according
to the HDMI device parameters (EDID) and sets dynamically the input
ports in the TDA998x I2C driver on start/stop audio streaming.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/Kconfig | 1 +
drivers/gpu/drm/i2c/tda998x_drv.c | 139 --
include/sound/tda998x.h | 23 +
sound/soc/codecs/Kconfig | 4 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tda998x.c| 175 ++
6 files changed, 339 insertions(+), 5 deletions(-)
create mode 100644 include/sound/tda998x.h
create mode 100644 sound/soc/codecs/tda998x.c
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..24fc975 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -28,6 +28,7 @@ config DRM_I2C_SIL164
config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+ select SND_SOC_TDA998X
help
Support for NXP Semiconductors TDA998X HDMI encoders.
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index ce1478d..a26a516 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -27,6 +27,11 @@
#include
#include
#include
+#include
+
+#if defined(CONFIG_SND_SOC_TDA998X) || defined(CONFIG_SND_SOC_TDA998X_MODULE)
+#define WITH_CODEC 1
+#endif
#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
@@ -47,6 +52,10 @@ struct tda998x_priv {
struct drm_encoder *encoder;
u8 audio_ports[2];
+#ifdef WITH_CODEC
+ u8 sad[3]; /* Short Audio Descriptor */
+ struct snd_pcm_hw_constraint_list rate_constraints;
+#endif
};
#define to_tda998x_priv(x) ((struct tda998x_priv
*)to_encoder_slave(x)->slave_priv)
@@ -730,11 +739,109 @@ tda998x_configure_audio(struct tda998x_priv *priv,
tda998x_write_aif(priv, p);
}
+#ifdef WITH_CODEC
+/* tda998x audio codec interface */
+
+/* return the audio parameters extracted from the last EDID */
+static int tda998x_get_audio_var(struct device *dev,
+ u8 **sad,
+ struct snd_pcm_hw_constraint_list **rate_constraints)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+
+ if (!priv->encoder->crtc
+|| !priv->is_hdmi_sink)
+ return -ENODEV;
+
+ *sad = priv->sad;
+ *rate_constraints = &priv->rate_constraints;
+ return 0;
+}
+
+/* switch the audio port and initialize the audio parameters for streaming */
+static int tda998x_set_audio_input(struct device *dev,
+ int port_index,
+ unsigned sample_rate,
+ int sample_format)
+{
+ struct tda998x_priv *priv = dev_get_drvdata(dev);
+ struct tda998x_encoder_params *p = &priv->params;
+
+ if (!priv->encoder->crtc)
+ return -ENODEV;
+
+ /* if no port, just disable the audio port */
+ if (port_index == PORT_NONE) {
+ reg_write(priv, REG_ENA_AP, 0);
+ return 0;
+ }
+
+ /* if same audio parameters, just enable the audio port */
+ if (p->audio_cfg == priv->audio_ports[port_index] &&
+ p->audio_sample_rate == sample_rate) {
+ reg_write(priv, REG_ENA_AP, p->audio_cfg);
+ return 0;
+ }
+
+ p->audio_format = port_index == PORT_SPDIF ? AFMT_SPDIF : AFMT_I2S;
+ p->audio_clk_cfg = port_index == PORT_SPDIF ? 0 : 1;
+ p->audio_cfg = priv->audio_ports[port_index];
+ p->audio_sample_rate = sample_rate;
+ tda998x_configure_audio(priv, &priv->encoder->crtc->hwmode, p);
+ return 0;
+}
+
+/* get the audio capabilities from the EDID */
+static void tda998x_get_audio_caps(struct tda998x_priv *priv,
+ struct drm_connector *connector)
+{
+ u8 *eld = connector->eld;
+ u8 *sad;
+ int sad_count;
+ unsigned eld_ver, mnl;
+ u8 max_channels, rate_mask, fmt;
+
+ /* adjust the hw params from the ELD (EDID) */
+ eld_ver = eld[0] >> 3;
+ if (eld_ver != 2 && eld_ver != 31)
+ return;
+
+ mnl = eld[4] & 0x1f;
+ if (mnl > 16)
+ return;
+
+ sad_count = eld[5] >> 4;
+ sad = eld + 20 + mnl;
+
+ /* Start from the basic audio settings */
+ max_channels = 1;
+ rate_mask = 0;
+ fmt = 0;
+ while (sad_count--) {
+ switch (sad[0] & 0x78) {
+ case 0x08: /* SAD uncompressed audio */
+ if ((sad[0] & 7) > max_channels)
+ max_channels = sad[0] & 7;
+ rat
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #3 from Arthur Marsh --- Created attachment 111906 --> https://bugs.freedesktop.org/attachment.cgi?id=111906&action=edit 20150107dmesg.txt -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/a456fa9f/attachment.html>
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #2 from Arthur Marsh --- Created attachment 111905 --> https://bugs.freedesktop.org/attachment.cgi?id=111905&action=edit 2015010719dmesg.txt -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/aface3c9/attachment.html>
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
https://bugs.freedesktop.org/show_bug.cgi?id=88152 --- Comment #1 from Arthur Marsh --- Created attachment 111904 --> https://bugs.freedesktop.org/attachment.cgi?id=111904&action=edit dmesg output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/3219d45d/attachment.html>
[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD
2 8192 8192 A88192 8192 Video mixer: feature namesup DEINTERLACE_TEMPORAL y DEINTERLACE_TEMPORAL_SPATIAL - INVERSE_TELECINE - NOISE_REDUCTION y SHARPNESSy LUMA_KEY - HIGH QUALITY SCALING - L1- HIGH QUALITY SCALING - L2- HIGH QUALITY SCALING - L3- HIGH QUALITY SCALING - L4- HIGH QUALITY SCALING - L5- HIGH QUALITY SCALING - L6- HIGH QUALITY SCALING - L7- HIGH QUALITY SCALING - L8- HIGH QUALITY SCALING - L9- parameter name sup min max - VIDEO_SURFACE_WIDTH y48 2048 VIDEO_SURFACE_HEIGHT y48 1152 CHROMA_TYPE y LAYERS y 04 attribute name sup min max - BACKGROUND_COLOR y CSC_MATRIX y NOISE_REDUCTION_LEVELy 0.00 1.00 SHARPNESS_LEVEL y -1.00 1.00 LUMA_KEY_MIN_LUMAy LUMA_KEY_MAX_LUMAy I am happy to supply additional information or try things to narrow down the source of the problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/57898dc5/attachment-0001.html>
[PATCH v9 2/4] drm/i2c: tda998x: Change drvdata for audio extension
The device drvdata is used for component bind, but points to the
encoder/connector structure which is hidden from the slave encoder.
For audio extension, the slave encoder private data must be accessible,
so, this patch changes drvdata to the slave encoder private data and
sets it in case of slave encoder use.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 9d9b072..ce1478d 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1437,6 +1437,8 @@ static int tda998x_encoder_init(struct i2c_client *client,
encoder_slave->slave_priv = priv;
encoder_slave->slave_funcs = &tda998x_encoder_slave_funcs;
+ dev_set_drvdata(&client->dev, priv);
+
return 0;
}
@@ -1563,7 +1565,7 @@ static int tda998x_bind(struct device *dev, struct device
*master, void *data)
if (!priv)
return -ENOMEM;
- dev_set_drvdata(dev, priv);
+ dev_set_drvdata(dev, &priv->base);
priv->base.encoder = &priv->encoder;
priv->connector.interlace_allowed = 1;
@@ -1613,7 +1615,9 @@ err_encoder:
static void tda998x_unbind(struct device *dev, struct device *master,
void *data)
{
- struct tda998x_priv2 *priv = dev_get_drvdata(dev);
+ struct tda998x_priv *priv_s = dev_get_drvdata(dev);
+ struct tda998x_priv2 *priv =
+ container_of(priv_s, struct tda998x_priv2, base);
drm_connector_cleanup(&priv->connector);
drm_encoder_cleanup(&priv->encoder);
--
2.1.4
[PATCH v18 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi
On 12/05/2014 02:22 PM, Andy Yan wrote:
>
> We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
> use the interface compatible Designware HDMI IP, but they also have some
> lightly differences, such as phy pll configuration, register width(imx hdmi
> register is one byte, but rk3288 is 4 bytes width and can only be accessed
> by word), 4K support(imx6 doesn't support 4k, but rk3288 does), and HDMI2.0
> support.
>
> To reuse the imx-hdmi driver, we make this patch set:
> (1): fix some CodingStyle warning to make checkpatch happy
> (2): convert imx-hdmi to drm_bridge
> (3): split platform specific code
> (4): move imx-hdmi to bridge/dw_hdmi
> (5): extend dw_hdmi.c to support rk3288 hdmi
> (6): add rockchip rk3288 platform specific code dw_hdmi-rockchip.c
>
> Changes in v18:
> - remove a multiple blank lines in imx-hdmi.c
> - fix a checkpatch warning in imx-hdmi_pltfm.c
> - add port bindings
> - correct some spelling mistakes in dw_hdmi bindings doc
> - correct some spelling mistakes in dw_hdmi-rockchip bindings doc
>
> Changes in v17:
> - remove platform device stuff, adviced by Russell King
> - remove prompt message of dw_hdmi, adviced by Russel King
> - parse resource and irq in platform driver
>
> Changes in v16:
> - use the common binding for the clocks
> - describe ddc-i2c-bus as optional
> - add common clocks bindings
> - modify clocks bindings
> - descrbie ddc-i2c-bus as optional
>
> Changes in v15:
> - add prefix dw_hdmi/DW_HDMI for public used dw_hdmi structs
>adviced by Philipp Zabel
> - remove THIS_MODULE in platform driver
> - remove unio of the multi-byte register access, adviced by Philipp Zabel
> - remove THIS_MODULE in platform driver
>
> Changes in v14:
> - add defer probing, adviced by Philipp Zabel
> - remove drm_connector_register, because imx-drm core has registered
> connector
>
> Changes in v13:
> - patch against drm-next
> - split platform specific phy configuration
> - split phy configuration from patch#4
>
> Changes in v12:
> - refactor of_node_put(ddc_node)
> - squash patch
> - add comment for the depend on patch
>
> Changes in v11:
> - squash patch
>
> Changes in v10:
> - split generic dw_hdmi.c improvements from patch#11 (add rk3288 support)
> - add more display mode support mpll configuration for rk3288
>
> Changes in v9:
> - move some phy configuration to platform driver
>
> Changes in v8:
> - correct some spelling mistake
> - modify ddc-i2c-bus and interrupt description
> - Add documentation for rockchip dw hdmi
>
> Changes in v7:
> - remove unused variables from structure dw_hdmi
> - remove a wrong modification
> - add copyrights for dw_hdmi-imx.c
>
> Changes in v6:
> - rearrange the patch order
> - refactor register access without reg_shift
>
> Changes in v5:
> - refactor reg-io-width
>
> Changes in v4:
> - fix checkpatch CHECK
> - defer probe ddc i2c adapter
>
> Changes in v3:
> - split multi-register access to one indepent patch
>
> Andy Yan (12):
>drm: imx: imx-hdmi: make checkpatch happy
>drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter
>drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode
>drm: imx: imx-hdmi: split phy configuration to platform driver
>drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi
>dt-bindings: add document for dw_hdmi
>drm: bridge/dw_hdmi: add support for multi-byte register width access
>drm: bridge/dw_hdmi: add mode_valid support
>drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done
>drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare
>dt-bindings: Add documentation for rockchip dw hdmi
>drm: bridge/dw_hdmi: add rockchip rk3288 support
>
> .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 50 ++
> .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 46 ++
> drivers/gpu/drm/bridge/Kconfig | 5 +
> drivers/gpu/drm/bridge/Makefile| 1 +
> .../gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} | 717
> ++---
> .../gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} | 4 +-
> drivers/gpu/drm/imx/Kconfig| 1 +
> drivers/gpu/drm/imx/Makefile | 2 +-
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 258
> drivers/gpu/drm/rockchip/Kconfig | 10 +
> drivers/gpu/drm/rockchip/Makefile | 2 +
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 341 ++
> include/drm/bridge/dw_hdmi.h | 61 ++
> 13 files changed, insertions(+), 387 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
> create mode 100644
> Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
> rename drivers/gpu/drm/{imx/imx-hdmi.c => bridge/dw_hdmi.c} (72%)
> rename drivers/gpu/drm/{imx/imx-hdmi.h => bridge/dw_hdmi.h} (99%)
> create mode 100644 drivers/gpu/drm/imx/dw_hdmi-imx.c
> create mode 100644 dri
[PULL] drm-intel-next
Hi Dave, drm-intel-next-2014-12-19: - plane handling refactoring from Matt Roper and Gustavo Padovan in prep for atomic updates - fixes and more patches for the seqno to request transformation from John - docbook for fbc from Rodrigo - prep work for dual-link dsi from Gaurav Signh - crc fixes from Ville - special ggtt views infrastructure from Tvrtko Ursulin - shadow patch copying for the cmd parser from Brad Volkin - execlist and full ppgtt by default on gen8, for testing for now drm-intel-next-2014-12-05: - dual-dsi enabling from Gaurav with prep work from Jani - reshuffling the ring init code to move towards a clean sw/hw state setup split - ring free space refactoring from Dave Gordon - s/seqno/request/ rework from John Harrison - psr support for vlv/chv from Rodrigo - skl mmio flip support from Damien - and the usual bits&pieces all over Cheers, Daniel The following changes since commit 00f0b3781028605910cb4662a0f8a4849b445fc2: drm/i915: Reject modeset when the same digital port is used more than once (2014-12-03 09:31:53 +0100) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-12-19 for you to fetch changes up to 0e2cfc005b376ed7b5c9a9fc466b5842fcc18cc7: drm/i915: Update DRIVER_DATE to 20141219 (2014-12-19 16:21:42 +0100) - plane handling refactoring from Matt Roper and Gustavo Padovan in prep for atomic updates - fixes and more patches for the seqno to request transformation from John - docbook for fbc from Rodrigo - prep work for dual-link dsi from Gaurav Signh - crc fixes from Ville - special ggtt views infrastructure from Tvrtko Ursulin - shadow patch copying for the cmd parser from Brad Volkin - execlist and full ppgtt by default on gen8, for testing for now Ander Conselvan de Oliveira (1): drm/i915: Remove unnecessary goto in intel_primary_plane_disable() Brad Volkin (5): drm/i915: Implement a framework for batch buffer pools drm/i915: Use batch pools with the command parser drm/i915: Use batch length instead of object size in command parser drm/i915: Mark shadow batch buffers as purgeable drm/i915: Tidy up execbuffer command parsing code Chris Wilson (1): drm/i915: Assert that we successfully downclock the GPU before suspend Damien Lespiau (8): drm/i915/skl: Read out crtl1 for eDP/DPLL0 drm/i915/skl: Implement the skl version of MMIO flips drm/i915: Fix short description of intel_display_power_is_enabled() drm/i915/skl: Update the DDI translation values for DP/eDP 1.3 drm/i915: Don't display nonsensical values in i915_ddb_info on gen < 9 drm/i915: Add headers to the various render state drm/i915: Consolidate DDI clock reading out in a single function drm/i915/skl: Skylake also supports DP MST Daniel Vetter (16): drm/i915: Remove user pinning code drm/i915: Convert i915_wait_seqno to i915_wait_request drm/i915: Check locking in i915_gem_request_unreference drm/i915: Remove redundant flip_work->flip_queued_ring drm/i915: s/init()/init_hw()/ in intel_engine_cs drm/i915: Move intel_init_pipe_control out of engine->init_hw drm/i915: Only init engines once drm/i915: Flatten engine init control flow drm/i915: Move init_unused_rings to gem_init_hw drm/i915: Update DRIVER_DATE to 20141205 drm/i915: Move golden context init into ->init_context drm/i915: Check mask/bit helper functions drm/i915: Protect against leaks in pipe_crc_set_source drm/i915: Name the lrc irq handler correctly drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON drm/i915: Update DRIVER_DATE to 20141219 Dave Gordon (4): drm/i915: Check for matching ringbuffer in logical_ring_wait_request() drm/i915: Don't read 'HEAD' MMIO register in LRC mode drm/i915: Make ring freespace calculation more robust drm/i915: Consolidate ring freespace calculations Deepak M (1): drm/i915: Parsing LFP brightness control from VBT Deepak S (3): drm/i915: Forcewake Register Range changes for CHV drm/i915/chv: Use timeout mode for RC6 on chv drm/i915: Skip gunit save/restore for cherryview Gaurav K Singh (14): drm/i915: New functions added for enabling & disabling MIPI Port Ctrl reg drm/i915: Added port as parameter to the functions which does read/write of DSI Controller drm/i915: Add support for port enable/disable for dual link configuration drm/i915: Pixel Clock changes for DSI dual link drm/i915: Dual link needs Shutdown and Turn on packet for both ports drm/i915: Enable DSI PLL for both DSI0 and DSI1 in case of dual link drm/i915: cck reg used for checking DSI Pll locked drm/i915: MIPI Timings related changes for dual link drm/i915: Update the DSI disabl
[PATCH v9 1/4] drm/i2c: tda998x: Add DT support for audio
This patch permits the definition of the audio ports from the device tree.
Signed-off-by: Jean-Francois Moine
---
.../devicetree/bindings/drm/i2c/tda998x.txt| 18 +++
drivers/gpu/drm/i2c/tda998x_drv.c | 60 ++
2 files changed, 69 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index e9e4bce..e50e7cd 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -17,6 +17,20 @@ Optional properties:
- video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>
+ - audio-ports: must contain one or two values selecting the source
+ in the audio port.
+ The source type is given by the corresponding entry in
+ the audio-port-names property.
+
+ - audio-port-names: must contain entries matching the entries in
+ the audio-ports property.
+ Each value may be "i2s" or "spdif", giving the type of
+ the audio source.
+
+ - #sound-dai-cells: must be set to <1> for use with the simple-card.
+ The TDA998x audio CODEC always defines two DAIs.
+ The DAI 0 is the S/PDIF input and the DAI 1 is the I2S input.
+
Example:
tda998x: hdmi-encoder {
@@ -26,4 +40,8 @@ Example:
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <&pmx_camera>;
pinctrl-names = "default";
+
+ audio-ports = <0x04>, <0x03>;
+ audio-port-names = "spdif", "i2s";
+ #sound-dai-cells = <1>;
};
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 70658af..9d9b072 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,8 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+
+ u8 audio_ports[2];
};
#define to_tda998x_priv(x) ((struct tda998x_priv
*)to_encoder_slave(x)->slave_priv)
@@ -1254,12 +1257,16 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
{
struct device_node *np = client->dev.of_node;
u32 video;
- int rev_lo, rev_hi, ret;
+ int i, rev_lo, rev_hi, ret;
+ const char *p;
priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5);
+ priv->params.audio_frame[1] = 1;/* channels - 1 */
+ priv->params.audio_sample_rate = 48000; /* 48kHz */
+
priv->current_page = 0xff;
priv->hdmi = client;
priv->cec = i2c_new_dummy(client->adapter, 0x34);
@@ -1351,15 +1358,50 @@ static int tda998x_create(struct i2c_client *client,
struct tda998x_priv *priv)
/* enable EDID read irq: */
reg_set(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD);
- if (!np)
- return 0; /* non-DT */
+ /* get the device tree parameters */
+ if (np) {
+
+ /* optional video properties */
+ ret = of_property_read_u32(np, "video-ports", &video);
+ if (ret == 0) {
+ priv->vip_cntrl_0 = video >> 16;
+ priv->vip_cntrl_1 = video >> 8;
+ priv->vip_cntrl_2 = video;
+ }
+
+ /* optional audio properties */
+ for (i = 0; i < 2; i++) {
+ u32 port;
- /* get the optional video properties */
- ret = of_property_read_u32(np, "video-ports", &video);
- if (ret == 0) {
- priv->vip_cntrl_0 = video >> 16;
- priv->vip_cntrl_1 = video >> 8;
- priv->vip_cntrl_2 = video;
+ ret = of_property_read_u32_index(np, "audio-ports", i,
&port);
+ if (ret)
+ break;
+ ret = of_property_read_string_index(np,
"audio-port-names",
+ i, &p);
+ if (ret) {
+ dev_err(&client->dev,
+ "missing audio-port-names[%d]\n", i);
+ break;
+ }
+ if (strcmp(p, "spdif") == 0) {
+ priv->audio_ports[0] = port;
+ } else if (strcmp(p, "i2s") == 0) {
+ priv->audio_ports[1] = port;
+ } else {
+ dev_err(&client->dev,
+
"EDID checksum is invalid"
On Wed, Jan 7, 2015 at 9:51 AM, Daniel Vetter wrote: > > Not sure whether that'd be the same voltage rails, but > i915.disable_power_wells=0 disable all the runtime pm we do (which > does kick in for dpms off and shut down the entire display block and a > bunch more) I still get the "No HDMI (MHL) Cable" with that kernel command line, and the same failure to come back after an extended dpms off. So it doesn't seem to be related to the runtime pm you do on a chip level. Linus
"EDID checksum is invalid"
On Tue, Jan 6, 2015 at 11:32 PM, Daniel Vetter wrote: > > Yeah if the edid probe fails userspace will get a hotplug and > autodisable the output. With a failsafe X session (just a dumb > terminal) we can avoid that to check that dpms on itself would work or > whether the edid probe fail here is just indicative of more trouble. > Also please boot with drm.debug=0xe, repro and grab dmesg, that might > shed some more light on what's failing. Here is an annotated attachment with the dpms off output witj drm.debug=0xe. It turns out the real failure case doesn't seem to be when the bad EDID happens. See my notes interspersed with the dmesg output. Linus -- next part -- A non-text attachment was scrubbed... Name: dpms-failure Type: application/octet-stream Size: 79407 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/32ad4248/attachment-0001.obj>
[PATCH] drm: tda998x: Change cec_write address type
The CEC registers of the TDA998x have no access by page,
so, a 8 bits address is enough.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d476279..70658af 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -342,7 +342,7 @@ struct tda998x_priv {
#define TDA19988 0x0301
static void
-cec_write(struct tda998x_priv *priv, uint16_t addr, uint8_t val)
+cec_write(struct tda998x_priv *priv, uint8_t addr, uint8_t val)
{
struct i2c_client *client = priv->cec;
uint8_t buf[] = {addr, val};
--
2.1.4
[pull] radeon drm-fixes-3.19
Hi Dave, Some fixes for radeon. Nothing major. The following changes since commit 2f6bd4da08b5054ba933be6f7b17ed02ad6c4162: Merge tag 'amdkfd-fixes-2014-12-30' of git://people.freedesktop.org/~gabbayo/linux into linus (2015-01-04 17:44:43 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.19 for you to fetch changes up to dd5a74f2f982193620cfa1ef609df1ee805781d4: drm/radeon: integer underflow in radeon_cp_dispatch_texture() (2015-01-05 12:10:08 -0500) Alex Deucher (4): drm/radeon: KV has three PPLLs (v2) drm/radeon: fix sad_count check for dce3 drm/radeon: properly filter DP1.2 4k modes on non-DP1.2 hw drm/radeon: adjust default bapm settings for KV Dan Carpenter (1): drm/radeon: integer underflow in radeon_cp_dispatch_texture() drivers/gpu/drm/radeon/atombios_crtc.c | 8 drivers/gpu/drm/radeon/atombios_dp.c | 4 drivers/gpu/drm/radeon/dce3_1_afmt.c | 2 +- drivers/gpu/drm/radeon/kv_dpm.c| 10 -- drivers/gpu/drm/radeon/radeon_state.c | 2 +- 5 files changed, 14 insertions(+), 12 deletions(-)
[LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel
Kees Cook writes: > On Sun, Jan 4, 2015 at 8:28 PM, Rusty Russell > wrote: >> Kees, as far as I can tell you need another 0-terminated vmlinux.relocs >> section for weak symbols. These should not be relocated if already 0. > > A few questions: > > Why doesn't this break on 32-bit without kASLR? 32-bit does relocation > by default, even without CONFIG_RANDOMIZE_BASE. Well, the offset was 0 until I removed CONFIG_HIBERNATE. > Are there any symbols that are NULL that aren't weak? I'd expect all > strong symbols to have non-zero offsets, but I must be > misunderstanding something here. I don't think there would be. Anyway, you might be able to filter them out in x86/tools/relocs itself. Cheers, Rusty.
"EDID checksum is invalid"
On Tue, Jan 6, 2015 at 10:21 PM, Robert Morell wrote: > > FWIW, I've seen that exact symptom on some monitors when the +5V pin on > the DVI or HDMI cable from the GPU isn't enabled (or isn't providing > enough current). Some monitors power the i2c/edid/DDC logic from that > +5V either exclusively or when in the DPMS off state, and the i2c chip > will just stop responding after a few cycles if not provided sufficient > power. That makes a ton of sense, especially the "when in DPMS off state" case. I'll do the drm.debug=0xe thing, and maybe Daniel can make more sense of the details. Maybe the i2c driver ends up powering down too soon (or maybe it needs to power up a bit earlier)? This is a bog-standard intel motherboard (DH87RL), but I actually needed to update the BIOS for it to get it to POST reliably with this monitor. I was blaming that on the odd 3840x2160 at 30Hz mode, but maybe it's related to the EDID being finicky wrt i2c power. I'm assuming even the hdmi +5V line is under sw control at least for power management reasons. Maybe dpms off turns it off, and shouldn't? My monitor actually says "No HDMI (HML) Cable" when I do "xset dpms force off". Maybe that's normal, but maybe that's indicative of dpms turning things a bit *too* off? Linus
[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
On Tue, Jan 06, 2015 at 02:14:27PM +, Cheng, Yao wrote: > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Monday, January 5, 2015 16:40 > > To: Cheng, Yao > > Cc: Daniel Vetter; Thierry Reding; intel-gfx at lists.freedesktop.org; dri- > > devel at lists.freedesktop.org; Kelley, Sean V; Chehab, John; > > emil.l.velikov at gmail.com; Jiang, Fei; Beckett, Robert; Barbalho, Rafael > > Subject: Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support > > > > On Sun, Dec 21, 2014 at 02:40:24PM +, Cheng, Yao wrote: > > > > -Original Message- > > > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] > > > > Sent: Thursday, December 18, 2014 19:21 > > > > To: Thierry Reding > > > > Cc: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri- > > > > devel at lists.freedesktop.org; Kelley, Sean V; Chehab, John; > > > > emil.l.velikov at gmail.com; Jiang, Fei > > > > Subject: Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr > > > > support > > > > > > > > On Thu, Dec 18, 2014 at 11:04 AM, Thierry Reding > > > > > > > > wrote: > > > > >> I double checked the symptom and found it was a deadlock on > > > > drm_global_mutex. > > > > >> When i915_driver_load() registers the platform device while ipvr > > > > >> module > > > > is in the system, ipvr's probe() function tries to lock > > > > drm_global_mutex which was already held by i915. > > > > >> I think either of the following 2 actions need to be moved to a > > > > >> bottom half > > > > e.g. a work queue: > > > > >> platform_device_add () call in i915_ved.c (called during > > > > i915_driver_load()) > > > > >> drm_dev_register() call during ipvr's probe() Which one > > > > >> makes more sense? pls kindly advise (I personally prefer the former > > one.). > > > > > > > > > > Yes, that's somewhat ugly, but I don't see a way around that. I'd > > > > > also think that moving platform_device_add() to a workqueue would > > > > > be the best option here. > > > > > > > > Or we simply kill drm_global_mutex for platform drivers that don't > > > > use the - > > > > >probe hook. It should work when they have a correct order betwen > > > > drm_dev_alloc and _register and all the code in between. So just > > > > ditch the - > > > > >load callback in teh ipvr driver and rework the load sequence as > > > > >suggested > > > > somewhere else and this is fixed already. No need for bottom halfs I > > think. > > > > > > Daniel, sorry I didn't quite understand "platform drivers that don't > > > use the probe hook". For initialization, the ipvr platform driver's > > > probe() is called in following 2 possible paths: > > > 1. ipvr installed before i915. In this case, ipvr's probe() is called > > > inside i915_driver_load() and falls into the drm_global_mutex dead lock. > > > 2. i915 installed before ipvr. In this case, ipvr's probe() is called > > > without drm_global_mutex held by i915 and no dead lock issue. > > > If we kill drm_global_mutex, will path 2 run into issue? And in your > > > suggestion, how to rework the load sequence? Do you mean calling > > > ipvr's > > > load() callback directly during platform driver probe()? > > > > Hm right it's not that simple really. What we need in more detail is: > > - Move the mutex_lock(&drm_global_mutex) out of drm_dev_register into > > all the callers. If a driver has a ->load() callback it most likely is > > racy with the usual load ordering issues. > > > > - Rework ipvr to no longer have a ->load callback. Insteaed use the > > following sequence (in the platform ->probe callback): > > > > drm_dev_alloc(); > > ipvr_load(); > > drm_dev_register(); > > > > With that ordering we don't need the additional guarantees that > > drm_global_mutex provides and we can avoid to take that lock around > > drm_dev_registrer() call in the ipvr code. > > Thanks for the detailed explanation, Daniel! > That sounds to be a small refactor on drm core, and need change many drm > drivers: nouveau, tegra, udl. > Should it be a standalone RFC patch? I think the locking shuffling should be doable in just one patch, but definitely needs to be split out. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
"EDID checksum is invalid"
On Wed, Jan 7, 2015 at 3:01 AM, Linus Torvalds wrote: > So my el-cheapo UHD Dell monitor is unhappy with dmps, and just never > wakes up from it. > > I work around it with just doing "xset -dpms" and it's not a big deal, > but I thought I'd report it anyway, since there are actual debug > messages, and maybe there's a better way to handle it. Does anybody > have any idea of why it would do this: Yeah if the edid probe fails userspace will get a hotplug and autodisable the output. With a failsafe X session (just a dumb terminal) we can avoid that to check that dpms on itself would work or whether the edid probe fail here is just indicative of more trouble. Also please boot with drm.debug=0xe, repro and grab dmesg, that might shed some more light on what's failing. Thanks, Daniel >[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, > remainder is 111 >Raw EDID: > 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 > 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 > 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 b3 00 > d1 c0 d1 00 7f ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > >[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, > remainder is 240 >Raw EDID: > 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 > 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 > 0f 50 54 a5 4b 00 71 4f 81 00 81 87 ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > >[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, > remainder is 35 >Raw EDID: > 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 > 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 > 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 b3 00 > d1 c7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > >[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, > remainder is 212 >Raw EDID: > 00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41 > 24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28 > 0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > it looks like the beginning is the same, but then it just turns to all > ones at a random point (even *within* a byte). > > Does anything spring to mind? > > Linus > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #223 from Michel Dänzer --- (In reply to fdb4c415 from comment #222) > VM fault (0x04, vmid 1) at page 30481, read from DMA1 (61) > > I have the latest debian test 64 bit installed: There's a good chance that a newer upstream version of Mesa would help for your problem, if not fix it completely. For those still having problems, the kernel patches http://lists.freedesktop.org/archives/dri-devel/2015-January/074968.html and http://lists.freedesktop.org/archives/dri-devel/2015-January/074969.html might be worth a try. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/9b93459a/attachment-0001.html>
[Bug 84292] [r600] crashes in Tropico 5 with Radeon HD 5xxx
https://bugs.freedesktop.org/show_bug.cgi?id=84292 --- Comment #12 from Michel Dänzer --- (In reply to leonmaxx from comment #11) > Is Valve's VOGL trace will be enough? Possibly. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/4a058b83/attachment.html>
[Bug 87796] radeonsi 120Hz graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=87796 --- Comment #1 from Michel Dänzer --- Please attach /var/log/Xorg.0.log and the output of dmesg. Can you upload the video somewhere? If not, please provide more details about the glitches, e.g.: Are they always visible, or only intermittently? If the latter, how often? Does the vertical location of the glitches change or is it always the same? ... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/0083d4b7/attachment.html>
[Bug 72710] rv635: resume from hibernation the second time fails
https://bugs.freedesktop.org/show_bug.cgi?id=72710 --- Comment #4 from Michel Dänzer --- Is there any way you can get more information about the panic on resume, e.g. via a serial console or netconsole or some suspend/hibernate specific debugging mechanism? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/4b4728d2/attachment.html>
[Bug 87856] Driver load fails with no error on ppc64 host
https://bugs.freedesktop.org/show_bug.cgi?id=87856 --- Comment #1 from Michel Dänzer --- See bug 71789. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/ed0c59bf/attachment-0001.html>
[Bug 84292] [r600] crashes in Tropico 5 with Radeon HD 5xxx
https://bugs.freedesktop.org/show_bug.cgi?id=84292 --- Comment #11 from leonmaxx --- Is Valve's VOGL trace will be enough? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/fe96d9ca/attachment.html>
[Bug 90851] radeonsi on pitcairn: nine and skyrim - unable to handle kernel paging request
https://bugzilla.kernel.org/show_bug.cgi?id=90851 --- Comment #1 from Michel Dänzer --- Can you try decoding the backtrace with scripts/decode_stacktrace.sh from the kernel tree? Does it only happen with a 3.19 kernel, or also with older ones? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 87457] [Hawaii XT] 290x reclocking problems
https://bugs.freedesktop.org/show_bug.cgi?id=87457 Alex Deucher changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|DRM/Radeon Version|git |unspecified Product|Mesa|DRI -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/c89d9eeb/attachment.html>
[Bug 87457] [Hawaii XT] 290x reclocking problems
https://bugs.freedesktop.org/show_bug.cgi?id=87457 --- Comment #4 from John Brooks --- Forgot to mention my setup. I'm using an ASUS R9 290, a Linux Mint base system tracking the xorg-edgers PPA, and kernel 3.19-rc3 from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc3-vivid/ I have the latest linux-firmware. The mclk began changing after I upgraded from 3.18.1, but the sclk is still stuck at the lowest level. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/e1008065/attachment.html>
[Bug 87457] [Hawaii XT] 290x reclocking problems
https://bugs.freedesktop.org/show_bug.cgi?id=87457 --- Comment #3 from John Brooks --- I have the same problem. Output from radeon_pm_info when the state is supposed to be set to high: uvddisabled vcedisabled power level avgsclk: 3 mclk: 126000 Some relevant dmesg output: [1.744912] [drm] radeon kernel modesetting enabled. [1.746987] checking generic (d000 e1) vs hw (d000 1000) [1.746990] fb: switching to radeondrmfb from VESA VGA [1.747009] Console: switching to colour dummy device 80x25 [1.747325] [drm] initializing kernel modesetting (HAWAII 0x1002:0x67B1 0x1043:0x0470). [1.747337] [drm] register mmio base: 0xFBD8 [1.747338] [drm] register mmio size: 262144 [1.747342] [drm] doorbell mmio base: 0xCF80 [1.747343] [drm] doorbell mmio size: 8388608 [1.747365] radeon :01:00.0: Invalid ROM contents [1.747977] ATOM BIOS: 67B1HB.15.41.0.2.AS04L [1.748038] radeon :01:00.0: VRAM: 4096M 0x - 0x (4096M used) [1.748039] radeon :01:00.0: GTT: 1024M 0x0001 - 0x00013FFF [1.748041] [drm] Detected VRAM RAM=4096M, BAR=256M [1.748042] [drm] RAM width 512bits DDR [1.748115] [TTM] Zone kernel: Available graphics memory: 4087274 kiB [1.748116] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [1.748117] [TTM] Initializing pool allocator [1.748120] [TTM] Initializing DMA pool allocator [1.748136] [drm] radeon: 4096M of VRAM memory ready [1.748137] [drm] radeon: 1024M of GTT memory ready. [1.748147] [drm] Loading hawaii Microcode [1.748302] [drm] Internal thermal controller with fan control [1.748342] [drm] probing gen 2 caps for device 1022:960b = 1300c82/0 [1.763278] [drm:ci_dpm_init [radeon]] *ERROR* Invalid PCC GPIO: 13! [1.763282] == power state 0 == [1.763283] ui class: none [1.763284] internal class: boot [1.763285] caps: [1.763286] uvdvclk: 0 dclk: 0 [1.763287] power level 0sclk: 3 mclk: 15000 pcie gen: 2 pcie lanes: 8 [1.763288] status: c r b [1.763289] == power state 1 == [1.763290] ui class: performance [1.763290] internal class: none [1.763291] caps: [1.763292] uvdvclk: 0 dclk: 0 [1.763293] power level 0sclk: 3 mclk: 15000 pcie gen: 2 pcie lanes: 8 [1.763294] power level 1sclk: 10 mclk: 126000 pcie gen: 2 pcie lanes: 8 [1.763295] status: [1.771519] [drm] radeon: dpm initialized -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/563fd688/attachment.html>
[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg
https://bugs.freedesktop.org/show_bug.cgi?id=46711 Branen Salmon changed: What|Removed |Added CC||bugs at nenarb.net --- Comment #20 from Branen Salmon --- Created attachment 111880 --> https://bugs.freedesktop.org/attachment.cgi?id=111880&action=edit Logs from a reproduction of the bug using recent software I'm seeing the same issue with Xorg 1.16.2.901, Linux 3.16.0, and a Radeon HD 7750. I've attached DRM logs that contrast the behavior when the monitor is power-cycled in X (there's no signal when the monitor is powered back on) to the behavior when the monitor is power-cycled in kernel framebuffer VT (the signal returns when the monitor is powered back on), but am not sure what to make of them. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/dbace726/attachment.html>
[Bug 90861] Panic on suspend from KDE with radeon
https://bugzilla.kernel.org/show_bug.cgi?id=90861 --- Comment #6 from Michel Dänzer --- Looks like dpm_watchdog_handler kicks in while the radeon driver is waiting for a fence to signal. Maybe the Radeon GPU IRQ is disabled too early during suspend or something like that? (In reply to Jon Arne Jørgensen from comment #5) > I was _not_ able to reproduce the panic with kernel-3.10.0-rc7 that I had > lying around in my /boot directory. Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 83510] Graphical glitches in Unreal Engine 4
https://bugs.freedesktop.org/show_bug.cgi?id=83510 --- Comment #14 from Clément Guérin --- (In reply to Michel Dänzer from comment #13) > Make sure you use the current versions of the demos. I was seeing the > darkness in the first version of the Realistic Rendering demo, but it's > fixed with the current version, and Shooter Game looks fine as well. It's great if latest versions of Unreal Engine don't have this issue, but it also means it's not exposing a potential driver bug anymore. This could show up later :( If anyone else can confirm it's fixed, I think we can close this bug report. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150107/728c26f3/attachment-0001.html>
[PATCH 3/3] drm/radeon: fix VM flush on CIK (v3)
We need to wait for the GPUVM flush to complete. There
was some confusion as to how this mechanism was supposed
to work. The operation is not atomic. For GPU initiated
invalidations you need to read back a VM register to
introduce enough latency for the update to complete.
v2: drop gart changes
v3: just read back rather than polling
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c | 11 +++
drivers/gpu/drm/radeon/cik_sdma.c | 10 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 6dcde37..64fdae5 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6033,6 +6033,17 @@ void cik_vm_flush(struct radeon_device *rdev, struct
radeon_ring *ring,
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 1 << vm_id);
+ /* wait for the invalidate to complete */
+ radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+ radeon_ring_write(ring, (WAIT_REG_MEM_OPERATION(0) | /* wait */
+WAIT_REG_MEM_FUNCTION(0) | /* always */
+WAIT_REG_MEM_ENGINE(0))); /* me */
+ radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+ radeon_ring_write(ring, 0);
+ radeon_ring_write(ring, 0); /* ref */
+ radeon_ring_write(ring, 0); /* mask */
+ radeon_ring_write(ring, 0x20); /* poll interval */
+
/* compute doesn't have PFP */
if (usepfp) {
/* sync PFP to ME, otherwise we might get invalid PFP reads */
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c
b/drivers/gpu/drm/radeon/cik_sdma.c
index dde5c7e..a0133c7 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -903,6 +903,9 @@ void cik_sdma_vm_pad_ib(struct radeon_ib *ib)
void cik_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
unsigned vm_id, uint64_t pd_addr)
{
+ u32 extra_bits = (SDMA_POLL_REG_MEM_EXTRA_OP(0) |
+ SDMA_POLL_REG_MEM_EXTRA_FUNC(0)); /* always */
+
radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SRBM_WRITE, 0, 0xf000));
if (vm_id < 8) {
radeon_ring_write(ring, (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR +
(vm_id << 2)) >> 2);
@@ -943,5 +946,12 @@ void cik_dma_vm_flush(struct radeon_device *rdev, struct
radeon_ring *ring,
radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SRBM_WRITE, 0, 0xf000));
radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
radeon_ring_write(ring, 1 << vm_id);
+
+ radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_POLL_REG_MEM, 0,
extra_bits));
+ radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+ radeon_ring_write(ring, 0);
+ radeon_ring_write(ring, 0); /* reference */
+ radeon_ring_write(ring, 0); /* mask */
+ radeon_ring_write(ring, (0xfff << 16) | 10); /* retry count, poll
interval */
}
--
1.8.3.1
[PATCH 2/3] drm/radeon: fix VM flush on SI (v3)
We need to wait for the GPUVM flush to complete. There was some confusion as to how this mechanism was supposed to work. The operation is not atomic. For GPU initiated invalidations you need to read back a VM register to introduce enough latency for the update to complete. v2: drop gart changes v3: just read back rather than polling Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/si.c | 10 ++ drivers/gpu/drm/radeon/si_dma.c | 8 drivers/gpu/drm/radeon/sid.h| 18 ++ 3 files changed, 36 insertions(+) diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index 60df444..5d89b87 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -5057,6 +5057,16 @@ void si_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring, radeon_ring_write(ring, 0); radeon_ring_write(ring, 1 << vm_id); + /* wait for the invalidate to complete */ + radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5)); + radeon_ring_write(ring, (WAIT_REG_MEM_FUNCTION(0) | /* always */ +WAIT_REG_MEM_ENGINE(0))); /* me */ + radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2); + radeon_ring_write(ring, 0); + radeon_ring_write(ring, 0); /* ref */ + radeon_ring_write(ring, 0); /* mask */ + radeon_ring_write(ring, 0x20); /* poll interval */ + /* sync PFP to ME, otherwise we might get invalid PFP reads */ radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); radeon_ring_write(ring, 0x0); diff --git a/drivers/gpu/drm/radeon/si_dma.c b/drivers/gpu/drm/radeon/si_dma.c index f5cc777..aa7b872 100644 --- a/drivers/gpu/drm/radeon/si_dma.c +++ b/drivers/gpu/drm/radeon/si_dma.c @@ -206,6 +206,14 @@ void si_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring, radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0, 0, 0)); radeon_ring_write(ring, (0xf << 16) | (VM_INVALIDATE_REQUEST >> 2)); radeon_ring_write(ring, 1 << vm_id); + + /* wait for invalidate to complete */ + radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_POLL_REG_MEM, 0, 0, 0, 0)); + radeon_ring_write(ring, VM_INVALIDATE_REQUEST); + radeon_ring_write(ring, 0xff << 16); /* retry */ + radeon_ring_write(ring, 1 << vm_id); /* mask */ + radeon_ring_write(ring, 0); /* value */ + radeon_ring_write(ring, (0 << 28) | 0x20); /* func(always) | poll interval */ } /** diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h index 4069be89..8499924 100644 --- a/drivers/gpu/drm/radeon/sid.h +++ b/drivers/gpu/drm/radeon/sid.h @@ -1632,6 +1632,23 @@ #definePACKET3_MPEG_INDEX 0x3A #definePACKET3_COPY_DW 0x3B #definePACKET3_WAIT_REG_MEM0x3C +#defineWAIT_REG_MEM_FUNCTION(x)((x) << 0) +/* 0 - always +* 1 - < +* 2 - <= +* 3 - == +* 4 - != +* 5 - >= +* 6 - > +*/ +#defineWAIT_REG_MEM_MEM_SPACE(x) ((x) << 4) +/* 0 - reg +* 1 - mem +*/ +#defineWAIT_REG_MEM_ENGINE(x) ((x) << 8) +/* 0 - me +* 1 - pfp +*/ #definePACKET3_MEM_WRITE 0x3D #definePACKET3_COPY_DATA 0x40 #definePACKET3_CP_DMA 0x41 @@ -1835,6 +1852,7 @@ #defineDMA_PACKET_TRAP 0x7 #defineDMA_PACKET_SRBM_WRITE 0x9 #defineDMA_PACKET_CONSTANT_FILL 0xd +#defineDMA_PACKET_POLL_REG_MEM 0xe #defineDMA_PACKET_NOP0xf #define VCE_STATUS 0x20004 -- 1.8.3.1
[PATCH 1/3] drm/radeon: fix VM flush on cayman/aruba (v3)
We need to wait for the GPUVM flush to complete. There was some confusion as to how this mechanism was supposed to work. The operation is not atomic. For GPU initiated invalidations you need to read back a VM register to introduce enough latency for the update to complete. v2: drop gart changes v3: just read back rather than polling Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/ni.c | 10 ++ drivers/gpu/drm/radeon/ni_dma.c | 6 ++ drivers/gpu/drm/radeon/nid.h| 24 3 files changed, 40 insertions(+) diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index 360de9f..aea48c8 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -2516,6 +2516,16 @@ void cayman_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring, radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0)); radeon_ring_write(ring, 1 << vm_id); + /* wait for the invalidate to complete */ + radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5)); + radeon_ring_write(ring, (WAIT_REG_MEM_FUNCTION(0) | /* always */ +WAIT_REG_MEM_ENGINE(0))); /* me */ + radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2); + radeon_ring_write(ring, 0); + radeon_ring_write(ring, 0); /* ref */ + radeon_ring_write(ring, 0); /* mask */ + radeon_ring_write(ring, 0x20); /* poll interval */ + /* sync PFP to ME, otherwise we might get invalid PFP reads */ radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0)); radeon_ring_write(ring, 0x0); diff --git a/drivers/gpu/drm/radeon/ni_dma.c b/drivers/gpu/drm/radeon/ni_dma.c index 50f8861..4be2bb7 100644 --- a/drivers/gpu/drm/radeon/ni_dma.c +++ b/drivers/gpu/drm/radeon/ni_dma.c @@ -463,5 +463,11 @@ void cayman_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring, radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0, 0)); radeon_ring_write(ring, (0xf << 16) | (VM_INVALIDATE_REQUEST >> 2)); radeon_ring_write(ring, 1 << vm_id); + + /* wait for invalidate to complete */ + radeon_ring_write(ring, DMA_SRBM_READ_PACKET); + radeon_ring_write(ring, (0xff << 20) | (VM_INVALIDATE_REQUEST >> 2)); + radeon_ring_write(ring, 0); /* mask */ + radeon_ring_write(ring, 0); /* value */ } diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h index 2e12e4d..ad71254 100644 --- a/drivers/gpu/drm/radeon/nid.h +++ b/drivers/gpu/drm/radeon/nid.h @@ -1133,6 +1133,23 @@ #definePACKET3_MEM_SEMAPHORE 0x39 #definePACKET3_MPEG_INDEX 0x3A #definePACKET3_WAIT_REG_MEM0x3C +#defineWAIT_REG_MEM_FUNCTION(x)((x) << 0) +/* 0 - always +* 1 - < +* 2 - <= +* 3 - == +* 4 - != +* 5 - >= +* 6 - > +*/ +#defineWAIT_REG_MEM_MEM_SPACE(x) ((x) << 4) +/* 0 - reg +* 1 - mem +*/ +#defineWAIT_REG_MEM_ENGINE(x) ((x) << 8) +/* 0 - me +* 1 - pfp +*/ #definePACKET3_MEM_WRITE 0x3D #definePACKET3_PFP_SYNC_ME 0x42 #definePACKET3_SURFACE_SYNC0x43 @@ -1272,6 +1289,13 @@ (1 << 21) |\ (((n) & 0xF) << 0)) +#define DMA_SRBM_POLL_PACKET ((9 << 28) |\ +(1 << 27) |\ +(1 << 26)) + +#define DMA_SRBM_READ_PACKET ((9 << 28) |\ +(1 << 27)) + /* async DMA Packet types */ #defineDMA_PACKET_WRITE 0x2 #defineDMA_PACKET_COPY 0x3 -- 1.8.3.1
