[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> Looking at the of_drm_find_panel function I actually wonder how that
> works - the drm_panel doesn't really need to stick around afaics.
> After all panel_list is global so some other driver can unload.
> Russell's of support for possible_crtcs code works differently since
> it only looks at per-drm_device lists.
>
> This bridge code here though suffers from the same. So to me this
> looks rather fishy.
>
> It doesn't help that we have drm_of.[hc] around but not all the of
> code is in there. Adding Russell too.
I rather dropped the ball with imx-drm when things became difficult with
asking Greg to pull my git tree - and as a result, I decided that I would
no longer be helping with patch submission for imx-drm, nor trying to get
it out of the staging tree anymore.
I do still have the patch (dated from July) in my git tree which adds it
to imx-drm - see below. Rebased to 3.18-rc2 today.
I also have a patch (from April) which creates a generic OF DDC connector
helper, but that remains unfinished, in the sense that it lives beside
imx-drm, pulling the DDC specific code out of imx-hdmi and imx-tve, even
though there's nothing imx-drm specific about it.
8<
From: Russell King
Subject: [PATCH] imx-drm: convert imx-drm to use the generic DRM OF helper
Use the generic DRM OF helper to locate the possible CRTCs for the
encoder, thereby shrinking the imx-drm driver some more.
Acked-by: Philipp Zabel
Signed-off-by: Russell King
---
drivers/staging/imx-drm/imx-drm-core.c | 72 ++
1 file changed, 13 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 9cb222e2996f..5e2c1f4b9165 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "imx-drm.h"
@@ -47,7 +48,6 @@ struct imx_drm_crtc {
struct drm_crtc *crtc;
int pipe;
struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
- struct device_node *port;
};
static int legacyfb_depth = 16;
@@ -366,9 +366,10 @@ int imx_drm_add_crtc(struct drm_device *drm, struct
drm_crtc *crtc,
imx_drm_crtc->imx_drm_helper_funcs = *imx_drm_helper_funcs;
imx_drm_crtc->pipe = imxdrm->pipes++;
- imx_drm_crtc->port = port;
imx_drm_crtc->crtc = crtc;
+ crtc->port = port;
+
imxdrm->crtc[imx_drm_crtc->pipe] = imx_drm_crtc;
*new_crtc = imx_drm_crtc;
@@ -409,34 +410,6 @@ int imx_drm_remove_crtc(struct imx_drm_crtc *imx_drm_crtc)
}
EXPORT_SYMBOL_GPL(imx_drm_remove_crtc);
-/*
- * Find the DRM CRTC possible mask for the connected endpoint.
- *
- * The encoder possible masks are defined by their position in the
- * mode_config crtc_list. This means that CRTCs must not be added
- * or removed once the DRM device has been fully initialised.
- */
-static uint32_t imx_drm_find_crtc_mask(struct imx_drm_device *imxdrm,
- struct device_node *endpoint)
-{
- struct device_node *port;
- unsigned i;
-
- port = of_graph_get_remote_port(endpoint);
- if (!port)
- return 0;
- of_node_put(port);
-
- for (i = 0; i < MAX_CRTC; i++) {
- struct imx_drm_crtc *imx_drm_crtc = imxdrm->crtc[i];
-
- if (imx_drm_crtc && imx_drm_crtc->port == port)
- return drm_crtc_mask(imx_drm_crtc->crtc);
- }
-
- return 0;
-}
-
static struct device_node *imx_drm_of_get_next_endpoint(
const struct device_node *parent, struct device_node *prev)
{
@@ -449,35 +422,16 @@ static struct device_node *imx_drm_of_get_next_endpoint(
int imx_drm_encoder_parse_of(struct drm_device *drm,
struct drm_encoder *encoder, struct device_node *np)
{
- struct imx_drm_device *imxdrm = drm->dev_private;
- struct device_node *ep = NULL;
- uint32_t crtc_mask = 0;
- int i;
+ uint32_t crtc_mask = drm_of_find_possible_crtcs(drm, np);
- for (i = 0; ; i++) {
- u32 mask;
-
- ep = imx_drm_of_get_next_endpoint(np, ep);
- if (!ep)
- break;
-
- mask = imx_drm_find_crtc_mask(imxdrm, ep);
-
- /*
-* If we failed to find the CRTC(s) which this encoder is
-* supposed to be connected to, it's because the CRTC has
-* not been registered yet. Defer probing, and hope that
-* the required CRTC is added later.
-*/
- if (mask == 0)
- return -EPROBE_DEFER;
-
- crtc_mask |= mask;
- }
-
- of_node_put(ep);
- if (i == 0)
- return -ENOENT;
+ /*
+* If we failed to find the CRTC(s)
[Bug 83748] Only black content on screen, in the Tokyo flashback of the game "The Secret World"
https://bugs.freedesktop.org/show_bug.cgi?id=83748 --- Comment #12 from John --- I tried with latest git, but still 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/20141027/079860ce/attachment.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter wrote:
> On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
@@ -660,8 +662,11 @@ struct drm_bridge_funcs {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge {
- struct drm_device *dev;
+ struct device *dev;
>>>
>>> Please don't rename the ->dev pointer into drm. Because _all_ the other
>>> drm structures still call it ->dev. Also, can't we use struct device_node
>>> here like we do in the of helpers Russell added? See 7e435aad38083
>>>
>>
>> I think this is modeled after the naming in drm_panel, FWIW. However,
>> seems reasonable to keep the device_node instead.
>
> Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> drm_crtc drop the struct device and go directly to a struct
> device_node. Since we don't really need the sturct device, the only
> thing we care about is the of_node. For added bonus wrap an #ifdef
> CONFIG_OF around all the various struct device_node in drm_foo.h.
> Should be all fairly simple to pull off with cocci.
>
> Thierry?
Looking at the of_drm_find_panel function I actually wonder how that
works - the drm_panel doesn't really need to stick around afaics.
After all panel_list is global so some other driver can unload.
Russell's of support for possible_crtcs code works differently since
it only looks at per-drm_device lists.
This bridge code here though suffers from the same. So to me this
looks rather fishy.
It doesn't help that we have drm_of.[hc] around but not all the of
code is in there. Adding Russell too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
>>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
>>> * @driver_private: pointer to the bridge driver's internal context
>>> */
>>> struct drm_bridge {
>>> - struct drm_device *dev;
>>> + struct device *dev;
>>
>> Please don't rename the ->dev pointer into drm. Because _all_ the other
>> drm structures still call it ->dev. Also, can't we use struct device_node
>> here like we do in the of helpers Russell added? See 7e435aad38083
>>
>
> I think this is modeled after the naming in drm_panel, FWIW. However,
> seems reasonable to keep the device_node instead.
Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
drm_crtc drop the struct device and go directly to a struct
device_node. Since we don't really need the sturct device, the only
thing we care about is the of_node. For added bonus wrap an #ifdef
CONFIG_OF around all the various struct device_node in drm_foo.h.
Should be all fairly simple to pull off with cocci.
Thierry?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 Dieter Nützel changed: What|Removed |Added CC||Dieter at nuetzel-hh.de --- Comment #5 from Dieter Nützel --- Can you please test with one of kernel git | 3.18-rc2 | drm-next together with git revert 59bc1d8? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #34 from Dieter Nützel --- (In reply to Dieter Nützel from comment #33) > Hello Alexandre, > > maybe you can take a look, here to speed things up? > https://bugzilla.kernel.org/show_bug.cgi?id=86891 > Comment #3 and #4. I'll testing it on RV730 AGP with git revert of 59bc1d89d6a4d67c94a9b70fa81bda1d5b04f0cb is the first bad commit commit 59bc1d89d6a4d67c94a9b70fa81bda1d5b04f0cb Author: Lauri Kasanen Date: Sun Apr 20 20:29:33 2014 +0300 drm/radeon: Inline r100_mm_rreg, -wreg, v3 Now. -- 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/20141027/1a44af76/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #33 from Dieter Nützel --- Hello Alexandre, maybe you can take a look, here to speed things up? https://bugzilla.kernel.org/show_bug.cgi?id=86891 Comment #3 and #4. -- 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/20141027/74d117ac/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #2 from Alex Deucher --- Can you bisect mesa to indentify the problematic commit between 10.3.1 and 10.3.2? there are only a few changes between the two versions: http://cgit.freedesktop.org/mesa/mesa/log/?h=10.3 -- 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/20141027/2730b5c8/attachment-0001.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #32 from Alexandre Demers --- (In reply to José Suárez from comment #31) > I've been testing linux 3.18 rc1 for a few days and I've found it to be > quite stable with regard to this bug. No hangs for me yet, but the Patcket0 > massages still show up in dmesg. Indeed, pretty much the same over here. I'm still bisecting. Everything points to something introduced between 3.16 and 3.17-rc1. It just takes awhile since the problem doesn't appear everytime. -- 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/20141027/e61f6456/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 Dieter Nützel changed: What|Removed |Added Attachment #108536|text/plain |image/png mime type|| -- 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/20141027/0ad0ada8/attachment.html>
[PATCH] allow 32bpp framebuffers for cirrus drm
ajax, What do you mean by a pci revision id bump? Do you want it in qemu or the kernel? Why is a revision bump needed when none of the behavior of the cirrus device has changed? I agree that reading the BAR size from the device would be an enhancement. I'm working on the patch to include that now. -Zach On Mon Oct 27 2014 at 9:21:42 AM Adam Jackson wrote: > On Mon, 2014-10-27 at 16:30 +0100, Gerd Hoffmann wrote: > > > How about stop using cirrus and go for 'qemu -vga std' instead? > > > > Linux kernel 3.14+ comes with a modesetting driver for the qemu standard > > vga (CONFIG_DRM_BOCHS). Just switch over, and all your cirrus pain is > > gone. > > > > That is much better than trying use features the real cirrus hardware > > never had, then praying that all qemu versions in the wild are actually > > doing what you want qemu do. > > I was going to ask for a pci revision id bump at the same time, so the > guest could know. > > I heartily agree, people should stop using cirrus. And qemu should stop > defaulting to it. Since neither has happened yet, enhancing the > emulation holds the promise of making the future better... > > - ajax > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141027/86e05c01/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #1 from Hamish Wilson --- Seeing as attaching an image did not seem to work, the screenshots in question can also be seen here: http://www.phoronix.com/forums/showthread.php?108068-Help-diagnosing-problems-with-a-Readon-HD-4670-on-Mesa-10-3-2-1&p=448863#post448863 -- 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/20141027/2f85de66/attachment.html>
[Bug 85526] New: Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 Bug ID: 85526 Summary: Screen corruptions in OpenGL reliant applications Product: Mesa Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: hamish at icculus.org Created attachment 108536 --> https://bugs.freedesktop.org/attachment.cgi?id=108536&action=edit Image corruptions in Chromium, Blood II: The Chosen through WINE, and Quake III Arena I have been having a very confusing problem with the version of Mesa packaged with Arch Linux. I am using a Diamond Radeon HD 4670 with R600g. Yesterday I updated the various Mesa packages from 10.3.1-1 to 10.3.2-1 and upon doing so I started to encounter screen corruptions in all of the games I tested as well as the browser Chromium. Reverting to the previous version packaged by Arch Linux fixes the issue: cd /var/cache/pacman/pkg/ pacman -U mesa-10.3.1-1-i686.pkg.tar.xz mesa-dri-10.3.1-1-i686.pkg.tar.xz mesa-libgl-10.3.1-1-i686.pkg.tar.xz mesa-vdpau-10.3.1-1-i686.pkg.tar.xz While the bug itself is of course distressing, the main thing that is confusing me is that I am even having trouble finding mention of Mesa 10.3.2 release as the website does not mention it and I can not even find an entry for Mesa 10.3 in the Version field of this very submission form. Games seem to run without any stated errors in spite of the corruptions, something which is making it difficult for me to find any additional information. I have attached screenshots showing off some of the problems I am talking about. I apologize if this report is too vague or if I am missing something with regards to the Mesa version information, but this is the best I can figure out for the moment. Any suggestions as to deriving more useful information would of course be appreciated. -- 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/20141027/87a18875/attachment.html>
[PATCH 12/12] ARM: shmobile: koelsch: Add DU HDMI output support
2014/10/27 21:13 "Laurent Pinchart" :
>
> Hi Simon,
>
> On Monday 27 October 2014 09:38:29 Simon Horman wrote:
> > On Wed, Sep 24, 2014 at 11:04:32PM +0300, Laurent Pinchart wrote:
> > > Add DT nodes for the ADV7511 HDMI encoder and its HDMI output
connector
> > > and configure the DISP pin group that drives the HDMI transmitter DE
> > > pin.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> >
> > Acked-by: Simon Horman
> >
> > Please be careful of any conflicts that may arise if this patch
> > doesn't go through my renesas tree.
>
> I think it would be best if the patch went through your tree. There's no
> compile time or runtime dependency on the DU HDMI code, so as soon as the
> ADV7511 DT bindings get accepted I plan to ask you to merge this patch.
Sure, that sounds like a good plan.
> > > ---
> > >
> > > arch/arm/boot/dts/r8a7791-koelsch.dts | 50
+-
> > > 1 file changed, 49 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
> > > b/arch/arm/boot/dts/r8a7791-koelsch.dts index 9051e01..b7d0c41 100644
> > > --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> > > +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> > > @@ -209,6 +209,17 @@
> > > states = <330 1
> > > 180 0>;
> > > };
> > > +
> > > + hdmi-out {
> > > + compatible = "hdmi-connector";
> > > + type = "a";
> > > +
> > > + port {
> > > + hdmi_con: endpoint {
> > > + remote-endpoint = <&adv7511_out>;
> > > + };
> > > + };
> > > + };
> > > };
> > >
> > > &du {
> > > @@ -217,6 +228,11 @@
> > > status = "okay";
> > >
> > > ports {
> > > + port at 0 {
> > > + endpoint {
> > > + remote-endpoint = <&adv7511_in>;
> > > + };
> > > + };
> > > port at 1 {
> > > lvds_connector: endpoint {
> > > };
> > > @@ -235,7 +251,7 @@
> > > };
> > >
> > > du_pins: du {
> > > - renesas,groups = "du_rgb666", "du_sync", "du_clk_out_0";
> > > + renesas,groups = "du_rgb666", "du_sync", "du_disp",
> > > "du_clk_out_0";
> > > renesas,function = "du";
> > > };
> > >
> > > @@ -439,6 +455,38 @@
> > > };
> > > };
> > >
> > > + hdmi at 39 {
> > > + compatible = "adi,adv7511w";
> > > + reg = <0x39>;
> > > + interrupt-parent = <&gpio3>;
> > > + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> > > +
> > > + adi,input-depth = <8>;
> > > + adi,input-colorspace = "rgb";
> > > + adi,input-clock = "1x";
> > > + adi,input-style = <1>;
> > > + adi,input-justification = "evenly";
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port at 0 {
> > > + reg = <0>;
> > > + adv7511_in: endpoint {
> > > + remote-endpoint = <&du_out_rgb>;
> > > + };
> > > + };
> > > +
> > > + port at 1 {
> > > + reg = <1>;
> > > + adv7511_out: endpoint {
> > > + remote-endpoint = <&hdmi_con>;
> > > + };
> > > + };
> > > + };
> > > + };
> > > +
> > > eeprom at 50 {
> > > compatible = "renesas,24c02";
> > > reg = <0x50>;
>
> --
> Regards,
>
> Laurent Pinchart
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141027/c2a99cd2/attachment-0001.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #248 from Laurento Frittella --- (In reply to Alex Deucher from comment #247) > Not until it's tested and it proves to work reliably on all the problematic > systems here. Unfortunately I tried your patch on kernel 3.17.1 and it doesn't work, my system still hangs resuming after hibernate. Everything is working well with DPM disabled. $ lspci | grep VGA 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470] Please let me know if I can provide any other useful information. -- 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/20141027/ac6cc0d8/attachment-0001.html>
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #4 from Michael Mair-Keimberger --- Created attachment 155491 --> https://bugzilla.kernel.org/attachment.cgi?id=155491&action=edit bisec.tar.gz Additional all benchmarks i've made from every bisected kernel. the first one is the 3.16rc7 benchmark, the second the 3.17rc1. The others are from the bisected kernels. You'll see on the benchmarks it always has a difference of about 100 points (good vs bad), which is about 10% performance difference. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #3 from Michael Mair-Keimberger --- I though it takes more time, but i already finished bisecting :) The result: 59bc1d89d6a4d67c94a9b70fa81bda1d5b04f0cb is the first bad commit commit 59bc1d89d6a4d67c94a9b70fa81bda1d5b04f0cb Author: Lauri Kasanen Date: Sun Apr 20 20:29:33 2014 +0300 drm/radeon: Inline r100_mm_rreg, -wreg, v3 This was originally un-inlined by Andi Kleen in 2011 citing size concerns. Indeed, a first attempt at inlining it grew radeon.ko by 7%. However, 2% of cpu is spent in this function. Simply inlining it gave 1% more fps in Urban Terror. v2: We know the minimum MMIO size. Adding it to the if allows the compiler to optimize the branch out, improving both performance and size. The v2 patch decreases radeon.ko size by 2%. I didn't re-benchmark, but common sense says perf is now more than 1% better. v3: Also change _wreg, make the threshold a define. Inlining _wreg increased the size a bit compared to v2, so now radeon.ko is only 1% smaller. Signed-off-by: Lauri Kasanen Reviewed-by: Christian König Signed-off-by: Alex Deucher :04 04 91cde817761a93a06d21855ec896d22f03685665 e7de121e74c415308e8266c26ae7ad518d0e8530 M drivers This is the bad commit. asterix linux # git bisect log git bisect start # bad: [7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9] Linux 3.17-rc1 git bisect bad 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9 # good: [64aa90f26c06e1cb2aacfb98a7d0eccfbd6c1a91] Linux 3.16-rc7 git bisect good 64aa90f26c06e1cb2aacfb98a7d0eccfbd6c1a91 # good: [ae045e2455429c418a418a3376301a9e5753a0a8] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect good ae045e2455429c418a418a3376301a9e5753a0a8 # bad: [44c916d58b9ef1f2c4aec2def57fa8289c716a60] Merge tag 'cleanup-for-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect bad 44c916d58b9ef1f2c4aec2def57fa8289c716a60 # good: [e669830526a0abaf301bf408df69cde33901ac63] Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus git bisect good e669830526a0abaf301bf408df69cde33901ac63 # bad: [7963e9db1b1f842fdc53309baa8714d38e9f5681] Revert "drm: drop redundant drm_file->is_master" git bisect bad 7963e9db1b1f842fdc53309baa8714d38e9f5681 # good: [8a105aaa25f4504d26ca828f12d709d2213a230e] Merge branch 'drm-armada-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into drm-next git bisect good 8a105aaa25f4504d26ca828f12d709d2213a230e # good: [a2fe6cdc03d7a9b0d048a7f32f9d8827e06c67fa] drm/msm/hdmi: fix HDMI_MUX_EN gpio request typo git bisect good a2fe6cdc03d7a9b0d048a7f32f9d8827e06c67fa # bad: [e7e31600d3e2f8b7726b0521149fc55c62a90467] drm/radeon: remove taking mclk_lock from radeon_bo_unref git bisect bad e7e31600d3e2f8b7726b0521149fc55c62a90467 # bad: [c748990b7b1c320c626c758379d50748588c6ed6] drm/radeon: Use correct value for unknown audio/video latency git bisect bad c748990b7b1c320c626c758379d50748588c6ed6 # good: [96b1b9711031a1e95e3cf15d830802aed38479a6] Merge branch 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next git bisect good 96b1b9711031a1e95e3cf15d830802aed38479a6 # good: [636e2582658742b94e7620becce58f939996c961] drm/radeon/dpm: add support for SVI2 voltage for SI git bisect good 636e2582658742b94e7620becce58f939996c961 # good: [f2c6b0f452c3804496f55655fda28c2809e1a58b] drm/radeon/cik: Add support for new ucode format (v5) git bisect good f2c6b0f452c3804496f55655fda28c2809e1a58b # good: [da9976206c15178eeae1b4445c9266125bf35b0a] drm/radeon: enable display scaling on all connectors (v2) git bisect good da9976206c15178eeae1b4445c9266125bf35b0a # bad: [59bc1d89d6a4d67c94a9b70fa81bda1d5b04f0cb] drm/radeon: Inline r100_mm_rreg, -wreg, v3 git bisect bad 59bc1d89d6a4d67c94a9b70fa81bda1d5b04f0cb # good: [3e22920fbd0005927bc41f71daeb056a0f4def82] drm/radeon: consolidate vga and dvi get_modes functions (v2) git bisect good 3e22920fbd0005927bc41f71daeb056a0f4def82 # first bad co
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
So don't ask why but I accidentally ended up in a branch looking at this
patch and didn't like it. So very quick&grumpy review.
First, please make the patch subject more descriptive: I'd expect a helper
function scaffolding like the various crtc/probe/dp ... helpers we already
have. You instead add code to untangle the probe ordering. Please say so.
More comments below.
On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
> A set of helper functions are defined in this patch to make
> bridge driver probe independent of the drm flow.
>
> The bridge devices register themselves on a lookup table
> when they get probed by calling "drm_bridge_add".
>
> The parent encoder driver waits till the bridge is available
> in the lookup table(by calling "of_drm_find_bridge") and then
> continues with its initialization.
>
> The encoder driver should also call "drm_bridge_attach" to pass
> on the drm_device, encoder pointers to the bridge object.
>
> drm_bridge_attach inturn calls drm_bridge_init to register itself
> with the drm core. Later, it calls "bridge->funcs->attach" so that
> bridge can continue with other initializations.
>
> Signed-off-by: Ajay Kumar
[snip]
> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> * @driver_private: pointer to the bridge driver's internal context
> */
> struct drm_bridge {
> - struct drm_device *dev;
> + struct device *dev;
Please don't rename the ->dev pointer into drm. Because _all_ the other
drm structures still call it ->dev. Also, can't we use struct device_node
here like we do in the of helpers Russell added? See 7e435aad38083
> + struct drm_device *drm;
> + struct drm_encoder *encoder;
This breaks bridge->bridge chaining (if we ever get there). It seems
pretty much unused anyway except for an EBUSY check. Can't you use
bridge->dev for that?
> struct list_head head;
> + struct list_head list;
These lists need better names. I know that the "head" is really awful,
especially since it's actually not the head of the list but just an
element.
>
> struct drm_mode_object base;
Aside: I've noticed all this trying to update the kerneldoc for struct
drm_bridge, which just showed that this patch makes inconsistent changes.
Trying to write kerneldoc is a really great way to come up with better
interfaces imo.
Cheers, Daniel
>
> @@ -906,6 +911,11 @@ extern void drm_connector_cleanup(struct drm_connector
> *connector);
> /* helper to unplug all connectors from sysfs for device */
> extern void drm_connector_unplug_all(struct drm_device *dev);
>
> +extern int drm_bridge_add(struct drm_bridge *bridge);
> +extern void drm_bridge_remove(struct drm_bridge *bridge);
> +extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
> +extern int drm_bridge_attach(struct drm_bridge *bridge,
> + struct drm_encoder *encoder);
> extern int drm_bridge_init(struct drm_device *dev, struct drm_bridge
> *bridge);
> extern void drm_bridge_cleanup(struct drm_bridge *bridge);
>
> --
> 1.7.9.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/5] MAINTAINERS: Add entry for MIPI DSI bus
On Mon, Oct 27, 2014 at 04:20:21PM +0100, Andrzej Hajda wrote: > On 10/27/2014 03:17 PM, Daniel Vetter wrote: > > On Mon, Oct 27, 2014 at 10:48:26AM +0100, Andrzej Hajda wrote: > >> Signed-off-by: Andrzej Hajda > >> --- > >> MAINTAINERS | 7 +++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index dd31933..476679c 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -3071,6 +3071,13 @@ F: drivers/gpu/vga/ > >> F:include/drm/ > >> F:include/uapi/drm/ > >> > >> +DRM MIPI DSI BUS > >> +M:Andrzej Hajda > >> +L:dri-devel at lists.freedesktop.org > >> +S:Supported > >> +F:drivers/gpu/drm/drm_mipi_dsi.c > >> +F:include/drm/drm_mipi_dsi.h > > > > I really prefer when common infrastructure like this doesn't get > > maintainer by a vendor. And I care with my intel hat on since we also ahve > > a dsi driver that sooner or later needs to be converted to to this stuff. > > > > Why doesn't the usual model of merging stuff through Dave's tree, or if > > that doesn't work well due to patch depencies, through vendor trees with > > Dave's ack? > > The main intention of this patch is to be on CC in case of patches > touching MIPI DSI bus. > I do not want to create separate tree for such small subsystem. > > So if such things are not allowed please drop the patch and sorry for > the noise. For that stuff you can just create a mail filter that shovels everything touching anything dsi related on dri-devel (people arleady should send all stuff there anyway) into a special folder/mark it as important. If you rely on people to always use get_maintainers.pl that won't work properly anyway. So if all you want is to notice all dsi related patches then adding a maintainer entry isn't a good solution anyway. So best to drop this one. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc2
With kernel 3.18.0-rc2 I'm getting the following kernel panic in drm_calc_vbltimestamp_from_scanoutpos()on the parisc platform. As you can see in the attached log, the ring test fails. This is not a new bug - it has failed with older kernels too and of course it would be nice to get it fixed at some point: [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) But what's new here now, is that the radeon driver segfaults afterwards. There were no monitors attached to the radeon card. I haven't tested this patch yet, but would it be the right fix? : diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index 8309b11..0358676 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -795,6 +795,8 @@ int radeon_get_vblank_timestamp_kms(struct drm_device *dev, int crtc, /* Get associated drm_crtc: */ drmcrtc = &rdev->mode_info.crtcs[crtc]->base; + if (!drmcrtc) + return -EINVAL; Helge ... [ 11.312000] Linux agpgart interface v0.103 [ 11.36] quicksilver: IO PDIR shared with sba_iommu [ 11.436000] (null): AGP aperture is 512M @ 0x6000 [ 11.50] [drm] Initialized drm 1.1.0 20060810 [ 11.552000] [drm] radeon kernel modesetting enabled. [ 11.628000] radeon :80:00.0: enabling SERR and PARITY (0187 -> 01c7) [ 11.708000] [drm] initializing kernel modesetting (R300 0x1002:0x4E47 0x1002:0x0152). [ 11.816000] [drm] register mmio base: 0xD003 [ 11.868000] [drm] register mmio size: 65536 [ 11.98] radeon :80:00.0: putting AGP V3 device into 8x mode [ 12.056000] radeon :80:00.0: GTT: 512M 0x6000 - 0x7FFF [ 12.132000] [drm] Generation 1 PCI interface in multifunction mode [ 12.204000] [drm] Limiting VRAM to one aperture [ 12.26] radeon :80:00.0: VRAM: 256M 0xC800 - 0xD7FF (256M used) [ 12.364000] [drm] Detected VRAM RAM=256M, BAR=128M [ 12.42] [drm] RAM width 256bits DDR [ 12.468000] [TTM] Zone kernel: Available graphics memory: 4112944 kiB [ 12.544000] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 12.624000] [TTM] Initializing pool allocator [ 12.676000] [drm] radeon: 256M of VRAM memory ready [ 12.732000] [drm] radeon: 512M of GTT memory ready. [ 12.792000] [drm] radeon: 2 quad pipes, 1 Z pipes initialized. [ 12.876000] radeon :80:00.0: WB disabled [ 12.928000] radeon :80:00.0: fence driver on ring 0 use gpu addr 0x6000 and cpu addr 0x00048000 [ 13.056000] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 13.136000] [drm] Driver supports precise vblank timestamp query. [ 13.208000] [drm] radeon: irq initialized. [ 13.256000] [drm] Loading R300 Microcode [ 13.32] [drm] radeon: ring at 0x60001000 [ 13.576000] [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [ 13.676000] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [ 13.756000] radeon :80:00.0: failed initializing CP (-22). [ 13.824000] radeon :80:00.0: Disabling GPU acceleration [ 14.088000] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [ 14.192000] [drm] radeon: cp finalized [ 14.704000] Backtrace: [ 14.732000] [<40647740>] radeon_get_vblank_timestamp_kms+0x90/0xa8 [ 14.816000] [<405e7590>] drm_get_last_vbltimestamp+0x98/0xc0 [ 14.892000] [<405e7b28>] vblank_disable_and_save+0xb8/0x350 [ 14.968000] [<405ea270>] drm_vblank_cleanup+0xc8/0x158 [ 15.04] [<40690ab0>] radeon_irq_kms_fini+0x40/0xb8 [ 15.112000] [<406a75c0>] r300_init+0x500/0x5a8 [ 15.172000] [<40643304>] radeon_device_init+0xdac/0x1150 [ 15.248000] [<40646bfc>] radeon_driver_load_kms+0x124/0x238 [ 15.324000] [<405ec65c>] drm_dev_register+0x11c/0x250 [ 15.392000] [<405f1994>] drm_get_pci_dev+0x1bc/0x2d8 [ 15.46] [<4061e7d0>] radeon_pci_probe+0x128/0x148 [ 15.532000] [<40513920>] pci_device_probe+0xb0/0x158 [ 15.60] [<407c4a60>] driver_probe_device+0x148/0x3c0 [ 15.672000] [<407c4dbc>] __driver_attach+0xe4/0x160 [ 15.74] [<407c139c>] bus_for_each_dev+0xac/0x140 [ 15.812000] [<407c40a0>] driver_attach+0x48/0x60 [ 15.876000] [ 15.892000] [ 15.912000] Kernel Fault: Code=26 regs=7fcb1230 (Addr=024c) [ 16.00] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc1-64bit+ #562 [ 16.084000] task: 7fca8000 ti: 7fcb task.ti: 7fcb [ 17.276000] [ 17.296000] IASQ: IAOQ: 405e95e8 405e95ec [ 17.396000] IIR: 4aad0498ISR: IOR: 024c [ 17.476000] CPU:1 CR30: 7fcb CR31: 9cb9a6fbd01f400f [ 17.56] ORIG_R28: 7fcb1420 [ 17.
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #9 from Rafael Pereira --- @Michel Dänzer: thanks for helping. I performed the bisection and that is result: %git bisect log # bad: [bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9] Linux 3.17 # good: [acfaf47549491e5f804d30855c9055ebeb6ecc7b] Linux 3.16.6 git bisect start 'v3.17' 'v3.16.6' # good: [19583ca584d6f574384e17fe7613dfaeadcdc4a6] Linux 3.16 git bisect good 19583ca584d6f574384e17fe7613dfaeadcdc4a6 # good: [f2d7e4d4398092d14fb039cb4d38e502d3f019ee] checkpatch: add fix_insert_line and fix_delete_line helpers git bisect good f2d7e4d4398092d14fb039cb4d38e502d3f019ee # bad: [c309bfa9b481e7dbd3e1ab819271bf3009f44859] Merge tag 'for-linus-20140808' of git://git.infradead.org/linux-mtd git bisect bad c309bfa9b481e7dbd3e1ab819271bf3009f44859 # good: [43c40df2c7fedce640a6c39fcdf58764f6bbac5c] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds git bisect good 43c40df2c7fedce640a6c39fcdf58764f6bbac5c # bad: [b3345d7c57d70e6cb6749af25cdbe80515582e99] Merge tag 'soc-for-3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect bad b3345d7c57d70e6cb6749af25cdbe80515582e99 # bad: [03f62abd112d5150b6ce8957fa85d4f6e85e357f] drm/radeon: split PT setup in more functions git bisect bad 03f62abd112d5150b6ce8957fa85d4f6e85e357f # good: [2f295791312937d077cecec4cd8f453ce2ce93df] drm/i915: Reorder ctx unref on ppgtt cleanup git bisect good 2f295791312937d077cecec4cd8f453ce2ce93df # good: [60b61c2f9e13cb1cfa995984d3a3dca1fdb6490d] drm/exynos/ipp: remove type casting git bisect good 60b61c2f9e13cb1cfa995984d3a3dca1fdb6490d # bad: [920f946428b70494eb1c64e0de260da0d8bde040] Merge branch 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next git bisect bad 920f946428b70494eb1c64e0de260da0d8bde040 # good: [2ee39452fa2fff1e8edb954ccb7e0daee9646557] drm: close race in connector registration (v2) git bisect good 2ee39452fa2fff1e8edb954ccb7e0daee9646557 # good: [b544021f18931258e4e1ef8d88d43dedb73a7ecf] drm/msm: fix double struct_mutex acquire git bisect good b544021f18931258e4e1ef8d88d43dedb73a7ecf # good: [944fc36c31ed685cf8d3d125eb681ae7198f06fc] drm/msm: use upstream iommu git bisect good 944fc36c31ed685cf8d3d125eb681ae7198f06fc # good: [a2fe6cdc03d7a9b0d048a7f32f9d8827e06c67fa] drm/msm/hdmi: fix HDMI_MUX_EN gpio request typo git bisect good a2fe6cdc03d7a9b0d048a7f32f9d8827e06c67fa # good: [c707c3619ca81f499a5ce032021405e989a96ff0] drm/i2c: tda998x: add component support git bisect good c707c3619ca81f499a5ce032021405e989a96ff0 # good: [eceb55a0ecd584ac5bebf667ffd8e859f261d0c0] Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next git bisect good eceb55a0ecd584ac5bebf667ffd8e859f261d0c0 # first bad commit: [920f946428b70494eb1c64e0de260da0d8bde040] Merge branch 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next -- 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/20141027/1cca7685/attachment.html>
[PATCH v5 4/4] drm: synchronize BOs when required
On architectures for which access to GPU memory is non-coherent,
caches need to be flushed and invalidated explicitly when BO control
changes between CPU and GPU.
This patch adds buffer synchronization functions which invokes the
correct API (PCI or DMA) to ensure synchronization is effective.
Based on the TTM DMA cache helper patches by Lucas Stach.
Signed-off-by: Lucas Stach
Signed-off-by: Alexandre Courbot
---
drm/nouveau_bo.c | 42 ++
drm/nouveau_bo.h | 2 ++
drm/nouveau_gem.c | 12
3 files changed, 56 insertions(+)
diff --git a/drm/nouveau_bo.c b/drm/nouveau_bo.c
index ed9a6946f6d6..d2a4768e3efd 100644
--- a/drm/nouveau_bo.c
+++ b/drm/nouveau_bo.c
@@ -426,6 +426,46 @@ nouveau_bo_unmap(struct nouveau_bo *nvbo)
ttm_bo_kunmap(&nvbo->kmap);
}
+void
+nouveau_bo_sync_for_device(struct nouveau_bo *nvbo)
+{
+ struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
+ struct nouveau_device *device = nvkm_device(&drm->device);
+ struct ttm_dma_tt *ttm_dma = (struct ttm_dma_tt *)nvbo->bo.ttm;
+ int i;
+
+ if (!ttm_dma)
+ return;
+
+ /* Don't waste time looping if the object is coherent */
+ if (nvbo->force_coherent)
+ return;
+
+ for (i = 0; i < ttm_dma->ttm.num_pages; i++)
+ dma_sync_single_for_device(nv_device_base(device),
+ ttm_dma->dma_address[i], PAGE_SIZE, DMA_TO_DEVICE);
+}
+
+void
+nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
+{
+ struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
+ struct nouveau_device *device = nvkm_device(&drm->device);
+ struct ttm_dma_tt *ttm_dma = (struct ttm_dma_tt *)nvbo->bo.ttm;
+ int i;
+
+ if (!ttm_dma)
+ return;
+
+ /* Don't waste time looping if the object is coherent */
+ if (nvbo->force_coherent)
+ return;
+
+ for (i = 0; i < ttm_dma->ttm.num_pages; i++)
+ dma_sync_single_for_cpu(nv_device_base(device),
+ ttm_dma->dma_address[i], PAGE_SIZE, DMA_FROM_DEVICE);
+}
+
int
nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -437,6 +477,8 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool
interruptible,
if (ret)
return ret;
+ nouveau_bo_sync_for_device(nvbo);
+
return 0;
}
diff --git a/drm/nouveau_bo.h b/drm/nouveau_bo.h
index 0f8bbd48a0b9..c827f233e41d 100644
--- a/drm/nouveau_bo.h
+++ b/drm/nouveau_bo.h
@@ -85,6 +85,8 @@ void nouveau_bo_wr32(struct nouveau_bo *, unsigned index, u32
val);
void nouveau_bo_fence(struct nouveau_bo *, struct nouveau_fence *, bool
exclusive);
int nouveau_bo_validate(struct nouveau_bo *, bool interruptible,
bool no_wait_gpu);
+void nouveau_bo_sync_for_device(struct nouveau_bo *nvbo);
+void nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo);
struct nouveau_vma *
nouveau_bo_vma_find(struct nouveau_bo *, struct nouveau_vm *);
diff --git a/drm/nouveau_gem.c b/drm/nouveau_gem.c
index 36951ee4b157..42c34babc2e5 100644
--- a/drm/nouveau_gem.c
+++ b/drm/nouveau_gem.c
@@ -867,6 +867,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
else
ret = lret;
}
+ nouveau_bo_sync_for_cpu(nvbo);
drm_gem_object_unreference_unlocked(gem);
return ret;
@@ -876,6 +877,17 @@ int
nouveau_gem_ioctl_cpu_fini(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
+ struct drm_nouveau_gem_cpu_fini *req = data;
+ struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
+
+ gem = drm_gem_object_lookup(dev, file_priv, req->handle);
+ if (!gem)
+ return -ENOENT;
+ nvbo = nouveau_gem_object(gem);
+
+ nouveau_bo_sync_for_device(nvbo);
+ drm_gem_object_unreference_unlocked(gem);
return 0;
}
--
2.1.2
[PATCH v5 3/4] drm: allocate GPFIFOs and fences coherently
Specify TTM_PL_FLAG_UNCACHED when allocating GPFIFOs and fences to
allow them to be safely accessed by the kernel without being synced
on non-coherent architectures.
Signed-off-by: Alexandre Courbot
---
drm/nouveau_chan.c | 2 +-
drm/nv84_fence.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drm/nouveau_chan.c b/drm/nouveau_chan.c
index 77c81d6b45ee..0f3da86840f2 100644
--- a/drm/nouveau_chan.c
+++ b/drm/nouveau_chan.c
@@ -102,7 +102,7 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct
nvif_device *device,
chan->drm = drm;
/* allocate memory for dma push buffer */
- target = TTM_PL_FLAG_TT;
+ target = TTM_PL_FLAG_TT | TTM_PL_FLAG_UNCACHED;
if (nouveau_vram_pushbuf)
target = TTM_PL_FLAG_VRAM;
diff --git a/drm/nv84_fence.c b/drm/nv84_fence.c
index d6c6c87c3f07..4d79be7558d8 100644
--- a/drm/nv84_fence.c
+++ b/drm/nv84_fence.c
@@ -246,8 +246,8 @@ nv84_fence_create(struct nouveau_drm *drm)
if (ret == 0)
ret = nouveau_bo_new(drm->dev, 16 * priv->base.contexts, 0,
-TTM_PL_FLAG_TT, 0, 0, NULL, NULL,
-&priv->bo_gart);
+TTM_PL_FLAG_TT | TTM_PL_FLAG_UNCACHED, 0,
+0, NULL, NULL, &priv->bo_gart);
if (ret == 0) {
ret = nouveau_bo_pin(priv->bo_gart, TTM_PL_FLAG_TT);
if (ret == 0) {
--
2.1.2
[PATCH v5 2/4] drm: implement explicitly coherent BOs
Allow nouveau_bo_new() to recognize the TTM_PL_FLAG_UNCACHED flag, which
means that we want the allocated BO to be perfectly coherent between the
CPU and GPU. This is useful on non-coherent architectures for which we
do not want to manually sync some rarely-accessed buffers: typically,
fences and pushbuffers.
A TTM BO allocated with the TTM_PL_FLAG_UNCACHED on a non-coherent
architecture will be populated using the DMA API, and accesses to it
performed using the coherent mapping performed by dma_alloc_coherent().
Signed-off-by: Alexandre Courbot
---
drm/nouveau_bo.c | 80 ++--
drm/nouveau_bo.h | 1 +
2 files changed, 73 insertions(+), 8 deletions(-)
diff --git a/drm/nouveau_bo.c b/drm/nouveau_bo.c
index 9a8adeec80cd..ed9a6946f6d6 100644
--- a/drm/nouveau_bo.c
+++ b/drm/nouveau_bo.c
@@ -214,6 +214,9 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
nvbo->tile_flags = tile_flags;
nvbo->bo.bdev = &drm->ttm.bdev;
+ if (!nv_device_is_cpu_coherent(nvkm_device(&drm->device)))
+ nvbo->force_coherent = flags & TTM_PL_FLAG_UNCACHED;
+
nvbo->page_shift = 12;
if (drm->client.vm) {
if (!(flags & TTM_PL_FLAG_TT) && size > 256 * 1024)
@@ -291,8 +294,9 @@ void
nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t busy)
{
struct ttm_placement *pl = &nvbo->placement;
- uint32_t flags = TTM_PL_MASK_CACHING |
- (nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
+ uint32_t flags = (nvbo->force_coherent ? TTM_PL_FLAG_UNCACHED :
+TTM_PL_MASK_CACHING) |
+(nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
pl->placement = nvbo->placements;
set_placement_list(nvbo->placements, &pl->num_placement,
@@ -396,7 +400,14 @@ nouveau_bo_map(struct nouveau_bo *nvbo)
if (ret)
return ret;
- ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.mem.num_pages, &nvbo->kmap);
+ /*
+* TTM buffers allocated using the DMA API already have a mapping, let's
+* use it instead.
+*/
+ if (!nvbo->force_coherent)
+ ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.mem.num_pages,
+ &nvbo->kmap);
+
ttm_bo_unreserve(&nvbo->bo);
return ret;
}
@@ -404,7 +415,14 @@ nouveau_bo_map(struct nouveau_bo *nvbo)
void
nouveau_bo_unmap(struct nouveau_bo *nvbo)
{
- if (nvbo)
+ if (!nvbo)
+ return;
+
+ /*
+* TTM buffers allocated using the DMA API already had a coherent
+* mapping which we used, no need to unmap.
+*/
+ if (!nvbo->force_coherent)
ttm_bo_kunmap(&nvbo->kmap);
}
@@ -422,12 +440,36 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool
interruptible,
return 0;
}
+static inline void *
+_nouveau_bo_mem_index(struct nouveau_bo *nvbo, unsigned index, void *mem, u8
sz)
+{
+ struct ttm_dma_tt *dma_tt;
+ u8 *m = mem;
+
+ index *= sz;
+
+ if (m) {
+ /* kmap'd address, return the corresponding offset */
+ m += index;
+ } else {
+ /* DMA-API mapping, lookup the right address */
+ dma_tt = (struct ttm_dma_tt *)nvbo->bo.ttm;
+ m = dma_tt->cpu_address[index / PAGE_SIZE];
+ m += index % PAGE_SIZE;
+ }
+
+ return m;
+}
+#define nouveau_bo_mem_index(o, i, m) _nouveau_bo_mem_index(o, i, m,
sizeof(*m))
+
u16
nouveau_bo_rd16(struct nouveau_bo *nvbo, unsigned index)
{
bool is_iomem;
u16 *mem = ttm_kmap_obj_virtual(&nvbo->kmap, &is_iomem);
- mem = &mem[index];
+
+ mem = nouveau_bo_mem_index(nvbo, index, mem);
+
if (is_iomem)
return ioread16_native((void __force __iomem *)mem);
else
@@ -439,7 +481,9 @@ nouveau_bo_wr16(struct nouveau_bo *nvbo, unsigned index,
u16 val)
{
bool is_iomem;
u16 *mem = ttm_kmap_obj_virtual(&nvbo->kmap, &is_iomem);
- mem = &mem[index];
+
+ mem = nouveau_bo_mem_index(nvbo, index, mem);
+
if (is_iomem)
iowrite16_native(val, (void __force __iomem *)mem);
else
@@ -451,7 +495,9 @@ nouveau_bo_rd32(struct nouveau_bo *nvbo, unsigned index)
{
bool is_iomem;
u32 *mem = ttm_kmap_obj_virtual(&nvbo->kmap, &is_iomem);
- mem = &mem[index];
+
+ mem = nouveau_bo_mem_index(nvbo, index, mem);
+
if (is_iomem)
return ioread32_native((void __force __iomem *)mem);
else
@@ -463,7 +509,9 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned index,
u32 val)
{
bool is_iomem;
u32 *mem = ttm_kmap_obj_virtual(&nvbo->kmap, &is_iomem);
- mem = &mem[index];
+
+ mem = nouveau_bo_mem_index(nvbo, index, mem);
+
if (is_iomem)
iowrite32_native(val, (void __force __iomem
[PATCH v5 1/4] drm: introduce nv_device_is_cpu_coherent()
Add a function allowing us to know whether a device is CPU-coherent,
i.e. accesses performed by the CPU on GPU-mapped buffers will
be immediately visible on the GPU side and vice-versa.
For now, a device is considered to be coherent if it uses the PCI bus on
a non-ARM architecture.
Signed-off-by: Alexandre Courbot
---
lib/core/os.h | 2 ++
nvkm/include/core/device.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/lib/core/os.h b/lib/core/os.h
index fba9542292ac..79462eb2cfd4 100644
--- a/lib/core/os.h
+++ b/lib/core/os.h
@@ -101,6 +101,8 @@ typedef dma_addr_t resource_size_t;
#define __printf(a,b)
#define __user
+#define IS_ENABLED(x) (0)
+
static inline int
order_base_2(u64 base)
{
diff --git a/nvkm/include/core/device.h b/nvkm/include/core/device.h
index 1d9d893929bb..0d839e1ddaf4 100644
--- a/nvkm/include/core/device.h
+++ b/nvkm/include/core/device.h
@@ -158,6 +158,12 @@ nv_device_is_pci(struct nouveau_device *device)
return device->pdev != NULL;
}
+static inline bool
+nv_device_is_cpu_coherent(struct nouveau_device *device)
+{
+ return (!IS_ENABLED(CONFIG_ARM) && nv_device_is_pci(device));
+}
+
static inline struct device *
nv_device_base(struct nouveau_device *device)
{
--
2.1.2
[PATCH v5 0/4] drm: nouveau: memory coherency on ARM
It has been a couple of months since v4 - apologies for this. v4 has not received many comments, but this version addresses them and makes a new attempt at pushing the critical bit for GK20A and Nouveau on ARM in general. As a reminder, this series addresses the memory coherency issue that we are seeing on ARM platforms. Contrary to x86 which invalidates the PCI caches whenever a write is made by the CPU to a GPU-accessed area (and vice-versa), such accesses on ARM might result in the other accessor to end up in an incoherent state. To address this, patches 1-3 add the ability to understand whether we are on a non-coherent architecture, implement a way to explicitly allocate coherent buffers buffers using the DMA API, and uses it for GPFIFOS and fences. Patch 4 also uses the DMA API to synchronize user-space allocated buffers when they are passed from the CPU to the GPU and vice-versa. Thanks to the feedback received on the previous revisions I believe this code looks rather good now. I also have extensively tested it and could not see any buffer corruption issue anymore. There is still one point which is not completely satisfying in my opinion: TTMs for TTM-backed objects are allocated in nouveau_sgdma_create_ttm() and populated in nouveau_ttm_tt_populate(). Coherently-allocated buffers need to use the ttm_dma API instead of the pool-based TTM API, and whether an object is coherent or not is stored in its instance of nouveau_bo. The problem is that neither nouveau_sgdma_create_ttm() nor nouveau_ttm_tt_populate() have a way to access the nouveau_bo they are working for. This is in particular a problem for nouveau_ttm_tt_populate() since we need to rely on a purely TTM-based heuristic to decide how to allocate the memory. The heuristic we are using works, but it makes the code harder to understand than if we could just access the nouveau_bo. nouveau_sgdma_create_ttm() always allocates a ttm_dma_tt structure, which is wrong but happens to suit us for now. Still, this part of the code could be rewritten much more cleanly if only we could access the nouveau_bo instance in these functions. I proposed some time ago to address this by making the ttm_tt_create hook take a pointer to a ttm_bo_object instead of a ttm_bo_device. This would still allow us to access the ttm_bo_device, while letting us retrieve the nouveau_bo and store it into whatever structure we embed our TTM into. For some reason David was not fond of the idea - I am taking another chance at submitting it since the issue is still not resolved and leads in inferior-looking code in at least Nouveau. Phew, sorry for the long cover letter - thanks if you have read until here! :) Changes since v4: - Only use DMA API for sync, as suggested by Daniel Alexandre Courbot (4): drm: introduce nv_device_is_cpu_coherent() drm: implement explicitly coherent BOs drm: allocate GPFIFOs and fences coherently drm: synchronize BOs when required drm/nouveau_bo.c | 122 ++--- drm/nouveau_bo.h | 3 ++ drm/nouveau_chan.c | 2 +- drm/nouveau_gem.c | 12 + drm/nv84_fence.c | 4 +- lib/core/os.h | 2 + nvkm/include/core/device.h | 6 +++ 7 files changed, 140 insertions(+), 11 deletions(-) -- 2.1.2
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #2 from Michael Mair-Keimberger --- (In reply to Alex Deucher from comment #1) > Likely a duplicate of: > https://bugs.freedesktop.org/show_bug.cgi?id=84662 > and > https://bugs.freedesktop.org/show_bug.cgi?id=84570 > Can you bisect? Sure, give me some days - i'll try to bisect the problem. :) Guess it will take some time, since there were many commits between 3.16 and 3.17rc1. I'll take the kernel git tree for the bisect (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git) and bisect between 3.16rc8 and 3.17rc1. As soon as i have some result's i'll gonna update this bug. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #31 from José Suárez --- I've been testing linux 3.18 rc1 for a few days and I've found it to be quite stable with regard to this bug. No hangs for me yet, but the Patcket0 massages still show up in dmesg. -- 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/20141027/bec5fa7a/attachment.html>
[PATCH 02/11] radeon: evergreen: Fix probable mask then right shift defects
On 27.10.2014 14:24, Joe Perches wrote: > Precedence of & and >> is not the same and is not left to right. > shift has higher precedence and should be done after the mask. > > Add parentheses around the mask. > > Use the already #defined values instead of hardcoding. > > Signed-off-by: Joe Perches > --- > drivers/gpu/drm/radeon/evergreen.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/evergreen.c > b/drivers/gpu/drm/radeon/evergreen.c > index a31f1ca..a97a685 100644 > --- a/drivers/gpu/drm/radeon/evergreen.c > +++ b/drivers/gpu/drm/radeon/evergreen.c > @@ -3303,7 +3303,8 @@ static void evergreen_gpu_init(struct radeon_device > *rdev) > rdev->config.evergreen.tile_config |= > ((gb_addr_config & 0x3000) >> 28) << 12; > > - num_shader_engines = (gb_addr_config & NUM_SHADER_ENGINES(3) >> 12) + 1; > + num_shader_engines = ((gb_addr_config & NUM_SHADER_ENGINES_MASK) > + >> NUM_SHADER_ENGINES) + 1; ^^ I think this should be NUM_SHADER_ENGINES_SHIFT? Looks good to me other than that. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #181 from agapito --- After 5 hours i am still stable. I've played L4D2, unigine valley, watched vdpau content, flash videos, Google Earth, chromium with a lot of tabs, kwin effects... HD7950 under Archlinux with 3.18 rc2 kernel and mesa 10.3.2 -- 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/20141027/74736746/attachment.html>
[PATCH] allow 32bpp framebuffers for cirrus drm
On Mo, 2014-10-27 at 11:00 -0400, Adam Jackson wrote: > On Fri, 2014-10-24 at 18:31 -0700, Stéphane Marchesin wrote: > > > Dave, Adam: are you ok with this patch? > > Seems like it doesn't go far enough? You'd already need an "aware" > guest to have this work, since the chip actually being emulated didn't > have 32bpp. The pitch check would prevent 1024x768x32 and larger from > working, which makes it sort of a weak win on its own. > > Could we read the BAR size from the device instead of hardcoding 4M? > That alone would make 1920x1200x16 work; and then, if that pitch limit > isn't encoded into the register space representation, the aware guest > would have resolutions worth using at least be possible. How about stop using cirrus and go for 'qemu -vga std' instead? Linux kernel 3.14+ comes with a modesetting driver for the qemu standard vga (CONFIG_DRM_BOCHS). Just switch over, and all your cirrus pain is gone. That is much better than trying use features the real cirrus hardware never had, then praying that all qemu versions in the wild are actually doing what you want qemu do. cheers, Gerd https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
[PATCH 1/2] drm: make sure visible is set to false if fb is null
On Fri, Oct 24, 2014 at 07:00:17PM +0100, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> We can't let visible set true while the fb is null, some places of
> the code only check for visible to base its decisions.
>
> Signed-off-by: Gustavo Padovan
For the series:
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_plane_helper.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index 827ec1a..fe4d1fb 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -127,6 +127,11 @@ int drm_plane_helper_check_update(struct drm_plane
> *plane,
> return -ERANGE;
> }
>
> + if (!fb) {
> + *visible = false;
> + return 0;
> + }
> +
> *visible = drm_rect_clip_scaled(src, dest, clip, hscale, vscale);
> if (!*visible)
> /*
> --
> 1.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[PATCH 1/5] MAINTAINERS: Add entry for MIPI DSI bus
On 10/27/2014 03:17 PM, Daniel Vetter wrote: > On Mon, Oct 27, 2014 at 10:48:26AM +0100, Andrzej Hajda wrote: >> Signed-off-by: Andrzej Hajda >> --- >> MAINTAINERS | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index dd31933..476679c 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -3071,6 +3071,13 @@ F:drivers/gpu/vga/ >> F: include/drm/ >> F: include/uapi/drm/ >> >> +DRM MIPI DSI BUS >> +M: Andrzej Hajda >> +L: dri-devel at lists.freedesktop.org >> +S: Supported >> +F: drivers/gpu/drm/drm_mipi_dsi.c >> +F: include/drm/drm_mipi_dsi.h > > I really prefer when common infrastructure like this doesn't get > maintainer by a vendor. And I care with my intel hat on since we also ahve > a dsi driver that sooner or later needs to be converted to to this stuff. > > Why doesn't the usual model of merging stuff through Dave's tree, or if > that doesn't work well due to patch depencies, through vendor trees with > Dave's ack? The main intention of this patch is to be on CC in case of patches touching MIPI DSI bus. I do not want to create separate tree for such small subsystem. So if such things are not allowed please drop the patch and sorry for the noise. Regards Andrzej > > Thanks, Daniel > >> + >> RADEON DRM DRIVERS >> M: Alex Deucher >> M: Christian König >> -- >> 1.9.1 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar
wrote:
> A set of helper functions are defined in this patch to make
> bridge driver probe independent of the drm flow.
>
> The bridge devices register themselves on a lookup table
> when they get probed by calling "drm_bridge_add".
>
> The parent encoder driver waits till the bridge is available
> in the lookup table(by calling "of_drm_find_bridge") and then
> continues with its initialization.
>
> The encoder driver should also call "drm_bridge_attach" to pass
> on the drm_device, encoder pointers to the bridge object.
>
> drm_bridge_attach inturn calls drm_bridge_init to register itself
> with the drm core. Later, it calls "bridge->funcs->attach" so that
> bridge can continue with other initializations.
>
> Signed-off-by: Ajay Kumar
> ---
> drivers/gpu/drm/Makefile |1 +
> drivers/gpu/drm/bridge/Kconfig | 15 -
> drivers/gpu/drm/drm_bridge.c | 102
>
> drivers/gpu/drm/drm_crtc.c |4 +-
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |4 +-
> include/drm/drm_crtc.h | 12 +++-
> 6 files changed, 131 insertions(+), 7 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_bridge.c
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 4a55d59..bdbfb6f 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -19,6 +19,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
> drm_cache.o \
> drm-$(CONFIG_COMPAT) += drm_ioc32.o
> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> drm-$(CONFIG_PCI) += ati_pcigart.o
> +drm-$(CONFIG_DRM_BRIDGE) += drm_bridge.o
> drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> drm-$(CONFIG_OF) += drm_of.o
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 884923f..5a8e907 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -1,5 +1,16 @@
> -config DRM_PTN3460
> - tristate "PTN3460 DP/LVDS bridge"
> +config DRM_BRIDGE
I'm not convinced this adds any value, to be honest. In addition to
whether or not it's useful, it seems like you'd need to stub the
drm_bridge_* functions that are declared in drm_crtc.h or break them
out into drm_bridge.h.
Sean
> + tristate
> depends on DRM
> select DRM_KMS_HELPER
> + help
> + Bridge registration and lookup framework.
> +
> +menu "bridge chips"
> + depends on DRM_BRIDGE
> +
> +config DRM_PTN3460
> + tristate "PTN3460 DP/LVDS bridge"
> + depends on DRM_BRIDGE
> ---help---
> +
> +endmenu
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> new file mode 100644
> index 000..b2d43fd
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -0,0 +1,102 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd
> + *
> + * 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, sub license,
> + * 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 (including the
> + * next paragraph) 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 NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS 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.
> + */
> +
> +#include
> +#include
> +
> +#include
> +
> +#include "drm/drmP.h"
> +
> +static DEFINE_MUTEX(bridge_lock);
> +static LIST_HEAD(bridge_list);
> +
> +int drm_bridge_add(struct drm_bridge *bridge)
> +{
> + mutex_lock(&bridge_lock);
> + list_add_tail(&bridge->list, &bridge_list);
> + mutex_unlock(&bridge_lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_bridge_add);
> +
> +void drm_bridge_remove(struct drm_bridge *bridge)
> +{
> + mutex_lock(&bridge_lock);
> + list_del_init(&bridge->list);
> + mutex_unlock(&bridge_lock);
> +}
> +EXPORT_SYMBOL(drm_bridge_remove);
> +
> +int drm_bridge_attach(struct drm_bridge *bridge,
> + struct drm_encoder *encoder)
> +{
> + int ret;
> +
> + if (!bridge || !encoder)
> + return -EINVAL;
> +
> + if (bridge->encoder)
> + return -EBUSY;
> +
> + encoder->b
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #247 from Alex Deucher --- (In reply to Mateusz JoÅczyk from comment #246) > (In reply to Alex Deucher from comment #244) > > Created attachment 106085 [details] [review] [review] > > workaround for basic enablement > > > > As per feedback from the last few comments the attached patch forces the > > performance level to high rather than auto which should fix the stability > > issues and lower power usage due to clockgating, etc. and enables dpm by > > default for rv6xx. > > Is this patch going to be mainlined? (or was it mainlined already?) Not until it's tested and it proves to work reliably on all the problematic systems here. -- 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/20141027/e90a0b5e/attachment.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
> So don't ask why but I accidentally ended up in a branch looking at this
> patch and didn't like it. So very quick&grumpy review.
>
> First, please make the patch subject more descriptive: I'd expect a helper
> function scaffolding like the various crtc/probe/dp ... helpers we already
> have. You instead add code to untangle the probe ordering. Please say so.
>
> More comments below.
>
> On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when they get probed by calling "drm_bridge_add".
>>
>> The parent encoder driver waits till the bridge is available
>> in the lookup table(by calling "of_drm_find_bridge") and then
>> continues with its initialization.
>>
>> The encoder driver should also call "drm_bridge_attach" to pass
>> on the drm_device, encoder pointers to the bridge object.
>>
>> drm_bridge_attach inturn calls drm_bridge_init to register itself
>> with the drm core. Later, it calls "bridge->funcs->attach" so that
>> bridge can continue with other initializations.
>>
>> Signed-off-by: Ajay Kumar
>
> [snip]
>
>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
>> * @driver_private: pointer to the bridge driver's internal context
>> */
>> struct drm_bridge {
>> - struct drm_device *dev;
>> + struct device *dev;
>
> Please don't rename the ->dev pointer into drm. Because _all_ the other
> drm structures still call it ->dev. Also, can't we use struct device_node
> here like we do in the of helpers Russell added? See 7e435aad38083
>
I think this is modeled after the naming in drm_panel, FWIW. However,
seems reasonable to keep the device_node instead.
>> + struct drm_device *drm;
>> + struct drm_encoder *encoder;
>
> This breaks bridge->bridge chaining (if we ever get there). It seems
> pretty much unused anyway except for an EBUSY check. Can't you use
> bridge->dev for that?
>
Yeah, I'd prefer to pass drm_device directly into drm_bridge_attach
and leave it up to the caller to establish the proper chain.
>> struct list_head head;
>> + struct list_head list;
>
> These lists need better names. I know that the "head" is really awful,
> especially since it's actually not the head of the list but just an
> element.
I think we can just rip bridge_list out of mode_config if we're going
to keep track of bridges elsewhere. So we can nuke "head" and keep
"list". This also means that bridge->destroy() goes away, but that's
probably Ok if everything converts to the standalone driver model
where we have driver->remove()
Sean
>>
>> struct drm_mode_object base;
>
>
> Aside: I've noticed all this trying to update the kerneldoc for struct
> drm_bridge, which just showed that this patch makes inconsistent changes.
> Trying to write kerneldoc is a really great way to come up with better
> interfaces imo.
>
> Cheers, Daniel
>
>>
>> @@ -906,6 +911,11 @@ extern void drm_connector_cleanup(struct drm_connector
>> *connector);
>> /* helper to unplug all connectors from sysfs for device */
>> extern void drm_connector_unplug_all(struct drm_device *dev);
>>
>> +extern int drm_bridge_add(struct drm_bridge *bridge);
>> +extern void drm_bridge_remove(struct drm_bridge *bridge);
>> +extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
>> +extern int drm_bridge_attach(struct drm_bridge *bridge,
>> + struct drm_encoder *encoder);
>> extern int drm_bridge_init(struct drm_device *dev, struct drm_bridge
>> *bridge);
>> extern void drm_bridge_cleanup(struct drm_bridge *bridge);
>>
>> --
>> 1.7.9.5
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH V7 02/12] drm/bridge: do not pass drm_bridge_funcs to drm_bridge_init
On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar
wrote:
> Assign the pointer to bridge ops structure(drm_bridge_funcs) in
> the bridge driver itself, instead of passing it to drm_bridge_init.
>
> This will allow bridge driver developer to pack bridge private
> information inside the bridge object and pass only the drm-relevant
> information to drm_bridge_init.
>
> Signed-off-by: Ajay Kumar
This matches how drm_panel works, which it looks like this set is
trying to emulate.
Acked-by: Sean Paul
> ---
> drivers/gpu/drm/bridge/ptn3460.c |3 ++-
> drivers/gpu/drm/drm_crtc.c |5 +
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 ++-
> drivers/gpu/drm/sti/sti_hda.c |3 ++-
> drivers/gpu/drm/sti/sti_hdmi.c |3 ++-
> include/drm/drm_crtc.h |3 +--
> 6 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ptn3460.c
> b/drivers/gpu/drm/bridge/ptn3460.c
> index 4db38e1..a2ddc8d 100644
> --- a/drivers/gpu/drm/bridge/ptn3460.c
> +++ b/drivers/gpu/drm/bridge/ptn3460.c
> @@ -313,7 +313,8 @@ int ptn3460_init(struct drm_device *dev, struct
> drm_encoder *encoder,
> goto err;
> }
>
> - ret = drm_bridge_init(dev, &ptn_bridge->bridge,
> &ptn3460_bridge_funcs);
> + ptn_bridge->bridge.funcs = &ptn3460_bridge_funcs;
> + ret = drm_bridge_init(dev, &ptn_bridge->bridge);
> if (ret) {
> DRM_ERROR("Failed to initialize bridge with drm\n");
> goto err;
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fa2be24..25f5cfa 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1022,7 +1022,6 @@ EXPORT_SYMBOL(drm_connector_unplug_all);
> * drm_bridge_init - initialize a drm transcoder/bridge
> * @dev: drm device
> * @bridge: transcoder/bridge to set up
> - * @funcs: bridge function table
> *
> * Initialises a preallocated bridge. Bridges should be
> * subclassed as part of driver connector objects.
> @@ -1030,8 +1029,7 @@ EXPORT_SYMBOL(drm_connector_unplug_all);
> * Returns:
> * Zero on success, error code on failure.
> */
> -int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
> - const struct drm_bridge_funcs *funcs)
> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge)
> {
> int ret;
>
> @@ -1042,7 +1040,6 @@ int drm_bridge_init(struct drm_device *dev, struct
> drm_bridge *bridge,
> goto out;
>
> bridge->dev = dev;
> - bridge->funcs = funcs;
>
> list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
> dev->mode_config.num_bridge++;
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> index f6cf745..0309539 100644
> --- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> +++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
> @@ -221,8 +221,9 @@ struct drm_bridge *hdmi_bridge_init(struct hdmi *hdmi)
> hdmi_bridge->hdmi = hdmi_reference(hdmi);
>
> bridge = &hdmi_bridge->base;
> + bridge->funcs = &hdmi_bridge_funcs;
>
> - drm_bridge_init(hdmi->dev, bridge, &hdmi_bridge_funcs);
> + drm_bridge_init(hdmi->dev, bridge);
>
> return bridge;
>
> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> index 72d957f..b3344c7 100644
> --- a/drivers/gpu/drm/sti/sti_hda.c
> +++ b/drivers/gpu/drm/sti/sti_hda.c
> @@ -664,7 +664,8 @@ static int sti_hda_bind(struct device *dev, struct device
> *master, void *data)
> return -ENOMEM;
>
> bridge->driver_private = hda;
> - drm_bridge_init(drm_dev, bridge, &sti_hda_bridge_funcs);
> + bridge->funcs = &sti_hda_bridge_funcs;
> + drm_bridge_init(drm_dev, bridge);
>
> encoder->bridge = bridge;
> connector->encoder = encoder;
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index 284e541..3ad319f 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -629,7 +629,8 @@ static int sti_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> return -ENOMEM;
>
> bridge->driver_private = hdmi;
> - drm_bridge_init(drm_dev, bridge, &sti_hdmi_bridge_funcs);
> + bridge->funcs = &sti_hdmi_bridge_funcs;
> + drm_bridge_init(drm_dev, bridge);
>
> encoder->bridge = bridge;
> connector->encoder = encoder;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index f1105d0..f48a436 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -906,8 +906,7 @@ extern void drm_connector_cleanup(struct drm_connector
> *connector);
> /* helper to unplug all connectors from sysfs for device */
> extern void drm_connector_unplug_all(struct drm_device *dev);
>
> -extern int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
> -
[PATCH] allow 32bpp framebuffers for cirrus drm
Real cirrus did have 32bpp according to both the reference manual and qemu's emulation of the hardware. The cirrus DRM driver even had the modesetting code for 32bpp but the driver prevented the creation of 32bpp framebuffers. Best, Zach On Mon, Oct 27, 2014, 08:30 Gerd Hoffmann wrote: > On Mo, 2014-10-27 at 11:00 -0400, Adam Jackson wrote: > > On Fri, 2014-10-24 at 18:31 -0700, Stéphane Marchesin wrote: > > > > > Dave, Adam: are you ok with this patch? > > > > Seems like it doesn't go far enough? You'd already need an "aware" > > guest to have this work, since the chip actually being emulated didn't > > have 32bpp. The pitch check would prevent 1024x768x32 and larger from > > working, which makes it sort of a weak win on its own. > > > > Could we read the BAR size from the device instead of hardcoding 4M? > > That alone would make 1920x1200x16 work; and then, if that pitch limit > > isn't encoded into the register space representation, the aware guest > > would have resolutions worth using at least be possible. > > How about stop using cirrus and go for 'qemu -vga std' instead? > > Linux kernel 3.14+ comes with a modesetting driver for the qemu standard > vga (CONFIG_DRM_BOCHS). Just switch over, and all your cirrus pain is > gone. > > That is much better than trying use features the real cirrus hardware > never had, then praying that all qemu versions in the wild are actually > doing what you want qemu do. > > cheers, > Gerd > > https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/ > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141027/0115b8d0/attachment-0001.html>
[Intel-gfx] [PATCH 1/2] drm: make sure visible is set to false if fb is null
On Mon, Oct 27, 2014 at 04:23:26PM +0200, Ville Syrjälä wrote: > On Fri, Oct 24, 2014 at 07:00:17PM +0100, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > We can't let visible set true while the fb is null, some places of > > the code only check for visible to base its decisions. > > > > Signed-off-by: Gustavo Padovan > > For the series: > Reviewed-by: Ville Syrjälä Both merged to dinq, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/5] MAINTAINERS: Add entry for MIPI DSI bus
On Mon, Oct 27, 2014 at 10:48:26AM +0100, Andrzej Hajda wrote: > Signed-off-by: Andrzej Hajda > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index dd31933..476679c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3071,6 +3071,13 @@ F: drivers/gpu/vga/ > F: include/drm/ > F: include/uapi/drm/ > > +DRM MIPI DSI BUS > +M: Andrzej Hajda > +L: dri-devel at lists.freedesktop.org > +S: Supported > +F: drivers/gpu/drm/drm_mipi_dsi.c > +F: include/drm/drm_mipi_dsi.h I really prefer when common infrastructure like this doesn't get maintainer by a vendor. And I care with my intel hat on since we also ahve a dsi driver that sooner or later needs to be converted to to this stuff. Why doesn't the usual model of merging stuff through Dave's tree, or if that doesn't work well due to patch depencies, through vendor trees with Dave's ack? Thanks, Daniel > + > RADEON DRM DRIVERS > M: Alex Deucher > M: Christian König > -- > 1.9.1 > > ___ > 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
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
I guess it's debatable whether drivers should automatically use features in the kernel if they happen to be enabled in the Kconfig, or should they be individually enabled for that driver. I personally like the latter option, as it allows more precise control, but it probably also depends on the feature in question. I also think the 'depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds like a hack to me =). Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141027/aaad451e/attachment-0001.sig>
[PATCH qxl] qxl: don't create too large primary surface
ping
On Thu, Oct 16, 2014 at 11:39 AM, Marc-André Lureau <
marcandre.lureau at gmail.com> wrote:
> Limit primary to qemu vgamem size, to avoid reaching
> qemu guest bug "requested primary larger than framebuffer"
> on resizing screen too large to fit.
>
> Remove unneeded and misleading variables.
>
> Related to:
> https://bugzilla.redhat.com/show_bug.cgi?id=1127552
>
> Signed-off-by: Marc-André Lureau
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 5d7ea24..98a344c 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -523,7 +523,6 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
> struct qxl_framebuffer *qfb;
> struct qxl_bo *bo, *old_bo = NULL;
> struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
> - uint32_t width, height, base_offset;
> bool recreate_primary = false;
> int ret;
> int surf_id;
> @@ -553,9 +552,10 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
> if (qcrtc->index == 0)
> recreate_primary = true;
>
> - width = mode->hdisplay;
> - height = mode->vdisplay;
> - base_offset = 0;
> + if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
> + DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
> + return -EINVAL;
> +}
>
> ret = qxl_bo_reserve(bo, false);
> if (ret != 0)
> @@ -569,10 +569,10 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
> if (recreate_primary) {
> qxl_io_destroy_primary(qdev);
> qxl_io_log(qdev,
> - "recreate primary: %dx%d (was %dx%d,%d,%d)\n",
> - width, height, bo->surf.width,
> - bo->surf.height, bo->surf.stride,
> bo->surf.format);
> - qxl_io_create_primary(qdev, base_offset, bo);
> + "recreate primary: %dx%d,%d,%d\n",
> + bo->surf.width, bo->surf.height,
> + bo->surf.stride, bo->surf.format);
> + qxl_io_create_primary(qdev, 0, bo);
> bo->is_primary = true;
> }
>
> --
> 1.9.3
>
>
--
Marc-André Lureau
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141027/90e09367/attachment.html>
[Bug 85454] Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 --- Comment #3 from sarnex --- (In reply to Michel Dänzer from comment #1) > Can you run it with the environment variable R600_DEBUG=vs,ps and attach the > stderr output from that? > > P.S. Any particular reason for not using the Linux version of Unigine > Sanctuary? Hi Michel, thanks for your response. The stderr output is attached. PS. The crash does NOT occur in native Linux Sanctuary, it works perfectly. I was testing the preformance of wine d3d9 vs gallium nine. -- 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/20141027/cd0162af/attachment.html>
[Bug 85454] Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 --- Comment #2 from sarnex --- Created attachment 108512 --> https://bugs.freedesktop.org/attachment.cgi?id=108512&action=edit stderr stderr -- 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/20141027/e78323da/attachment.html>
[PATCH 12/12] ARM: shmobile: koelsch: Add DU HDMI output support
Hi Simon,
On Monday 27 October 2014 09:38:29 Simon Horman wrote:
> On Wed, Sep 24, 2014 at 11:04:32PM +0300, Laurent Pinchart wrote:
> > Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector
> > and configure the DISP pin group that drives the HDMI transmitter DE
> > pin.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Acked-by: Simon Horman
>
> Please be careful of any conflicts that may arise if this patch
> doesn't go through my renesas tree.
I think it would be best if the patch went through your tree. There's no
compile time or runtime dependency on the DU HDMI code, so as soon as the
ADV7511 DT bindings get accepted I plan to ask you to merge this patch.
> > ---
> >
> > arch/arm/boot/dts/r8a7791-koelsch.dts | 50 +-
> > 1 file changed, 49 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
> > b/arch/arm/boot/dts/r8a7791-koelsch.dts index 9051e01..b7d0c41 100644
> > --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> > +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> > @@ -209,6 +209,17 @@
> > states = <330 1
> > 180 0>;
> > };
> > +
> > + hdmi-out {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con: endpoint {
> > + remote-endpoint = <&adv7511_out>;
> > + };
> > + };
> > + };
> > };
> >
> > &du {
> > @@ -217,6 +228,11 @@
> > status = "okay";
> >
> > ports {
> > + port at 0 {
> > + endpoint {
> > + remote-endpoint = <&adv7511_in>;
> > + };
> > + };
> > port at 1 {
> > lvds_connector: endpoint {
> > };
> > @@ -235,7 +251,7 @@
> > };
> >
> > du_pins: du {
> > - renesas,groups = "du_rgb666", "du_sync", "du_clk_out_0";
> > + renesas,groups = "du_rgb666", "du_sync", "du_disp",
> > "du_clk_out_0";
> > renesas,function = "du";
> > };
> >
> > @@ -439,6 +455,38 @@
> > };
> > };
> >
> > + hdmi at 39 {
> > + compatible = "adi,adv7511w";
> > + reg = <0x39>;
> > + interrupt-parent = <&gpio3>;
> > + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> > +
> > + adi,input-depth = <8>;
> > + adi,input-colorspace = "rgb";
> > + adi,input-clock = "1x";
> > + adi,input-style = <1>;
> > + adi,input-justification = "evenly";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > + adv7511_in: endpoint {
> > + remote-endpoint = <&du_out_rgb>;
> > + };
> > + };
> > +
> > + port at 1 {
> > + reg = <1>;
> > + adv7511_out: endpoint {
> > + remote-endpoint = <&hdmi_con>;
> > + };
> > + };
> > + };
> > + };
> > +
> > eeprom at 50 {
> > compatible = "renesas,24c02";
> > reg = <0x50>;
--
Regards,
Laurent Pinchart
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Wed, 22 Oct 2014, Tomi Valkeinen wrote: > On 18/10/14 00:13, Jani Nikula wrote: >> Documentation/kbuild/kconfig-language.txt warns to use select with care, >> and in general use select only for non-visible symbols and for symbols >> with no dependencies, because select will force a symbol to a value >> without visiting the dependencies. >> >> Select has become particularly problematic, interdependently, with the >> BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example: >> >> scripts/kconfig/conf --randconfig Kconfig >> KCONFIG_SEED=0x48312B00 >> warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && >> DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY >> && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && >> EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE >> which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) >> warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && >> DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY >> && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && >> EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE >> which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) >> >> With tristates it's possible to end up selecting FOO=y depending on >> BAR=m in the config, which gets discovered at build time, not config >> time, like reported in the thread referenced below. >> >> Do the following to fix the dependencies: >> >> * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop >> select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of >> BACKLIGHT_CLASS_DEVICE. >> >> * Remove config FB_BACKLIGHT altogether, and replace it with a >> dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting >> FB_BACKLIGHT select or depend on FB anyway, so we can simplify. >> >> * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of >> selecting ACPI_VIDEO and a number of its dependencies if ACPI is >> enabled. This is tied to backlight, as ACPI_VIDEO depends on >> BACKLIGHT_CLASS_DEVICE. >> >> * Replace a couple of select INPUT/VT with depends as it seemed to be >> necessary. > > While doing 'depends on' instead of 'select' is an "easy" fix for this, > I do dislike it quite a bit. It's a major pain to go around the kernel > config, trying to find all the dependencies that a particular driver > wants. If I need fb-foobar, I should just be able to enable it, instead > of first searching and selecting its minor dependencies individually. Agreed, but I don't think that's specific to this patch. > So, not a NACK, but a "isn't there an another way to fix this?". I think the real answer would be to fix kconfig to also show menu items whose dependencies are not met, and then recursively enabling the dependencies when the item is enabled. Beyond my scope. > Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta" > option, it only enables a Kconfig submenu. > > So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option. > But if we do that, all the items in drivers/video/backlight/Kconfig with > default 'y' or 'm' would get enabled by default, so I think we should > remove the 'default's from that file. That makes sense in any case, as I > don't see why "HP Jornada 700 series LCD Driver" should be "default y". > > BACKLIGHT_CLASS_DEVICE doesn't depend on anything except > BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should > be safe to 'select' BACKLIGHT_CLASS_DEVICE. > > BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in > drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE > could be made to select BACKLIGHT_CLASS_DEVICE instead. I think it should be possible to choose between y and m when it's selected, and it should be possible to enable it when it's not selected by any drivers. I'm not sure a hidden option is good for that. > That doesn't exactly fix anything, but I think it makes sense as > BACKLIGHT_CLASS_DEVICE is something that's selected from all around the > kernel, so it should be a selectable "library" instead of a Kconfig menu > option. At least for drm/i915 BACKLIGHT_CLASS_DEVICE is "an option". We use it if it's enabled, but we are just fine if it's not. I've learned the way to express that is depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n but I don't think there's a way to express that in terms of select, is there? The dependency above guarantees there's no DRM_I915=y and BACKLIGHT_CLASS_DEVICE=m combo which would fail. And this, btw, is where this whole patch got started, as select didn't handle that properly. > I didn't look at the ACPI_VIDEO side, so no idea how messy that is. Basically it's another dependency on BACKLIGHT_CLASS_DEVICE. I can only imagine trying to solve this problem with select is going to end up in recursive depende
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #180 from agapito --- I know it's early to say this but 3.18 rc2 solved this bug for me. -- 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/20141027/7f77c283/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #179 from Maximilian Böhm --- Just want to remind you that there is a Mesa connection somehow. Either it's a kernel call only later Mesa versions implement or it's a Mesa issue â I'm stable for *months* now on Linux 3.16/3.17 and this downgraded packages on Arch Linux with a Radeon HD 7770: ati-dri-10.1.4-1-x86_64.pkg.tar.xz clang-3.4.1-2-x86_64.pkg.tar.xz lib32-llvm-libs-3.4.1-1-x86_64.pkg.tar.xz lib32-mesa-10.1.4-1-x86_64.pkg.tar.xz lib32-mesa-libgl-10.1.4-1-x86_64.pkg.tar.xz llvm-3.4.1-2-x86_64.pkg.tar.xz llvm-libs-3.4.1-2-x86_64.pkg.tar.xz mesa-10.1.4-1-x86_64.pkg.tar.xz mesa-demos-8.1.0-2-x86_64.pkg.tar.xz mesa-libgl-10.1.4-1-x86_64.pkg.tar.xz -- 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/20141027/40ff6ec0/attachment.html>
[PATCH] allow 32bpp framebuffers for cirrus drm
On Mon, 2014-10-27 at 16:30 +0100, Gerd Hoffmann wrote: > How about stop using cirrus and go for 'qemu -vga std' instead? > > Linux kernel 3.14+ comes with a modesetting driver for the qemu standard > vga (CONFIG_DRM_BOCHS). Just switch over, and all your cirrus pain is > gone. > > That is much better than trying use features the real cirrus hardware > never had, then praying that all qemu versions in the wild are actually > doing what you want qemu do. I was going to ask for a pci revision id bump at the same time, so the guest could know. I heartily agree, people should stop using cirrus. And qemu should stop defaulting to it. Since neither has happened yet, enhancing the emulation holds the promise of making the future better... - ajax
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #178 from Jacob --- The "supposedly" random crashes I encountered with 3.15-rc3 weren't really random at all. I came to a somewhat sad realization that only one application actually crashed with it, so the bisection has mostly been a waste. I've personally been stable on 3.14.20, and according to DJ Dunn, the issue has now hit 3.14.22, so I'm gonna check 21 and 22 to see if it crashes for me as well, and this time make sure it's application independent. -- 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/20141027/4a520cbe/attachment.html>
[PATCH] drm/radeon: fix vm lock in radeon_gem_va_update_vm
On Thu, Oct 23, 2014 at 5:32 AM, Christian König wrote: > From: Christian König > > Without the lock we might corrupt the BO lists. > > Might be squashed into "update the VM after setting BO address" for > upstreaming. Squashed into that commit. Thanks! Alex > > Signed-off-by: Christian König > --- > drivers/gpu/drm/radeon/radeon_gem.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_gem.c > b/drivers/gpu/drm/radeon/radeon_gem.c > index 0002575..49d56b5 100644 > --- a/drivers/gpu/drm/radeon/radeon_gem.c > +++ b/drivers/gpu/drm/radeon/radeon_gem.c > @@ -559,12 +559,16 @@ static void radeon_gem_va_update_vm(struct > radeon_device *rdev, > goto error_unreserve; > } > > + mutex_lock(&bo_va->vm->mutex); > r = radeon_vm_clear_freed(rdev, bo_va->vm); > if (r) > - goto error_unreserve; > + goto error_unlock; > > r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem); > > +error_unlock: > + mutex_unlock(&bo_va->vm->mutex); > + > error_unreserve: > ttm_eu_backoff_reservation(&ticket, &list); > > -- > 1.9.1 >
[PATCH] allow 32bpp framebuffers for cirrus drm
On Fri, 2014-10-24 at 18:31 -0700, Stéphane Marchesin wrote: > Dave, Adam: are you ok with this patch? Seems like it doesn't go far enough? You'd already need an "aware" guest to have this work, since the chip actually being emulated didn't have 32bpp. The pitch check would prevent 1024x768x32 and larger from working, which makes it sort of a weak win on its own. Could we read the BAR size from the device instead of hardcoding 4M? That alone would make 1920x1200x16 work; and then, if that pitch limit isn't encoded into the register space representation, the aware guest would have resolutions worth using at least be possible. - ajax
[PATCH 5/5] MAINTAINERS: Add entry for Exynos MIPI DPI DRM driver
Signed-off-by: Andrzej Hajda --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 256183e..06cdb5a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3656,6 +3656,12 @@ L: dri-devel at lists.freedesktop.org S: Supported F: drivers/gpu/drm/exynos/exynos_drm_dsi.c +EXYNOS MIPI DPI DRM DRIVER +M: Andrzej Hajda +L: dri-devel at lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/exynos/exynos_drm_dpi.c + F71805F HARDWARE MONITORING DRIVER M: Jean Delvare L: lm-sensors at lm-sensors.org -- 1.9.1
[PATCH 4/5] MAINTAINERS: Add entry for Exynos MIPI DSI DRM driver
Signed-off-by: Andrzej Hajda --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2546fca..256183e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3650,6 +3650,12 @@ S: Maintained F: drivers/video/fbdev/exynos/exynos_mipi* F: include/video/exynos_mipi* +EXYNOS MIPI DSI DRM DRIVER +M: Andrzej Hajda +L: dri-devel at lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/exynos/exynos_drm_dsi.c + F71805F HARDWARE MONITORING DRIVER M: Jean Delvare L: lm-sensors at lm-sensors.org -- 1.9.1
[PATCH 3/5] MAINTAINERS: Add entry for S6E8AA0 drm panel driver
Signed-off-by: Andrzej Hajda --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6e57cad..2546fca 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3104,6 +3104,13 @@ S: Supported F: drivers/gpu/drm/panel/panel-ld9040.c F: Documentation/devicetree/bindings/panel/samsung,ld9040.txt +DRM PANEL S6E8AA0 DRIVER +M: Andrzej Hajda +L: dri-devel at lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/panel/panel-s6e8aa0.c +F: Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt + INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets) M: Daniel Vetter M: Jani Nikula -- 1.9.1
[PATCH 2/5] MAINTAINERS: Add entry for LD9040 drm panel driver
Signed-off-by: Andrzej Hajda --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 476679c..6e57cad 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3097,6 +3097,13 @@ F: drivers/gpu/drm/panel/ F: include/drm/drm_panel.h F: Documentation/devicetree/bindings/panel/ +DRM PANEL LD9040 DRIVER +M: Andrzej Hajda +L: dri-devel at lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/panel/panel-ld9040.c +F: Documentation/devicetree/bindings/panel/samsung,ld9040.txt + INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets) M: Daniel Vetter M: Jani Nikula -- 1.9.1
[PATCH 1/5] MAINTAINERS: Add entry for MIPI DSI bus
Signed-off-by: Andrzej Hajda --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index dd31933..476679c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3071,6 +3071,13 @@ F: drivers/gpu/vga/ F: include/drm/ F: include/uapi/drm/ +DRM MIPI DSI BUS +M: Andrzej Hajda +L: dri-devel at lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/drm_mipi_dsi.c +F: include/drm/drm_mipi_dsi.h + RADEON DRM DRIVERS M: Alex Deucher M: Christian König -- 1.9.1
[PATCH 0/5] MAINTAINERS: add entries for few DRM drivers
Hi, These patches adds MAINTAINERS entries for DRM panel and encoder drivers and DSI bus I have written. Regards Andrzej Andrzej Hajda (5): MAINTAINERS: Add entry for MIPI DSI bus MAINTAINERS: Add entry for LD9040 drm panel driver MAINTAINERS: Add entry for S6E8AA0 drm panel driver MAINTAINERS: Add entry for Exynos MIPI DSI DRM driver MAINTAINERS: Add entry for Exynos MIPI DPI DRM driver MAINTAINERS | 33 + 1 file changed, 33 insertions(+) -- 1.9.1
[Bulk] Re: [3.16-rcX][pciehp][radeon] PCIe HotPlug conflicts with radeon GPU
On Sun, Oct 26, 2014 at 11:31 AM, Alex Deucher wrote:
> On Mon, Oct 13, 2014 at 12:11 PM, Bjorn Helgaas
> wrote:
>> [+cc Alex, Christian, dri-devel]
>>
>> On Sat, Oct 11, 2014 at 1:37 PM, Shawn Starr
>> wrote:
>>> On September 11, 2014 04:26:21 PM Bjorn Helgaas wrote:
[+cc linux-pci]
On Sat, Aug 2, 2014 at 10:02 AM, Shawn Starr
wrote:
> Hello devs,
>
> There are two issues I am encountering with the PCIe Hotplug driver on my
> Lenovo Laptop (W500). I note this goes back further than 3.15.
>
> It is noted here:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> f244d8b623dae7a7bc695b0336f67729b95a9736
> https://bugzilla.kernel.org/show_bug.cgi?id=79701
>
> And my open bug here:
> https://bugzilla.kernel.org/show_bug.cgi?id=77261
>
> 1) If I enable the device to use both the integrated and discrete GPU,
> pciehp will decide to force unload radeon because it puts itself into a
> power saving state, fails back to the Intel integrated GPU in this case
> unless I tell radeon.ko to runpm=0 (no power management, then pciehp wont
> touch it).
>
> 2) If the Radeon GPU resets and you use pci_reset=1 for kernel module
> option, pciehp decides to force unload radeon even though the GPU is
> trying to setup after failing.
>
> Kernel I am using right now: 3.16.0-0.rc7.git3.1.fc21.x86_64 (about to
> boot into snapshot kernel-core-3.16.0-0.rc7.git4.1.fc21.x86_64)
Hi Shawn,
Thanks for the report and sorry that it got dropped. But I see you're
cc'd on https://bugzilla.kernel.org/show_bug.cgi?id=79701, so you've
probably seen the work there. If you can try out the patches I just
posted, that would be great.
Bjorn
>>>
>>> Hi Bjorn,
>>>
>>> For #1) This is fixed in linux-next (tracking
>>> 3.18.0-0.rc0.git1.2.fc22.1.x86_64
>>> nondebug kernel for Fedora). PCIe HotPlug no longer unloads radeon. For this
>>> bugzilla report we can close it.
>>>
>>> #2) This still has weird results however, radeon.hard_reset=1 is
>>> experimental
>>> and while it attempts to reset GPU, PCIe HotPlug seems to interact in this.
>>>
>>> This can be tested by adding to grub command line radeon.hard_reset=1.
>>> When X has started up, trigger a reset by cat
>>> /sys/kernel/debug/dri/#/radeon_gpu_reset. It will output 0, cat it again
>>> will
>>> show 1.
>>>
>>> Attempt to drag a window. The this will trigger a GPU reset, but fail to
>>> recover, its unknown if PCIe HotPlug is preventing a proper reset or not but
>>> there is pciehp calls in the stack trace.
>>
>> A PCIe device reset usually looks like a hotplug event because the
>> PCIe link goes down and comes back up. As far as the PCI core is
>> concerned, it can't tell the difference between (1) a simple reset
>> where the link bounces and (2) removal of one device followed by
>> addition of another.
>>
>> b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events
>> for a device") addressed this for some similar cases, but it looks
>> like we probably need some more calls to pci_ignore_hotplug() in the
>> radeon driver reset methods.
>>
>> Can you please open a bugzilla and attach the complete dmesg log,
>> including the GPU reset and recovery failure?
>
> Is there a way we could temporarily disable pci hotplug around a GPU reset?
There is pci_ignore_hotplug(). Do you mean something more? Oh, I
guess you mean a way to disable, then *re*-enable hotplug. We can
easily add that if that would help.
Bjorn
[Bug 85508] New: spec/ARB_fragment_program/fp-long-alu: Crash in src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c:1153
https://bugs.freedesktop.org/show_bug.cgi?id=85508 Bug ID: 85508 Summary: spec/ARB_fragment_program/fp-long-alu: Crash in src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c:11 53 Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: kai at dev.carbon-project.org Created attachment 108500 --> https://bugs.freedesktop.org/attachment.cgi?id=108500&action=edit GDB backtrace and register dump of the crash While running Piglit quick on a R9 290 (see below for the full stack), I encountered a crash in src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c on line 1153 in the emit_immediate function, triggered by running spec/ARB_fragment_program/fp-long-alu. The attached file contains a full backtrace and a register dump. Let me know, if you need something else. This might be a duplicate of bug 82477 (or at least caused by that), but since the crash happend somewhere else, I filed my own report. My current stack is (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/1a170980a0 libdrm: Git:master/00847fa48b LLVM: SVN:trunk/r220648 (3.6 devel) X.Org: 2:1.16.1-1 Linux: Git:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git:v3.18-rc1 + attachment 107451 and attachment 107544 Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> > 9e05820da42549ce9c89d147cf1f8e19 > /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_ce.bin > c8bab593090fc54f239c8d7596c8d846 > /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_mc.bin > 3618dbb955d8a84970e262bb2e6d2a16 > /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_me.bin > c000b0fc9ff6582145f66504b0ec9597 > /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_mec.bin > 0643ad24b3beff2214cce533e094c1b7 > /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_pfp.bin > ba6054b7d78184a74602fd81607e1386 > /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_rlc.bin > 11288f635737331b69de9ee82fe04898 > /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_sdma.bin > 284429675a5560e0fad42aa982965fc2 > /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_smc.bin libclc: Git:master/7f6f5bff1f DDX: 1:7.5.0-1 -- 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/20141027/64964637/attachment.html>
[PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active
On Fri, Oct 24, 2014 at 06:07:15PM +0300, Ville Syrjälä wrote: > On Fri, Oct 24, 2014 at 02:51:34PM +0100, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > There is no point in flipping a buffer for a disabled crtc. > > That thing doesn't actually flip but just signal the frontbuffer > tracking code that either has just flipped or is going to real soon now > (tm). But yeah, still makes no sense when the entire pipe is off, so: > > Reviewed-by: Ville Syrjälä Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 12/12] ARM: shmobile: koelsch: Add DU HDMI output support
On Wed, Sep 24, 2014 at 11:04:32PM +0300, Laurent Pinchart wrote:
> Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector
> and configure the DISP pin group that drives the HDMI transmitter DE
> pin.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Simon Horman
Please be careful of any conflicts that may arise if this patch
doesn't go through my renesas tree.
> ---
> arch/arm/boot/dts/r8a7791-koelsch.dts | 50
> ++-
> 1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
> b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 9051e01..b7d0c41 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -209,6 +209,17 @@
> states = <330 1
> 180 0>;
> };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con: endpoint {
> + remote-endpoint = <&adv7511_out>;
> + };
> + };
> + };
> };
>
> &du {
> @@ -217,6 +228,11 @@
> status = "okay";
>
> ports {
> + port at 0 {
> + endpoint {
> + remote-endpoint = <&adv7511_in>;
> + };
> + };
> port at 1 {
> lvds_connector: endpoint {
> };
> @@ -235,7 +251,7 @@
> };
>
> du_pins: du {
> - renesas,groups = "du_rgb666", "du_sync", "du_clk_out_0";
> + renesas,groups = "du_rgb666", "du_sync", "du_disp",
> "du_clk_out_0";
> renesas,function = "du";
> };
>
> @@ -439,6 +455,38 @@
> };
> };
>
> + hdmi at 39 {
> + compatible = "adi,adv7511w";
> + reg = <0x39>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "rgb";
> + adi,input-clock = "1x";
> + adi,input-style = <1>;
> + adi,input-justification = "evenly";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7511_in: endpoint {
> + remote-endpoint = <&du_out_rgb>;
> + };
> + };
> +
> + port at 1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_con>;
> + };
> + };
> + };
> + };
> +
> eeprom at 50 {
> compatible = "renesas,24c02";
> reg = <0x50>;
> --
> 1.8.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #109 from Michel Dänzer --- (In reply to madcatx from comment #107) > (Is there any reason why would the desktop animations feel much smoother and > snappier than with the old hackofix?) Sounds like the 'hackofix' disabled more SEs than necessary, so the card wasn't running as fast as it can. -- 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/20141027/55919989/attachment.html>
[Bug 85454] Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 --- Comment #1 from Michel Dänzer --- Can you run it with the environment variable R600_DEBUG=vs,ps and attach the stderr output from that? P.S. Any particular reason for not using the Linux version of Unigine Sanctuary? -- 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/20141027/5db2c6ef/attachment.html>
[PATCH 02/11 V2] radeon: evergreen: Fix probable mask then right shift defect
Precedence of & and >> is not the same and is not left to right.
shift has higher precedence and should be done after the mask.
Add parentheses around the mask.
Use the already #defined values instead of hardcoding.
Signed-off-by: Joe Perches
---
> I think this should be NUM_SHADER_ENGINES_SHIFT?
(Joe can't type)
exactly right, thanks Michel
drivers/gpu/drm/radeon/evergreen.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index a31f1ca..a97a685 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3303,7 +3303,8 @@ static void evergreen_gpu_init(struct radeon_device *rdev)
rdev->config.evergreen.tile_config |=
((gb_addr_config & 0x3000) >> 28) << 12;
- num_shader_engines = (gb_addr_config & NUM_SHADER_ENGINES(3) >> 12) + 1;
+ num_shader_engines = ((gb_addr_config & NUM_SHADER_ENGINES_MASK)
+ >> NUM_SHADER_ENGINES_SHIFT) + 1;
if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= CHIP_HEMLOCK)) {
u32 efuse_straps_4;
[Bug 85476] add device/name to /sys/class/hwmon/hwmonX/ to better follow hwmon practices
https://bugs.freedesktop.org/show_bug.cgi?id=85476 --- Comment #5 from Alex Deucher --- Might be worth asking the hwmon people. I'm not sure how hwmon decides where to hang the name element in the sysfs tree. -- 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/20141027/97e374ce/attachment.html>
