[PATCH] drm/msm/dsi: fix definition of msm_dsi_pll_28nm_8960_init()
On 04/02/16 05:09, Archit Taneja wrote:
>
>
> On 02/03/2016 07:55 PM, Luis Henriques wrote:
>> This fixes the following build failure:
>>
>> drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o: In function
>> `msm_dsi_pll_28nm_8960_init':
>> dsi_pll_28nm.c:(.text+0x1198): multiple definition of
>> `msm_dsi_pll_28nm_8960_init'
>> drivers/gpu/drm/msm/dsi/pll/dsi_pll.o:dsi_pll.c:(.text+0x0): first
>> defined here
>
> Thanks for the fix.
>
> Acked-by: Archit Taneja
>
> Dave,
>
> Could you please queue this for the next -rc cycle since it causes a
> build break?
>
I've just hit this build break on v4.5-rc7 ... was there any progress
getting this fix in ? I can't see any further reference to this thread
on LKML.
Just to note, changing to a static generates a build-warning for me:
CC drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o
In file included from
sources/linux/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c:17:0:
sources/linux/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h:100:28: warning:
âmsm_dsi_pll_28nm_8960_initâ defined but not used [-Wunused-function]
static struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
platform_device *pdev,
^
--
Kieran
> Thanks,
> Archit
>
>>
>> Signed-off-by: Luis Henriques
>> ---
>> drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
>> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
>> index 80b6038334a6..2cf1664723e8 100644
>> --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
>> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
>> @@ -97,8 +97,8 @@ static inline struct msm_dsi_pll
>> *msm_dsi_pll_28nm_init(
>> struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
>> platform_device *pdev,
>> int id);
>> #else
>> -struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct platform_device
>> *pdev,
>> - int id)
>> +static inline struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(
>> +struct platform_device *pdev, int id)
>> {
>> return ERR_PTR(-ENODEV);
>> }
>>
>
[PATCH] drm/msm/dsi: fix definition of msm_dsi_pll_28nm_8960_init()
On Sun, Mar 13, 2016 at 5:12 PM, Kieran Bingham
wrote:
> On 04/02/16 05:09, Archit Taneja wrote:
>>
>>
>> On 02/03/2016 07:55 PM, Luis Henriques wrote:
>>> This fixes the following build failure:
>>>
>>> drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o: In function
>>> `msm_dsi_pll_28nm_8960_init':
>>> dsi_pll_28nm.c:(.text+0x1198): multiple definition of
>>> `msm_dsi_pll_28nm_8960_init'
>>> drivers/gpu/drm/msm/dsi/pll/dsi_pll.o:dsi_pll.c:(.text+0x0): first
>>> defined here
>>
>> Thanks for the fix.
>>
>> Acked-by: Archit Taneja
>>
>> Dave,
>>
>> Could you please queue this for the next -rc cycle since it causes a
>> build break?
>>
>
> I've just hit this build break on v4.5-rc7 ... was there any progress
> getting this fix in ? I can't see any further reference to this thread
> on LKML.
>
> Just to note, changing to a static generates a build-warning for me:
>
> CC drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.o
> In file included from
> sources/linux/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c:17:0:
> sources/linux/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h:100:28: warning:
> âmsm_dsi_pll_28nm_8960_initâ defined but not used [-Wunused-function]
> static struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
> platform_device *pdev,
> ^
oh, the patch to change it to static inline was in my pull req for
4.6, but perhaps this should have been sent as a -fixes pull for 4.5?
Dave, if you are sending another -fixes pull for 4.5 could you include
this?
Not sure about the warning (I don't see that, but I have static-inline
vs static)
BR,
-R
> --
> Kieran
>
>> Thanks,
>> Archit
>>
>>>
>>> Signed-off-by: Luis Henriques
>>> ---
>>> drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
>>> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
>>> index 80b6038334a6..2cf1664723e8 100644
>>> --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
>>> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
>>> @@ -97,8 +97,8 @@ static inline struct msm_dsi_pll
>>> *msm_dsi_pll_28nm_init(
>>> struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct
>>> platform_device *pdev,
>>> int id);
>>> #else
>>> -struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(struct platform_device
>>> *pdev,
>>> - int id)
>>> +static inline struct msm_dsi_pll *msm_dsi_pll_28nm_8960_init(
>>> +struct platform_device *pdev, int id)
>>> {
>>> return ERR_PTR(-ENODEV);
>>> }
>>>
>>
>
[Bug 94525] OpenCL memory allocation is limited to 1GB
https://bugs.freedesktop.org/show_bug.cgi?id=94525 Bug ID: 94525 Summary: OpenCL memory allocation is limited to 1GB Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: b.bellec at gmail.com QA Contact: dri-devel at lists.freedesktop.org I wanted to try "ethminer" (the OpenCL Ethereum miner) on Mesa. I installed Ubuntu 15.10 (x86-64), the "ethminer" client, and the Oibaf PPA Mesa packages. The OpenCL's Mesa detects only 1GB on my Radeon R9 390 8GB. So I can't even start "ethminer" since it currently requires 1.4 GB. Moreover, the two others R9 Nano plugged in the computer are not even detected by "ethminer" nor "clinfo". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160313/9252e810/attachment.html>
[Intel-gfx] [PATCH 1/2] drm/i915: Call intel_dp_mst_resume() before resuming displays
On Fri, Mar 11, 2016 at 10:57:01AM -0500, Lyude wrote:
> Since we need MST devices ready before we try to resume displays,
> calling this after intel_display_resume() can result in some issues with
> various laptop docks where the monitor won't turn back on after
> suspending the system.
>
> This order was originally changed in
>
> commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
>
> In order to fix some unclaimed register errors, however the actual cause
> of those has since been fixed.
>
> CC: stable at vger.kernel.org
> Signed-off-by: Lyude
Don't we need to first apply patch 2/2 to avoid breaking systems
in-between?
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f357058..08854ae 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -761,12 +761,12 @@ static int i915_drm_resume(struct drm_device *dev)
> dev_priv->display.hpd_irq_setup(dev);
> spin_unlock_irq(_priv->irq_lock);
>
> + intel_dp_mst_resume(dev);
> +
> drm_modeset_lock_all(dev);
> intel_display_resume(dev);
> drm_modeset_unlock_all(dev);
>
> - intel_dp_mst_resume(dev);
> -
> /*
>* ... but also need to make sure that hotplug processing
>* doesn't cause havoc. Like in the driver load code we don't
> --
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 2/2] drm/i915: Retry after 30ms if we fail to resume DP MST
On Fri, Mar 11, 2016 at 10:57:02AM -0500, Lyude wrote:
> For whatever reason, I've found that some laptops aren't immediately
> capable of doing aux transactions with their docks when they come out of
> standby. While I'm still not entirely sure what the cause of this is,
> sleeping for 30ms and then retrying drm_dp_mst_topology_mgr_resume()
> should be a sufficient enough workaround until we find a real fix.
>
> CC: stable at vger.kernel.org
> Signed-off-by: Lyude
> ---
> drivers/gpu/drm/i915/intel_dp.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1d8de43..8cc5f6f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6114,6 +6114,19 @@ void intel_dp_mst_resume(struct drm_device *dev)
>
> ret =
> drm_dp_mst_topology_mgr_resume(_dig_port->dp.mst_mgr);
> if (ret != 0) {
> + /*
> + * For some reason, some laptops can't bring
> + * their MST docks back up immediately after
> + * resume and need to wait a short period of
> + * time before aux transactions with the dock
> + * become functional again. Until we find a
> + * proper fix for this, this workaround should
> + * suffice
> + */
> + msleep(30);
> + ret =
> drm_dp_mst_topology_mgr_resume(_dig_port->dp.mst_mgr);
> + }
Hm, since it's the dp aux that fails (and not something higher up
apparently) shouldnt' we have this massive retry somewhere in the dp aux
helpers maybe? DP resume in general is a bit fragile, maybe we're just
missing a lot of retries in general?
Either way this needs a lot more details. Comment definitely should start
out with FIXME, and the commit message should have a protocol of all the
experiments you've done thus far. Yes this means a ridiculously long
commit message, but in roughly 2 weeks someone else will go wtf on this,
and then they must be able to read up the full story. And we need links to
bugzillas and mail threads, too.
And please Cc: Art with this one too.
Thanks, Daniel
> + if (ret != 0) {
> intel_dp_check_mst_status(_dig_port->dp);
> }
> }
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm: atomic helper: do not unreference error pointer
On Fri, Mar 11, 2016 at 12:17:26PM +, Lionel Landwerlin wrote:
> 562c5b4d8986 didn't quite fix the issue of dealing with an error
> pointer. We can't free/unref an error pointer so reset it to NULL.
>
> Many thanks to Dan Carpenter for pointing this out again.
>
> Signed-off-by: Lionel Landwerlin
> Cc: Dan Carpenter
> Cc: Daniel Stone
> Cc: Daniel Vetter
> Cc: Matt Roper
> Cc: dri-devel at lists.freedesktop.org
> Fixes: 562c5b4d8986 ("drm: fix blob pointer check")
Applied to drm-misc. Also I guess I've run out of my quota of silly stuff
I merge pretty fast ... ;-)
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 892de99..2bb90fa 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2926,6 +2926,7 @@ void drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> NULL);
> if (IS_ERR(blob)) {
> ret = PTR_ERR(blob);
> + blob = NULL;
> goto fail;
> }
>
> --
> 2.7.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/edid: Extract SADs properly from multiple audio data blocks
On Fri, Mar 11, 2016 at 04:24:35PM +0200, Jani Nikula wrote:
> On Fri, 11 Mar 2016, Ville Syrjälä wrote:
> > [ text/plain ]
> > On Fri, Mar 11, 2016 at 03:36:48PM +0200, Jani Nikula wrote:
> >> On Wed, 09 Mar 2016, ville.syrjala at linux.intel.com wrote:
> >> > From: Ville Syrjälä
> >> >
> >> > SADs may span multiple CEA audio data blocks in the EDID.
> >> >
> >> > CEA-861-E says:
> >> > "The order of the Data Blocks is not constrained. It is also possible
> >> > to have more than one of a specific type of data block if necessary to
> >> > include all of the descriptors needed to describe the sinkâs
> >> > capabilities."
> >> >
> >> > Each audio data block can carry up to 10 SADs, whereas the ELD SAD limit
> >> > is 15 according to HDA 1.0a spec. So we should support at least two data
> >> > blocks. And apparently some devices take a more liberal interpretation
> >> > and stuff only one SAD per data block even when they would fit into one.
> >> >
> >> > So let's try to extract all the SADs we can fit into the ELD even when
> >> > they span multiple data blocks.
> >> >
> >> > While at it, toss in a comment to explain the 13 byte monitor name
> >> > string limit which confused me at first.
> >> >
> >> > Cc: Arturo Pérez
> >> > Tested-by: Arturo Pérez
> >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197
> >> > Signed-off-by: Ville Syrjälä
> >> > ---
> >> > drivers/gpu/drm/drm_edid.c | 17 +++--
> >> > 1 file changed, 11 insertions(+), 6 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> > index fdb1eb014586..414d7f61aa05 100644
> >> > --- a/drivers/gpu/drm/drm_edid.c
> >> > +++ b/drivers/gpu/drm/drm_edid.c
> >> > @@ -3308,7 +3308,7 @@ void drm_edid_to_eld(struct drm_connector
> >> > *connector, struct edid *edid)
> >> > u8 *cea;
> >> > u8 *name;
> >> > u8 *db;
> >> > -int sad_count = 0;
> >> > +int total_sad_count = 0;
> >> > int mnl;
> >> > int dbl;
> >> >
> >> > @@ -3322,6 +3322,7 @@ void drm_edid_to_eld(struct drm_connector
> >> > *connector, struct edid *edid)
> >> >
> >> > name = NULL;
> >> > drm_for_each_detailed_block((u8 *)edid, monitor_name, );
> >> > +/* max: 13 bytes EDID, 16 bytes ELD */
> >> > for (mnl = 0; name && mnl < 13; mnl++) {
> >> > if (name[mnl] == 0x0a)
> >> > break;
> >> > @@ -3350,11 +3351,15 @@ void drm_edid_to_eld(struct drm_connector
> >> > *connector, struct edid *edid)
> >> > dbl = cea_db_payload_len(db);
> >> >
> >> > switch (cea_db_tag(db)) {
> >> > +int sad_count;
> >> > +
> >> > case AUDIO_BLOCK:
> >> > /* Audio Data Block, contains SADs */
> >> > -sad_count = dbl / 3;
> >> > -if (dbl >= 1)
> >> > -memcpy(eld + 20 + mnl, [1],
> >> > dbl);
> >> > +sad_count = min(dbl / 3, 15 -
> >> > total_sad_count);
> >>
> >> What if total_sad_count > 15? At a glance, this seems to self correct by
> >> subtracting the excess every second time... ;)
> >
> > Since sad_count will not exceed 15-total_sad_count, total_sad_count will
> > never
> > exceed 15.
>
> Right. I guess it could be spelled out for folks like me. :/
>
> Reviewed-by: Jani Nikula
>
> If you run out of things to do (that'll be the day), you could follow up
> with replacing some of the magic here for offsets etc. with the
> DRM_ELD_* defines I added in drm_edid.h.
Applied to drm-misc but not yet pushed since I want to roll forward to
latest drm-next as soon as Dave has merged everything.
-Daniel
>
> BR,
> Jani.
>
>
> >
> >>
> >> BR,
> >> Jani.
> >>
> >> > +if (sad_count >= 1)
> >> > +memcpy(eld + 20 + mnl +
> >> > total_sad_count * 3,
> >> > + [1], sad_count * 3);
> >> > +total_sad_count += sad_count;
> >> > break;
> >> > case SPEAKER_BLOCK:
> >> > /* Speaker Allocation Data Block */
> >> > @@ -3371,13 +3376,13 @@ void drm_edid_to_eld(struct drm_connector
> >> > *connector, struct edid *edid)
> >> > }
> >> > }
> >> > }
> >> > -eld[5] |= sad_count << 4;
> >> > +eld[5] |= total_sad_count << 4;
> >> >
> >> > eld[DRM_ELD_BASELINE_ELD_LEN] =
> >> > DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
> >> >
> >> > DRM_DEBUG_KMS("ELD size %d, SAD count %d\n",
> >> > - drm_eld_size(eld), sad_count);
> >> > + drm_eld_size(eld),
[Bug 94284] [radeonsi] outlast segfault on start
https://bugs.freedesktop.org/show_bug.cgi?id=94284 --- Comment #6 from EoD --- (In reply to Nicolai H�hnle from comment #5) > Fixed by commit 28d2a7e67 "radeonsi: avoid crash when a sampler state is > bound for a buffer texture" The commit fixes my apitrace ARK-replay of bug 94326, though ARK still crashes now with: Mesa: User error: GL_OUT_OF_MEMORY in glMapBufferRange(map failed) Assertion failed: Data != NULL [File:Runtime/OpenGLDrv/Public/OpenGLResources.h] [Line: 231] Signal 11 caught. Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. LowLevelFatalError [File:C:\SVN_Ark\Engine\Source\Runtime\Core\Private\GenericPlatform\GenericPlatformMemory.cpp] [Line: 51] Ran out of memory allocating 65536 bytes with alignment 0 Using binned. 4.5.1-0+UE4 7038 3077 402 5 Is this related? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160313/873b2b33/attachment.html>
[Bug 113861] [radeon] Xorg fatal freeze upon startx
https://bugzilla.kernel.org/show_bug.cgi?id=113861 martin.hamrle at gmail.com changed: What|Removed |Added CC||martin.hamrle at gmail.com --- Comment #12 from martin.hamrle at gmail.com --- I had the same issue and latest torvalds master (that contains reverted patch) fixed my problem. -- You are receiving this mail because: You are watching the assignee of the bug.
[patch] drm/vc4: Return -EFAULT on copy_from_user() failure
Dan Carpenter writes:
> The copy_from_user() function returns the number of bytes not copied but
> we want to return a negative error code.
>
> Fixes: 463873d57014 ('drm/vc4: Add an API for creating GPU shaders in GEM
> BOs.')
> Signed-off-by: Dan Carpenter
Pulled. Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160313/f86fdc9c/attachment.sig>
[PATCH] drm/vc4: improve throughput by pipelining binning and rendering jobs
Varad Gautam writes: > Hi Eric, > > On Sat, Mar 5, 2016 at 7:17 AM, Eric Anholt wrote: > > Varad Gautam writes: > > > >> The hardware provides us with separate threads for binning and > >> rendering, and the existing model waits for them both to complete > >> before submitting the next job. > >> > >> Splitting the binning and rendering submissions reduces idle time > >> and gives us approx 20-30% speedup with several x11perf tests. > > > > This patch is: > > > > Reviewed-by: Eric Anholt > > > Which tests did you find improved, specifically? I'm seeing > openarena > > improved by 1.01897% +/- 0.247857% (n=16). x11perf -aa24text and > > -copypixwin looked like they had about the same level of improvement. > > Here's a sample of the speedups I've noticed with x11perf: > > without queue with queue% delta test > -(reps/sec)- -(reps/sec)- --- --- > 184236 28.26% 10x10 tiled rectangle (17x15 tile) > 192244 27.08% 10x10 tiled rectangle (4x4 tile) > 134162 20.90% 10x10 tiled rectangle (216x208 > tile) > 9901190 20.20% 10-pixel line > 131157 19.85% 10x10 tiled rectangle (161x145 > tile) > 280327 16.79% 10x10 rectangle > 272314 15.44% 100-pixel vertical line segment > 876000 101 15.30% 100-pixel line segment (2 kids) > 199000 22900015.08% Circulate Unmapped window (200 > kids) > 119135 13.45% 100-pixel line segment (1 kid) > 176000 19900013.07% 500-pixel line segment > 172000 19400012.79% 500-pixel line > 116000 12900011.21% Destroy window via parent (100 > kids) > 203225 10.84% 100-pixel horizontal line segment > 635000 697000 9.76% 100-pixel line segment (3 kids) Some of these results seem to be spurious (ucirculate, for example). However, -line10 and -tilerect10 seem to be good. Pulled for -next. Thanks! -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160313/e4cee195/attachment.sig>
[Intel-gfx] Possible 4.5 i915 Skylake regression
On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter wrote: > On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote: >> On Tue, Feb 16, 2016 at 9:12 AM, Andy Lutomirski >> wrote: >> > On Tue, Feb 16, 2016 at 8:12 AM, Daniel Vetter wrote: >> >> On Mon, Feb 15, 2016 at 06:58:33AM -0800, Andy Lutomirski wrote: >> >>> On Sun, Feb 14, 2016 at 6:59 PM, Andy Lutomirski >> >>> wrote: >> >>> > Hi- >> >>> > >> >>> > On 4.5-rc3 on a Dell XPS 13 9350 (Skylake i915, no nvidia on this >> >>> > model), shortly after resume, I saw a single black flash on the >> >>> > screen. The log said: >> >>> > >> >>> > [Feb13 07:05] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* >> >>> > CPU pipe A FIFO underrun >> >>> > >> >>> > I haven't seen this on 4.4. >> >>> > >> >>> > I'd be happy to dig up debugging info, but I don't know what would be >> >>> > useful. I have no i915 module options set. >> >>> >> >>> It's flashing quite frequently now, although I seem to get the >> >>> underrun warning only once per resume. >> >> >> >> We shut up the warning irq source to avoid hijacking an entire cpu core >> >> ;-) >> >> >> >> There's a fix from Matt right after 4.5-rc4 in Linus' branch. I'm hoping >> >> that should help. >> > >> > Do you mean: >> > >> > commit e2e407dc093f530b771ee8bf8fe1be41e3cea8b3 >> > Author: Matt Roper >> > Date: Mon Feb 8 11:05:28 2016 -0800 >> > >> > drm/i915: Pretend cursor is always on for ILK-style WM calculations >> > (v2) >> > >> > If so, it didn't help. I'm currently doing a full rebuild just in >> > case I messed something up, though. >> > >> >> Definitely not fixed. It seems to be okay after a reboot until the >> first suspend/resume. >> >> This happened after resuming. Five cents says it's the root cause. > > That's interesting, but doesn't ring a bell unfortunately. Can you try to > attempt a bisect? > I'm giving up on my attempt to bisect for now. After a bunch of false starts to avoid this crap, I'm stuck at 651174a4a0ccaf41e14fadc4bc525d61ae7f7b18, which is based on 4.3-rc3 and doesn't merge cleanly up to 4.4. It's also annoying because it reproduces reasonably quickly but not instantaneously, and I can never reproduce it before a suspend/resume, so my bisection attempts are full of errors. --Andy > Thanks, Daniel > >> >> [ 160.361200] WARNING: CPU: 2 PID: 2512 at >> drivers/gpu/drm/i915/intel_uncore.c:599 >> hsw_unclaimed_reg_debug+0x69/0x90 [i915]() >> [ 160.361209] Unclaimed register detected before writing to register 0x20a8 >> [ 160.361213] Modules linked in: rfcomm fuse ccm cmac xt_CHECKSUM >> ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns >> nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 >> xt_conntrack ebtable_filter ebtable_nat ebtable_broute bridge stp llc >> ebtables ip6table_raw ip6table_mangle ip6table_security ip6table_nat >> nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_filter >> ip6_tables iptable_raw iptable_mangle iptable_security iptable_nat >> nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bnep >> arc4 iwlmvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek >> hid_multitouch snd_hda_codec_generic iwlwifi snd_hda_intel intel_rapl >> snd_hda_codec x86_pkg_temp_thermal coretemp kvm_intel snd_hwdep >> cfg80211 snd_hda_core kvm snd_seq uvcvideo snd_seq_device >> i2c_designware_platform >> [ 160.361385] i2c_designware_core btusb snd_pcm videobuf2_vmalloc >> wmi_mof vfat dell_wmi fat videobuf2_memops btrtl btbcm btintel >> bluetooth dell_laptop dell_smbios dcdbas videobuf2_v4l2 snd_timer >> videobuf2_core rtsx_pci_ms snd irqbypass videodev memstick >> ghash_clmulni_intel joydev mei_me efi_pstore mei i2c_i801 soundcore >> efivars pcspkr idma64 shpchp virt_dma media rfkill intel_lpss_pci >> processor_thermal_device intel_soc_dts_iosf wmi acpi_als kfifo_buf >> int3403_thermal tpm_tis industrialio pinctrl_sunrisepoint tpm >> intel_hid int3400_thermal pinctrl_intel intel_lpss_acpi sparse_keymap >> int340x_thermal_zone acpi_thermal_rel intel_lpss nfsd acpi_pad >> auth_rpcgss nfs_acl lockd binfmt_misc grace sunrpc dm_crypt i915 >> i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt >> fb_sys_fops drm rtsx_pci_sdmmc >> [ 160.361548] mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel >> rtsx_pci serio_raw i2c_hid video >> [ 160.361575] CPU: 2 PID: 2512 Comm: gnome-shell Not tainted >> 4.5.0-rc4-acpi+ #59 >> [ 160.361581] Hardware name: Dell Inc. XPS 13 9350/07TYC2, BIOS 1.1.9 >> 12/18/2015 >> [ 160.361588] 0086 604232f7 88024d55ba60 >> 81449d83 >> [ 160.361601] 88024d55baa8 a01e15e8 88024d55ba98 >> 81094252 >> [ 160.361612] 88026f4d 20a8 88026f4d >> fefe >> [ 160.361624] Call Trace: >> [ 160.361644] [] dump_stack+0x65/0x92 >> [ 160.361660] [] warn_slowpath_common+0x82/0xc0 >> [ 160.361671] [] warn_slowpath_fmt+0x5c/0x80 >> [ 160.361764] [] hsw_unclaimed_reg_debug+0x69/0x90
[GIT PULL] exynos-drm-next for 4.6
Hi Dave, This pull request adds DRM_EXYNOS_GEM_MAP ioctl interface for the use of render node. This interface had been tried to mainline but tackled by Daniel Stone because there was no non-libdrm user, http://www.spinics.net/lists/dri-devel/msg93243.html We have already added the non-libdrm user support like below, https://review.tizen.org/git/?p=platform/adaptation/samsung_exynos/libtbm-exynos.git;a=commit;h=773b66e9f51db46745508c739c71b3f8a4e35a30 And that has been tested enough. For more information about libtbm, this module is a buffer manager for Tizen platform. All applications - who want to use dma buffer - use this module to allocate dma buffer through DRM GEM. Kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 550e3b23a53c88adfa46e64f9d442743e65d47da: Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux into drm-next (2016-03-08 10:51:51 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git exynos-drm-next for you to fetch changes up to 6564c65f3a2b75832957e53bcc3c6066d1d73487: drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl (2016-03-13 14:54:03 +0900) Joonyoung Shim (1): drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl drivers/gpu/drm/exynos/exynos_drm_drv.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_gem.c |9 + drivers/gpu/drm/exynos/exynos_drm_gem.h |4 include/uapi/drm/exynos_drm.h | 17 - 4 files changed, 31 insertions(+), 1 deletion(-)
[Bug 94284] [radeonsi] outlast segfault on start
https://bugs.freedesktop.org/show_bug.cgi?id=94284 Nicolai H�hnle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nicolai H�hnle --- Fixed by commit 28d2a7e67 "radeonsi: avoid crash when a sampler state is bound for a buffer texture" -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160313/014cf608/attachment.html>
[Bug 94511] rv730 agp reproducable uvd gpu hangs in fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=94511
--- Comment #9 from Roman Elshin ---
bool uvd_v2_2_semaphore_emit(struct radeon_device *rdev,
struct radeon_ring *ring,
struct radeon_semaphore *semaphore,
bool emit_wait)
{
return false;
}
Same things.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160313/a8497b48/attachment.html>
[Bug 94511] rv730 agp reproducable uvd gpu hangs in fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=94511 --- Comment #8 from Christian K�nig --- A complete shoot in the dark, but please try to disable semaphores by just returning false from uvd_v2_2_semaphore_emit() in drivers/gpu/drm/radeon/uvd_v2_2.c. Otherwise I'm running out of ideas what that could be. The only other explanation I have is that the added load of UVD+displaying at a certain resolution is crashing the GFX block. But I have no idea why that should happen. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160313/886f96be/attachment-0001.html>
Reminder: 2016 X.Org Board of Directors Elections Nomination period is NOW
We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2016 election are now open and will remain open until 23:59 UTC on 15 March 2016. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2015 were Peter Hutterer, Martin Peres, Rob Clark and Daniel Vetter, They will continue to serve until their term ends in 2017. Current directors whose term expires in 2016 are Alex Deucher, Matt Dew, Egbert Eich and Keith Packard. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the members account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 15 March 2016. The slate of candidates will be published 17 March 2016 and candidate Q will begin then. The deadline for Xorg membership applications and renewals is 17 March 2016. Cheers, Peter, on behalf of the X.Org BoD
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #77 from Steven Haigh --- Bueller? Bueller? Bueller? -- You are receiving this mail because: You are watching the assignee of the bug.
