On Wed, Apr 26, 2017 at 02:57:49PM -0300, Gabriel Krisman Bertazi wrote:
> Paulo Zanoni writes:
>
> > Ouch... Good catch!
> >
> > Can you please move the logic to the setup_fbc() function?
> >
> > if (gen < 7)
> > opt.fbc_check_compression = false;
> >
> > This way we avoid redoing the same c
Em Qua, 2017-04-26 às 21:12 +0300, Ville Syrjälä escreveu:
> On Wed, Apr 26, 2017 at 02:57:49PM -0300, Gabriel Krisman Bertazi
> wrote:
> >
> > Paulo Zanoni writes:
> >
> > >
> > > Ouch... Good catch!
> > >
> > > Can you please move the logic to the setup_fbc() function?
> > >
> > > if (gen <
Paulo Zanoni writes:
> Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi escreveu:
>> After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
>> intel_fbc_can_choose()"), no_fbc_reason will be updated to a new
>> error
>> message if we don't have a plane in the new state, which should mak
On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
> I was thinking of exactly the same thing as this patch does, u64
> context id as key, u32 seqnos (wrapped in a container with
> hlist_node).
#define NSYNC 32
struct intel_timeline_sync { /* kmalloc-256 slab */
struct hlist_n
Em Qua, 2017-04-26 às 15:40 -0300, Gabriel Krisman Bertazi escreveu:
> Paulo Zanoni writes:
>
> >
> > Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi
> > escreveu:
> > >
> > > After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
> > > intel_fbc_can_choose()"), no_fbc_reason will be
On Wed, Apr 26, 2017 at 03:47:44PM +0200, Takashi Iwai wrote:
> On Wed, 26 Apr 2017 15:38:53 +0200,
> Ville Syrjälä wrote:
> >
> > On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > > On Tue, 25 Apr 2017 22:27:19 +0200,
> > > ville.syrj...@linux.intel.com wrote:
> > > >
> > > > Fro
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, I'll work up a draft proposal and send it in a couple days. But
without a lot of cleanup such as this series it's not going t
On Friday, April 21, 2017 01:43:51 PM Hans de Goede wrote:
> Hi,
>
> On 21-04-17 13:38, Andy Shevchenko wrote:
> > On Fri, 2017-04-21 at 12:47 +0200, Hans de Goede wrote:
> >> Several Bay / Cherry Trail devices (all of which ship with Windows 10)
> >> hide
> >> the LPSS PWM controller in ACPI, typ
On Wed, Apr 26, 2017 at 07:56:14PM +0100, Chris Wilson wrote:
> On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
> > I was thinking of exactly the same thing as this patch does, u64
> > context id as key, u32 seqnos (wrapped in a container with
> > hlist_node).
>
> #define NSYNC 32
On 26/04/17 02:59 AM, wrote:
> Good to know that somebody is working on this. Those problems troubled
> us as well.
Thanks Christian. It's a daunting problem and a there's a lot of work to
do before we will ever be where we need to be so any help, even an ack,
is greatly appreciated.
Logan
_
On Tue, 2017-04-25 at 09:51 +0200, Maarten Lankhorst wrote:
> On 21-04-17 07:51, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran"
> >
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> >
From: "Pandiyan, Dhinakaran"
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and cle
On Mon, 2017-04-24 at 11:53 -0400, Harry Wentland wrote:
> Patches 1-3: Reviewed-by: Harry Wentland
> Patch 4: Acked-by: Harry Wentland
>
> Harry
>
Thanks for the review.
-DK
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://list
== Series Details ==
Series: Adding driver-private objects to atomic state (rev2)
URL : https://patchwork.freedesktop.org/series/23308/
State : warning
== Summary ==
Series 23308v2 Adding driver-private objects to atomic state
https://patchwork.freedesktop.org/api/1.0/series/23308/revisions/2/
Hi Daniele:
Thanks for the reply! Joonas and I did some researches in irc after
the email. We found B-spec did say the context image for render engine
consist 20 pages in context layout section. It looks like a mistake in
b-spec. Another interesting we found is the context image size for KB
> + David and Jon
>
> On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
>
> The blocking issue I see is that bisecting is still not pointing at
> relevant commits. Both bisected commits from Bugzilla are not related
> to changes in stolen memory usage behavior. I'd assume a successful
> bisect
On Wed, Apr 26, 2017 at 12:11:33PM -0600, Logan Gunthorpe wrote:
> Ok, well for starters I think you are mistaken about kmap being able to
> fail. I'm having a hard time finding many users of that function that
> bother to check for an error when calling it.
A quick audit of the arch code shows yo
101 - 117 of 117 matches
Mail list logo
