Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
On 四, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote: > On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: > > On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: > > > AMD ACPI interface may overload the standard event > > > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > > > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the > > > userspace because the user did not press the mode switch key (the > > > spurious keypress confuses the DE which usually changes the > > > display configuration and messes up a dual-screen setup). > > > This patch gives the radeon driver the chance to examine the event and > > > block the keypress if the event is an "AMD event". > > > > > > Signed-off-by: Luca Tettamanti > > > --- > > > Any comment from ACPI front? > > > > > it looks good to me. > > But I'm wondering if we can use the following code for ACPI part, which > > looks cleaner. > > I know this may change the behavior of other events, but in theory, we > > should not send any input event if we know something wrong in kernel. > > > > what do you think? > > I like it, it's cleaner. > I've split the patch in two pieces (one for video, the other for > radeon) and adopted your suggestion. > Great. Acked-by: Zhang Rui hmm, who should take these two patches? and which tree the second patch is based on? thanks, rui ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
On 四, 2012-08-02 at 21:45 -0400, Alex Deucher wrote: > On Thu, Aug 2, 2012 at 9:40 PM, Zhang Rui wrote: > > On 四, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote: > >> On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: > >> > On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: > >> > > AMD ACPI interface may overload the standard event > >> > > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > >> > > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the > >> > > userspace because the user did not press the mode switch key (the > >> > > spurious keypress confuses the DE which usually changes the > >> > > display configuration and messes up a dual-screen setup). > >> > > This patch gives the radeon driver the chance to examine the event and > >> > > block the keypress if the event is an "AMD event". > >> > > > >> > > Signed-off-by: Luca Tettamanti > >> > > --- > >> > > Any comment from ACPI front? > >> > > > >> > it looks good to me. > >> > But I'm wondering if we can use the following code for ACPI part, which > >> > looks cleaner. > >> > I know this may change the behavior of other events, but in theory, we > >> > should not send any input event if we know something wrong in kernel. > >> > > >> > what do you think? > >> > >> I like it, it's cleaner. > >> I've split the patch in two pieces (one for video, the other for > >> radeon) and adopted your suggestion. > >> > > Great. > > Acked-by: Zhang Rui > > > > hmm, who should take these two patches? > > I'm happy to take the patches. > > > and which tree the second patch is based on? > > I've got a tree with all the radeon ACPI patches on the acpi_patches > branches of my git tree: > git://people.freedesktop.org/~agd5f/linux > great. thanks, rui ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
Hi Rob, Tomi, On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark wrote: > On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen wrote: >> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: >>> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen >>> wrote: >>> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >>> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >>> >> wrote: >>> > >>> >> > I guess the fact is that DRM concepts do not really match the OMAP DSS >>> >> > hardware, and we'll have to use whatever gives us least problems. >>> >> >>> >> Actually, I think it does map fairly well to the hardware.. at least >>> >> more so than to omapdss ;-) >>> > >>> > Hm, I'm not sure I understand, omapdss concepts map directly to the >>> > hardware. >>> >>> I think it is mainly exposing the encoder and panel as two separate >>> entities.. which seems to be what Archit is working on >> >> I still don't follow =) They are separate entities. Omapdss models the >> HW quite directly, I think. It doesn't expose everything, though, as the >> output drivers (dsi.c, dpi.c etc) are used via the panel drivers. > > right.. so we just need to expose the output drivers as separate > entities, and let omapdrm propagate information such as timings > between them > >>> in case of something like DVI bridge from DPI, this seems pretty >>> straightforward.. only the connector needs to know about DDC stuff, >>> which i2c to use and that sort of thing. So at kms level we would >>> have (for example) an omap_dpi_encoder which would be the same for DPI >>> panel (connector) or DPI->DVI bridge. For HDMI I'm still looking >>> through the code to see how this would work. Honestly I've looked >>> less at this part of code and encoder related registers in the TRM, >>> compared to the ovl/mgr parts, but at least from the 'DSS overview' >>> picture in the TRM it seems to make sense ;-) >>> >>> KMS even exposes the idea that certain crtcs can connect to only >>> certain encoders. Or that you could you could have certain connectors >>> switched between encoders. For example if you had a hw w/ DPI out, >>> and some mux to switch that back and forth between a DPI lcd panel and >>> a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does >>> this, but it is in theory possible.) So we could expose possible >>> video chain topologies to userspace in this way. >> >> OMAP3 SDP board has such a setup, with manual switch to select between >> LCD and DVI. > > ahh, good to know.. so I'm not crazy for wanting to expose this > possibility to userspace > >>> The other thing is that we don't need to propagate timings from the >>> panel up to the mgr at the dss level.. kms is already handling this >>> for us. In my latest version, which I haven't pushed, I removed the >>> 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. >> >> You're thinking only about simple DPI cases. Consider this example, with >> a DSI-to-DP bridge chip. What we have is the following flow of data: >> >> DISPC -> DSI -> DSI-2-DP -> DP monitor >> >> The timings you are thinking about are in the DISPC, but here they are >> only one part of the link. And here the DISPC timings are not actually >> the timings what the user is interested about. The user wants his >> timings to be between DSI-2-DP chip and the DP monitor. >> >> Timings programmed to DISPC are not the same. The timings for DISPC come >> from the DSI driver, and they may be very different than the user's >> timings. With DSI video mode, the DISPC timings would have some >> resemblance to the user's timings, mainly the time to send one line >> would be the same. With DSI cmd mode, the DISPC timings would be >> something totally different, most likely with 0 blank times and as fast >> pixel clock as possible. > > hmm, well kms already has a concept of adjusted_timings, which could > perhaps be used here to propagate the timings between crtc->encoder.. > although the order is probably backwards from what we want (it comes > from the crtc to the encoder.. and if I understand properly we want it > the other way and actually possibly from the connector). But that > isn't to say that internally in omapdrm the crtc couldn't get the > adjusted timings from the connector. So I still think the parameter > flow doesn't need to be 'under the hood' in omapdss. > > And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper > fxns, so if the way the core kms handles it isn't what we want, we can > just plug in our own fxn instead of using drm_crtc_helper_set_mode(), > so that isn't really a big problem. > >> What omapdss does currently is that you set the user's timings to the >> right side of the chain, which propagate back to DSS. This allows the >> DSI-2-DP bridge use DSI timings that work optimally for the bridge, and >> DSI driver will use DISPC timings that work optimally for it. >> >> And it's not only about timings above, but also other settings related >> to the busses between the components. Clock dividers
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #87 from Alexandre Demers 2012-08-03 06:03:39 UTC --- (In reply to comment #86) > (In reply to comment #85) > > I found a demo that has the issue, in the demos repository for mesa within > > the > > src/demo folder the program 'reflect'. After I start it up and press 's' to > > see the stencil buffer the white plan blinks continuously. Applying the > > patch > > 'fixes to wait on the bo and to free the va after the kernel' removes the > > blinking, as does disabling va through the variable > > ws->info.r600_virtual_address. > > > > The other issue with the kernel reporting a va conflict is going to be a > > little > > harder to reproduce because it appears to be caused by a race condition. > > > > I'll still look for other demos that have the issue. > > Yes, I understand it can be hard to track for you Jerome. Well for the va > issue, on my side, it is as simple as logging in KDE or Gnome 3. Before > logging > in, there is no va error in dmesg. Once I'm in, there are usually 3 or > sometimes 6 errors (they are written in block of 3, so I suspect it tries a > first time and for some reason it fails and try again second time). > > I also experience the issue when watching some movies. With Anthony's patch, > va > issues are gone and I watched a couple of shows yesterday without any problem. > Before the patch, it would blink and get corrupted after about 16 minutes and > then crash. So, Anthony has put a finger on something. > > However, I also run piglit tests and some other applications like > RendererFeatTest64 (which is an application released before Amnesia went out > to > test OpenGL performances if I recall recorrectly). With Anthony's patch, I'm > still able to lock the display everytime (if I play music at the same time, it > will continue to play but I won't be able to change terminal even if sometimes > my mouse pointer can still be moved). RendererFeatTest64 will always lock at > the same test, but it is not the same for piglit tests (even if it happens > often at the same or near the same). > > I'm installing a freshly compiled kernel 3.5.0 with both Alex and your patches > (by the way, they can't be applied on latest drm-next branch) and I'll tell > you > if I'm still experiencing the lockups. I'll also try Anthony's test to see if > I > get the same results (blinking without his patch, OK with it) Well it still locks up even with the patches. I also tested the reflect demo and I don't have any blink without Anthony's patch, but we may be experiencing different symptoms of the same problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.
1, Handle io prot correctly for MIPS. 2, Define SAREA_MAX as the size of one page. 3, Include swiotlb.h if SWIOTLB configured. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/drm_vm.c|2 +- drivers/gpu/drm/radeon/radeon_ttm.c |4 drivers/gpu/drm/ttm/ttm_bo_util.c |2 +- include/drm/drm_sarea.h |2 ++ 4 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 961ee08..3f06166 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma) tmp = pgprot_writecombine(tmp); else tmp = pgprot_noncached(tmp); -#elif defined(__sparc__) || defined(__arm__) +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) tmp = pgprot_noncached(tmp); #endif return tmp; diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include +#endif + #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index f8187ea..0df71ea 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp) else tmp = pgprot_noncached(tmp); #endif -#if defined(__sparc__) +#if defined(__sparc__) || defined(__mips__) if (!(caching_flags & TTM_PL_FLAG_CACHED)) tmp = pgprot_noncached(tmp); #endif diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h index ee5389d..1d1a858 100644 --- a/include/drm/drm_sarea.h +++ b/include/drm/drm_sarea.h @@ -37,6 +37,8 @@ /* SAREA area needs to be at least a page */ #if defined(__alpha__) #define SAREA_MAX 0x2000U +#elif defined(__mips__) +#define SAREA_MAX 0x4000U #elif defined(__ia64__) #define SAREA_MAX 0x1U /* 64kB */ #else -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] of: Add videomode helper
Hi Stephen,
On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
> On 07/04/2012 01:56 AM, Sascha Hauer wrote:
> > This patch adds a helper function for parsing videomodes from the
> > devicetree.
> > The videomode can be either converted to a struct drm_display_mode or a
> > struct fb_videomode.
>
> > diff --git a/Documentation/devicetree/bindings/video/displaymode
> > b/Documentation/devicetree/bindings/video/displaymode
>
> > +Required properties:
> > + - xres, yres: Display resolution
> > + - left-margin, right-margin, hsync-len: Horizontal Display timing
> > parameters
> > + in pixels
> > + upper-margin, lower-margin, vsync-len: Vertical display timing
> > parameters in
> > + lines
>
> Perhaps bike-shedding, but...
>
> For the margin property names, wouldn't it be better to use terminology
> more commonly used for video timings rather than Linux FB naming. In
> other words naming like:
>
> hactive, hsync-len, hfront-porch, hback-porch?
Can do. Just to make sure:
hactive == xres
hsync-len == hsync-len
hfront-porch == right-margin
hback-porch == left-margin
?
>
> This node appears to describe a video mode, not a display, hence the
> node name seems wrong.
>
> Many displays can support multiple different video modes. As mentioned
> elsewhere, properties like display width/height are properties of the
> display not the mode.
>
> So, I might expect something more like the following (various overhead
> properties like reg/#address-cells etc. elided for simplicity):
>
> disp: display {
> width-mm = <...>;
> height-mm = <...>;
> modes {
> mode@0 {
> /* 1920x1080p24 */
> clock = <5200>;
> xres = <1920>;
> yres = <1080>;
> left-margin = <25>;
> right-margin = <25>;
> hsync-len = <25>;
> lower-margin = <2>;
> upper-margin = <2>;
> vsync-len = <2>;
> hsync-active-high;
> };
> mode@1 {
> };
> };
> };
Ok, we can do this.
>
> display-connector {
> display = <&disp>;
> // interface-specific properties such as pixel format here
> };
>
> Finally, have you considered just using an EDID instead of creating
> something custom? I know that creating an EDID is harder than writing a
> few simple properties into a DT, but EDIDs have the following advantages:
I have considered using EDID and I also tried it. It's painful. There
are no (open) tools available for creating EDID. That's something we
could change of course. Then when generating a devicetree there is
always an extra step involved creating the EDID blob. Once the EDID
blob is in devicetree it is not parsable anymore by mere humans, so
to see what we've got there is another tool involved to generate a
readable form again.
>
> a) They're already standardized and very common.
Indeed, that's a big plus for EDID. I have no intention of removing EDID
data from the devicetree. There are situations where EDID is handy, for
example when you get EDID data provided by your vendor.
>
> b) They allow other information such as a display's HDMI audio
> capabilities to be represented, which can then feed into an ALSA driver.
>
> c) The few LCD panel datasheets I've seen actually quote their
> specification as an EDID already, so deriving the EDID may actually be easy.
>
> d) People familiar with displays are almost certainly familiar with
> EDID's mode representation. There are many ways of representing display
> modes (sync position vs. porch widths, htotal specified rather than
> specifying all the components and hence htotal being calculated etc.).
> Not everyone will be familiar with all representations. Conversion
> errors are less likely if the target is EDID's familiar format.
You seem to think about a different class of displays for which EDID
indeed is a better way to handle. What I have to deal with here mostly
are dumb displays which:
- can only handle their native resolution
- Have no audio capabilities at all
- come with a datasheet which specify a min/typ/max triplet for
xres,hsync,..., often enough they are scanned to pdf from some previously
printed paper.
These displays are very common on embedded devices, probably that's the
reason I did not even think about the possibility that a single display
might have different modes.
>
> e) You'll end up with exactly the same data as if you have a DDC-based
> external monitor rather than an internal panel, so you end up getting to
> a common path in display handling code much more quickly.
All we have in our display driver currently is:
edidp = of_get_property(np, "edid", &imxpd->edid_len);
if (edidp) {
imxpd->edid = kmemdup(edidp, imxpd->edid_len, GFP_KERNEL);
} else {
ret = of_get_video_mode(np, &imxpd->mode, NULL);
if (!ret)
imxpd->mode_valid = 1;
}
Sas
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #88 from Michel Dänzer 2012-08-03 07:47:17 UTC --- (In reply to comment #86) > So, Anthony has put a finger on something. Yes, I think something like Anthony's patch is needed due to asynchronous GPU processing: when the userspace driver assigns virtual address space for a new BO, the GPU may not have finished processing command streams using previous BOs occupying that same virtual address space. However, the userspace driver shouldn't wait synchronously for the BO to go idle when destroying it but should instead defer destruction (or at least the freeing of the virtual address space) until it notices the BO has become idle. > With Anthony's patch, I'm still able to lock the display everytime And these lockups do not happen when not using virtual address space? Can you provide the dmesg output of the GPU reset for such a lockup? Ideally from a single piglit test reproducing it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #2 from Michel Dänzer 2012-08-03 07:49:18 UTC --- Please attach the /var/log/Xorg.0.log file. Which version of libdrm_radeon are you using? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.
On Fre, 2012-08-03 at 15:06 +0800, Huacai Chen wrote: > 1, Handle io prot correctly for MIPS. > 2, Define SAREA_MAX as the size of one page. > 3, Include swiotlb.h if SWIOTLB configured. > > Signed-off-by: Huacai Chen > Signed-off-by: Hongliang Tao > Signed-off-by: Hua Yan > Cc: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/drm_vm.c|2 +- > drivers/gpu/drm/radeon/radeon_ttm.c |4 > drivers/gpu/drm/ttm/ttm_bo_util.c |2 +- > include/drm/drm_sarea.h |2 ++ > 4 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c > index 961ee08..3f06166 100644 > --- a/drivers/gpu/drm/drm_vm.c > +++ b/drivers/gpu/drm/drm_vm.c > @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct > vm_area_struct *vma) > tmp = pgprot_writecombine(tmp); > else > tmp = pgprot_noncached(tmp); > -#elif defined(__sparc__) || defined(__arm__) > +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) > tmp = pgprot_noncached(tmp); > #endif > return tmp; > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > b/drivers/gpu/drm/radeon/radeon_ttm.c > index 5b71c71..fc3ac22 100644 > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > @@ -41,6 +41,10 @@ > #include "radeon_reg.h" > #include "radeon.h" > > +#ifdef CONFIG_SWIOTLB > +#include > +#endif > + > #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) > > static int radeon_ttm_debugfs_init(struct radeon_device *rdev); > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c > b/drivers/gpu/drm/ttm/ttm_bo_util.c > index f8187ea..0df71ea 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c > @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp) > else > tmp = pgprot_noncached(tmp); > #endif > -#if defined(__sparc__) > +#if defined(__sparc__) || defined(__mips__) > if (!(caching_flags & TTM_PL_FLAG_CACHED)) > tmp = pgprot_noncached(tmp); > #endif > diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h > index ee5389d..1d1a858 100644 > --- a/include/drm/drm_sarea.h > +++ b/include/drm/drm_sarea.h > @@ -37,6 +37,8 @@ > /* SAREA area needs to be at least a page */ > #if defined(__alpha__) > #define SAREA_MAX 0x2000U > +#elif defined(__mips__) > +#define SAREA_MAX 0x4000U > #elif defined(__ia64__) > #define SAREA_MAX 0x1U /* 64kB */ > #else This should be four separate patches. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #89 from Alexandre Demers 2012-08-03 08:05:07 UTC --- (In reply to comment #88) > (In reply to comment #86) > > So, Anthony has put a finger on something. > > Yes, I think something like Anthony's patch is needed due to asynchronous GPU > processing: when the userspace driver assigns virtual address space for a new > BO, the GPU may not have finished processing command streams using previous > BOs > occupying that same virtual address space. > > However, the userspace driver shouldn't wait synchronously for the BO to go > idle when destroying it but should instead defer destruction (or at least the > freeing of the virtual address space) until it notices the BO has become idle. > > > > With Anthony's patch, I'm still able to lock the display everytime > > And these lockups do not happen when not using virtual address space? Can you > provide the dmesg output of the GPU reset for such a lockup? Ideally from a > single piglit test reproducing it. Nope, no lockup without va (I may only be lucky though if the bug is there but only shown when using va). I'll try to find a way to get dmesg... It has been a problem since the start for that part, but I may be able to use another computer to log in remotely. May take a couple of days to do though. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #90 from Michel Dänzer 2012-08-03 08:13:03 UTC --- (In reply to comment #89) > Nope, no lockup without va (I may only be lucky though if the bug is there but > only shown when using va). That's indeed possible: Using virtual address space will catch out of bounds memory access that may otherwise go unnoticed. So, I think in this report we should focus on the rendering regression(s), and track the lockups in other reports. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.
OK, I'll split it. On Fri, Aug 3, 2012 at 4:01 PM, Michel Dänzer wrote: > On Fre, 2012-08-03 at 15:06 +0800, Huacai Chen wrote: >> 1, Handle io prot correctly for MIPS. >> 2, Define SAREA_MAX as the size of one page. >> 3, Include swiotlb.h if SWIOTLB configured. >> >> Signed-off-by: Huacai Chen >> Signed-off-by: Hongliang Tao >> Signed-off-by: Hua Yan >> Cc: dri-devel@lists.freedesktop.org >> --- >> drivers/gpu/drm/drm_vm.c|2 +- >> drivers/gpu/drm/radeon/radeon_ttm.c |4 >> drivers/gpu/drm/ttm/ttm_bo_util.c |2 +- >> include/drm/drm_sarea.h |2 ++ >> 4 files changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c >> index 961ee08..3f06166 100644 >> --- a/drivers/gpu/drm/drm_vm.c >> +++ b/drivers/gpu/drm/drm_vm.c >> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct >> vm_area_struct *vma) >> tmp = pgprot_writecombine(tmp); >> else >> tmp = pgprot_noncached(tmp); >> -#elif defined(__sparc__) || defined(__arm__) >> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) >> tmp = pgprot_noncached(tmp); >> #endif >> return tmp; >> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c >> b/drivers/gpu/drm/radeon/radeon_ttm.c >> index 5b71c71..fc3ac22 100644 >> --- a/drivers/gpu/drm/radeon/radeon_ttm.c >> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c >> @@ -41,6 +41,10 @@ >> #include "radeon_reg.h" >> #include "radeon.h" >> >> +#ifdef CONFIG_SWIOTLB >> +#include >> +#endif >> + >> #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) >> >> static int radeon_ttm_debugfs_init(struct radeon_device *rdev); >> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c >> b/drivers/gpu/drm/ttm/ttm_bo_util.c >> index f8187ea..0df71ea 100644 >> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c >> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c >> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t >> tmp) >> else >> tmp = pgprot_noncached(tmp); >> #endif >> -#if defined(__sparc__) >> +#if defined(__sparc__) || defined(__mips__) >> if (!(caching_flags & TTM_PL_FLAG_CACHED)) >> tmp = pgprot_noncached(tmp); >> #endif >> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h >> index ee5389d..1d1a858 100644 >> --- a/include/drm/drm_sarea.h >> +++ b/include/drm/drm_sarea.h >> @@ -37,6 +37,8 @@ >> /* SAREA area needs to be at least a page */ >> #if defined(__alpha__) >> #define SAREA_MAX 0x2000U >> +#elif defined(__mips__) >> +#define SAREA_MAX 0x4000U >> #elif defined(__ia64__) >> #define SAREA_MAX 0x1U /* 64kB */ >> #else > > This should be four separate patches. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26345] [845G] CPU/GPU incoherency
https://bugs.freedesktop.org/show_bug.cgi?id=26345 Chris Wilson changed: What|Removed |Added CC||artem.rusa...@gmail.com --- Comment #147 from Chris Wilson 2012-08-03 12:18:44 UTC --- *** Bug 53065 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
On Fri, Aug 3, 2012 at 1:01 AM, Semwal, Sumit wrote: > Hi Rob, Tomi, > On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark wrote: >> On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen wrote: >>> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote: > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >> wrote: > >> > I guess the fact is that DRM concepts do not really match the OMAP DSS >> > hardware, and we'll have to use whatever gives us least problems. >> >> Actually, I think it does map fairly well to the hardware.. at least >> more so than to omapdss ;-) > > Hm, I'm not sure I understand, omapdss concepts map directly to the > hardware. I think it is mainly exposing the encoder and panel as two separate entities.. which seems to be what Archit is working on >>> >>> I still don't follow =) They are separate entities. Omapdss models the >>> HW quite directly, I think. It doesn't expose everything, though, as the >>> output drivers (dsi.c, dpi.c etc) are used via the panel drivers. >> >> right.. so we just need to expose the output drivers as separate >> entities, and let omapdrm propagate information such as timings >> between them >> in case of something like DVI bridge from DPI, this seems pretty straightforward.. only the connector needs to know about DDC stuff, which i2c to use and that sort of thing. So at kms level we would have (for example) an omap_dpi_encoder which would be the same for DPI panel (connector) or DPI->DVI bridge. For HDMI I'm still looking through the code to see how this would work. Honestly I've looked less at this part of code and encoder related registers in the TRM, compared to the ovl/mgr parts, but at least from the 'DSS overview' picture in the TRM it seems to make sense ;-) KMS even exposes the idea that certain crtcs can connect to only certain encoders. Or that you could you could have certain connectors switched between encoders. For example if you had a hw w/ DPI out, and some mux to switch that back and forth between a DPI lcd panel and a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does this, but it is in theory possible.) So we could expose possible video chain topologies to userspace in this way. >>> >>> OMAP3 SDP board has such a setup, with manual switch to select between >>> LCD and DVI. >> >> ahh, good to know.. so I'm not crazy for wanting to expose this >> possibility to userspace >> The other thing is that we don't need to propagate timings from the panel up to the mgr at the dss level.. kms is already handling this for us. In my latest version, which I haven't pushed, I removed the 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. >>> >>> You're thinking only about simple DPI cases. Consider this example, with >>> a DSI-to-DP bridge chip. What we have is the following flow of data: >>> >>> DISPC -> DSI -> DSI-2-DP -> DP monitor >>> >>> The timings you are thinking about are in the DISPC, but here they are >>> only one part of the link. And here the DISPC timings are not actually >>> the timings what the user is interested about. The user wants his >>> timings to be between DSI-2-DP chip and the DP monitor. >>> >>> Timings programmed to DISPC are not the same. The timings for DISPC come >>> from the DSI driver, and they may be very different than the user's >>> timings. With DSI video mode, the DISPC timings would have some >>> resemblance to the user's timings, mainly the time to send one line >>> would be the same. With DSI cmd mode, the DISPC timings would be >>> something totally different, most likely with 0 blank times and as fast >>> pixel clock as possible. >> >> hmm, well kms already has a concept of adjusted_timings, which could >> perhaps be used here to propagate the timings between crtc->encoder.. >> although the order is probably backwards from what we want (it comes >> from the crtc to the encoder.. and if I understand properly we want it >> the other way and actually possibly from the connector). But that >> isn't to say that internally in omapdrm the crtc couldn't get the >> adjusted timings from the connector. So I still think the parameter >> flow doesn't need to be 'under the hood' in omapdss. >> >> And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper >> fxns, so if the way the core kms handles it isn't what we want, we can >> just plug in our own fxn instead of using drm_crtc_helper_set_mode(), >> so that isn't really a big problem. >> >>> What omapdss does currently is that you set the user's timings to the >>> right side of the chain, which propagate back to DSS. This allows the >>> DSI-2-DP bridge use DSI timings that work optimally for the bridge, and >>> DSI driver will use DISPC timings that work
Re: [PATCH v2 7/7] drm: Renesas SH Mobile DRM driver
Hi Laurent,
Some minor stuff inside.
Thanks
Sascha+
On Fri, Jul 20, 2012 at 03:04:22PM +0200, Laurent Pinchart wrote:
> The SH Mobile LCD controller (LCDC) DRM driver supports the main
> graphics plane in RGB and YUV formats, as well as the overlay planes (in
> alpha-blending mode only).
>
> Only flat panel outputs using the parallel interface are supported.
> Support for SYS panels, HDMI and DSI is currently not implemented.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/Kconfig|2 +
> drivers/gpu/drm/Makefile |1 +
> drivers/gpu/drm/shmobile/Kconfig | 10 +
> drivers/gpu/drm/shmobile/Makefile |7 +
> drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 90 +++
> drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 23 +
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 768
>
> drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 60 ++
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 360 +++
> drivers/gpu/drm/shmobile/shmob_drm_drv.h | 52 ++
> drivers/gpu/drm/shmobile/shmob_drm_kms.c | 160 +
> drivers/gpu/drm/shmobile/shmob_drm_kms.h | 34 +
> drivers/gpu/drm/shmobile/shmob_drm_plane.c | 263
> drivers/gpu/drm/shmobile/shmob_drm_plane.h | 22 +
> drivers/gpu/drm/shmobile/shmob_drm_regs.h | 304 ++
> include/drm/shmob_drm.h| 99 +++
> 16 files changed, 2255 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpu/drm/shmobile/Kconfig
> create mode 100644 drivers/gpu/drm/shmobile/Makefile
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h
> create mode 100644 include/drm/shmob_drm.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 98ba7d5..0b40bf2 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -208,3 +208,5 @@ source "drivers/gpu/drm/ast/Kconfig"
> source "drivers/gpu/drm/mgag200/Kconfig"
>
> source "drivers/gpu/drm/cirrus/Kconfig"
> +
> +source "drivers/gpu/drm/shmobile/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 58961b9..2ff5cef 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -47,4 +47,5 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> obj-$(CONFIG_DRM_GMA500) += gma500/
> obj-$(CONFIG_DRM_UDL) += udl/
> obj-$(CONFIG_DRM_AST) += ast/
> +obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
> obj-y+= i2c/
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> new file mode 100644
> index 000..c7be5f7
> --- /dev/null
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> @@ -0,0 +1,768 @@
[...]
> +
> +static void shmob_drm_encoder_destroy(struct drm_encoder *encoder)
> +{
> + drm_encoder_cleanup(encoder);
> +}
> +
> +static const struct drm_encoder_funcs encoder_funcs = {
> + .destroy = shmob_drm_encoder_destroy,
You could add drm_encoder_cleanup here.
[...]
> +
> +static enum drm_connector_status
> +shmob_drm_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_unknown;
> +}
Shouldn't you return connector_status_connected here? I mean all that
you handle is a dumb display which is always connected.
[...]
> +
> +static int __devinit shmob_drm_setup_clocks(struct shmob_drm_device *sdev,
> + enum shmob_drm_clk_source clksrc)
> +{
> + struct clk *clk;
> + char *clkname;
> +
> + switch (clksrc) {
> + case SHMOB_DRM_CLK_BUS:
> + clkname = "bus_clk";
> + sdev->lddckr = LDDCKR_ICKSEL_BUS;
> + break;
> + case SHMOB_DRM_CLK_PERIPHERAL:
> + clkname = "peripheral_clk";
> + sdev->lddckr = LDDCKR_ICKSEL_MIPI;
> + break;
> + case SHMOB_DRM_CLK_EXTERNAL:
> + clkname = NULL;
> + sdev->lddckr = LDDCKR_ICKSEL_HDMI;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + clk = clk_get(sdev->dev, clkname);
> + if (IS_ERR(clk)) {
> + dev_err(sdev->dev, "cannot get dot clock %s\n", clkname);
> + return PTR_ERR(clk);
> + }
> +
> + sdev->clock = clk;
> + return 0;
>
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Christian König changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Comment #91 from Christian König 2012-08-03 12:58:04 UTC --- I just fixed a memory leak in radeonsi, and it looks like I'm hitting the same problem now. Do I understand it correctly that the userspace VM manager is releasing allocations to early and not waiting for async buffer use to end? That should be easy to fix. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #92 from Michel Dänzer 2012-08-03 13:21:22 UTC --- (In reply to comment #91) > I just fixed a memory leak in radeonsi, and it looks like I'm hitting the same > problem now. Ah cool, you found it already. :) > Do I understand it correctly that the userspace VM manager is releasing > allocations to early and not waiting for async buffer use to end? That's my working theory. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #93 from Michel Dänzer 2012-08-03 13:26:32 UTC --- (In reply to comment #92) > > Do I understand it correctly that the userspace VM manager is releasing > > allocations to early and not waiting for async buffer use to end? > > That's my working theory. Also, if it wasn't the case, I don't see how Anthony's patch could make a difference. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: ignore disconnected <-> unknown status changes
On Thu, Aug 2, 2012 at 3:21 AM, Knut Petersen wrote: > On an AOpen i915GMm-hfs the hotplug events generated > by transitions between connector_status_unknown and > connector_status_disconnected cause screen distortions. > > The attached patch cures the problem by disabling the > generation of hotplug events in those cases. That should > be safe for everybody as the only relevant changes are > those from / to connector_status_connected. Seems reasonable to me. We should just drop unknown. Reviewed-by: Alex Deucher > > cu, > Knut > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Optimize i2f()
On Mon, Jul 30, 2012 at 5:49 PM, Steven Fuerst wrote:
> Looking through the kernel radeon drm source, it looks like the i2f()
> functions in r600_blit.c and r600_blit_ksm() can be optimized a bit.
Care to send a patch?
Thanks,
Alex
>
> The following extends the range to all unsigned 32bit integers, and avoids
> the slow loop by using the bsr instruction via __fls(). It provides an
> exact 1-1 correspondence up to 2^24. Above that, there is the inevitable
> rounding. This routine rounds towards zero (truncation).
>
> /* 23 bits of float fractional data */
> #define I2F_FRAC_BITS 23
> #define I2F_MASK ((1 << I2F_FRAC_BITS) - 1)
>
> /*
> * Converts an unsigned integer into 32-bit IEEE floating point
> representation.
> * Will be exact from 0 to 2^24. Above that, we round towards zero
> * as the fractional bits will not fit in a float. (It would be better to
> * round towards even as the fpu does, but that is slower.)
> * This routine depends on the mod(32) behaviour of the rotate instructions
> * on x86.
> */
> uint32_t i2f(uint32_t x)
> {
> uint32_t msb, exponent, fraction;
>
> /* Zero is special */
> if (!x) return 0;
>
> /* Get location of the most significant bit */
> msb = __fls(x);
>
> /*
> * Use a rotate instead of a shift because that works both leftwards
> * and rightwards due to the mod(32) beahviour. This means we don't
> * need to check to see if we are above 2^24 or not.
> */
> fraction = ror32(x, msb - I2F_FRAC_BITS) & I2F_MASK;
> exponent = (127 + msb) << I2F_FRAC_BITS;
>
> return fraction + exponent;
> }
>
> Steven Fuerst
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #94 from Jerome Glisse 2012-08-03 14:39:59 UTC --- (In reply to comment #88) > (In reply to comment #86) > > So, Anthony has put a finger on something. > > Yes, I think something like Anthony's patch is needed due to asynchronous GPU > processing: when the userspace driver assigns virtual address space for a new > BO, the GPU may not have finished processing command streams using previous > BOs > occupying that same virtual address space. > > However, the userspace driver shouldn't wait synchronously for the BO to go > idle when destroying it but should instead defer destruction (or at least the > freeing of the virtual address space) until it notices the BO has become idle. > > > > With Anthony's patch, I'm still able to lock the display everytime > > And these lockups do not happen when not using virtual address space? Can you > provide the dmesg output of the GPU reset for such a lockup? Ideally from a > single piglit test reproducing it. No, Anthony patch should not be needed. Once userspace call kernel to destroy bo userspace should be able to reuse va right away even if kernel is delaying bo destruction. My patch should fix the va issue, note that the patch attached here have a bug but it should not affect the va thing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #95 from Alexandre Demers 2012-08-03 14:51:56 UTC --- (In reply to comment #90) > (In reply to comment #89) > > Nope, no lockup without va (I may only be lucky though if the bug is there > > but > > only shown when using va). > > That's indeed possible: Using virtual address space will catch out of bounds > memory access that may otherwise go unnoticed. > > So, I think in this report we should focus on the rendering regression(s), and > track the lockups in other reports. OK, I'll open another bug for the lockups. This one will be renamed for va issues and rendering regression. I'll wait until tonight to make changes to see if someone objects. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Christian König changed: What|Removed |Added Attachment #65051|0 |1 is obsolete|| --- Comment #96 from Christian König 2012-08-03 15:03:52 UTC --- Created attachment 65093 --> https://bugs.freedesktop.org/attachment.cgi?id=65093 Possible fix. It's hard and uneffecient to solve this problem completely in the kernel. Since we patch the VM table synchronously, but use it asynchronously we will always end up needing to wait for a bo use by the GPU to end before patching in the new VA. Please take a look at the attached patch it should fix the issue nicely in userspace. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #97 from Marek Olšák 2012-08-03 15:20:12 UTC --- (In reply to comment #96) > Created attachment 65093 [details] [review] > Possible fix. > > It's hard and uneffecient to solve this problem completely in the kernel. > > Since we patch the VM table synchronously, but use it asynchronously we will > always end up needing to wait for a bo use by the GPU to end before patching > in > the new VA. > > Please take a look at the attached patch it should fix the issue nicely in > userspace. Please use the radeon_bo_is_busy function. Calling DRM_RADEON_GEM_BUSY directly is not reliable because of the thread offloading of the CS ioctl. The same applies to any other kernel queries and commands which depend on the CS ioctl. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix some missing parens in asic macros
From: Alex Deucher Better safe than sorry. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 118e4b9..9f58885 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1789,11 +1789,11 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t v); #define radeon_pm_finish(rdev) (rdev)->asic->pm.finish((rdev)) #define radeon_pm_init_profile(rdev) (rdev)->asic->pm.init_profile((rdev)) #define radeon_pm_get_dynpm_state(rdev) (rdev)->asic->pm.get_dynpm_state((rdev)) -#define radeon_pre_page_flip(rdev, crtc) rdev->asic->pflip.pre_page_flip((rdev), (crtc)) -#define radeon_page_flip(rdev, crtc, base) rdev->asic->pflip.page_flip((rdev), (crtc), (base)) -#define radeon_post_page_flip(rdev, crtc) rdev->asic->pflip.post_page_flip((rdev), (crtc)) -#define radeon_wait_for_vblank(rdev, crtc) rdev->asic->display.wait_for_vblank((rdev), (crtc)) -#define radeon_mc_wait_for_idle(rdev) rdev->asic->mc_wait_for_idle((rdev)) +#define radeon_pre_page_flip(rdev, crtc) (rdev)->asic->pflip.pre_page_flip((rdev), (crtc)) +#define radeon_page_flip(rdev, crtc, base) (rdev)->asic->pflip.page_flip((rdev), (crtc), (base)) +#define radeon_post_page_flip(rdev, crtc) (rdev)->asic->pflip.post_page_flip((rdev), (crtc)) +#define radeon_wait_for_vblank(rdev, crtc) (rdev)->asic->display.wait_for_vblank((rdev), (crtc)) +#define radeon_mc_wait_for_idle(rdev) (rdev)->asic->mc_wait_for_idle((rdev)) /* Common functions */ /* AGP */ -- 1.7.7.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 David L. changed: What|Removed |Added CC||equinox-freedesktopbugs@dia ||c24.net Summary|Radeon KMS on Macs with EFI |Radeon KMS fails with |boot|inaccessible AtomBIOS on ||systems with (U)EFI boot --- Comment #22 from David L. 2012-08-03 16:12:27 UTC --- Exact same issue appears on an HP EliteBook 8470p if you select "native UEFI" as boot method in setup. Legacy and hybrid boot options work fine. Changing bug title since this is not a Mac-specific issue, although it is more severe on Macs without the legacy/hybrid options easily accessible. It seems that the driver either cannot rely on the AtomBIOS being accessible, or we need to add code to enable the mapping with some PCI hacks? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote: > This is one of the things I wasn't so sure about. There are various > checks in intel_lvds_init() that can cause it to bail out before we try > to get the EDID, and I don't fully understand all of them. If non-laptop > machines are expected to bail out before the EDID check then the > approach I've taken seems reasonable. Otherwise adding a quirk probably > is a good idea. I know we've previously had problems with machines with phantom LVDS hardware, but I'm not sure what the current state of affairs is. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote: > Some Apple hybrid graphics machines do not have the LVDS panel connected > to the integrated GPU at boot and also do not supply a VBT. The LVDS > connector is not registered as a result, making it impossible to support > graphics switching. > > This patch changes intel_lvds_init() to register the connector even if > we can't find any panel modes. This makes it necessary to always check > intel_lvds->fixed_mode before use, as it could now be NULL. This one kind of sucks. I think adding a quirk for this situation would be justifiable, rather than doing it for all devices. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #23 from Alex Deucher 2012-08-03 16:33:04 UTC --- On UEFI systems the vbios should be accessible via the ACPI VFCT. See the bottom of atombios.h for struct definitions. Macs do their own thing so I don't know if this will work on them or not. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #98 from Jerome Glisse 2012-08-03 16:54:04 UTC --- Created attachment 65095 --> https://bugs.freedesktop.org/attachment.cgi?id=65095 Properly protect virtual address Properly protect virtual address Patch against Linus master, gonna attach patch against 3.5 next. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Jerome Glisse changed: What|Removed |Added Attachment #65095|0 |1 is obsolete|| --- Comment #99 from Jerome Glisse 2012-08-03 16:56:00 UTC --- Created attachment 65096 --> https://bugs.freedesktop.org/attachment.cgi?id=65096 Properly protect virtual address Properly protect virtual address Patch against Linus master, gonna attach patch against 3.5 next. Sorry previous one was wrong one. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Jerome Glisse changed: What|Removed |Added Attachment #65096|0 |1 is obsolete|| --- Comment #100 from Jerome Glisse 2012-08-03 16:59:41 UTC --- Created attachment 65097 --> https://bugs.freedesktop.org/attachment.cgi?id=65097 Properly protect virtual address Properly protect virtual address Patch against Linus master, gonna attach patch against 3.5 next. Again, sorry previous one was wrong one. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #101 from Jerome Glisse 2012-08-03 17:05:15 UTC --- Created attachment 65098 --> https://bugs.freedesktop.org/attachment.cgi?id=65098 Properly protect virtual address against kernel 3.5 Same patch against 3.5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #24 from David L. 2012-08-03 17:12:52 UTC --- (In reply to comment #23) > On UEFI systems the vbios should be accessible via the ACPI VFCT. See the > bottom of atombios.h for struct definitions. Macs do their own thing so I > don't know if this will work on them or not. Should this already work on 3.4.7 and should I file a separate report about ACPI VFCT being broken or is that future tense/upcoming? Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just tried acpidump | grep VFCT, that should show something shouldn't it?) Will try under native UEFI in a minute... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #25 from Alex Deucher 2012-08-03 17:26:03 UTC --- (In reply to comment #24) > Should this already work on 3.4.7 and should I file a separate report about > ACPI VFCT being broken or is that future tense/upcoming? Support for fetching the vbios from VFCT still needs to be implemented. > > Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just > tried acpidump | grep VFCT, that should show something shouldn't it?) Will try > under native UEFI in a minute... I'm not too familiar with ACPI and UEFI unfortunately. It's part of the GOP stuff for UEFI. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #15 from ojab 2012-08-03 17:37:58 UTC --- Still happens with libdrm/mesa/xf86-video-ati latest git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #26 from David L. 2012-08-03 18:49:14 UTC --- Created attachment 65100 --> https://bugs.freedesktop.org/attachment.cgi?id=65100 hacked-up radeon VFCT BIOS access patch So the good news is that a VFCT ACPI table does indeed show up when I boot under UEFI native mode on the HP EliteBook. I hacked up some code to get the BIOS from there and it successfully brought up the card and drove my DisplayPort screen. (hack patch attached) The bad news is that the LVDS panel first went backlight-off, on starting X started displaying flickering pixelgarbage and at some later point the entire box locked up. I'll go diff the BIOS images against each other, maybe the BIOS from VFCT is corrupted... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Jerome Glisse changed: What|Removed |Added Attachment #65098|0 |1 is obsolete|| --- Comment #102 from Jerome Glisse 2012-08-03 19:04:54 UTC --- Created attachment 65101 --> https://bugs.freedesktop.org/attachment.cgi?id=65101 Properly protect virtual address kernel 3.5 v2 Updated -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Jerome Glisse changed: What|Removed |Added Attachment #65097|0 |1 is obsolete|| --- Comment #103 from Jerome Glisse 2012-08-03 19:05:47 UTC --- Created attachment 65102 --> https://bugs.freedesktop.org/attachment.cgi?id=65102 Properly protect virtual address v2 Against Linus master -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #27 from Alex Deucher 2012-08-03 19:23:34 UTC --- (In reply to comment #26) > Created attachment 65100 [details] [review] > hacked-up radeon VFCT BIOS access patch > > So the good news is that a VFCT ACPI table does indeed show up when I boot > under UEFI native mode on the HP EliteBook. > > I hacked up some code to get the BIOS from there and it successfully brought > up > the card and drove my DisplayPort screen. (hack patch attached) > Excellent. > The bad news is that the LVDS panel first went backlight-off, on starting X > started displaying flickering pixelgarbage and at some later point the entire > box locked up. You probably need this patch: http://lists.freedesktop.org/archives/dri-devel/2012-July/025567.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #104 from Alexandre Demers 2012-08-03 19:44:34 UTC --- (In reply to comment #103) > Created attachment 65102 [details] [review] > Properly protect virtual address v2 > > Against Linus master I will test them later today. They should take care of the va issues, right? Probably nothing to do with lockups? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #105 from Jerome Glisse 2012-08-03 19:46:50 UTC --- Well for va issue you also need the mesa patch from Christian. This patch mostly fix kernel, it might help with lockup, thought here piglit lockup hard with lastest mesa. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix some missing parens in asic macros
On Fri, Aug 3, 2012 at 11:53 AM, wrote: > From: Alex Deucher > > Better safe than sorry. > > Signed-off-by: Alex Deucher Reviewed-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/radeon.h | 10 +- > 1 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h > index 118e4b9..9f58885 100644 > --- a/drivers/gpu/drm/radeon/radeon.h > +++ b/drivers/gpu/drm/radeon/radeon.h > @@ -1789,11 +1789,11 @@ void radeon_ring_write(struct radeon_ring *ring, > uint32_t v); > #define radeon_pm_finish(rdev) (rdev)->asic->pm.finish((rdev)) > #define radeon_pm_init_profile(rdev) (rdev)->asic->pm.init_profile((rdev)) > #define radeon_pm_get_dynpm_state(rdev) > (rdev)->asic->pm.get_dynpm_state((rdev)) > -#define radeon_pre_page_flip(rdev, crtc) > rdev->asic->pflip.pre_page_flip((rdev), (crtc)) > -#define radeon_page_flip(rdev, crtc, base) > rdev->asic->pflip.page_flip((rdev), (crtc), (base)) > -#define radeon_post_page_flip(rdev, crtc) > rdev->asic->pflip.post_page_flip((rdev), (crtc)) > -#define radeon_wait_for_vblank(rdev, crtc) > rdev->asic->display.wait_for_vblank((rdev), (crtc)) > -#define radeon_mc_wait_for_idle(rdev) rdev->asic->mc_wait_for_idle((rdev)) > +#define radeon_pre_page_flip(rdev, crtc) > (rdev)->asic->pflip.pre_page_flip((rdev), (crtc)) > +#define radeon_page_flip(rdev, crtc, base) > (rdev)->asic->pflip.page_flip((rdev), (crtc), (base)) > +#define radeon_post_page_flip(rdev, crtc) > (rdev)->asic->pflip.post_page_flip((rdev), (crtc)) > +#define radeon_wait_for_vblank(rdev, crtc) > (rdev)->asic->display.wait_for_vblank((rdev), (crtc)) > +#define radeon_mc_wait_for_idle(rdev) (rdev)->asic->mc_wait_for_idle((rdev)) > > /* Common functions */ > /* AGP */ > -- > 1.7.7.5 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fence virtual address and free it once idle v2
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_cs.c | 32 +---
drivers/gpu/drm/radeon/radeon_gart.c | 24 ++--
drivers/gpu/drm/radeon/radeon_gem.c| 13 ++---
drivers/gpu/drm/radeon/radeon_object.c |6 +-
5 files changed, 55 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5431af2..8d75c65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -300,6 +300,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+ struct radeon_fence *fence;
boolvalid;
};
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8a4c49e..995f3ab 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+ struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+ struct radeon_vm *vm = &fpriv->vm;
+ struct radeon_bo_list *lobj;
+ int r;
+
+ if (parser->chunk_ib_idx == -1)
+ return;
+ if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
+ return;
+
+ list_for_each_entry(lobj, &parser->validated, tv.head) {
+ struct radeon_bo_va *bo_va;
+ struct radeon_bo *rbo = lobj->bo;
+
+ bo_va = radeon_bo_va(rbo, vm);
+ radeon_fence_unref(&bo_va->fence);
+ bo_va->fence = radeon_fence_ref(fence);
+ }
+ return 0;
+}
+
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
{
unsigned i;
- if (!error)
+ if (!error) {
+ /* fence all bo va before ttm_eu_fence_buffer_objects so bo are
still reserved */
+ radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
- else
+ } else {
ttm_eu_backoff_reservation(&parser->validated);
+ }
if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index b372005..9912182 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
- if (bo_va->valid)
+ if (bo_va->valid && mem)
return 0;
ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
struct radeon_bo *bo)
{
struct radeon_bo_va *bo_va;
+ int r;
bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;
+ /* wait for va use to end */
+ while (bo_va->fence) {
+ r = radeon_fence_wait(bo_va->fence, false);
+ if (r) {
+ DRM_ERROR("error while waiting for fence: %d\n", r);
+ }
+ if (r == -EDEADLK) {
+ r = radeon_gpu_reset(rdev);
+ if (!r)
+ continue;
+ }
+ break;
+ }
+ radeon_fence_unref(&bo_va->fence);
+
mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -952,12 +968,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
mutex_unlock(&rdev->vm_manager.lock);
- /* remove all bo */
+ /* remove all bo at this point non are busy any more because unbind
+* waited for the last vm fence to signal
+*/
r = radeon_bo_reserve(rdev->ring_tmp_bo.
[PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
This version is for stable 3.5 only.
cc: sta...@vger.kernel.org
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_cs.c | 32 +---
drivers/gpu/drm/radeon/radeon_gart.c | 24 ++--
drivers/gpu/drm/radeon/radeon_gem.c| 13 ++---
drivers/gpu/drm/radeon/radeon_object.c | 6 +-
5 files changed, 55 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fefcca5..01d2a87 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -323,6 +323,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+ struct radeon_fence *fence;
boolvalid;
};
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 142f894..70f6d08 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -294,6 +294,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+ struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+ struct radeon_vm *vm = &fpriv->vm;
+ struct radeon_bo_list *lobj;
+ int r;
+
+ if (parser->chunk_ib_idx == -1)
+ return;
+ if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
+ return;
+
+ list_for_each_entry(lobj, &parser->validated, tv.head) {
+ struct radeon_bo_va *bo_va;
+ struct radeon_bo *rbo = lobj->bo;
+
+ bo_va = radeon_bo_va(rbo, vm);
+ radeon_fence_unref(&bo_va->fence);
+ bo_va->fence = radeon_fence_ref(fence);
+ }
+ return 0;
+}
+
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -306,11 +330,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
{
unsigned i;
- if (!error)
+ if (!error) {
+ /* fence all bo va before ttm_eu_fence_buffer_objects so bo are
still reserved */
+ radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
- else
+ } else {
ttm_eu_backoff_reservation(&parser->validated);
+ }
if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -407,7 +434,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index 84b648a..f651f22 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -564,7 +564,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
- if (bo_va->valid)
+ if (bo_va->valid && mem)
return 0;
ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -597,11 +597,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
struct radeon_bo *bo)
{
struct radeon_bo_va *bo_va;
+ int r;
bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;
+ /* wait for va use to end */
+ while (bo_va->fence) {
+ r = radeon_fence_wait(bo_va->fence, false);
+ if (r) {
+ DRM_ERROR("error while waiting for fence: %d\n", r);
+ }
+ if (r == -EDEADLK) {
+ r = radeon_gpu_reset(rdev);
+ if (!r)
+ continue;
+ }
+ break;
+ }
+ radeon_fence_unref(&bo_va->fence);
+
radeon_mutex_lock(&rdev->cs_mutex);
mutex_lock(&vm->mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -661,12 +677,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
radeon_mutex_unlock(&rdev->cs_mutex);
- /* remove all bo */
+ /* remove all bo at this point non are busy any more because unbind
+* waited for the last vm fence to signal
+
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
On Fri, Aug 3, 2012 at 4:16 PM, Greg KH wrote: > On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote: >> From: Jerome Glisse >> >> Virtual address need to be fenced to know when we can safely remove it. >> This patch also properly clear the pagetable. Previously it was >> serouisly broken. >> >> v2: For to update pagetable when unbinding bo (don't bailout if >> bo_va->valid is true). >> >> This version is for stable 3.5 only. > > Why? Because 3.4 needs again a different patch and 3.6 needs a different patch. Code around this patch changed btw 3.4-3.5 and changed again btw 3.5-3.6 and in non trivial way. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #28 from David L. 2012-08-03 21:17:10 UTC --- (In reply to comment #27) > > The bad news is that the LVDS panel first went backlight-off, on starting X > > started displaying flickering pixelgarbage and at some later point the > > entire > > box locked up. > > You probably need this patch: > http://lists.freedesktop.org/archives/dri-devel/2012-July/025567.html After both patches, that indeed fixes things as soon as X is started, but the console is still broken. After loading the module, the panel just switches off, though the console is still usable. Plugging my DisplayPort screen in also reenables the LVDS panel, although the image is wrapped around by around 100 pixels. (Left part of my prompt is on the right of the screen.) Wraparound might be related to the different resolution for the ext display; the external screen only shows the nonwrapping part of the image (and is therefore missing the first characters of the prompt). Either way that's a separate bug... Apart from the above, I now have working graphics (including 3D) on an UEFI native booted HP EliteBook. I'll clean up my hack VFCT patch and send it to dri-devel. P.S.: The laptop also needs your backlight control patch, thanks a zillion for that - you wouldn't believe how nuts that was driving me. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fence virtual address and free it once idle v3
From: Jerome Glisse
Virtual address need to be fenced to know when we can safely remove it.
This patch also properly clear the pagetable. Previously it was
serouisly broken.
Kernel 3.5/3.4 need a similar patch but adapted for difference in mutex locking.
v2: For to update pagetable when unbinding bo (don't bailout if
bo_va->valid is true).
v3: Add kernel 3.5/3.4 comment.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_cs.c | 32 +---
drivers/gpu/drm/radeon/radeon_gart.c | 24 ++--
drivers/gpu/drm/radeon/radeon_gem.c| 13 ++---
drivers/gpu/drm/radeon/radeon_object.c |6 +-
5 files changed, 55 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5431af2..8d75c65 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -300,6 +300,7 @@ struct radeon_bo_va {
uint64_tsoffset;
uint64_teoffset;
uint32_tflags;
+ struct radeon_fence *fence;
boolvalid;
};
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 8a4c49e..995f3ab 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,6 +278,30 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
return 0;
}
+static void radeon_bo_vm_fence_va(struct radeon_cs_parser *parser,
+ struct radeon_fence *fence)
+{
+ struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+ struct radeon_vm *vm = &fpriv->vm;
+ struct radeon_bo_list *lobj;
+ int r;
+
+ if (parser->chunk_ib_idx == -1)
+ return;
+ if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
+ return;
+
+ list_for_each_entry(lobj, &parser->validated, tv.head) {
+ struct radeon_bo_va *bo_va;
+ struct radeon_bo *rbo = lobj->bo;
+
+ bo_va = radeon_bo_va(rbo, vm);
+ radeon_fence_unref(&bo_va->fence);
+ bo_va->fence = radeon_fence_ref(fence);
+ }
+ return 0;
+}
+
/**
* cs_parser_fini() - clean parser states
* @parser:parser structure holding parsing context.
@@ -290,11 +314,14 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
{
unsigned i;
- if (!error)
+ if (!error) {
+ /* fence all bo va before ttm_eu_fence_buffer_objects so bo are
still reserved */
+ radeon_bo_vm_fence_va(parser, parser->ib.fence);
ttm_eu_fence_buffer_objects(&parser->validated,
parser->ib.fence);
- else
+ } else {
ttm_eu_backoff_reservation(&parser->validated);
+ }
if (parser->relocs != NULL) {
for (i = 0; i < parser->nrelocs; i++) {
@@ -388,7 +415,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
if (parser->chunk_ib_idx == -1)
return 0;
-
if ((parser->cs_flags & RADEON_CS_USE_VM) == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
b/drivers/gpu/drm/radeon/radeon_gart.c
index b372005..9912182 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -814,7 +814,7 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -EINVAL;
}
- if (bo_va->valid)
+ if (bo_va->valid && mem)
return 0;
ngpu_pages = radeon_bo_ngpu_pages(bo);
@@ -859,11 +859,27 @@ int radeon_vm_bo_rmv(struct radeon_device *rdev,
struct radeon_bo *bo)
{
struct radeon_bo_va *bo_va;
+ int r;
bo_va = radeon_bo_va(bo, vm);
if (bo_va == NULL)
return 0;
+ /* wait for va use to end */
+ while (bo_va->fence) {
+ r = radeon_fence_wait(bo_va->fence, false);
+ if (r) {
+ DRM_ERROR("error while waiting for fence: %d\n", r);
+ }
+ if (r == -EDEADLK) {
+ r = radeon_gpu_reset(rdev);
+ if (!r)
+ continue;
+ }
+ break;
+ }
+ radeon_fence_unref(&bo_va->fence);
+
mutex_lock(&rdev->vm_manager.lock);
mutex_lock(&vm->mutex);
radeon_vm_bo_update_pte(rdev, vm, bo, NULL);
@@ -952,12 +968,15 @@ void radeon_vm_fini(struct radeon_device *rdev, struct
radeon_vm *vm)
radeon_vm_unbind_locked(rdev, vm);
mutex_unlock(&rdev->vm_manager.lock);
- /* remove all bo */
+ /* remove all bo at this point non are busy any more because unb
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
On Fri, Aug 3, 2012 at 4:47 PM, Greg KH wrote: > On Fri, Aug 03, 2012 at 04:31:22PM -0400, Jerome Glisse wrote: >> On Fri, Aug 3, 2012 at 4:16 PM, Greg KH wrote: >> > On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote: >> >> From: Jerome Glisse >> >> >> >> Virtual address need to be fenced to know when we can safely remove it. >> >> This patch also properly clear the pagetable. Previously it was >> >> serouisly broken. >> >> >> >> v2: For to update pagetable when unbinding bo (don't bailout if >> >> bo_va->valid is true). >> >> >> >> This version is for stable 3.5 only. >> > >> > Why? >> >> Because 3.4 needs again a different patch and 3.6 needs a different >> patch. Code around this patch changed btw 3.4-3.5 and changed again >> btw 3.5-3.6 and in non trivial way. > > Then please say that in the original patch, and point to where the > changes happened, and resend it so that I can apply it. > > I also need an ack from the maintainer(s) that this is acceptable. > > greg k-h I resend the original patch with comment that says 3.5 need special patch. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #29 from Jerome Glisse 2012-08-03 22:05:53 UTC --- Is the lvds console display shifted if you don't connect any external monitor ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53109] New: egl_gallium fails to link if both r600 and radeonsi are enabled
https://bugs.freedesktop.org/show_bug.cgi?id=53109 Bug #: 53109 Summary: egl_gallium fails to link if both r600 and radeonsi are enabled Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: freedesk...@blino.org When both r600 and radeonsi gallium drivers are enabled, egl_gallium fails to link because of duplicate symbols in r600 and radeonsi. See my configure command line and build errors below. $ ./configure --build=x86_64-mageia-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64 --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --x-includes=/usr/include --x-libraries=/usr/lib64 --enable-dri --enable-glx --with-dri-driverdir=/usr/lib64/dri --with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast --enable-shared-dricore --enable-egl --with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi --enable-gles1 --enable-gles2 --enable-openvg --enable-gallium-egl --enable-gallium-g3dvl --enable-osmesa --disable-xvmc --enable-vdpau --disable-va --with-gallium-drivers=r300,r600,radeonsi,nouveau,swrast --enable-gallium-llvm gmake[3]: Entering directory `/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/targets/egl-static' /bin/sh ../../../../bin/mklib -o egl_gallium.so -noprefix -linker 'g++' \ -ldflags '-L../../../../lib64 -Wl,--no-undefined -L/usr/lib64/llvm -Wl,--as-needed -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -L/usr/lib -lpthread -lffi -ldl -lm ' \ -cplusplus -install ../../../../lib64/egl \ egl.o egl_pipe.o egl_st.o -Wl,--start-group ../../../../src/egl/wayland/wayland-drm/.libs/libwayland-drm.a ../../../../src/gallium/auxiliary/libgallium.a ../../../../src/gallium/drivers/identity/libidentity.a ../../../../src/gallium/drivers/llvmpipe/libllvmpipe.a ../../../../src/gallium/drivers/nouveau/libnouveau.a ../../../../src/gallium/drivers/nv30/libnv30.a ../../../../src/gallium/drivers/nv50/libnv50.a ../../../../src/gallium/drivers/nvc0/libnvc0.a ../../../../src/gallium/drivers/r300/libr300.a ../../../../src/gallium/drivers/r600/libr600.a ../../../../src/gallium/drivers/radeonsi/libradeonsi.a ../../../../src/gallium/drivers/rbug/librbug.a ../../../../src/gallium/drivers/softpipe/libsoftpipe.a ../../../../src/gallium/drivers/trace/libtrace.a ../../../../src/gallium/state_trackers/egl/libegl.a ../../../../src/gallium/state_trackers/vega/libvega.a ../../../../src/gallium/winsys/nouveau/drm/libnouveaudrm.a ../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.a ../../../../src/gallium/winsys/sw/wayland/libws_wayland.a ../../../../src/gallium/winsys/sw/xlib/libws_xlib.a ../../../../src/mesa/libmesagallium.a -Wl,--end-group \ -lEGL -lOpenVG -lX11 -lXext -lXfixes -ldl -ldrm -ldrm_nouveau -ldrm_radeon -lgbm -lglapi -lm -lpthread -lrt -ludev -lwayland-client -lwayland-server -lLLVMMCJIT -lLLVMBitWriter -lLLVMX86AsmParser -lLLVMX86Disassembler -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport mklib: Making Linux shared library: egl_gallium.so /bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl ../../../../src/gallium/drivers/radeonsi/libradeonsi.a(evergreen_hw_context.o): In function `evergreen_flush_vgt_streamout': /home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/radeonsi/evergreen_hw_context.c:117: multiple definition of `evergreen_flush_vgt_streamout' ../../../../src/gallium/drivers/r600/libr600.a(evergreen_hw_context.o):/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/r600/evergreen_hw_context.c:753: first defined here ../../../../src/gallium/drivers/radeonsi/libradeonsi.a(evergreen_hw_context.o): In function `evergreen_set_streamout_enable': /home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/radeonsi/evergreen_hw_context.c:137: multiple definition of `evergreen_set_streamout_enable' ../../../../src/gallium/drivers/r600/libr600.a(evergreen_hw_context.o):/home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/r600/evergreen_hw_context.c:773: first defined here ../../../../src/gallium/drivers/radeonsi/libradeonsi.a(r600_buffer.o): In function `r600_init_resource': /home/iurt/rpm/BUILD/mesa-20120802/src/gallium/drivers/radeonsi/r600_buffer.c:121: multiple definition of `r600_init_resource' ../../../
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #30 from David L. 2012-08-03 22:54:12 UTC --- (In reply to comment #29) > Is the lvds console display shifted if you don't connect any external monitor > ? So far I only got the LVDS to display anything by connecting the DP monitor, so I don't really know. I didn't try much there... I'll try some other magic incantations/plug sequences tomorrow, maybe there's a sequence to get LVDS-only with it actually showing something. Starting X while the LVDS is off works fine, reenabling it. Also, the "LVDS off" state after loading the module has the backlight off too, maybe it's a bug in the brightness control and there is content but I just don't see it... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #31 from David L. 2012-08-03 23:21:21 UTC --- (In reply to comment #30) > (In reply to comment #29) > > Is the lvds console display shifted if you don't connect any external > > monitor ? > > So far I only got the LVDS to display anything by connecting the DP monitor, > so > I don't really know. I didn't try much there... I'll try some other magic > incantations/plug sequences tomorrow, maybe there's a sequence to get > LVDS-only > with it actually showing something. > > Starting X while the LVDS is off works fine, reenabling it. Correction: I just had a hard freeze after an hour or so of X use. Since I need to get some things done, I've booted in hybrid UEFI mode now with only the brightness patch applied. The LVDS-blank-after-insmod issue is gone, so it's not the backlight control I guess. Also, interestingly, the power consumption of the laptop was considerably lower under UEFI native mode (24W) vs. UEFI hybrid mode (29W). Could be either the CRTC programming patch or something completely unrelated. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #106 from Anthony Waters 2012-08-04 02:05:34 UTC --- I tried the patch from Christian in comment 96 atop of mesa git and the patch from Jerome in comment 102 atop of linux-3.5 and I no longer experience the rendering regression and I have not seen the va conflict error, thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #107 from Alexandre Demers 2012-08-04 03:55:56 UTC --- Tested with 3.6-rc1 and latest mesa with both respective patches. No va issue anymore. However, lockups still happen with RendererFeatTest64: I tried to run some tests and my system locked completly and restarted. This seems to be a different problem though not related to the va conflict issue. So I'll open a different bug for the lockups revealed by the same commit (as previously said, without virtual address space, it doesn't lock). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Alexandre Demers changed: What|Removed |Added Summary|[bisected] rendering|[bisected] rendering |regression since added |regression and va conflicts |support for virtual address |since added support for |space on cayman v11 |virtual address space on ||cayman v11 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] New: [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 Bug #: 53111 Summary: [bisected] lockups since added support for virtual address space on cayman v11 Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: alexandre.f.dem...@gmail.com When running RendererFeatTest64, it always locks at the same test. Lockups also happen when running piglit r600.test, locking always near the same test (sanity tests are OK). If we disable virtual address space as explained under bug 45018, no lockups happen. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #1 from Anthony Waters 2012-08-04 04:13:14 UTC --- Created attachment 65108 --> https://bugs.freedesktop.org/attachment.cgi?id=65108 dmesg of piglit r600.test crash I also have the same issue, here is the dmesg of the crash I get when running the piglit test case r600.test. This is with virtual address enabled and the patches from bug 45018 applied. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #2 from Alexandre Demers 2012-08-04 04:32:01 UTC --- Small note to whoever could come here and was not following bug 45018: Bisecting identified the following commit as culprit: bb1f0cf3508630a9a93512c79badf8c493c46743 is the first bad commit commit bb1f0cf3508630a9a93512c79badf8c493c46743 Author: Jerome Glisse Date: Fri Dec 2 10:20:29 2011 -0500 r600g: add support for virtual address space on cayman v11 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43655] Latest radeon dri driver on HD6950 with GRUB set gfxpayload=$linux_gfx_mode put the display in a flickering state
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #17 from Alexandre Demers 2012-08-04 04:58:03 UTC --- (In reply to comment #16) > (In reply to comment #15) > > If it's same as https://bugs.freedesktop.org/show_bug.cgi?id=42373 then > > patch > > there should fix your issue. > > I'll try it as soon as I'll have time. Thank you Jerome for your follow-up. (In reply to comment #15) > If it's same as https://bugs.freedesktop.org/show_bug.cgi?id=42373 then patch > there should fix your issue. It fixes it. Applied, rebooted 3 times without problem, went back to 3.6-rc1 (no patch) problem appeared, went back to patched kernel and still no problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] nouveau: Do not use nva3 engine for 0xaf chipset
The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. Signed-off-by: Henrik Rydberg --- Hi Ben, this patch is still needed in 3.6-rc1, so perhaps we should apply it after all. I have been running it without problems for a long time now. Thanks, Henrik drivers/gpu/drm/nouveau/nouveau_state.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 1cdfd6e..1866dbb 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) case 0xa3: case 0xa5: case 0xa8: - case 0xaf: nva3_copy_create(dev); break; } -- 1.7.11.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #84 from Anthony Waters 2012-08-03 01:28:25 UTC --- I randomly saw it when I was playing a game of Warcraft 3, the terrain textures would blink. I'll check the piglit tests and mesa demos to see if I can reproduce the issue with them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #85 from Anthony Waters 2012-08-03 02:07:06 UTC --- I found a demo that has the issue, in the demos repository for mesa within the src/demo folder the program 'reflect'. After I start it up and press 's' to see the stencil buffer the white plan blinks continuously. Applying the patch 'fixes to wait on the bo and to free the va after the kernel' removes the blinking, as does disabling va through the variable ws->info.r600_virtual_address. The other issue with the kernel reporting a va conflict is going to be a little harder to reproduce because it appears to be caused by a race condition. I'll still look for other demos that have the issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #86 from Alexandre Demers 2012-08-03 03:00:00 UTC --- (In reply to comment #85) > I found a demo that has the issue, in the demos repository for mesa within the > src/demo folder the program 'reflect'. After I start it up and press 's' to > see the stencil buffer the white plan blinks continuously. Applying the patch > 'fixes to wait on the bo and to free the va after the kernel' removes the > blinking, as does disabling va through the variable > ws->info.r600_virtual_address. > > The other issue with the kernel reporting a va conflict is going to be a > little > harder to reproduce because it appears to be caused by a race condition. > > I'll still look for other demos that have the issue. Yes, I understand it can be hard to track for you Jerome. Well for the va issue, on my side, it is as simple as logging in KDE or Gnome 3. Before logging in, there is no va error in dmesg. Once I'm in, there are usually 3 or sometimes 6 errors (they are written in block of 3, so I suspect it tries a first time and for some reason it fails and try again second time). I also experience the issue when watching some movies. With Anthony's patch, va issues are gone and I watched a couple of shows yesterday without any problem. Before the patch, it would blink and get corrupted after about 16 minutes and then crash. So, Anthony has put a finger on something. However, I also run piglit tests and some other applications like RendererFeatTest64 (which is an application released before Amnesia went out to test OpenGL performances if I recall recorrectly). With Anthony's patch, I'm still able to lock the display everytime (if I play music at the same time, it will continue to play but I won't be able to change terminal even if sometimes my mouse pointer can still be moved). RendererFeatTest64 will always lock at the same test, but it is not the same for piglit tests (even if it happens often at the same or near the same). I'm installing a freshly compiled kernel 3.5.0 with both Alex and your patches (by the way, they can't be applied on latest drm-next branch) and I'll tell you if I'm still experiencing the lockups. I'll also try Anthony's test to see if I get the same results (blinking without his patch, OK with it) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC 0/3] solving omapdrm/omapdss layering issues
Hi Rob, Tomi, On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark wrote: > On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen > wrote: >> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: >>> On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen >>> wrote: >>> > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >>> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >> >> ti.com> wrote: >>> > >>> >> > I guess the fact is that DRM concepts do not really match the OMAP DSS >>> >> > hardware, and we'll have to use whatever gives us least problems. >>> >> >>> >> Actually, I think it does map fairly well to the hardware.. at least >>> >> more so than to omapdss ;-) >>> > >>> > Hm, I'm not sure I understand, omapdss concepts map directly to the >>> > hardware. >>> >>> I think it is mainly exposing the encoder and panel as two separate >>> entities.. which seems to be what Archit is working on >> >> I still don't follow =) They are separate entities. Omapdss models the >> HW quite directly, I think. It doesn't expose everything, though, as the >> output drivers (dsi.c, dpi.c etc) are used via the panel drivers. > > right.. so we just need to expose the output drivers as separate > entities, and let omapdrm propagate information such as timings > between them > >>> in case of something like DVI bridge from DPI, this seems pretty >>> straightforward.. only the connector needs to know about DDC stuff, >>> which i2c to use and that sort of thing. So at kms level we would >>> have (for example) an omap_dpi_encoder which would be the same for DPI >>> panel (connector) or DPI->DVI bridge. For HDMI I'm still looking >>> through the code to see how this would work. Honestly I've looked >>> less at this part of code and encoder related registers in the TRM, >>> compared to the ovl/mgr parts, but at least from the 'DSS overview' >>> picture in the TRM it seems to make sense ;-) >>> >>> KMS even exposes the idea that certain crtcs can connect to only >>> certain encoders. Or that you could you could have certain connectors >>> switched between encoders. For example if you had a hw w/ DPI out, >>> and some mux to switch that back and forth between a DPI lcd panel and >>> a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does >>> this, but it is in theory possible.) So we could expose possible >>> video chain topologies to userspace in this way. >> >> OMAP3 SDP board has such a setup, with manual switch to select between >> LCD and DVI. > > ahh, good to know.. so I'm not crazy for wanting to expose this > possibility to userspace > >>> The other thing is that we don't need to propagate timings from the >>> panel up to the mgr at the dss level.. kms is already handling this >>> for us. In my latest version, which I haven't pushed, I removed the >>> 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. >> >> You're thinking only about simple DPI cases. Consider this example, with >> a DSI-to-DP bridge chip. What we have is the following flow of data: >> >> DISPC -> DSI -> DSI-2-DP -> DP monitor >> >> The timings you are thinking about are in the DISPC, but here they are >> only one part of the link. And here the DISPC timings are not actually >> the timings what the user is interested about. The user wants his >> timings to be between DSI-2-DP chip and the DP monitor. >> >> Timings programmed to DISPC are not the same. The timings for DISPC come >> from the DSI driver, and they may be very different than the user's >> timings. With DSI video mode, the DISPC timings would have some >> resemblance to the user's timings, mainly the time to send one line >> would be the same. With DSI cmd mode, the DISPC timings would be >> something totally different, most likely with 0 blank times and as fast >> pixel clock as possible. > > hmm, well kms already has a concept of adjusted_timings, which could > perhaps be used here to propagate the timings between crtc->encoder.. > although the order is probably backwards from what we want (it comes > from the crtc to the encoder.. and if I understand properly we want it > the other way and actually possibly from the connector). But that > isn't to say that internally in omapdrm the crtc couldn't get the > adjusted timings from the connector. So I still think the parameter > flow doesn't need to be 'under the hood' in omapdss. > > And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper > fxns, so if the way the core kms handles it isn't what we want, we can > just plug in our own fxn instead of using drm_crtc_helper_set_mode(), > so that isn't really a big problem. > >> What omapdss does currently is that you set the user's timings to the >> right side of the chain, which propagate back to DSS. This allows the >> DSI-2-DP bridge use DSI timings that work optimally for the bridge, and >> DSI driver will use DISPC timings that work optimally for it. >> >> And it's not only about timings above, but also other settings related >> to the busses between the components. Clock
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #87 from Alexandre Demers 2012-08-03 06:03:39 UTC --- (In reply to comment #86) > (In reply to comment #85) > > I found a demo that has the issue, in the demos repository for mesa within > > the > > src/demo folder the program 'reflect'. After I start it up and press 's' to > > see the stencil buffer the white plan blinks continuously. Applying the > > patch > > 'fixes to wait on the bo and to free the va after the kernel' removes the > > blinking, as does disabling va through the variable > > ws->info.r600_virtual_address. > > > > The other issue with the kernel reporting a va conflict is going to be a > > little > > harder to reproduce because it appears to be caused by a race condition. > > > > I'll still look for other demos that have the issue. > > Yes, I understand it can be hard to track for you Jerome. Well for the va > issue, on my side, it is as simple as logging in KDE or Gnome 3. Before > logging > in, there is no va error in dmesg. Once I'm in, there are usually 3 or > sometimes 6 errors (they are written in block of 3, so I suspect it tries a > first time and for some reason it fails and try again second time). > > I also experience the issue when watching some movies. With Anthony's patch, > va > issues are gone and I watched a couple of shows yesterday without any problem. > Before the patch, it would blink and get corrupted after about 16 minutes and > then crash. So, Anthony has put a finger on something. > > However, I also run piglit tests and some other applications like > RendererFeatTest64 (which is an application released before Amnesia went out > to > test OpenGL performances if I recall recorrectly). With Anthony's patch, I'm > still able to lock the display everytime (if I play music at the same time, it > will continue to play but I won't be able to change terminal even if sometimes > my mouse pointer can still be moved). RendererFeatTest64 will always lock at > the same test, but it is not the same for piglit tests (even if it happens > often at the same or near the same). > > I'm installing a freshly compiled kernel 3.5.0 with both Alex and your patches > (by the way, they can't be applied on latest drm-next branch) and I'll tell > you > if I'm still experiencing the lockups. I'll also try Anthony's test to see if > I > get the same results (blinking without his patch, OK with it) Well it still locks up even with the patches. I also tested the reflect demo and I don't have any blink without Anthony's patch, but we may be experiencing different symptoms of the same problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
On ?, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote: > On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: > > On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: > > > AMD ACPI interface may overload the standard event > > > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > > > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the > > > userspace because the user did not press the mode switch key (the > > > spurious keypress confuses the DE which usually changes the > > > display configuration and messes up a dual-screen setup). > > > This patch gives the radeon driver the chance to examine the event and > > > block the keypress if the event is an "AMD event". > > > > > > Signed-off-by: Luca Tettamanti > > > --- > > > Any comment from ACPI front? > > > > > it looks good to me. > > But I'm wondering if we can use the following code for ACPI part, which > > looks cleaner. > > I know this may change the behavior of other events, but in theory, we > > should not send any input event if we know something wrong in kernel. > > > > what do you think? > > I like it, it's cleaner. > I've split the patch in two pieces (one for video, the other for > radeon) and adopted your suggestion. > Great. Acked-by: Zhang Rui hmm, who should take these two patches? and which tree the second patch is based on? thanks, rui
[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
On ?, 2012-08-02 at 21:45 -0400, Alex Deucher wrote: > On Thu, Aug 2, 2012 at 9:40 PM, Zhang Rui wrote: > > On ?, 2012-08-02 at 15:46 +0200, Luca Tettamanti wrote: > >> On Thu, Aug 02, 2012 at 08:45:30AM +0800, Zhang Rui wrote: > >> > On ?, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote: > >> > > AMD ACPI interface may overload the standard event > >> > > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > >> > > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the > >> > > userspace because the user did not press the mode switch key (the > >> > > spurious keypress confuses the DE which usually changes the > >> > > display configuration and messes up a dual-screen setup). > >> > > This patch gives the radeon driver the chance to examine the event and > >> > > block the keypress if the event is an "AMD event". > >> > > > >> > > Signed-off-by: Luca Tettamanti > >> > > --- > >> > > Any comment from ACPI front? > >> > > > >> > it looks good to me. > >> > But I'm wondering if we can use the following code for ACPI part, which > >> > looks cleaner. > >> > I know this may change the behavior of other events, but in theory, we > >> > should not send any input event if we know something wrong in kernel. > >> > > >> > what do you think? > >> > >> I like it, it's cleaner. > >> I've split the patch in two pieces (one for video, the other for > >> radeon) and adopted your suggestion. > >> > > Great. > > Acked-by: Zhang Rui > > > > hmm, who should take these two patches? > > I'm happy to take the patches. > > > and which tree the second patch is based on? > > I've got a tree with all the radeon ACPI patches on the acpi_patches > branches of my git tree: > git://people.freedesktop.org/~agd5f/linux > great. thanks, rui
[PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.
1, Handle io prot correctly for MIPS. 2, Define SAREA_MAX as the size of one page. 3, Include swiotlb.h if SWIOTLB configured. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_vm.c|2 +- drivers/gpu/drm/radeon/radeon_ttm.c |4 drivers/gpu/drm/ttm/ttm_bo_util.c |2 +- include/drm/drm_sarea.h |2 ++ 4 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 961ee08..3f06166 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma) tmp = pgprot_writecombine(tmp); else tmp = pgprot_noncached(tmp); -#elif defined(__sparc__) || defined(__arm__) +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) tmp = pgprot_noncached(tmp); #endif return tmp; diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include +#endif + #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index f8187ea..0df71ea 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp) else tmp = pgprot_noncached(tmp); #endif -#if defined(__sparc__) +#if defined(__sparc__) || defined(__mips__) if (!(caching_flags & TTM_PL_FLAG_CACHED)) tmp = pgprot_noncached(tmp); #endif diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h index ee5389d..1d1a858 100644 --- a/include/drm/drm_sarea.h +++ b/include/drm/drm_sarea.h @@ -37,6 +37,8 @@ /* SAREA area needs to be at least a page */ #if defined(__alpha__) #define SAREA_MAX 0x2000U +#elif defined(__mips__) +#define SAREA_MAX 0x4000U #elif defined(__ia64__) #define SAREA_MAX 0x1U /* 64kB */ #else -- 1.7.7.3
[PATCH v2] of: Add videomode helper
Hi Stephen,
On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
> On 07/04/2012 01:56 AM, Sascha Hauer wrote:
> > This patch adds a helper function for parsing videomodes from the
> > devicetree.
> > The videomode can be either converted to a struct drm_display_mode or a
> > struct fb_videomode.
>
> > diff --git a/Documentation/devicetree/bindings/video/displaymode
> > b/Documentation/devicetree/bindings/video/displaymode
>
> > +Required properties:
> > + - xres, yres: Display resolution
> > + - left-margin, right-margin, hsync-len: Horizontal Display timing
> > parameters
> > + in pixels
> > + upper-margin, lower-margin, vsync-len: Vertical display timing
> > parameters in
> > + lines
>
> Perhaps bike-shedding, but...
>
> For the margin property names, wouldn't it be better to use terminology
> more commonly used for video timings rather than Linux FB naming. In
> other words naming like:
>
> hactive, hsync-len, hfront-porch, hback-porch?
Can do. Just to make sure:
hactive == xres
hsync-len == hsync-len
hfront-porch == right-margin
hback-porch == left-margin
?
>
> This node appears to describe a video mode, not a display, hence the
> node name seems wrong.
>
> Many displays can support multiple different video modes. As mentioned
> elsewhere, properties like display width/height are properties of the
> display not the mode.
>
> So, I might expect something more like the following (various overhead
> properties like reg/#address-cells etc. elided for simplicity):
>
> disp: display {
> width-mm = <...>;
> height-mm = <...>;
> modes {
> mode at 0 {
> /* 1920x1080p24 */
> clock = <5200>;
> xres = <1920>;
> yres = <1080>;
> left-margin = <25>;
> right-margin = <25>;
> hsync-len = <25>;
> lower-margin = <2>;
> upper-margin = <2>;
> vsync-len = <2>;
> hsync-active-high;
> };
> mode at 1 {
> };
> };
> };
Ok, we can do this.
>
> display-connector {
> display = <&disp>;
> // interface-specific properties such as pixel format here
> };
>
> Finally, have you considered just using an EDID instead of creating
> something custom? I know that creating an EDID is harder than writing a
> few simple properties into a DT, but EDIDs have the following advantages:
I have considered using EDID and I also tried it. It's painful. There
are no (open) tools available for creating EDID. That's something we
could change of course. Then when generating a devicetree there is
always an extra step involved creating the EDID blob. Once the EDID
blob is in devicetree it is not parsable anymore by mere humans, so
to see what we've got there is another tool involved to generate a
readable form again.
>
> a) They're already standardized and very common.
Indeed, that's a big plus for EDID. I have no intention of removing EDID
data from the devicetree. There are situations where EDID is handy, for
example when you get EDID data provided by your vendor.
>
> b) They allow other information such as a display's HDMI audio
> capabilities to be represented, which can then feed into an ALSA driver.
>
> c) The few LCD panel datasheets I've seen actually quote their
> specification as an EDID already, so deriving the EDID may actually be easy.
>
> d) People familiar with displays are almost certainly familiar with
> EDID's mode representation. There are many ways of representing display
> modes (sync position vs. porch widths, htotal specified rather than
> specifying all the components and hence htotal being calculated etc.).
> Not everyone will be familiar with all representations. Conversion
> errors are less likely if the target is EDID's familiar format.
You seem to think about a different class of displays for which EDID
indeed is a better way to handle. What I have to deal with here mostly
are dumb displays which:
- can only handle their native resolution
- Have no audio capabilities at all
- come with a datasheet which specify a min/typ/max triplet for
xres,hsync,..., often enough they are scanned to pdf from some previously
printed paper.
These displays are very common on embedded devices, probably that's the
reason I did not even think about the possibility that a single display
might have different modes.
>
> e) You'll end up with exactly the same data as if you have a DDC-based
> external monitor rather than an internal panel, so you end up getting to
> a common path in display handling code much more quickly.
All we have in our display driver currently is:
edidp = of_get_property(np, "edid", &imxpd->edid_len);
if (edidp) {
imxpd->edid = kmemdup(edidp, imxpd->edid_len, GFP_KERNEL);
} else {
ret = of_get_video_mode(np, &imxpd->mode, NULL);
if (!ret)
imxpd->mode_valid = 1;
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #88 from Michel D?nzer 2012-08-03 07:47:17 UTC --- (In reply to comment #86) > So, Anthony has put a finger on something. Yes, I think something like Anthony's patch is needed due to asynchronous GPU processing: when the userspace driver assigns virtual address space for a new BO, the GPU may not have finished processing command streams using previous BOs occupying that same virtual address space. However, the userspace driver shouldn't wait synchronously for the BO to go idle when destroying it but should instead defer destruction (or at least the freeing of the virtual address space) until it notices the BO has become idle. > With Anthony's patch, I'm still able to lock the display everytime And these lockups do not happen when not using virtual address space? Can you provide the dmesg output of the GPU reset for such a lockup? Ideally from a single piglit test reproducing it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #2 from Michel D?nzer 2012-08-03 07:49:18 UTC --- Please attach the /var/log/Xorg.0.log file. Which version of libdrm_radeon are you using? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.
On Fre, 2012-08-03 at 15:06 +0800, Huacai Chen wrote: > 1, Handle io prot correctly for MIPS. > 2, Define SAREA_MAX as the size of one page. > 3, Include swiotlb.h if SWIOTLB configured. > > Signed-off-by: Huacai Chen > Signed-off-by: Hongliang Tao > Signed-off-by: Hua Yan > Cc: dri-devel at lists.freedesktop.org > --- > drivers/gpu/drm/drm_vm.c|2 +- > drivers/gpu/drm/radeon/radeon_ttm.c |4 > drivers/gpu/drm/ttm/ttm_bo_util.c |2 +- > include/drm/drm_sarea.h |2 ++ > 4 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c > index 961ee08..3f06166 100644 > --- a/drivers/gpu/drm/drm_vm.c > +++ b/drivers/gpu/drm/drm_vm.c > @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct > vm_area_struct *vma) > tmp = pgprot_writecombine(tmp); > else > tmp = pgprot_noncached(tmp); > -#elif defined(__sparc__) || defined(__arm__) > +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) > tmp = pgprot_noncached(tmp); > #endif > return tmp; > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > b/drivers/gpu/drm/radeon/radeon_ttm.c > index 5b71c71..fc3ac22 100644 > --- a/drivers/gpu/drm/radeon/radeon_ttm.c > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c > @@ -41,6 +41,10 @@ > #include "radeon_reg.h" > #include "radeon.h" > > +#ifdef CONFIG_SWIOTLB > +#include > +#endif > + > #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) > > static int radeon_ttm_debugfs_init(struct radeon_device *rdev); > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c > b/drivers/gpu/drm/ttm/ttm_bo_util.c > index f8187ea..0df71ea 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c > @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp) > else > tmp = pgprot_noncached(tmp); > #endif > -#if defined(__sparc__) > +#if defined(__sparc__) || defined(__mips__) > if (!(caching_flags & TTM_PL_FLAG_CACHED)) > tmp = pgprot_noncached(tmp); > #endif > diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h > index ee5389d..1d1a858 100644 > --- a/include/drm/drm_sarea.h > +++ b/include/drm/drm_sarea.h > @@ -37,6 +37,8 @@ > /* SAREA area needs to be at least a page */ > #if defined(__alpha__) > #define SAREA_MAX 0x2000U > +#elif defined(__mips__) > +#define SAREA_MAX 0x4000U > #elif defined(__ia64__) > #define SAREA_MAX 0x1U /* 64kB */ > #else This should be four separate patches. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #89 from Alexandre Demers 2012-08-03 08:05:07 UTC --- (In reply to comment #88) > (In reply to comment #86) > > So, Anthony has put a finger on something. > > Yes, I think something like Anthony's patch is needed due to asynchronous GPU > processing: when the userspace driver assigns virtual address space for a new > BO, the GPU may not have finished processing command streams using previous > BOs > occupying that same virtual address space. > > However, the userspace driver shouldn't wait synchronously for the BO to go > idle when destroying it but should instead defer destruction (or at least the > freeing of the virtual address space) until it notices the BO has become idle. > > > > With Anthony's patch, I'm still able to lock the display everytime > > And these lockups do not happen when not using virtual address space? Can you > provide the dmesg output of the GPU reset for such a lockup? Ideally from a > single piglit test reproducing it. Nope, no lockup without va (I may only be lucky though if the bug is there but only shown when using va). I'll try to find a way to get dmesg... It has been a problem since the start for that part, but I may be able to use another computer to log in remotely. May take a couple of days to do though. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #90 from Michel D?nzer 2012-08-03 08:13:03 UTC --- (In reply to comment #89) > Nope, no lockup without va (I may only be lucky though if the bug is there but > only shown when using va). That's indeed possible: Using virtual address space will catch out of bounds memory access that may otherwise go unnoticed. So, I think in this report we should focus on the rendering regression(s), and track the lockups in other reports. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH V4 11/16] drm/radeon: Make radeon card usable for Loongson.
OK, I'll split it. On Fri, Aug 3, 2012 at 4:01 PM, Michel D?nzer wrote: > On Fre, 2012-08-03 at 15:06 +0800, Huacai Chen wrote: >> 1, Handle io prot correctly for MIPS. >> 2, Define SAREA_MAX as the size of one page. >> 3, Include swiotlb.h if SWIOTLB configured. >> >> Signed-off-by: Huacai Chen >> Signed-off-by: Hongliang Tao >> Signed-off-by: Hua Yan >> Cc: dri-devel at lists.freedesktop.org >> --- >> drivers/gpu/drm/drm_vm.c|2 +- >> drivers/gpu/drm/radeon/radeon_ttm.c |4 >> drivers/gpu/drm/ttm/ttm_bo_util.c |2 +- >> include/drm/drm_sarea.h |2 ++ >> 4 files changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c >> index 961ee08..3f06166 100644 >> --- a/drivers/gpu/drm/drm_vm.c >> +++ b/drivers/gpu/drm/drm_vm.c >> @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct >> vm_area_struct *vma) >> tmp = pgprot_writecombine(tmp); >> else >> tmp = pgprot_noncached(tmp); >> -#elif defined(__sparc__) || defined(__arm__) >> +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) >> tmp = pgprot_noncached(tmp); >> #endif >> return tmp; >> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c >> b/drivers/gpu/drm/radeon/radeon_ttm.c >> index 5b71c71..fc3ac22 100644 >> --- a/drivers/gpu/drm/radeon/radeon_ttm.c >> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c >> @@ -41,6 +41,10 @@ >> #include "radeon_reg.h" >> #include "radeon.h" >> >> +#ifdef CONFIG_SWIOTLB >> +#include >> +#endif >> + >> #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) >> >> static int radeon_ttm_debugfs_init(struct radeon_device *rdev); >> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c >> b/drivers/gpu/drm/ttm/ttm_bo_util.c >> index f8187ea..0df71ea 100644 >> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c >> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c >> @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t >> tmp) >> else >> tmp = pgprot_noncached(tmp); >> #endif >> -#if defined(__sparc__) >> +#if defined(__sparc__) || defined(__mips__) >> if (!(caching_flags & TTM_PL_FLAG_CACHED)) >> tmp = pgprot_noncached(tmp); >> #endif >> diff --git a/include/drm/drm_sarea.h b/include/drm/drm_sarea.h >> index ee5389d..1d1a858 100644 >> --- a/include/drm/drm_sarea.h >> +++ b/include/drm/drm_sarea.h >> @@ -37,6 +37,8 @@ >> /* SAREA area needs to be at least a page */ >> #if defined(__alpha__) >> #define SAREA_MAX 0x2000U >> +#elif defined(__mips__) >> +#define SAREA_MAX 0x4000U >> #elif defined(__ia64__) >> #define SAREA_MAX 0x1U /* 64kB */ >> #else > > This should be four separate patches. > > > -- > Earthling Michel D?nzer | http://www.amd.com > Libre software enthusiast | Debian, X and DRI developer
[Bug 26345] [845G] CPU/GPU incoherency
https://bugs.freedesktop.org/show_bug.cgi?id=26345 Chris Wilson changed: What|Removed |Added CC||artem.rusanov at gmail.com --- Comment #147 from Chris Wilson 2012-08-03 12:18:44 UTC --- *** Bug 53065 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC 0/3] solving omapdrm/omapdss layering issues
On Fri, Aug 3, 2012 at 1:01 AM, Semwal, Sumit wrote: > Hi Rob, Tomi, > On Thu, Aug 2, 2012 at 7:46 PM, Rob Clark wrote: >> On Thu, Aug 2, 2012 at 8:15 AM, Tomi Valkeinen >> wrote: >>> On Thu, 2012-08-02 at 07:45 -0500, Rob Clark wrote: On Thu, Aug 2, 2012 at 2:13 AM, Tomi Valkeinen wrote: > On Wed, 2012-08-01 at 09:25 -0500, Rob Clark wrote: >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >>> >> ti.com> wrote: > >> > I guess the fact is that DRM concepts do not really match the OMAP DSS >> > hardware, and we'll have to use whatever gives us least problems. >> >> Actually, I think it does map fairly well to the hardware.. at least >> more so than to omapdss ;-) > > Hm, I'm not sure I understand, omapdss concepts map directly to the > hardware. I think it is mainly exposing the encoder and panel as two separate entities.. which seems to be what Archit is working on >>> >>> I still don't follow =) They are separate entities. Omapdss models the >>> HW quite directly, I think. It doesn't expose everything, though, as the >>> output drivers (dsi.c, dpi.c etc) are used via the panel drivers. >> >> right.. so we just need to expose the output drivers as separate >> entities, and let omapdrm propagate information such as timings >> between them >> in case of something like DVI bridge from DPI, this seems pretty straightforward.. only the connector needs to know about DDC stuff, which i2c to use and that sort of thing. So at kms level we would have (for example) an omap_dpi_encoder which would be the same for DPI panel (connector) or DPI->DVI bridge. For HDMI I'm still looking through the code to see how this would work. Honestly I've looked less at this part of code and encoder related registers in the TRM, compared to the ovl/mgr parts, but at least from the 'DSS overview' picture in the TRM it seems to make sense ;-) KMS even exposes the idea that certain crtcs can connect to only certain encoders. Or that you could you could have certain connectors switched between encoders. For example if you had a hw w/ DPI out, and some mux to switch that back and forth between a DPI lcd panel and a DPI->DVI bridge. (Ok, I'm not aware of any board that actually does this, but it is in theory possible.) So we could expose possible video chain topologies to userspace in this way. >>> >>> OMAP3 SDP board has such a setup, with manual switch to select between >>> LCD and DVI. >> >> ahh, good to know.. so I'm not crazy for wanting to expose this >> possibility to userspace >> The other thing is that we don't need to propagate timings from the panel up to the mgr at the dss level.. kms is already handling this for us. In my latest version, which I haven't pushed, I removed the 'struct omap_overlay_mgr' ptr from 'struct omap_dss_device'. >>> >>> You're thinking only about simple DPI cases. Consider this example, with >>> a DSI-to-DP bridge chip. What we have is the following flow of data: >>> >>> DISPC -> DSI -> DSI-2-DP -> DP monitor >>> >>> The timings you are thinking about are in the DISPC, but here they are >>> only one part of the link. And here the DISPC timings are not actually >>> the timings what the user is interested about. The user wants his >>> timings to be between DSI-2-DP chip and the DP monitor. >>> >>> Timings programmed to DISPC are not the same. The timings for DISPC come >>> from the DSI driver, and they may be very different than the user's >>> timings. With DSI video mode, the DISPC timings would have some >>> resemblance to the user's timings, mainly the time to send one line >>> would be the same. With DSI cmd mode, the DISPC timings would be >>> something totally different, most likely with 0 blank times and as fast >>> pixel clock as possible. >> >> hmm, well kms already has a concept of adjusted_timings, which could >> perhaps be used here to propagate the timings between crtc->encoder.. >> although the order is probably backwards from what we want (it comes >> from the crtc to the encoder.. and if I understand properly we want it >> the other way and actually possibly from the connector). But that >> isn't to say that internally in omapdrm the crtc couldn't get the >> adjusted timings from the connector. So I still think the parameter >> flow doesn't need to be 'under the hood' in omapdss. >> >> And fwiw, the adjusted_timings stuff is handled by drm_crtc_helper >> fxns, so if the way the core kms handles it isn't what we want, we can >> just plug in our own fxn instead of using drm_crtc_helper_set_mode(), >> so that isn't really a big problem. >> >>> What omapdss does currently is that you set the user's timings to the >>> right side of the chain, which propagate back to DSS. This allows the >>> DSI-2-DP bridge use DSI timings that work optimally for the bridge, and >>> DSI driver will use DISPC timings
[PATCH v2 7/7] drm: Renesas SH Mobile DRM driver
Hi Laurent,
Some minor stuff inside.
Thanks
Sascha+
On Fri, Jul 20, 2012 at 03:04:22PM +0200, Laurent Pinchart wrote:
> The SH Mobile LCD controller (LCDC) DRM driver supports the main
> graphics plane in RGB and YUV formats, as well as the overlay planes (in
> alpha-blending mode only).
>
> Only flat panel outputs using the parallel interface are supported.
> Support for SYS panels, HDMI and DSI is currently not implemented.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/Kconfig|2 +
> drivers/gpu/drm/Makefile |1 +
> drivers/gpu/drm/shmobile/Kconfig | 10 +
> drivers/gpu/drm/shmobile/Makefile |7 +
> drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 90 +++
> drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 23 +
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 768
>
> drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 60 ++
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 360 +++
> drivers/gpu/drm/shmobile/shmob_drm_drv.h | 52 ++
> drivers/gpu/drm/shmobile/shmob_drm_kms.c | 160 +
> drivers/gpu/drm/shmobile/shmob_drm_kms.h | 34 +
> drivers/gpu/drm/shmobile/shmob_drm_plane.c | 263
> drivers/gpu/drm/shmobile/shmob_drm_plane.h | 22 +
> drivers/gpu/drm/shmobile/shmob_drm_regs.h | 304 ++
> include/drm/shmob_drm.h| 99 +++
> 16 files changed, 2255 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpu/drm/shmobile/Kconfig
> create mode 100644 drivers/gpu/drm/shmobile/Makefile
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_backlight.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_crtc.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_drv.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_kms.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.c
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_plane.h
> create mode 100644 drivers/gpu/drm/shmobile/shmob_drm_regs.h
> create mode 100644 include/drm/shmob_drm.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 98ba7d5..0b40bf2 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -208,3 +208,5 @@ source "drivers/gpu/drm/ast/Kconfig"
> source "drivers/gpu/drm/mgag200/Kconfig"
>
> source "drivers/gpu/drm/cirrus/Kconfig"
> +
> +source "drivers/gpu/drm/shmobile/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 58961b9..2ff5cef 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -47,4 +47,5 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> obj-$(CONFIG_DRM_GMA500) += gma500/
> obj-$(CONFIG_DRM_UDL) += udl/
> obj-$(CONFIG_DRM_AST) += ast/
> +obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
> obj-y+= i2c/
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> new file mode 100644
> index 000..c7be5f7
> --- /dev/null
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> @@ -0,0 +1,768 @@
[...]
> +
> +static void shmob_drm_encoder_destroy(struct drm_encoder *encoder)
> +{
> + drm_encoder_cleanup(encoder);
> +}
> +
> +static const struct drm_encoder_funcs encoder_funcs = {
> + .destroy = shmob_drm_encoder_destroy,
You could add drm_encoder_cleanup here.
[...]
> +
> +static enum drm_connector_status
> +shmob_drm_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_unknown;
> +}
Shouldn't you return connector_status_connected here? I mean all that
you handle is a dumb display which is always connected.
[...]
> +
> +static int __devinit shmob_drm_setup_clocks(struct shmob_drm_device *sdev,
> + enum shmob_drm_clk_source clksrc)
> +{
> + struct clk *clk;
> + char *clkname;
> +
> + switch (clksrc) {
> + case SHMOB_DRM_CLK_BUS:
> + clkname = "bus_clk";
> + sdev->lddckr = LDDCKR_ICKSEL_BUS;
> + break;
> + case SHMOB_DRM_CLK_PERIPHERAL:
> + clkname = "peripheral_clk";
> + sdev->lddckr = LDDCKR_ICKSEL_MIPI;
> + break;
> + case SHMOB_DRM_CLK_EXTERNAL:
> + clkname = NULL;
> + sdev->lddckr = LDDCKR_ICKSEL_HDMI;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + clk = clk_get(sdev->dev, clkname);
> + if (IS_ERR(clk)) {
> + dev_err(sdev->dev, "cannot get dot clock %s\n", clkname);
> + return PTR_ERR(clk);
> + }
> +
> + sdev->clock = clk;
> + return 0;
>
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Christian K?nig changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Comment #91 from Christian K?nig 2012-08-03 12:58:04 UTC --- I just fixed a memory leak in radeonsi, and it looks like I'm hitting the same problem now. Do I understand it correctly that the userspace VM manager is releasing allocations to early and not waiting for async buffer use to end? That should be easy to fix. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #92 from Michel D?nzer 2012-08-03 13:21:22 UTC --- (In reply to comment #91) > I just fixed a memory leak in radeonsi, and it looks like I'm hitting the same > problem now. Ah cool, you found it already. :) > Do I understand it correctly that the userspace VM manager is releasing > allocations to early and not waiting for async buffer use to end? That's my working theory. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #93 from Michel D?nzer 2012-08-03 13:26:32 UTC --- (In reply to comment #92) > > Do I understand it correctly that the userspace VM manager is releasing > > allocations to early and not waiting for async buffer use to end? > > That's my working theory. Also, if it wasn't the case, I don't see how Anthony's patch could make a difference. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: ignore disconnected <-> unknown status changes
On Thu, Aug 2, 2012 at 3:21 AM, Knut Petersen wrote: > On an AOpen i915GMm-hfs the hotplug events generated > by transitions between connector_status_unknown and > connector_status_disconnected cause screen distortions. > > The attached patch cures the problem by disabling the > generation of hotplug events in those cases. That should > be safe for everybody as the only relevant changes are > those from / to connector_status_connected. Seems reasonable to me. We should just drop unknown. Reviewed-by: Alex Deucher > > cu, > Knut > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
Optimize i2f()
On Mon, Jul 30, 2012 at 5:49 PM, Steven Fuerst wrote:
> Looking through the kernel radeon drm source, it looks like the i2f()
> functions in r600_blit.c and r600_blit_ksm() can be optimized a bit.
Care to send a patch?
Thanks,
Alex
>
> The following extends the range to all unsigned 32bit integers, and avoids
> the slow loop by using the bsr instruction via __fls(). It provides an
> exact 1-1 correspondence up to 2^24. Above that, there is the inevitable
> rounding. This routine rounds towards zero (truncation).
>
> /* 23 bits of float fractional data */
> #define I2F_FRAC_BITS 23
> #define I2F_MASK ((1 << I2F_FRAC_BITS) - 1)
>
> /*
> * Converts an unsigned integer into 32-bit IEEE floating point
> representation.
> * Will be exact from 0 to 2^24. Above that, we round towards zero
> * as the fractional bits will not fit in a float. (It would be better to
> * round towards even as the fpu does, but that is slower.)
> * This routine depends on the mod(32) behaviour of the rotate instructions
> * on x86.
> */
> uint32_t i2f(uint32_t x)
> {
> uint32_t msb, exponent, fraction;
>
> /* Zero is special */
> if (!x) return 0;
>
> /* Get location of the most significant bit */
> msb = __fls(x);
>
> /*
> * Use a rotate instead of a shift because that works both leftwards
> * and rightwards due to the mod(32) beahviour. This means we don't
> * need to check to see if we are above 2^24 or not.
> */
> fraction = ror32(x, msb - I2F_FRAC_BITS) & I2F_MASK;
> exponent = (127 + msb) << I2F_FRAC_BITS;
>
> return fraction + exponent;
> }
>
> Steven Fuerst
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #94 from Jerome Glisse 2012-08-03 14:39:59 UTC --- (In reply to comment #88) > (In reply to comment #86) > > So, Anthony has put a finger on something. > > Yes, I think something like Anthony's patch is needed due to asynchronous GPU > processing: when the userspace driver assigns virtual address space for a new > BO, the GPU may not have finished processing command streams using previous > BOs > occupying that same virtual address space. > > However, the userspace driver shouldn't wait synchronously for the BO to go > idle when destroying it but should instead defer destruction (or at least the > freeing of the virtual address space) until it notices the BO has become idle. > > > > With Anthony's patch, I'm still able to lock the display everytime > > And these lockups do not happen when not using virtual address space? Can you > provide the dmesg output of the GPU reset for such a lockup? Ideally from a > single piglit test reproducing it. No, Anthony patch should not be needed. Once userspace call kernel to destroy bo userspace should be able to reuse va right away even if kernel is delaying bo destruction. My patch should fix the va issue, note that the patch attached here have a bug but it should not affect the va thing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #95 from Alexandre Demers 2012-08-03 14:51:56 UTC --- (In reply to comment #90) > (In reply to comment #89) > > Nope, no lockup without va (I may only be lucky though if the bug is there > > but > > only shown when using va). > > That's indeed possible: Using virtual address space will catch out of bounds > memory access that may otherwise go unnoticed. > > So, I think in this report we should focus on the rendering regression(s), and > track the lockups in other reports. OK, I'll open another bug for the lockups. This one will be renamed for va issues and rendering regression. I'll wait until tonight to make changes to see if someone objects. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Christian K?nig changed: What|Removed |Added Attachment #65051|0 |1 is obsolete|| --- Comment #96 from Christian K?nig 2012-08-03 15:03:52 UTC --- Created attachment 65093 --> https://bugs.freedesktop.org/attachment.cgi?id=65093 Possible fix. It's hard and uneffecient to solve this problem completely in the kernel. Since we patch the VM table synchronously, but use it asynchronously we will always end up needing to wait for a bo use by the GPU to end before patching in the new VA. Please take a look at the attached patch it should fix the issue nicely in userspace. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #97 from Marek Ol??k 2012-08-03 15:20:12 UTC --- (In reply to comment #96) > Created attachment 65093 [details] [review] > Possible fix. > > It's hard and uneffecient to solve this problem completely in the kernel. > > Since we patch the VM table synchronously, but use it asynchronously we will > always end up needing to wait for a bo use by the GPU to end before patching > in > the new VA. > > Please take a look at the attached patch it should fix the issue nicely in > userspace. Please use the radeon_bo_is_busy function. Calling DRM_RADEON_GEM_BUSY directly is not reliable because of the thread offloading of the CS ioctl. The same applies to any other kernel queries and commands which depend on the CS ioctl. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon: fix some missing parens in asic macros
From: Alex Deucher Better safe than sorry. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 118e4b9..9f58885 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1789,11 +1789,11 @@ void radeon_ring_write(struct radeon_ring *ring, uint32_t v); #define radeon_pm_finish(rdev) (rdev)->asic->pm.finish((rdev)) #define radeon_pm_init_profile(rdev) (rdev)->asic->pm.init_profile((rdev)) #define radeon_pm_get_dynpm_state(rdev) (rdev)->asic->pm.get_dynpm_state((rdev)) -#define radeon_pre_page_flip(rdev, crtc) rdev->asic->pflip.pre_page_flip((rdev), (crtc)) -#define radeon_page_flip(rdev, crtc, base) rdev->asic->pflip.page_flip((rdev), (crtc), (base)) -#define radeon_post_page_flip(rdev, crtc) rdev->asic->pflip.post_page_flip((rdev), (crtc)) -#define radeon_wait_for_vblank(rdev, crtc) rdev->asic->display.wait_for_vblank((rdev), (crtc)) -#define radeon_mc_wait_for_idle(rdev) rdev->asic->mc_wait_for_idle((rdev)) +#define radeon_pre_page_flip(rdev, crtc) (rdev)->asic->pflip.pre_page_flip((rdev), (crtc)) +#define radeon_page_flip(rdev, crtc, base) (rdev)->asic->pflip.page_flip((rdev), (crtc), (base)) +#define radeon_post_page_flip(rdev, crtc) (rdev)->asic->pflip.post_page_flip((rdev), (crtc)) +#define radeon_wait_for_vblank(rdev, crtc) (rdev)->asic->display.wait_for_vblank((rdev), (crtc)) +#define radeon_mc_wait_for_idle(rdev) (rdev)->asic->mc_wait_for_idle((rdev)) /* Common functions */ /* AGP */ -- 1.7.7.5
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 David L. changed: What|Removed |Added CC||equinox-freedesktopbugs at dia ||c24.net Summary|Radeon KMS on Macs with EFI |Radeon KMS fails with |boot|inaccessible AtomBIOS on ||systems with (U)EFI boot --- Comment #22 from David L. 2012-08-03 16:12:27 UTC --- Exact same issue appears on an HP EliteBook 8470p if you select "native UEFI" as boot method in setup. Legacy and hybrid boot options work fine. Changing bug title since this is not a Mac-specific issue, although it is more severe on Macs without the legacy/hybrid options easily accessible. It seems that the driver either cannot rely on the AtomBIOS being accessible, or we need to add code to enable the mapping with some PCI hacks? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote: > This is one of the things I wasn't so sure about. There are various > checks in intel_lvds_init() that can cause it to bail out before we try > to get the EDID, and I don't fully understand all of them. If non-laptop > machines are expected to bail out before the EDID check then the > approach I've taken seems reasonable. Otherwise adding a quirk probably > is a good idea. I know we've previously had problems with machines with phantom LVDS hardware, but I'm not sure what the current state of affairs is. -- Matthew Garrett | mjg59 at srcf.ucam.org
[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote: > Some Apple hybrid graphics machines do not have the LVDS panel connected > to the integrated GPU at boot and also do not supply a VBT. The LVDS > connector is not registered as a result, making it impossible to support > graphics switching. > > This patch changes intel_lvds_init() to register the connector even if > we can't find any panel modes. This makes it necessary to always check > intel_lvds->fixed_mode before use, as it could now be NULL. This one kind of sucks. I think adding a quirk for this situation would be justifiable, rather than doing it for all devices. -- Matthew Garrett | mjg59 at srcf.ucam.org
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #23 from Alex Deucher 2012-08-03 16:33:04 UTC --- On UEFI systems the vbios should be accessible via the ACPI VFCT. See the bottom of atombios.h for struct definitions. Macs do their own thing so I don't know if this will work on them or not. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #98 from Jerome Glisse 2012-08-03 16:54:04 UTC --- Created attachment 65095 --> https://bugs.freedesktop.org/attachment.cgi?id=65095 Properly protect virtual address Properly protect virtual address Patch against Linus master, gonna attach patch against 3.5 next. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Jerome Glisse changed: What|Removed |Added Attachment #65095|0 |1 is obsolete|| --- Comment #99 from Jerome Glisse 2012-08-03 16:56:00 UTC --- Created attachment 65096 --> https://bugs.freedesktop.org/attachment.cgi?id=65096 Properly protect virtual address Properly protect virtual address Patch against Linus master, gonna attach patch against 3.5 next. Sorry previous one was wrong one. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Jerome Glisse changed: What|Removed |Added Attachment #65096|0 |1 is obsolete|| --- Comment #100 from Jerome Glisse 2012-08-03 16:59:41 UTC --- Created attachment 65097 --> https://bugs.freedesktop.org/attachment.cgi?id=65097 Properly protect virtual address Properly protect virtual address Patch against Linus master, gonna attach patch against 3.5 next. Again, sorry previous one was wrong one. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #101 from Jerome Glisse 2012-08-03 17:05:15 UTC --- Created attachment 65098 --> https://bugs.freedesktop.org/attachment.cgi?id=65098 Properly protect virtual address against kernel 3.5 Same patch against 3.5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #24 from David L. 2012-08-03 17:12:52 UTC --- (In reply to comment #23) > On UEFI systems the vbios should be accessible via the ACPI VFCT. See the > bottom of atombios.h for struct definitions. Macs do their own thing so I > don't know if this will work on them or not. Should this already work on 3.4.7 and should I file a separate report about ACPI VFCT being broken or is that future tense/upcoming? Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just tried acpidump | grep VFCT, that should show something shouldn't it?) Will try under native UEFI in a minute... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #25 from Alex Deucher 2012-08-03 17:26:03 UTC --- (In reply to comment #24) > Should this already work on 3.4.7 and should I file a separate report about > ACPI VFCT being broken or is that future tense/upcoming? Support for fetching the vbios from VFCT still needs to be implemented. > > Also, in hybrid boot mode at least, acpidump gives me no hits for VFCT (just > tried acpidump | grep VFCT, that should show something shouldn't it?) Will try > under native UEFI in a minute... I'm not too familiar with ACPI and UEFI unfortunately. It's part of the GOP stuff for UEFI. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #15 from ojab 2012-08-03 17:37:58 UTC --- Still happens with libdrm/mesa/xf86-video-ati latest git. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
