[Bug 26345] [845G] CPU/GPU incoherency
https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #149 from slenkar 2012-09-03 02:14:44 UTC --- thanks chris how do I apply the patch? -- 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/exynos: Make g2d_pm_ops static
Applied. Thanks.
2012/8/29 Sachin Kamat :
> On 29 August 2012 12:32, Joonyoung Shim wrote:
>> On 08/28/2012 05:41 PM, Sachin Kamat wrote:
>>>
>>> Fixes the following warning:
>>> drivers/gpu/drm/exynos/exynos_drm_g2d.c:897:1: warning:
>>> symbol 'g2d_pm_ops' was not declared. Should it be static?
>>>
>>> Signed-off-by: Sachin Kamat
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>>> index 6adfa4e..1065e90 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
>>> @@ -894,7 +894,7 @@ static int g2d_resume(struct device *dev)
>>> }
>>> #endif
>>> -SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
>>> +static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
>>
>>
>> Right, it should be static but i don't get any warning message without
>> static.
>
> You will get it if you enable sparse checking while building the kernel.
>
>>
>> Thanks.
>>
>>
>>> struct platform_driver g2d_driver = {
>>> .probe = g2d_probe,
>>
>>
>
>
>
> --
> With warm regards,
> Sachin
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/exynos: Add missing braces around sizeof in exynos_hdmi.c
Applied. Thanks.
2012/8/31 Sachin Kamat :
> Fixes the following checkpatch warnings:
> WARNING: sizeof *res should be sizeof(*res)
> WARNING: sizeof res->regul_bulk[0] should be sizeof(res->regul_bulk[0])
> WARNING: sizeof *res should be sizeof(*res)
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 409e2ec..a4c6bbc 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2172,7 +2172,7 @@ static int __devinit hdmi_resources_init(struct
> hdmi_context *hdata)
>
> DRM_DEBUG_KMS("HDMI resource init\n");
>
> - memset(res, 0, sizeof *res);
> + memset(res, 0, sizeof(*res));
>
> /* get clocks, power */
> res->hdmi = clk_get(dev, "hdmi");
> @@ -2204,7 +2204,7 @@ static int __devinit hdmi_resources_init(struct
> hdmi_context *hdata)
> clk_set_parent(res->sclk_hdmi, res->sclk_pixel);
>
> res->regul_bulk = kzalloc(ARRAY_SIZE(supply) *
> - sizeof res->regul_bulk[0], GFP_KERNEL);
> + sizeof(res->regul_bulk[0]), GFP_KERNEL);
> if (!res->regul_bulk) {
> DRM_ERROR("failed to get memory for regulators\n");
> goto fail;
> @@ -2243,7 +2243,7 @@ static int hdmi_resources_cleanup(struct hdmi_context
> *hdata)
> clk_put(res->sclk_hdmi);
> if (!IS_ERR_OR_NULL(res->hdmi))
> clk_put(res->hdmi);
> - memset(res, 0, sizeof *res);
> + memset(res, 0, sizeof(*res));
>
> return 0;
> }
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/exynos: Add missing braces around sizeof in exynos_mixer.c
Applied. Thanks.
2012/8/31 Sachin Kamat :
> Fixes the following checkpatch warnings:
> WARNING: sizeof filter_y_horiz_tap8 should be sizeof(filter_y_horiz_tap8)
> WARNING: sizeof filter_y_vert_tap4 should be sizeof(filter_y_vert_tap4)
> WARNING: sizeof filter_cr_horiz_tap4 should be sizeof(filter_cr_horiz_tap4)
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 30fcc12..25b97d5 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -236,11 +236,11 @@ static inline void vp_filter_set(struct mixer_resources
> *res,
> static void vp_default_filter(struct mixer_resources *res)
> {
> vp_filter_set(res, VP_POLY8_Y0_LL,
> - filter_y_horiz_tap8, sizeof filter_y_horiz_tap8);
> + filter_y_horiz_tap8, sizeof(filter_y_horiz_tap8));
> vp_filter_set(res, VP_POLY4_Y0_LL,
> - filter_y_vert_tap4, sizeof filter_y_vert_tap4);
> + filter_y_vert_tap4, sizeof(filter_y_vert_tap4));
> vp_filter_set(res, VP_POLY4_C0_LL,
> - filter_cr_horiz_tap4, sizeof filter_cr_horiz_tap4);
> + filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
> }
>
> static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39222] VDPAU not working on RV710
https://bugs.freedesktop.org/show_bug.cgi?id=39222 --- Comment #16 from Micael Dias 2012-09-03 03:58:14 UTC --- (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > The xtended timing interface that mplayer2 uses > > > (vdp_presentation_queue_get_time) is currently not implemented. > > > > > > Honestly I have only tested it on mplayer, no guarantee that's working on > > > xine/mplayer2/... > > > > Right, I am using mplayer2, so that must be it. > > vdp_presentation_queue_get_time has been implemented in the meantime. > > Can we close this bug? Yes, no errors now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46931] Video output freezes with 'r600 startup failed on resume'
https://bugzilla.kernel.org/show_bug.cgi?id=46931 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher 2012-09-03 04:25:43 --- This is a GPU lockup. The kernel driver attempts to reset the GPU when that happens which is not always possible. You might try a newer mesa 3D driver as these are generally userspace acceleration driver issues rather than kernel issues. What application(s) causes the GPU lockup? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[GIT PULL] drm/exynos: updated exynos-drm-fixes
Hi Dave, this patch set fixes minor issues and also includes exception codes and code clean. Highlights: - fix modesetting - check pixel format specific to Exynos - hardware overlay disabling - plane's crtc updating - add exception codes and code clean The following changes since commit 350352dfef5028225b73994d304a38a4050d894b: Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux into drm-fixes (2012-09-03 11:29:56 +0900) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes if there is any problem, please let me know. Thanks, Inki Dae Inki Dae (11): drm/exynos: added device object to subdrv's remove callback as argument drm/exynos: separated subdrv_probe function into two parts. drm/exynos: fixed page align bug. drm/exynos: separeated fimd_power_on into some parts. drm/exynos: fixed duplicated mode setting. drm/exynos: add wait_for_vblank callback interface. drm/exynos: make sure that hardware overlay for fimd is disabled drm/exynos: make sure that hardware overlay for hdmi is disabled drm/exynos: check NV12M format specific to Exynos properly drm/exynos: update crtc to plane safely drm/exynos: Disable plane when released Sachin Kamat (9): drm/exynos: Remove redundant check in exynos_hdmi.c file drm/exynos: Remove redundant check in exynos_drm_fimd.c file drm/exynos: Use devm_kzalloc in exynos_drm_vidi.c file drm/exynos: Use devm_kzalloc in exynos_drm_hdmi.c file drm/exynos: Use devm_* functions in exynos_drm_g2d.c file drm/exynos: Add dependency for G2D in Kconfig drm/exynos: Make g2d_pm_ops static drm/exynos: Add missing braces around sizeof in exynos_hdmi.c drm/exynos: Add missing braces around sizeof in exynos_mixer.c Thomas Meyer (1): drm/exynos: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. [1] drivers/gpu/drm/exynos/Kconfig|2 +- drivers/gpu/drm/exynos/exynos_drm_connector.c | 41 +- drivers/gpu/drm/exynos/exynos_drm_connector.h |2 + drivers/gpu/drm/exynos/exynos_drm_core.c | 100 +++--- drivers/gpu/drm/exynos/exynos_drm_crtc.c |3 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 19 - drivers/gpu/drm/exynos/exynos_drm_encoder.c | 114 ++--- drivers/gpu/drm/exynos/exynos_drm_fb.c| 65 +- drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 ++--- drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 79 -- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 52 +++- drivers/gpu/drm/exynos/exynos_drm_gem.c |4 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 14 +++- drivers/gpu/drm/exynos/exynos_drm_hdmi.h |1 + drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 11 +-- drivers/gpu/drm/exynos/exynos_mixer.c | 19 - 19 files changed, 404 insertions(+), 153 deletions(-)
[GIT PULL] drm/exynos: updated exynos-drm-fixes
On Mon, Sep 3, 2012 at 2:47 PM, Inki Dae wrote: > Hi Dave, > > this patch set fixes minor issues and also includes exception codes > and code clean. > > Highlights: > - fix modesetting > - check pixel format specific to Exynos > - hardware overlay disabling > - plane's crtc updating > - add exception codes and code clean Hi Inki, This is getting a bit on the large size for this rc stage, maybe drop the code cleanups until -next, we should only be getting regression or major breakage fixes at this point. Dave.
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #20 from ojab 2012-09-03 05:58:48 UTC --- Still happens on OpenGL renderer string: Gallium 0.4 on AMD RS780 OpenGL version string: 2.1 Mesa 9.0-devel (git-a96119c) OpenGL shading language version string: 1.30 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[GIT PULL] drm/exynos: updated exynos-drm-fixes
2012/9/3 Dave Airlie : > On Mon, Sep 3, 2012 at 2:47 PM, Inki Dae wrote: >> Hi Dave, >> >> this patch set fixes minor issues and also includes exception codes >> and code clean. >> >> Highlights: >> - fix modesetting >> - check pixel format specific to Exynos >> - hardware overlay disabling >> - plane's crtc updating >> - add exception codes and code clean > > Hi Inki, > > This is getting a bit on the large size for this rc stage, maybe drop > the code cleanups until -next, > > we should only be getting regression or major breakage fixes at this point. > Hi Dave, got it. I will request pull again after merging them into exynos-drm-next. Thanks, Inki Dae > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54402] [r300g] st_glsl_to_tgsi.cpp:4006:dst_register: Assertion `index < VERT_RESULT_MAX' failed
https://bugs.freedesktop.org/show_bug.cgi?id=54402 Paul Menzel changed: What|Removed |Added CC||paulepanter at users.sourcefor ||ge.net --- Comment #1 from Paul Menzel 2012-09-03 06:52:13 UTC --- Trying the demo with $ midori --version Midori 0.4.6-585-gecfa79f and Debian Sid/unstable with the following packages libgl1-mesa-dri:i386 8.0.4-2 linux-image-3.2.0-3-686-pae 3.2.23-1 with 01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200] I can reproduce this crash. #0 0x9cd2e6c7 in dst_register (index=35, file=PROGRAM_OUTPUT, t=0xb9d4aef0) at state_tracker/st_glsl_to_tgsi.cpp:3989 3989state_tracker/st_glsl_to_tgsi.cpp: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x9cd2e6c7 in dst_register (index=35, file=PROGRAM_OUTPUT, t=0xb9d4aef0) at state_tracker/st_glsl_to_tgsi.cpp:3989 #1 translate_dst (saturate=false, dst_reg=0xba0cb12c, t=0xb9d4aef0) at state_tracker/st_glsl_to_tgsi.cpp:4066 #2 compile_tgsi_instruction (inst=0xba0cb120, t=0xb9d4aef0) at state_tracker/st_glsl_to_tgsi.cpp:4158 #3 st_translate_program (ctx=0xb9c62178, procType=procType at entry=1, ureg=ureg at entry=0xb96b00e0, program=0xa5dabd80, proginfo=proginfo at entry=0xba0e6860, numInputs=3, inputMapping=inputMapping at entry=0xba0f6af8, inputSemanticName=inputSemanticName at entry=0x0, inputSemanticIndex=inputSemanticIndex at entry=0x0, interpMode=interpMode at entry=0x0, numOutputs=17, outputMapping=outputMapping at entry=0xba0f6c00, outputSemanticName=outputSemanticName at entry=0xba0f6c8c "", outputSemanticIndex=outputSemanticIndex at entry=0xba0f6caf "", passthrough_edgeflags=0 '\000') at state_tracker/st_glsl_to_tgsi.cpp:4704 #4 0x9ccf8964 in st_translate_vertex_program (key=0xbf90d218, stvp=0xba0e6860, st=) at state_tracker/st_program.c:338 #5 st_get_vp_variant (st=st at entry=0xb9cb4d78, stvp=stvp at entry=0xba0e6860, key=key at entry=0xbf90d218) at state_tracker/st_program.c:426 #6 0x9cdc1a37 in update_vp (st=0xb9cb4d78) at state_tracker/st_atom_shader.c:144 #7 0x9cdbf116 in st_validate_state (st=st at entry=0xb9cb4d78) at state_tracker/st_atom.c:197 #8 0x9cdc5a58 in st_Clear (ctx=0xb9c62178, mask=272) at state_tracker/st_cb_clear.c:508 #9 0x9cd86c20 in _mesa_Clear (mask=16640) at main/clear.c:242 #10 0xb617ffa7 in WebCore::GraphicsContext3D::clear(unsigned int) () from /usr/lib/libwebkitgtk-1.0.so.0 #11 0xb615e1c7 in WebCore::WebGLRenderingContext::clearIfComposited(unsigned int) () from /usr/lib/libwebkitgtk-1.0.so.0 #12 0xb616a3e8 in WebCore::WebGLRenderingContext::clear(unsigned int) () from /usr/lib/libwebkitgtk-1.0.so.0 #13 0xb64aab2b in WebCore::jsWebGLRenderingContextPrototypeFunctionClear(JSC::ExecState*) () from /usr/lib/libwebkitgtk-1.0.so.0 #14 0xa868ef69 in ?? () #15 0xb52ac74a in JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) () from /usr/lib/libjavascriptcoregtk-1.0.so.0 #16 0xb537b692 in JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) () from /usr/lib/libjavascriptcoregtk-1.0.so.0 #17 0xb6b8a744 in WebCore::JSInspectorFrontendHost::port(JSC::ExecState*)::port () from /usr/lib/libwebkitgtk-1.0.so.0 ---Type to continue, or q to quit--- #18 0xb580f097 in WebCore::ScheduledAction::executeFunctionInContext(JSC::JSGlobalObject*, JSC::JSValue, WebCore::ScriptExecutionContext*) () from /usr/lib/libwebkitgtk-1.0.so.0 #19 0xa9331090 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Please tell me if you need more information and if that is the same problem or if I should submit a separate report. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39222] VDPAU not working on RV710
https://bugs.freedesktop.org/show_bug.cgi?id=39222 Andreas Boll changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Intel-gfx] [PATCH] drm/i915: add a tracepoint for gpu frequency changes
On Sat, Sep 01, 2012 at 06:36:32PM -0700, Ben Widawsky wrote: > On 2012-09-01 12:14, Daniel Vetter wrote: > >On Sat, Sep 1, 2012 at 8:35 PM, Ben Widawsky > >wrote: > >>On 2012-09-01 11:28, Arjan van de Ven wrote: > >>> > >>>On 9/1/2012 11:26 AM, Ben Widawsky wrote: > > On 2012-08-30 04:26, Daniel Vetter wrote: > > > >We've had and still have too many issues where the gpu > >turbot doesn't > >quite to what it's supposed to do (or what we want it to do). > > > >Adding a tracepoint to track when the desired gpu > >frequence changes > >should help a lot in characterizing and understanding problematic > >workloads. > > > >Also, this should be fairly interesting for power tuning (and > >especially noticing when the gpu is stuck in high > >frequencies, as has > >happened in the past) and hence for integration into powertop and > >similar tools. > > > >Cc: Arjan van de Ven > >Signed-off-by: Daniel Vetter > > > I can't help but think it's equally interesting to know when > the queue > the work as well. > > > >>> > >>>btw... if the userspace interface (e.g. the actual event) is not > >>>controversial and very unlikely to change, > >>>I'd like to start coding the powertop support for this already > >> > >> > >>I have no problem with Daniel's patch. It's just a matter of > >>cutting through > >>some scheduler BS of "when the GPU wants to change frequency" > >>vs. "when we > >>actually change the GPU frequency." I think *both* are interesting. > > > >Hm, aren't there some neat tracepoints to measure the latency of work > >items around already? I agree that this might be useful, but just > >adding a tracepoint for this one workqueue item feels like overkill > > It depends on what you're trying to measure. I think this patch is > quite useful but I think I'll make you defend your patch now since > you're the maintainer and you took your own patch and you're > shooting down my idea. So please tell me what PowerTOP should do > with this patch other than notice we're stuck (and furthermore, even > if we're stuck, what should it tell us to do)? Actually it shouldn't only notice that we're stuck but e.g. also notice that a blinking cursor keeps us at high gpu clock (which together with the low rc6 residency should explain the power usage in these scenarios). Or maybe integrate it into a graphical overview (but to make that useful we first need to figure out how to add precise tracepoints for batch_begin/end) so that interactions between gpu/cpu stand out more. > As you may recall we can get multiple up and down interrupts, and we > coalesce them and only do one thing. Information is lost there that > could have been useful; caveat to that - I haven't looked at the > code in a while, but that's what we used to do. What I mean though > is, if we get an up then down interrupt, in that order, it will go > out as a trace event that we're raising the GPU frequency (again, > previous caveat applies). So I think this event + the current GPU > frequency is more interesting than just when we change the > frequency; however all 3 would be even better for finding driver > bugs. The added tracepoints gives us an event when we actually change the hw state - which is imo the important thing to measure for performance tuning and diagnosing issues. Figuring out _why_ things are amiss is then the usual gfx driver debug madness, and I think adding a bunch of tracepoints specifically just for that feels like overwill. > More on tracing at the interrupt time: I think getting this info to > userspace is somewhat less useful than tying it into some kind of > CPU governor hooks. For example, if we get multiple consecutive RP > down interrupts, we can probably add it to a list of reasons we > might want to lower the CPU frequency, and the contrapositive is > also true. I didn't add the tracepoint at irq time, but only where we change the gpu clock. And the tracepoint dumps the new gpu clock freq we've just set, so no way to get out of sync with down/up irqs, either. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Intel-gfx] [PATCH] drm/i915: add a tracepoint for gpu frequency changes
On Sat, Sep 01, 2012 at 07:44:17PM -0700, Arjan van de Ven wrote: > On 9/1/2012 6:36 PM, Ben Widawsky wrote: > > > It depends on what you're trying to measure. I think this patch is quite > > useful but I think I'll make you defend your patch now since you're the > > maintainer and you took > > your own patch and you're shooting down my idea. So please tell me what > > PowerTOP should do with this patch other than notice we're stuck (and > > furthermore, even if we're > > stuck, what should it tell us to do)? > > what I would like to do, as the powertop guy is to show frequency stats > similar to how we do that > for CPUs. E.g. as close as to actual as we can get. > few questions: > 1) Can I read the momentary frequency somewhere? > (it's great to get change events, but I also need a start frequency, > otherwise I have a gap in > knowledge from start of measurement to first change event) Oops, forgotten about this, but it looks like Ben has already volunteered himself for those ;-) > 2) Can I read a "hardware average" somewhere, similar to what we can do for > cpus ? Afaik, there's nothing. But since the cpu controls the gpu freq completely, you can just compute those yourselves from the tracepoints. Together with the rc6 residency timers we already expose this should give a neat overview of how busy the gpu is and how much power it blows through -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Bug 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Andreas Boll 2012-09-03 08:43:11 UTC --- (In reply to comment #7) > It seem to be fixed by kernel 3.0. Closing 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.
[Bug 46931] Video output freezes with 'r600 startup failed on resume'
https://bugzilla.kernel.org/show_bug.cgi?id=46931 --- Comment #3 from Carlos Olmedo 2012-09-03 09:43:58 --- The last time i was running Speed Dreams 2.0.0+r4687. I will try a newer mesa driver as soon as i can. PD: I guess this is not related, but my HDMI output is not working anymore (even on BIOS). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #21 from Michel D?nzer 2012-09-03 09:47:07 UTC --- (In reply to comment #20) > Still happens on Please stop spamming this report with 'still happens' comments. It's safe to assume that the problem is still there while there are no updates. Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 54402] st_glsl_to_tgsi.cpp:4006:dst_register: Assertion `index < VERT_RESULT_MAX' failed
https://bugs.freedesktop.org/show_bug.cgi?id=54402 Michel D?nzer changed: What|Removed |Added AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Summary|[r300g] |st_glsl_to_tgsi.cpp:4006:ds |st_glsl_to_tgsi.cpp:4006:ds |t_register: Assertion |t_register: Assertion |`index < VERT_RESULT_MAX' |`index < VERT_RESULT_MAX' |failed |failed | Component|Drivers/DRI/r300|Mesa core -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31533] Black lines while scrolling on HD5850
https://bugs.freedesktop.org/show_bug.cgi?id=31533 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Andreas Boll 2012-09-03 10:16:58 UTC --- (In reply to comment #4) > (In reply to comment #2) > > Is this still an issue with the latest code in xf86-video-ati git master? > > It's no longer an issue since the 6 commits of 2012-04-16. Closing 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.
[Bug 43871] shader with uniform array/record and if clauses is not translated correctly into TGSI IR
https://bugs.freedesktop.org/show_bug.cgi?id=43871 Andreas Boll changed: What|Removed |Added AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core --- Comment #1 from Andreas Boll 2012-09-03 10:56:04 UTC --- (In reply to comment #0) > using mesa from git, swrast, and setting glsl supported version to 130 in > st_extensions.c ; glsl_compiler --dump-lir seems correct, so it might be an > issue with glsl-to-tgsi. Reassigning to mesa-core since the issue could be in glsl-to-tgsi. In the meantime GLSL 1.30 has been enabled by default on r600g. Is this still an issue with current mesa from git? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53261] [i915g] Performance regression in git
https://bugs.freedesktop.org/show_bug.cgi?id=53261 jano.vesely at gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from jano.vesely at gmail.com 2012-09-03 11:08:25 UTC --- Ignore this one, the drop is caused by compiling without llvm. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 52313] r600g: Linux 3.3.x broken since 30257c32
https://bugs.freedesktop.org/show_bug.cgi?id=52313 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andreas Boll 2012-09-03 11:23:46 UTC --- (In reply to comment #1) > Fixed in mesa master Marking this bug as fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[GIT PULL] drm/exynos: updated exynos-drm-fixes
Hi Dave, this patch set fixes build warnings and includes minor code cleanup. other patches posted before will go to -next because they include big changes. Highlights: - fix build warnings - minor code cleanup if there is any problem, please let me know. Thanks. Inki Dae The following changes since commit 350352dfef5028225b73994d304a38a4050d894b: Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux into drm-fixes (2012-09-03 11:29:56 +0900) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes Inki Dae (2): drm/exynos: added device object to subdrv's remove callback as argument drm/exynos: fixed page align bug. Sachin Kamat (9): drm/exynos: Remove redundant check in exynos_hdmi.c file drm/exynos: Remove redundant check in exynos_drm_fimd.c file drm/exynos: Use devm_kzalloc in exynos_drm_vidi.c file drm/exynos: Use devm_kzalloc in exynos_drm_hdmi.c file drm/exynos: Use devm_* functions in exynos_drm_g2d.c file drm/exynos: Add dependency for G2D in Kconfig drm/exynos: Make g2d_pm_ops static drm/exynos: Add missing braces around sizeof in exynos_hdmi.c drm/exynos: Add missing braces around sizeof in exynos_mixer.c Thomas Meyer (1): drm/exynos: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. [1] drivers/gpu/drm/exynos/Kconfig |2 +- drivers/gpu/drm/exynos/exynos_drm_drv.h |2 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c |7 +--- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 52 ++--- drivers/gpu/drm/exynos/exynos_drm_gem.c |4 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c |3 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +-- drivers/gpu/drm/exynos/exynos_hdmi.c | 11 ++ drivers/gpu/drm/exynos/exynos_mixer.c|6 ++-- 9 files changed, 25 insertions(+), 68 deletions(-)
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #11 from Andreas Boll 2012-09-03 12:22:38 UTC --- I think this issue has been fixed with the new libdrm surface allocator, since the commit below removes the code in question. commit 581f7e3101980a4e1068bb75c2eca60bb2071229 Author: Marek Ol??k Date: Sun Jul 29 18:53:19 2012 +0200 r600g: drop the old texture allocation code Made obsolete by the libdrm surface allocator. Could you confirm that this issue is resolved on mesa git master or mesa git 9.0 branch? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 --- Comment #1 from Michel D?nzer 2012-09-03 14:04:11 --- (In reply to comment #0) > This started happening in 3.6-rc1 and is still in rc2. It does happen on 3.5.1 > and 3.5.2 if the radeon module is manually loaded a second time after boot. So, do I understand this correctly: With 3.5.x it only happens after the radeon kernel module was loaded a second time, but with 3.6-rc* it even happens after it was loaded for the first time? If so, can you bisect what introduced the change in behaviour for 3.6-rc*? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/radeon: rework pll selection (v3)
From: Alex Deucher
For DP we can use the same PPLL for all active DP
encoders. Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work. Also clean up the code
a bit.
v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
- document functions
- break in main encoder search loop after matching.
no need to keep checking additional encoders.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 163 +---
1 files changed, 129 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 2817101..e721e30 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1479,14 +1479,98 @@ static void radeon_legacy_atom_fixup(struct drm_crtc
*crtc)
}
}
+/**
+ * radeon_get_pll_use_mask - look up a mask of which pplls are in use
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the mask of which PPLLs (Pixel PLLs) are in use.
+ */
+static u32 radeon_get_pll_use_mask(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_crtc *test_crtc;
+ struct radeon_crtc *radeon_test_crtc;
+ u32 pll_in_use = 0;
+
+ list_for_each_entry(test_crtc, &dev->mode_config.crtc_list, head) {
+ if (crtc == test_crtc)
+ continue;
+
+ radeon_test_crtc = to_radeon_crtc(test_crtc);
+ if (radeon_test_crtc->pll_id != ATOM_PPLL_INVALID)
+ pll_in_use |= (1 << radeon_test_crtc->pll_id);
+ }
+ return pll_in_use;
+}
+
+/**
+ * radeon_get_shared_dp_ppll - return the PPLL used by another crtc for DP
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the PPLL (Pixel PLL) used by another crtc/encoder which is
+ * also in DP mode. For DP, a single PPLL can be used for all DP
+ * crtcs/encoders.
+ */
+static int radeon_get_shared_dp_ppll(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_encoder *test_encoder;
+ struct radeon_crtc *radeon_test_crtc;
+
+ list_for_each_entry(test_encoder, &dev->mode_config.encoder_list, head)
{
+ if (test_encoder->crtc && (test_encoder->crtc != crtc)) {
+ if
(ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_encoder))) {
+ /* for DP use the same PLL for all */
+ radeon_test_crtc =
to_radeon_crtc(test_encoder->crtc);
+ if (radeon_test_crtc->pll_id !=
ATOM_PPLL_INVALID)
+ return radeon_test_crtc->pll_id;
+ }
+ }
+ }
+ return ATOM_PPLL_INVALID;
+}
+
+/**
+ * radeon_atom_pick_pll - Allocate a PPLL for use by the crtc.
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the PPLL (Pixel PLL) to be used by the crtc. For DP monitors
+ * a single PPLL can be used for all DP crtcs/encoders. For non-DP
+ * monitors a dedicated PPLL must be used. If a particular board has
+ * an external DP PLL, return ATOM_PPLL_INVALID to skip PLL programming
+ * as there is no need to program the PLL itself. If we are not able to
+ * allocate a PLL, return ATOM_PPLL_INVALID to skip PLL programming to
+ * avoid messing up an existing monitor.
+ *
+ * Asic specific PLL information
+ *
+ * DCE 6.1
+ * - PPLL2 is only available to UNIPHYA (both DP and non-DP)
+ * - PPLL0, PPLL1 are available for UNIPHYB/C/D/E/F (both DP and non-DP)
+ *
+ * DCE 6.0
+ * - PPLL0 is available to all UNIPHY (DP only)
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ * DCE 5.0
+ * - DCPLL is available to all UNIPHY (DP only)
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ * DCE 3.0/4.0/4.1
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ */
static int radeon_atom_pick_pll(struct drm_crtc *crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
struct drm_encoder *test_encoder;
- struct drm_crtc *test_crtc;
- uint32_t pll_in_use = 0;
+ u32 pll_in_use;
+ int pll;
if (ASIC_IS_DCE61(rdev)) {
list_for_each_entry(test_encoder,
&dev->mode_config.encoder_list, head) {
@@ -1498,32 +1582,40 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
if ((test_radeon_encoder->encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_UNIPHY) &&
- (dig->linkb == false)) /* UNIPHY A uses
PPLL2 */
+ (dig->linkb == false))
+ /* UNIPHY A uses PPLL2 */
return ATOM_PPLL2;
+
[Bug 54129] [bisected] Kernel 3.5.0 breaks KMS on Radeon RV250
https://bugs.freedesktop.org/show_bug.cgi?id=54129 Simon Kitching changed: What|Removed |Added CC||skitching at apache.org --- Comment #6 from Simon Kitching 2012-09-03 15:17:38 UTC --- I also had graphics corruption with a Radeon Mobility X1600 (RV350), and bisected to exactly the same two patches: bb63556 -- hangs on start of Plymouth 3b7a2b2 -- plymouth works again, but graphics corrupted. The symptoms were somewhat different than described here: I got shimmery 70s paisley patterns rather than "black rectangles". The problem continues up to 3.5.3. However 3.6.0-rc4 fixes the issue - graphics appear to work fine again. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 54129] [bisected] Kernel 3.5.0 breaks KMS on Radeon RV250
https://bugs.freedesktop.org/show_bug.cgi?id=54129 --- Comment #7 from Alex Deucher 2012-09-03 15:22:43 UTC --- (In reply to comment #6) > The problem continues up to 3.5.3. > However 3.6.0-rc4 fixes the issue - graphics appear to work fine again. Can you bisect to see what commit fixed 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.
[PATCH V6] drm: edid: add support for E-DDC
Hello Dave,
My patch-set for adding support for 4 block EDID is now reviewed and ready.
Please let me know if you want any further clarification
Regards,
Shirish S
On Thu, Aug 30, 2012 at 12:04 AM, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
>
> Signed-off-by: Shirish S
> Reviewed-by: Jean Delvare
> Reviewed-by: Daniel Vetter
> Reviewed-by: Ville Syrjala
> ---
> drivers/gpu/drm/drm_edid.c | 19 ---
> 1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bcc4725..7f62de5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> int block, int len)
> {
> unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned char xfers = segment ? 3 : 2;
> int ret, retries = 5;
>
> /* The core i2c driver will automatically retry the transfer if the
> @@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> do {
> struct i2c_msg msgs[] = {
> {
> + .addr = DDC_SEGMENT_ADDR,
> + .flags = 0,
> + .len= 1,
> + .buf= &segment,
> + }, {
> .addr = DDC_ADDR,
> .flags = 0,
> .len= 1,
> @@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> .buf= buf,
> }
> };
> - ret = i2c_transfer(adapter, msgs, 2);
> +
> + /*
> +* Avoid sending the segment addr to not upset non-compliant ddc
> +* monitors.
> +*/
> + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
> +
> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> adapter->name);
> break;
> }
> - } while (ret != 2 && --retries);
> + } while (ret != xfers && --retries);
>
> - return ret == 2 ? 0 : -1;
> + return ret == xfers ? 0 : -1;
> }
>
> static bool drm_edid_is_zero(u8 *in_edid, int length)
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120903/20bf1807/attachment.html>
[Bug 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 --- Comment #2 from bjackson0971 at gmail.com 2012-09-03 19:37:57 --- You are correct. I just tested 3.4.3 that I still had built and there is no error with repeated modprobes. I'm trying 3.4.10 to see if the problem started in 3.4. If it started in 3.5, I will do a few test builds of 3.5-RCx to find when it started. Then I can maybe try manually reverting any patches that looks like good candidates before I start a small bisect. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/i915: Optimize DIV_ROUND_CLOSEST call
From: Jean Delvare
Subject: drm/i915: Optimize DIV_ROUND_CLOSEST call
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends.
Signed-off-by: Jean Delvare
Cc: Guenter Roeck
Cc: Andrew Morton
Cc: Daniel Vetter
Cc: David Airlie
---
Daniel, I think we can safely assume ia_freq can't be negative?
drivers/gpu/drm/i915/intel_pm.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-3.6-rc3.orig/drivers/gpu/drm/i915/intel_pm.c 2012-08-28
14:46:22.0 +0200
+++ linux-3.6-rc3/drivers/gpu/drm/i915/intel_pm.c 2012-09-01
21:17:32.074619227 +0200
@@ -2499,7 +2499,8 @@ static void gen6_update_ring_freq(struct
{
struct drm_i915_private *dev_priv = dev->dev_private;
int min_freq = 15;
- int gpu_freq, ia_freq, max_ia_freq;
+ int gpu_freq;
+ unsigned int ia_freq, max_ia_freq;
int scaling_factor = 180;
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
--
Jean Delvare
[Bug 54129] [bisected] Kernel 3.5.0 breaks KMS on Radeon RV250
https://bugs.freedesktop.org/show_bug.cgi?id=54129 --- Comment #8 from Andrea 2012-09-03 20:19:45 UTC --- (In reply to comment #6) > I also had graphics corruption with a Radeon Mobility X1600 (RV350), and > bisected to exactly the same two patches: > bb63556 -- hangs on start of Plymouth > 3b7a2b2 -- plymouth works again, but graphics corrupted. > > The symptoms were somewhat different than described here: I got shimmery 70s > paisley patterns rather than "black rectangles". > > > The problem continues up to 3.5.3. > However 3.6.0-rc4 fixes the issue - graphics appear to work fine again. Not here. I've just tried 3.6-rc4 and I get the same corruptions. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 --- Comment #3 from bjackson0971 at gmail.com 2012-09-03 21:58:07 --- I had to bisect between 3.4.0 and 3.5-rc1 and this was the result. 416a2bd274566a6f607a271f524b2dc0b84d9106 is the first bad commit commit 416a2bd274566a6f607a271f524b2dc0b84d9106 Author: Alex Deucher Date: Thu May 31 19:00:25 2012 -0400 drm/radeon: fixup tiling group size and backendmap on r6xx-r9xx (v4) Tiling group size is always 256bits on r6xx/r7xx/r8xx/9xx. Also fix and simplify render backend map. This now properly sets up the backend map on r6xx-9xx which should improve 3D performance. Vadim benchmarked also: Some benchmarks on juniper (5750), fullscreen 1920x1080, first result - kernel 3.4.0+ (fb21affa), second - with these patches: Lightsmark: 91 fps => 123 fps+35% Doom3:74 fps => 101 fps+36% Signed-off-by: Alex Deucher Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie :04 04 897f0745cc0845c549d44d172c2949cc92b4777c 4c08505d2b214813be5c65e4b87bb809ff027ce2 Mdrivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 --- Comment #4 from bjackson0971 at gmail.com 2012-09-03 22:26:31 --- I tried backing the patch out of 3.6-rc4 (got minor offset and fuzz warnings) and the problem is gone there too. If a developer needs help narrowing down a fix to a specific file or line of code, I can do test builds if I can get patches to apply. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 39222] VDPAU not working on RV710
https://bugs.freedesktop.org/show_bug.cgi?id=39222 Andreas Boll changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- 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: [Intel-gfx] [PATCH] drm/i915: add a tracepoint for gpu frequency changes
On Sat, Sep 01, 2012 at 06:36:32PM -0700, Ben Widawsky wrote: > On 2012-09-01 12:14, Daniel Vetter wrote: > >On Sat, Sep 1, 2012 at 8:35 PM, Ben Widawsky > >wrote: > >>On 2012-09-01 11:28, Arjan van de Ven wrote: > >>> > >>>On 9/1/2012 11:26 AM, Ben Widawsky wrote: > > On 2012-08-30 04:26, Daniel Vetter wrote: > > > >We've had and still have too many issues where the gpu > >turbot doesn't > >quite to what it's supposed to do (or what we want it to do). > > > >Adding a tracepoint to track when the desired gpu > >frequence changes > >should help a lot in characterizing and understanding problematic > >workloads. > > > >Also, this should be fairly interesting for power tuning (and > >especially noticing when the gpu is stuck in high > >frequencies, as has > >happened in the past) and hence for integration into powertop and > >similar tools. > > > >Cc: Arjan van de Ven > >Signed-off-by: Daniel Vetter > > > I can't help but think it's equally interesting to know when > the queue > the work as well. > > > >>> > >>>btw... if the userspace interface (e.g. the actual event) is not > >>>controversial and very unlikely to change, > >>>I'd like to start coding the powertop support for this already > >> > >> > >>I have no problem with Daniel's patch. It's just a matter of > >>cutting through > >>some scheduler BS of "when the GPU wants to change frequency" > >>vs. "when we > >>actually change the GPU frequency." I think *both* are interesting. > > > >Hm, aren't there some neat tracepoints to measure the latency of work > >items around already? I agree that this might be useful, but just > >adding a tracepoint for this one workqueue item feels like overkill > > It depends on what you're trying to measure. I think this patch is > quite useful but I think I'll make you defend your patch now since > you're the maintainer and you took your own patch and you're > shooting down my idea. So please tell me what PowerTOP should do > with this patch other than notice we're stuck (and furthermore, even > if we're stuck, what should it tell us to do)? Actually it shouldn't only notice that we're stuck but e.g. also notice that a blinking cursor keeps us at high gpu clock (which together with the low rc6 residency should explain the power usage in these scenarios). Or maybe integrate it into a graphical overview (but to make that useful we first need to figure out how to add precise tracepoints for batch_begin/end) so that interactions between gpu/cpu stand out more. > As you may recall we can get multiple up and down interrupts, and we > coalesce them and only do one thing. Information is lost there that > could have been useful; caveat to that - I haven't looked at the > code in a while, but that's what we used to do. What I mean though > is, if we get an up then down interrupt, in that order, it will go > out as a trace event that we're raising the GPU frequency (again, > previous caveat applies). So I think this event + the current GPU > frequency is more interesting than just when we change the > frequency; however all 3 would be even better for finding driver > bugs. The added tracepoints gives us an event when we actually change the hw state - which is imo the important thing to measure for performance tuning and diagnosing issues. Figuring out _why_ things are amiss is then the usual gfx driver debug madness, and I think adding a bunch of tracepoints specifically just for that feels like overwill. > More on tracing at the interrupt time: I think getting this info to > userspace is somewhat less useful than tying it into some kind of > CPU governor hooks. For example, if we get multiple consecutive RP > down interrupts, we can probably add it to a list of reasons we > might want to lower the CPU frequency, and the contrapositive is > also true. I didn't add the tracepoint at irq time, but only where we change the gpu clock. And the tracepoint dumps the new gpu clock freq we've just set, so no way to get out of sync with down/up irqs, either. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: add a tracepoint for gpu frequency changes
On Sat, Sep 01, 2012 at 07:44:17PM -0700, Arjan van de Ven wrote: > On 9/1/2012 6:36 PM, Ben Widawsky wrote: > > > It depends on what you're trying to measure. I think this patch is quite > > useful but I think I'll make you defend your patch now since you're the > > maintainer and you took > > your own patch and you're shooting down my idea. So please tell me what > > PowerTOP should do with this patch other than notice we're stuck (and > > furthermore, even if we're > > stuck, what should it tell us to do)? > > what I would like to do, as the powertop guy is to show frequency stats > similar to how we do that > for CPUs. E.g. as close as to actual as we can get. > few questions: > 1) Can I read the momentary frequency somewhere? > (it's great to get change events, but I also need a start frequency, > otherwise I have a gap in > knowledge from start of measurement to first change event) Oops, forgotten about this, but it looks like Ben has already volunteered himself for those ;-) > 2) Can I read a "hardware average" somewhere, similar to what we can do for > cpus ? Afaik, there's nothing. But since the cpu controls the gpu freq completely, you can just compute those yourselves from the tracepoints. Together with the rc6 residency timers we already expose this should give a neat overview of how busy the gpu is and how much power it blows through -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Andreas Boll 2012-09-03 08:43:11 UTC --- (In reply to comment #7) > It seem to be fixed by kernel 3.0. Closing 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
[Bug 46931] Video output freezes with 'r600 startup failed on resume'
https://bugzilla.kernel.org/show_bug.cgi?id=46931 --- Comment #3 from Carlos Olmedo 2012-09-03 09:43:58 --- The last time i was running Speed Dreams 2.0.0+r4687. I will try a newer mesa driver as soon as i can. PD: I guess this is not related, but my HDMI output is not working anymore (even on BIOS). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of 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 #21 from Michel Dänzer 2012-09-03 09:47:07 UTC --- (In reply to comment #20) > Still happens on Please stop spamming this report with 'still happens' comments. It's safe to assume that the problem is still there while there are no updates. 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 54402] st_glsl_to_tgsi.cpp:4006:dst_register: Assertion `index < VERT_RESULT_MAX' failed
https://bugs.freedesktop.org/show_bug.cgi?id=54402 Michel Dänzer changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Summary|[r300g] |st_glsl_to_tgsi.cpp:4006:ds |st_glsl_to_tgsi.cpp:4006:ds |t_register: Assertion |t_register: Assertion |`index < VERT_RESULT_MAX' |`index < VERT_RESULT_MAX' |failed |failed | Component|Drivers/DRI/r300|Mesa core -- 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 31533] Black lines while scrolling on HD5850
https://bugs.freedesktop.org/show_bug.cgi?id=31533 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Andreas Boll 2012-09-03 10:16:58 UTC --- (In reply to comment #4) > (In reply to comment #2) > > Is this still an issue with the latest code in xf86-video-ati git master? > > It's no longer an issue since the 6 commits of 2012-04-16. Closing 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
[Bug 43871] shader with uniform array/record and if clauses is not translated correctly into TGSI IR
https://bugs.freedesktop.org/show_bug.cgi?id=43871 Andreas Boll changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core --- Comment #1 from Andreas Boll 2012-09-03 10:56:04 UTC --- (In reply to comment #0) > using mesa from git, swrast, and setting glsl supported version to 130 in > st_extensions.c ; glsl_compiler --dump-lir seems correct, so it might be an > issue with glsl-to-tgsi. Reassigning to mesa-core since the issue could be in glsl-to-tgsi. In the meantime GLSL 1.30 has been enabled by default on r600g. Is this still an issue with current mesa from 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 53261] [i915g] Performance regression in git
https://bugs.freedesktop.org/show_bug.cgi?id=53261 jano.ves...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from jano.ves...@gmail.com 2012-09-03 11:08:25 UTC --- Ignore this one, the drop is caused by compiling without llvm. -- 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 52313] r600g: Linux 3.3.x broken since 30257c32
https://bugs.freedesktop.org/show_bug.cgi?id=52313 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andreas Boll 2012-09-03 11:23:46 UTC --- (In reply to comment #1) > Fixed in mesa master Marking this bug as fixed. -- 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
[GIT PULL] drm/exynos: updated exynos-drm-fixes
Hi Dave, this patch set fixes build warnings and includes minor code cleanup. other patches posted before will go to -next because they include big changes. Highlights: - fix build warnings - minor code cleanup if there is any problem, please let me know. Thanks. Inki Dae The following changes since commit 350352dfef5028225b73994d304a38a4050d894b: Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux into drm-fixes (2012-09-03 11:29:56 +0900) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes Inki Dae (2): drm/exynos: added device object to subdrv's remove callback as argument drm/exynos: fixed page align bug. Sachin Kamat (9): drm/exynos: Remove redundant check in exynos_hdmi.c file drm/exynos: Remove redundant check in exynos_drm_fimd.c file drm/exynos: Use devm_kzalloc in exynos_drm_vidi.c file drm/exynos: Use devm_kzalloc in exynos_drm_hdmi.c file drm/exynos: Use devm_* functions in exynos_drm_g2d.c file drm/exynos: Add dependency for G2D in Kconfig drm/exynos: Make g2d_pm_ops static drm/exynos: Add missing braces around sizeof in exynos_hdmi.c drm/exynos: Add missing braces around sizeof in exynos_mixer.c Thomas Meyer (1): drm/exynos: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(.. [1] drivers/gpu/drm/exynos/Kconfig |2 +- drivers/gpu/drm/exynos/exynos_drm_drv.h |2 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c |7 +--- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 52 ++--- drivers/gpu/drm/exynos/exynos_drm_gem.c |4 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c |3 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +-- drivers/gpu/drm/exynos/exynos_hdmi.c | 11 ++ drivers/gpu/drm/exynos/exynos_mixer.c|6 ++-- 9 files changed, 25 insertions(+), 68 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43405] Only horizontal lines (snow) display in google earth/glxgears using current r600g on RS780M
https://bugs.freedesktop.org/show_bug.cgi?id=43405 --- Comment #11 from Andreas Boll 2012-09-03 12:22:38 UTC --- I think this issue has been fixed with the new libdrm surface allocator, since the commit below removes the code in question. commit 581f7e3101980a4e1068bb75c2eca60bb2071229 Author: Marek Olšák Date: Sun Jul 29 18:53:19 2012 +0200 r600g: drop the old texture allocation code Made obsolete by the libdrm surface allocator. Could you confirm that this issue is resolved on mesa git master or mesa git 9.0 branch? -- 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 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 --- Comment #1 from Michel Dänzer 2012-09-03 14:04:11 --- (In reply to comment #0) > This started happening in 3.6-rc1 and is still in rc2. It does happen on 3.5.1 > and 3.5.2 if the radeon module is manually loaded a second time after boot. So, do I understand this correctly: With 3.5.x it only happens after the radeon kernel module was loaded a second time, but with 3.6-rc* it even happens after it was loaded for the first time? If so, can you bisect what introduced the change in behaviour for 3.6-rc*? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: rework pll selection (v3)
From: Alex Deucher
For DP we can use the same PPLL for all active DP
encoders. Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work. Also clean up the code
a bit.
v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
- document functions
- break in main encoder search loop after matching.
no need to keep checking additional encoders.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 163 +---
1 files changed, 129 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 2817101..e721e30 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1479,14 +1479,98 @@ static void radeon_legacy_atom_fixup(struct drm_crtc
*crtc)
}
}
+/**
+ * radeon_get_pll_use_mask - look up a mask of which pplls are in use
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the mask of which PPLLs (Pixel PLLs) are in use.
+ */
+static u32 radeon_get_pll_use_mask(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_crtc *test_crtc;
+ struct radeon_crtc *radeon_test_crtc;
+ u32 pll_in_use = 0;
+
+ list_for_each_entry(test_crtc, &dev->mode_config.crtc_list, head) {
+ if (crtc == test_crtc)
+ continue;
+
+ radeon_test_crtc = to_radeon_crtc(test_crtc);
+ if (radeon_test_crtc->pll_id != ATOM_PPLL_INVALID)
+ pll_in_use |= (1 << radeon_test_crtc->pll_id);
+ }
+ return pll_in_use;
+}
+
+/**
+ * radeon_get_shared_dp_ppll - return the PPLL used by another crtc for DP
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the PPLL (Pixel PLL) used by another crtc/encoder which is
+ * also in DP mode. For DP, a single PPLL can be used for all DP
+ * crtcs/encoders.
+ */
+static int radeon_get_shared_dp_ppll(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_encoder *test_encoder;
+ struct radeon_crtc *radeon_test_crtc;
+
+ list_for_each_entry(test_encoder, &dev->mode_config.encoder_list, head)
{
+ if (test_encoder->crtc && (test_encoder->crtc != crtc)) {
+ if
(ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_encoder))) {
+ /* for DP use the same PLL for all */
+ radeon_test_crtc =
to_radeon_crtc(test_encoder->crtc);
+ if (radeon_test_crtc->pll_id !=
ATOM_PPLL_INVALID)
+ return radeon_test_crtc->pll_id;
+ }
+ }
+ }
+ return ATOM_PPLL_INVALID;
+}
+
+/**
+ * radeon_atom_pick_pll - Allocate a PPLL for use by the crtc.
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the PPLL (Pixel PLL) to be used by the crtc. For DP monitors
+ * a single PPLL can be used for all DP crtcs/encoders. For non-DP
+ * monitors a dedicated PPLL must be used. If a particular board has
+ * an external DP PLL, return ATOM_PPLL_INVALID to skip PLL programming
+ * as there is no need to program the PLL itself. If we are not able to
+ * allocate a PLL, return ATOM_PPLL_INVALID to skip PLL programming to
+ * avoid messing up an existing monitor.
+ *
+ * Asic specific PLL information
+ *
+ * DCE 6.1
+ * - PPLL2 is only available to UNIPHYA (both DP and non-DP)
+ * - PPLL0, PPLL1 are available for UNIPHYB/C/D/E/F (both DP and non-DP)
+ *
+ * DCE 6.0
+ * - PPLL0 is available to all UNIPHY (DP only)
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ * DCE 5.0
+ * - DCPLL is available to all UNIPHY (DP only)
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ * DCE 3.0/4.0/4.1
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ */
static int radeon_atom_pick_pll(struct drm_crtc *crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
struct drm_encoder *test_encoder;
- struct drm_crtc *test_crtc;
- uint32_t pll_in_use = 0;
+ u32 pll_in_use;
+ int pll;
if (ASIC_IS_DCE61(rdev)) {
list_for_each_entry(test_encoder,
&dev->mode_config.encoder_list, head) {
@@ -1498,32 +1582,40 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
if ((test_radeon_encoder->encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_UNIPHY) &&
- (dig->linkb == false)) /* UNIPHY A uses
PPLL2 */
+ (dig->linkb == false))
+ /* UNIPHY A uses PPLL2 */
return ATOM_PPLL2;
+
[Bug 54129] [bisected] Kernel 3.5.0 breaks KMS on Radeon RV250
https://bugs.freedesktop.org/show_bug.cgi?id=54129 Simon Kitching changed: What|Removed |Added CC||skitch...@apache.org --- Comment #6 from Simon Kitching 2012-09-03 15:17:38 UTC --- I also had graphics corruption with a Radeon Mobility X1600 (RV350), and bisected to exactly the same two patches: bb63556 -- hangs on start of Plymouth 3b7a2b2 -- plymouth works again, but graphics corrupted. The symptoms were somewhat different than described here: I got shimmery 70s paisley patterns rather than "black rectangles". The problem continues up to 3.5.3. However 3.6.0-rc4 fixes the issue - graphics appear to work fine again. -- 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 54129] [bisected] Kernel 3.5.0 breaks KMS on Radeon RV250
https://bugs.freedesktop.org/show_bug.cgi?id=54129 --- Comment #7 from Alex Deucher 2012-09-03 15:22:43 UTC --- (In reply to comment #6) > The problem continues up to 3.5.3. > However 3.6.0-rc4 fixes the issue - graphics appear to work fine again. Can you bisect to see what commit fixed 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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V6] drm: edid: add support for E-DDC
Hello Dave,
My patch-set for adding support for 4 block EDID is now reviewed and ready.
Please let me know if you want any further clarification
Regards,
Shirish S
On Thu, Aug 30, 2012 at 12:04 AM, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
>
> Signed-off-by: Shirish S
> Reviewed-by: Jean Delvare
> Reviewed-by: Daniel Vetter
> Reviewed-by: Ville Syrjala
> ---
> drivers/gpu/drm/drm_edid.c | 19 ---
> 1 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index bcc4725..7f62de5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> int block, int len)
> {
> unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned char xfers = segment ? 3 : 2;
> int ret, retries = 5;
>
> /* The core i2c driver will automatically retry the transfer if the
> @@ -265,6 +267,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> do {
> struct i2c_msg msgs[] = {
> {
> + .addr = DDC_SEGMENT_ADDR,
> + .flags = 0,
> + .len= 1,
> + .buf= &segment,
> + }, {
> .addr = DDC_ADDR,
> .flags = 0,
> .len= 1,
> @@ -276,15 +283,21 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> .buf= buf,
> }
> };
> - ret = i2c_transfer(adapter, msgs, 2);
> +
> + /*
> +* Avoid sending the segment addr to not upset non-compliant ddc
> +* monitors.
> +*/
> + ret = i2c_transfer(adapter, &msgs[3 - xfers], xfers);
> +
> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> adapter->name);
> break;
> }
> - } while (ret != 2 && --retries);
> + } while (ret != xfers && --retries);
>
> - return ret == 2 ? 0 : -1;
> + return ret == xfers ? 0 : -1;
> }
>
> static bool drm_edid_is_zero(u8 *in_edid, int length)
> --
> 1.7.0.4
>
> ___
> 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 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 --- Comment #2 from bjackson0...@gmail.com 2012-09-03 19:37:57 --- You are correct. I just tested 3.4.3 that I still had built and there is no error with repeated modprobes. I'm trying 3.4.10 to see if the problem started in 3.4. If it started in 3.5, I will do a few test builds of 3.5-RCx to find when it started. Then I can maybe try manually reverting any patches that looks like good candidates before I start a small bisect. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Optimize DIV_ROUND_CLOSEST call
From: Jean Delvare
Subject: drm/i915: Optimize DIV_ROUND_CLOSEST call
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be
dealing with unsigned dividends.
Signed-off-by: Jean Delvare
Cc: Guenter Roeck
Cc: Andrew Morton
Cc: Daniel Vetter
Cc: David Airlie
---
Daniel, I think we can safely assume ia_freq can't be negative?
drivers/gpu/drm/i915/intel_pm.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-3.6-rc3.orig/drivers/gpu/drm/i915/intel_pm.c 2012-08-28
14:46:22.0 +0200
+++ linux-3.6-rc3/drivers/gpu/drm/i915/intel_pm.c 2012-09-01
21:17:32.074619227 +0200
@@ -2499,7 +2499,8 @@ static void gen6_update_ring_freq(struct
{
struct drm_i915_private *dev_priv = dev->dev_private;
int min_freq = 15;
- int gpu_freq, ia_freq, max_ia_freq;
+ int gpu_freq;
+ unsigned int ia_freq, max_ia_freq;
int scaling_factor = 180;
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
--
Jean Delvare
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54129] [bisected] Kernel 3.5.0 breaks KMS on Radeon RV250
https://bugs.freedesktop.org/show_bug.cgi?id=54129 --- Comment #8 from Andrea 2012-09-03 20:19:45 UTC --- (In reply to comment #6) > I also had graphics corruption with a Radeon Mobility X1600 (RV350), and > bisected to exactly the same two patches: > bb63556 -- hangs on start of Plymouth > 3b7a2b2 -- plymouth works again, but graphics corrupted. > > The symptoms were somewhat different than described here: I got shimmery 70s > paisley patterns rather than "black rectangles". > > > The problem continues up to 3.5.3. > However 3.6.0-rc4 fixes the issue - graphics appear to work fine again. Not here. I've just tried 3.6-rc4 and I get the same corruptions. -- 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 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 --- Comment #3 from bjackson0...@gmail.com 2012-09-03 21:58:07 --- I had to bisect between 3.4.0 and 3.5-rc1 and this was the result. 416a2bd274566a6f607a271f524b2dc0b84d9106 is the first bad commit commit 416a2bd274566a6f607a271f524b2dc0b84d9106 Author: Alex Deucher Date: Thu May 31 19:00:25 2012 -0400 drm/radeon: fixup tiling group size and backendmap on r6xx-r9xx (v4) Tiling group size is always 256bits on r6xx/r7xx/r8xx/9xx. Also fix and simplify render backend map. This now properly sets up the backend map on r6xx-9xx which should improve 3D performance. Vadim benchmarked also: Some benchmarks on juniper (5750), fullscreen 1920x1080, first result - kernel 3.4.0+ (fb21affa), second - with these patches: Lightsmark: 91 fps => 123 fps+35% Doom3:74 fps => 101 fps+36% Signed-off-by: Alex Deucher Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie :04 04 897f0745cc0845c549d44d172c2949cc92b4777c 4c08505d2b214813be5c65e4b87bb809ff027ce2 Mdrivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46161] divide error on radeon modprobe
https://bugzilla.kernel.org/show_bug.cgi?id=46161 --- Comment #4 from bjackson0...@gmail.com 2012-09-03 22:26:31 --- I tried backing the patch out of 3.6-rc4 (got minor offset and fuzz warnings) and the problem is gone there too. If a developer needs help narrowing down a fix to a specific file or line of code, I can do test builds if I can get patches to apply. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54338] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
https://bugs.freedesktop.org/show_bug.cgi?id=54338 --- Comment #3 from Alex Deucher 2012-09-04 03:45:58 UTC --- (In reply to comment #2) > No, I'm just trying various kernel versions to get my card working. However, I > just tried Fedora 17 live CD (kernel 3.3) and there radeon module loaded > normally. Can you attach the dmesg from the working boot? > > So, I have to compare two linux kernel versions — 3.3 and 3.5.3 ? you might want to test 3.4 or even some early 3.5 kernels to see if you can narrow it down further. At that point you can use git to bisect and find what commit broke things. -- 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 43209] PAE and radeon integrated rs690 (x1200) prevents dri
https://bugzilla.kernel.org/show_bug.cgi?id=43209 Luis Montes changed: What|Removed |Added CC||lam...@gmail.com --- Comment #2 from Luis Montes 2012-09-04 04:35:19 --- Same here, on a 3.2.0-29-generic-pae kernel with a PCIe radeon: VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Turks [Radeon HD 6570] I get: [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD) radeon :01:00.0: disabling GPU acceleration I don't get acceleration, but other than that, the system works reasonably well, so that might be the reason some people don't see the problem? There was a similar report on the lkml about a year ago, but I tried a similar patch to that described in there and it caused a panic. https://lkml.org/lkml/2011/6/3/277 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
