The stolen allocator objects loudly if the caller requests a zero-sized
object. This is a useful verbose check as in most cases the request
should have been pruned much early. Here we just want to silently return
before attempting the allocation.
Regression from
commit 484b41dd70a9fbea894632d8926b
During KMS takeover, we try to capture the current configuration and
preserve it across our initialisation. For a variety of reasons, we may
fail this, for example if the current mode was using the legacy VGA
plane. Under such circumstances, we discard the fb in the plane config
and tried to find a
On Mon, Mar 10, 2014 at 08:07:02AM +, Chris Wilson wrote:
> The stolen allocator objects loudly if the caller requests a zero-sized
> object. This is a useful verbose check as in most cases the request
> should have been pruned much early. Here we just want to silently return
> before attemptin
It can happen ...
Fix up the check to match pre-gen6 reality where we don't have hw
contexts and hence also don't need to set the reset status on them.
This blows up when running any gpu reset testcase since for pre-gen6
request->ctx is NULL. With this my ilk here is happy again.
This regression
When adding new gunk, _always_ think of a good place. Start/end
usually just means that this didn't happen, and on top of that results
in needless conflicts with other patches doing the same.
Introduced in
commit 62d5d69b49b6fea9905e36e67cc6c4fc5a17d75f
Author: Mika Kuoppala
Date: Tue Feb 25 1
On Sun, Mar 09, 2014 at 12:37:49AM +0530, Sagar Arun Kamble wrote:
> On Sun, 2014-03-09 at 00:34 +0530, Sagar Arun Kamble wrote:
> > On Sat, 2014-03-08 at 13:51 -0500, Alex Deucher wrote:
> > > On Sat, Mar 8, 2014 at 1:49 PM, wrote:
> > > > From: Sagar Kamble
> > > >
> > > > With this patch we a
On Fri, Mar 07, 2014 at 08:34:46PM +0100, Daniel Vetter wrote:
> We need to enable interrupt processing before all the modeset
> state is set up. But that means we can fall over when we get a pipe
> underrun. This shouldn't happen as long as the bios works correctly
> but as usual this turns out to
On Mon, Mar 10, 2014 at 10:29 AM, Chris Wilson wrote:
>> Realized after sending mail that we just get to know current cursor
>> width and height. Can we have capability that exposes all supported
>> cursor sizes?
>
> The cap exposes the max cursor size. Knowing our hardware we can infer
> that pot
On Mon, Mar 10, 2014 at 10:55:40AM +0100, Daniel Vetter wrote:
> On Mon, Mar 10, 2014 at 10:29 AM, Chris Wilson
> wrote:
> >> Realized after sending mail that we just get to know current cursor
> >> width and height. Can we have capability that exposes all supported
> >> cursor sizes?
> >
> > The
On Sun, Mar 09, 2014 at 12:19:06AM +0530, sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> With this patch we allow larger cursor planes of sizes 128x128
> and 256x256.
>
> v2: Added more precise check on size while setting cursor plane.
>
> v3: Changes related to restructuring cursor s
On Mon, Mar 10, 2014 at 11:04 AM, Chris Wilson wrote:
>> > The cap exposes the max cursor size. Knowing our hardware we can infer
>> > that pot sizes from 64 to max are supported, but it would be better if
>> > we did expose that information through the cap as well.
>>
>> I think the right approac
On Mon, Mar 10, 2014 at 11:07 AM, Daniel Vetter wrote:
> On Mon, Mar 10, 2014 at 11:04 AM, Chris Wilson
> wrote:
>>> > The cap exposes the max cursor size. Knowing our hardware we can infer
>>> > that pot sizes from 64 to max are supported, but it would be better if
>>> > we did expose that info
On Fri, Mar 07, 2014 at 10:29:26PM +0100, Daniel Vetter wrote:
> On Fri, Mar 07, 2014 at 06:32:14PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We won't be calling intel_enable_primary_plane() or
> > intel_disable_primary_plane() with the primary plane in the
> > w
From: Sagar Kamble
With this patch we allow larger cursor planes of sizes 128x128
and 256x256.
v2: Added more precise check on size while setting cursor plane.
v3: Changes related to restructuring cursor size restrictions
and DRM_DEBUG usage.
v4: Indentation related changes for setting cursor
On Mon, Mar 10, 2014 at 12:20 PM, Ville Syrjälä
wrote:
> On Fri, Mar 07, 2014 at 10:29:26PM +0100, Daniel Vetter wrote:
>> On Fri, Mar 07, 2014 at 06:32:14PM +0200, ville.syrj...@linux.intel.com
>> wrote:
>> > From: Ville Syrjälä
>> >
>> > We won't be calling intel_enable_primary_plane() or
>> >
On Wed, Mar 05, 2014 at 01:50:27PM +0200, Jani Nikula wrote:
[...]
> I am not entirely happy with adding an extra name field, but I also
> didn't like the caller having to set up aux.ddc.name in advance. Ideas
> welcome.
What you propose is a whole lot better than having to modify the
internals of
On Mon, 10 Mar 2014, Thierry Reding wrote:
> On Wed, Mar 05, 2014 at 01:50:27PM +0200, Jani Nikula wrote:
> [...]
>> I am not entirely happy with adding an extra name field, but I also
>> didn't like the caller having to set up aux.ddc.name in advance. Ideas
>> welcome.
>
> What you propose is a w
Hi Sagar,
Thank you for the patch, it's really appreciated.
On Saturday 08 March 2014 12:58:43 sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> Started documenting drm properties for drm drivers. This patch provides
> information about properties in drm, i915, psb and cdv/gma-500. Infor
On Mon, Mar 10, 2014 at 3:25 PM, Jiri Kosina wrote:
> On Mon, 3 Mar 2014, Jiri Kosina wrote:
>> > first things first: this is hard to bisect, because it doesn't happen
>> > reliably and I don't really know what is the first good version, as I had
>> > a delay in following Linus' tree.
>> >
>> > Wh
Hi Sagar,
Thank you for the patch.
On Saturday 08 March 2014 13:51:19 sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> Cc: Rob Landley
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: David Herrmann
> Cc: Alex Deucher
> Cc: "Ville Syrjälä"
> Cc: Sagar Kamble
>
On Mon, 10 Mar 2014, Daniel Vetter wrote:
> >> > *ERROR* render ring initialization failed ctl 0001f001 head 3004
> >> > tail start 3000
> >> >
> >> > as it doesn't seem to be there in case of resumption that works properly.
> >> >
> >> > Please see the dmesg from the broken case
Hi Daniel,
On Monday 10 March 2014 06:21:49 Daniel Vetter wrote:
> On Wed, Mar 5, 2014 at 11:56 AM, wrote:
> > +
> > +
> > +
> > +Owner Module/Drivers
> > +Group
> > +Property Object
> > +Property Name
> > +Type
> > +Property Values
> > +Object attached
> > +Description
> > +
>
> In my opinion
Hi Chris,
For the issue mentioned by you ( regarding botching up ioctls), we understand
that this is related to the
compatibility between the older/newer versions of driver/userspace.
In our old implementation, the 'pad' field was replaced with 'flags' in the
ioctl structure. This would have
On Sat, 2014-03-08 at 11:04 +0100, Daniel Vetter wrote:
> On Fri, Mar 07, 2014 at 08:05:24PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Otherwise, when we run intel_modeset_check_state we may already be
> > runtime suspended, and our state checking code will read registers
> > whil
Introduced in
commit e0e33f8ff6f0b6d286afc314802be4993341bd47
Author: Imre Deak
Date: Tue Mar 4 19:23:07 2014 +0200
The impact was luckily minimal, due to the extra check we do against a
software pipestat IRQ mask.
Caught by Fengguang's 0-day tester.
Cc: Fengguang Wu
Signed-off-by: Imre Deak
[+cc linux-pci]
On Sat, Mar 08, 2014 at 03:44:37PM +0100, Paul Bolle wrote:
> Bjorn Helgaas schreef op za 08-03-2014 om 07:12 [-0700]:
> > I assume you have CONFIG_PHYS_ADDR_T_64BIT=n (which is perfectly
> > legal); let me know if otherwise.
>
> $ grep CONFIG_PHYS_ADDR_T_64BIT /boot/config-3.14.0
On Mon, Mar 3, 2014 at 11:15 AM, wrote:
> From: Ville Syrjälä
>
> Currently we allow encoders to indicate whether they can be part of a
> cloned set with just one flag. That's not flexible enough to describe
> the actual hardware capabilities. Instead make it a bitmask of encoder
> types with wh
On Mon, Mar 10, 2014 at 09:44:22AM +0100, Daniel Vetter wrote:
> It can happen ...
>
> Fix up the check to match pre-gen6 reality where we don't have hw
> contexts and hence also don't need to set the reset status on them.
>
> This blows up when running any gpu reset testcase since for pre-gen6
>
Reviewed-by: Rodrigo Vivi
On Mon, Mar 3, 2014 at 11:15 AM, wrote:
> From: Ville Syrjälä
>
> When cloning HDMI with other output types, we can't use 12bpc since the
> clocks for the other encoder types would be off. So have
> intel_hdmi_compute_config() check if there are other encoders besides
Reviewed-by: Rodrigo Vivi
On Mon, Mar 3, 2014 at 11:15 AM, wrote:
> From: Ville Syrjälä
>
> HDMI+VGA cloning should be supported on all platforms. The only real
> obstacle is the 1.5x clock adjustment for 12bpc HDMI, but that is now
> taken care of, so we can allow HDMI+VGA cloning.
>
> Bugzil
On Mon, Mar 3, 2014 at 11:15 AM, wrote:
> From: Ville Syrjälä
>
> BSpec is a bit unclear whether HDMI+HDMI cloning should work on g4x.
> Tests on real hardware say that it does. Since g4x can't send
> infoframes to more than one HDMI port anyway, we don't lose anything
> by allow it.
I hope thi
On Mon, Mar 10, 2014 at 03:27:09PM -0300, Rodrigo Vivi wrote:
> On Mon, Mar 3, 2014 at 11:15 AM, wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index b64fc1c..5be4ab2 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++ b/drivers/gpu/drm/i91
On Mon, Mar 10, 2014 at 7:30 PM, Ben Widawsky wrote:
> On Mon, Mar 10, 2014 at 09:44:22AM +0100, Daniel Vetter wrote:
>> It can happen ...
>>
>> Fix up the check to match pre-gen6 reality where we don't have hw
>> contexts and hence also don't need to set the reset status on them.
>>
>> This blows
On Mon, Mar 10, 2014 at 03:50:40PM -0300, Rodrigo Vivi wrote:
> On Mon, Mar 3, 2014 at 11:15 AM, wrote:
> > From: Ville Syrjälä
> >
> > BSpec is a bit unclear whether HDMI+HDMI cloning should work on g4x.
> > Tests on real hardware say that it does. Since g4x can't send
> > infoframes to more th
On Mon, Mar 10, 2014 at 07:44:48PM +0200, Imre Deak wrote:
> Introduced in
> commit e0e33f8ff6f0b6d286afc314802be4993341bd47
> Author: Imre Deak
> Date: Tue Mar 4 19:23:07 2014 +0200
>
> The impact was luckily minimal, due to the extra check we do against a
> software pipestat IRQ mask.
>
> Ca
On Tue, Mar 04, 2014 at 05:37:39PM -0800, Yu Dai wrote:
> Chris,
>
> This looks like a hw specific value which is difficult to
> understand. However, the definition of these values are just a list
> of available options of z-order. On Intel VLV, there is only 6
> options for the three planes Prima
On Tue, 2014-02-25 at 19:52 -0800, Ben Widawsky wrote:
> These page table helpers make the code much cleaner. There is some
> room to use the arch/x86 header files. The reason I've opted not to is
> in several cases, the definitions are dictated by the CONFIG_ options
> which do not always indicate
On Mon, Mar 10, 2014 at 11:05:42PM +0200, Imre Deak wrote:
> On Tue, 2014-02-25 at 19:52 -0800, Ben Widawsky wrote:
> > These page table helpers make the code much cleaner. There is some
> > room to use the arch/x86 header files. The reason I've opted not to is
> > in several cases, the definitions
On Mon, Mar 10, 2014 at 09:30:22PM +0100, Daniel Vetter wrote:
> On Mon, Mar 10, 2014 at 7:30 PM, Ben Widawsky wrote:
> > On Mon, Mar 10, 2014 at 09:44:22AM +0100, Daniel Vetter wrote:
> >> It can happen ...
> >>
> >> Fix up the check to match pre-gen6 reality where we don't have hw
> >> contexts
On Mon, Mar 10, 2014 at 04:12:23PM +, Gupta, Sourab wrote:
>
> Hi Chris,
>
> For the issue mentioned by you ( regarding botching up ioctls), we understand
> that this is related to the
> compatibility between the older/newer versions of driver/userspace.
> In our old implementation, the 'pa
On Fri, Mar 07, 2014 at 08:05:19PM +, Chris Wilson wrote:
> On Fri, Mar 07, 2014 at 07:18:29PM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 03/07/2014 02:18 PM, Chris Wilson wrote:
> > > If we set master_count to non-zero, we won't ever call drmDropMaster
> > > (since our get/put will be unb
Bjorn Helgaas schreef op ma 10-03-2014 om 12:24 [-0600]:
> Thanks. Can you try the patch below? I think it should fix the problem.
>
>
> PCI: Don't check resource_size() in pci_bus_alloc_resource()
>
> From: Bjorn Helgaas
>
> When resource_size_t is 32 bits wide, e.g., when CONFIG_PHYS_ADDR_
[+cc Rafael]
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-03-2014 om 12:24 [-0600]:
>> Thanks. Can you try the patch below? I think it should fix the problem.
>>
>>
>> PCI: Don't check resource_size() in pci_bus_alloc_resource()
>>
>> From: Bjorn Helgaas
On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote:
> > A bit of doubt is caused by two new boot time messages:
> > pnp 00:00: unknown resource type 10 in _CRS
> > pnp 00:00: can't evaluate _CRS: 1
> >
> > But I haven't yet tried v3.
On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle wrote:
> On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
>> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote:
>> > A bit of doubt is caused by two new boot time messages:
>> > pnp 00:00: unknown resource type 10 in _CRS
>> > pnp 00:00:
45 matches
Mail list logo
