On Mon, Oct 11, 2021 at 09:06:07PM +0200, Nirmoy Das wrote:
> Debugfs APIs returns encoded error on failure so use
> debugfs_lookup() instead of checking for NULL.
[...]
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -914,7 +914,7 @@ static void vga_switchero
On Mon, Oct 11, 2021 at 10:24:29PM +0200, Lukas Wunner wrote:
> On Mon, Oct 11, 2021 at 09:06:07PM +0200, Nirmoy Das wrote:
> > Debugfs APIs returns encoded error on failure so use
> > debugfs_lookup() instead of checking for NULL.
> [...]
> > --- a/drivers/gpu/vga/vg
ething like:
Retry creation of the vga_switcheroo debugfs if a previous
invocation of debugfs_create_dir() returned an error code.
With that addressed,
Reviewed-by: Lukas Wunner
Thanks,
Lukas
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/vga/vga_switcheroo.c | 2 +-
> 1 fi
void fbcon_remap_all(int idx)
That comment needs to be removed as well.
Not an expert on fbcon code but this looks sane to me, so in case it helps:
Acked-by: Lukas Wunner
Thanks,
Lukas
___
Intel-gfx mailing list
Intel-gfx@lists.
On Fri, Jul 01, 2016 at 03:47:56PM -0700, Manasi Navare wrote:
> Intel_dp_check_link_status() function reads the Link status registers
> and returns a boolean to indicate link is good or bad.
> If the link is bad, it is retrained outside the function based
> on the return value.
>
> Signed-off-by:
On Tue, Aug 02, 2016 at 02:37:37PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 06:48:47PM +0800, Baole Ni wrote:
> > I find that the developers often just specified the numeric value
> > when calling a macro which is defined with a parameter for access
> > permission.
> > As we know, the
On Tue, Aug 16, 2022 at 11:06:18AM +0300, Jani Nikula wrote:
> On Tue, 16 Aug 2022, Kai-Heng Feng wrote:
> > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch to
> > dGFX so external monitors are routed to dGFX, and more monitors can be
> > supported as result.
> >
> > To switc
ister with a simple
> error message. This is done at the same time due to lack of error
> propagation from i915_driver_register().
>
> Signed-off-by: Jani Nikula
Acked-by: Lukas Wunner
Seems like a good idea to limp on instead of bailing out if vga_switcheroo
registration fails.
On Wed, Aug 03, 2016 at 04:36:18PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Dell UP2414Q doesn't like it when we're driving it in MST mode, and then
> reboot the machine. After reboot, the monitor is somehow confused and
> refuses to do the payload allocation:
> [drm
On Mon, Aug 29, 2016 at 04:25:25PM +0100, Chris Wilson wrote:
> On Mon, Aug 29, 2016 at 05:54:45PM +0300, Imre Deak wrote:
> > On ma, 2016-08-29 at 16:24 +0200, Takashi Iwai wrote:
> > > Hmm, this always confuses me. Is the freeze callback called to the
> > > loader kernel?
> >
> > It's called bo
On Sat, Apr 08, 2017 at 05:05:11PM +0200, Hans de Goede wrote:
> Several cherrytrail devices (all of which ship with windows 10) hide the
> lpss pwm controller in ACPI, typically the _STA method looks like this:
>
> Method (_STA, 0, NotSerialized) // _STA: Status
> {
> If (OSID ==
On Sun, Apr 09, 2017 at 11:46:41AM +0200, Hans de Goede wrote:
> On 09-04-17 09:26, Lukas Wunner wrote:
> > On Sat, Apr 08, 2017 at 05:05:11PM +0200, Hans de Goede wrote:
> > > + pr_debug("Device [%s] is in always present list setting status
> > > [%08x]\n
On Wed, Apr 19, 2017 at 12:28:50PM +0200, Rafael J. Wysocki wrote:
> On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede wrote:
> > On 18-04-17 15:34, Rafael J. Wysocki wrote:
> >> On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede wrote:
> >>>
> >>> Several Cherry Trail devices (all of which ship with W
On Mon, Apr 24, 2017 at 05:27:42PM +0300, Imre Deak wrote:
> Some drivers - like i915 - may not support the system suspend direct
> complete optimization due to differences in their runtime and system
> suspend sequence. Add a flag that when set resumes the device before
> calling the driver's syst
ayed hidden.
No, the reason this hasn't popped up earlier is because direct_complete
has only been enabled for DRM devices for a few months now, to be specific
since
commit d14d2a8453d650bea32a1c5271af1458cd283a0f
Author: Lukas Wunner
Date: Wed Jun 8 12:49:29 2016 +0200
On Mon, Apr 24, 2017 at 10:02:30PM +0200, Lukas Wunner wrote:
> On Mon, Apr 24, 2017 at 05:27:42PM +0300, Imre Deak wrote:
> > Some drivers - like i915 - may not support the system suspend direct
> > complete optimization due to differences in their runtime and system
> > su
On Mon, Apr 24, 2017 at 10:56:40PM +0200, Rafael J. Wysocki wrote:
> On Monday, April 24, 2017 10:42:42 PM Lukas Wunner wrote:
> > On Mon, Apr 24, 2017 at 10:02:30PM +0200, Lukas Wunner wrote:
> > > On Mon, Apr 24, 2017 at 05:27:42PM +0300, Imre Deak wrote:
> > > >
On Tue, Apr 25, 2017 at 11:55:07AM +0300, Imre Deak wrote:
> On Tue, Apr 25, 2017 at 08:21:49AM +0200, Lukas Wunner wrote:
> > On Mon, Apr 24, 2017 at 10:56:40PM +0200, Rafael J. Wysocki wrote:
> > > On Monday, April 24, 2017 10:42:42 PM Lukas Wunner wrote:
> > > >
On Thu, Oct 18, 2018 at 05:25:58PM +0300, Imre Deak wrote:
> In order to ensure that our system suspend and resume callbacks are
> called in the correct order wrt. those of the HDA driver add a device
> link to the HDA driver during audio component binding time. With i915 as
> the supplier and HDA
On Mon, Mar 05, 2018 at 05:37:11PM +0200, Imre Deak wrote:
> On Mon, Feb 26, 2018 at 04:57:11PM +0100, Lukas Wunner wrote:
> > On Mon, Feb 26, 2018 at 04:41:09PM +0200, Imre Deak wrote:
> > > On Sun, Feb 25, 2018 at 12:42:30AM +0100, Lukas Wunner wrote:
> > >
tched as well. (Emil Velikov)
v6: The if-condition referring to PCI_BASE_CLASS_DISPLAY may be
considered a functional change. Move to a separate commit to
keep this a pure refactoring change. (Emil Velikov, Jani Nikula)
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: Alex Deucher
Signed-off-by:
change. (Emil Velikov, Jani Nikula)
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: Jani Nikula
Signed-off-by: Lukas Wunner
---
drivers/gpu/vga/vga_switcheroo.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga
On Mon, May 23, 2016 at 09:40:59AM +0100, Emil Velikov wrote:
> On 21 May 2016 at 15:08, Lukas Wunner wrote:
> > Daniel Vetter explicitly wanted the ability to use the helper in
> > vga_switcheroo audio clients, and those shouldn't run the apple-gmux
> > test. I think it
On Mon, May 23, 2016 at 09:23:14AM +0200, Daniel Vetter wrote:
> On Sat, May 21, 2016 at 03:59:16PM +0100, Lukas Wunner wrote:
[snip]
> > /**
> > + * vga_switcheroo_client_probe_defer() - whether to defer probing a given
> > client
> > + * @pdev: client pci devic
On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner wrote:
> > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
> >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> >> >
On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote:
> On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> > > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner wrote:
> > > > On T
[ 102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
[ 102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_fbdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.
On Fri, Jun 03, 2016 at 08:21:50PM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 09:30:06AM +0200, Lukas Wunner wrote:
> > On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> > > &
On Wed, Jun 08, 2016 at 02:09:40PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> > Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> > superfluous because the framebuffer will subsequently be
On Sat, Jun 11, 2016 at 09:21:11AM +0100, Chris Wilson wrote:
> One of the first steps in triaging memory corruption on module load is
> to disable stolen. (It helps reduce the impact of the BIOS clobbering
> our memory since we allocate our ringbuffers and initial objects from
> stolen, if they ar
On Fri, Jun 17, 2016 at 06:54:49PM +0100, Chris Wilson wrote:
> During lastclose, we call intel_fbdev_restore_mode() to switch back to
> the fbcon configuration on return to VT. However, if we have not yet
> finished the asynchronous fbdev initialisation, the current mode will be
> invalid and trig
Hi,
On Thu, Nov 19, 2015 at 04:58:44PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote:
> > Currently if intelfb_create() errors out, it unrefs the bo even though
> > the fb now owns that reference. (Spotted by Ville Syrjälä.) We should
&
Hi,
On Thu, Nov 19, 2015 at 05:02:04PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 01:43:20PM +0100, Lukas Wunner wrote:
> > intelfb_create() is called once on driver initialization. If it fails,
> > ifbdev->helper.fbdev, ifbdev->fb or ifbdev->fb->obj may be N
Hi again,
On Thu, Nov 19, 2015 at 05:02:04PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 01:43:20PM +0100, Lukas Wunner wrote:
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -408,7 +408,10 @@ static void intel_c
Hi Chris,
On Thu, Nov 19, 2015 at 09:46:34PM +, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 04:58:44PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote:
> > > @@ -727,7 +730,8 @@ void intel_fbdev_fini(stru
Hi Chris,
On Fri, Nov 20, 2015 at 04:29:52PM +, Chris Wilson wrote:
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS framebuffer and reusing its address in
> the GGTT for t
Hi,
On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote:
> > On Thu, 03 Dec 2015 21:33:29 +0100,
> > Ville Syrjälä wrote:
> > >
> > > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> > > > Hi,
> > > >
> > >
Hi Rafael,
On Thu, Dec 03, 2015 at 02:54:02PM -0800, Rafael Antognolli wrote:
> So far, the i915 driver and some other drivers set it to the drm_device,
> which doesn't allow one to know which DP a given aux channel is related
> to. Changing this to be the drm_connector provides proper nesting, st
Hi Rafael,
On Thu, Dec 03, 2015 at 02:54:00PM -0800, Rafael Antognolli wrote:
> The module_init and module_exit functions will start here, and call the
> subsequent init's and exit's.
>
> Signed-off-by: Rafael Antognolli
> ---
> drivers/gpu/drm/Makefile| 4 ++-
> drivers/gpu/dr
TR or NULL.
Also, further up in the function, the declaration of fb can then be
changed thus:
- struct drm_framebuffer *fb = NULL;
+ struct drm_framebuffer *fb;
Kind regards,
Lukas
>
> Signed-off-by: Chris Wilson
> Cc: "Goel, Akash"
> Cc: Daniel Vetter
> Cc
Hi,
I wouldn't normally nitpick like this but since I was reading it anyway
and you were asking for "OCD doc style thing". :-)
This is a proofread of the force-pushed v2 in drm-intel-nightly
(9a8730ddfe1d).
> +
> +Style Guidelines
> +
> + For consistency this documentation use Am
etter
Cc: Chris Wilson
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_fbdev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index bea75ca..09840f4 100644
--- a/drivers/gpu/drm/i915/intel_fb
Hi Dave,
On Tue, Feb 02, 2016 at 11:10:19AM +1000, Dave Airlie wrote:
> On 2 February 2016 at 08:49, Lukas Wunner wrote:
> > On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote:
> >> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5.
> >
>
Hi,
On Wed, Feb 03, 2016 at 09:17:37AM +, Chris Wilson wrote:
> If the initialisation fails, we may be left with a dangling pointer with
> an incomplete fbdev structure.
This shouldn't happen with 4.5, the fbdev is now clobbered if initialization
fails, the existing "if (dev_priv->fbdev)" che
Hi,
On Thu, Feb 04, 2016 at 03:00:11PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Ankitprasad Sharma
>
> The BIOS RapidStartTechnology may corrupt the stolen memory across S3
> suspend due to unalarmed hibernation, in which case we will not be able
> to preserve the User data stored in
Hi,
On Thu, Feb 04, 2016 at 04:05:04PM +, Chris Wilson wrote:
> On Thu, Feb 04, 2016 at 04:46:55PM +0100, Lukas Wunner wrote:
> > > + /* If the stolen region can be modified behind our backs upon suspend,
> > > + * then we cannot use it to store nonvolatile co
intel_fbdev_output_poll_changed(), not sure if these are racy as well.
At least the stack traces posted by Li Weinan and Gustav Fägerlind
only indicate that lastclose is racy.
Best regards,
Lukas
> From: Li, Weinan Z
> Sent: Thursday, February 04, 2016 10:34 AM
> To: 'gustav.fager
Hi Chris,
On Fri, Feb 05, 2016 at 11:09:27AM +, Chris Wilson wrote:
> On Fri, Feb 05, 2016 at 01:27:10AM +0100, Lukas Wunner wrote:
> > On Thu, Feb 04, 2016 at 09:21:17AM +, Li, Weinan Z wrote:
> > > We still need this patch. Seems 54632abe8ca3 ("drm/i915: Fix oops
[cc += Rafael J. Wysocki, linux-acpi]
Hi Stephen,
On Wed, Feb 10, 2016 at 12:24:51PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from drivers/gpu/drm/nouveau/nouveau_drm.
Hi,
On Wed, Feb 10, 2016 at 09:41:38AM +0100, Lukas Wunner wrote:
> On Wed, Feb 10, 2016 at 12:24:51PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the drm-misc tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this
Hi Ankitprasad,
On Thu, Feb 04, 2016 at 05:43:17PM +0100, Lukas Wunner wrote:
> On Thu, Feb 04, 2016 at 04:05:04PM +, Chris Wilson wrote:
> > We could #define INTEL_RAPID_START "INT3392" for
> > if (IS_ENABLED(CONFIG_SUSPEND) && acpi_dev_present(INTEL_RAPID_ST
Hi,
On Tue, Feb 09, 2016 at 10:04:01AM +0100, Daniel Vetter wrote:
> On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote:
[...]
> > @@ -967,6 +970,15 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> > struct pci_device_id *ent)
> > if
chronous thread to finish.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Reported-by: Gustav Fägerlind
Reported-by: "Li, Weinan Z"
Cc: Chris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/i915_dma.c| 8 +++-
drivers/gpu/drm/
load the module before the fbdev is fully
> initialized.)
>
> To make it bullet proof we could declare a completion in intel_fbdev.c
> and wait for that instead. Opinions?
Lukas Wunner (1):
drm/i915: Fix races on fbdev
drivers/gpu/drm/i915/i915_dma.c| 8 +++-
driver
Hi,
On Sun, Feb 14, 2016 at 01:46:28PM +0100, Daniel Vetter wrote:
> On Sun, Feb 14, 2016 at 1:10 PM, Lukas Wunner wrote:
> > /**
> > + * vga_switcheroo_client_probe_defer() - whether to defer probing a given
> > GPU
> > + * @pdev: pci device of GPU
> >
Hi,
On Tue, Feb 16, 2016 at 05:08:40PM +0100, Daniel Vetter wrote:
> On Tue, Feb 16, 2016 at 04:58:20PM +0100, Lukas Wunner wrote:
> > On Sun, Feb 14, 2016 at 01:46:28PM +0100, Daniel Vetter wrote:
> > > On Sun, Feb 14, 2016 at 1:10 PM, Lukas Wunner wrote:
> > > >
Hi,
On Thu, Feb 18, 2016 at 10:39:05PM +0100, Daniel Vetter wrote:
> On Thu, Feb 18, 2016 at 9:34 PM, Lukas Wunner wrote:
> >
> >> Ok, makes sense. I still think adding the check to the client_register
> >> function would be good, just as a safety measure.
>
chronous thread to finish.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Reported-by: Gustav Fägerlind
Reported-by: "Li, Weinan Z"
Cc: Chris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/i915_dma.c| 8 +++-
drivers/gpu/drm/
.org/series/3126/
Sorry, I give up.
Best regards,
Lukas
On Thu, Mar 03, 2016 at 06:02:53PM +0100, Lukas Wunner wrote:
> The ->lastclose callback invokes intel_fbdev_restore_mode() and has
> been witnessed to run before intel_fbdev_initial_config_async()
> has finished.
>
> We
Hi Bastien,
On Fri, Mar 04, 2016 at 04:12:27PM +, Bastien Nocera wrote:
> Lukas Wunner wunner.de> writes:
> > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5.
>
> I've tested your patchset on a MacBookPro8,1, with an integrated Intel and
> disc
an Z"
Cc: Chris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/i915_dma.c| 8 +++-
drivers/gpu/drm/i915/intel_fbdev.c | 3 +++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/
On Wed, Mar 09, 2016 at 12:06:24PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix races on fbdev (rev2)
> URL : https://patchwork.freedesktop.org/series/4068/
> State : failure
>
> == Summary ==
>
> Series 4068v2 drm/i915: Fix races on fbdev
> http://patchwork.freedes
Hi Bastien,
sorry for the delay.
On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote:
> We could, on boot, force using the integrated GPU, turning off the
> discrete GPU that we're not interested in.
Yes, many people "solve" this by having grub write the requisite commands
to gmux' I/
Hi Alex,
On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
> Is there any reason to make use of the mux?
Performance (lower latency => no need for framebuffer writes over PCIe),
improved battery life (no need to use 2 GPUs simultaneously).
Technically you can't just ignore that the m
Hi Alex,
On Tue, Mar 15, 2016 at 02:33:56PM -0400, Alex Deucher wrote:
> On Tue, Mar 15, 2016 at 1:54 PM, Lukas Wunner wrote:
> > On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
> >> Is there any reason to make use of the mux?
> >
> > Performance
On Fri, Dec 16, 2016 at 07:46:46AM +, Chris Wilson wrote:
> Prime numbers are interesting for testing components that use multiplies
> and divides, such as testing struct drm_mm alignment computations.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/Kconfig | 4 +
>
On Fri, Dec 16, 2016 at 09:43:54AM +, Chris Wilson wrote:
> On Fri, Dec 16, 2016 at 10:31:17AM +0100, Lukas Wunner wrote:
> > On Fri, Dec 16, 2016 at 07:46:46AM +, Chris Wilson wrote:
> > > Prime numbers are interesting for testing components that use multiplies
> >
till required acpi changes to
> detect device presence are pulled in (Ankit)
>
> v4: Enabled stolen by default as required acpi changes are merged
> (Ankit)
>
> v5: renamed variable, is IS_ENABLED() in place of #ifdef, use char*
> instead of structures (Lukas)
>
> Sig
Hi,
On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote:
> I'd like to propose that we push the i915 suspend_late/resume_early code
> into suspend_noirq/resume_noirq in order to reduce the total suspend time
> by ~15ms. According to the comments, when i915_pm_suspend_late was first
> a
ppen after calling this helper. (Daniel Vetter)
v4: Rebase on 412c8f7de011 ("drm/radeon: Return -EPROBE_DEFER when
amdkfd not loaded")
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: Alex Deucher
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/i915_drv.c | 10 +-
dr
Hi Chris,
On Thu, May 19, 2016 at 09:28:10AM +0100, Chris Wilson wrote:
> During cleanup we have to synchronise with the async task we are using
> to initialise and register our fbdev. Currently, we are using a full
> synchronisation on the global domain, but we can restrict this to just
> synchro
ppen after calling this helper. (Daniel Vetter)
v4: Rebase on 412c8f7de011 ("drm/radeon: Return -EPROBE_DEFER when
amdkfd not loaded")
v5: Some Optimus GPUs use PCI_CLASS_DISPLAY_3D, make sure those are
matched as well. (Emil Velikov)
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: A
Hi Emil,
On Fri, May 20, 2016 at 12:41:04AM +0100, Emil Velikov wrote:
> On 19 May 2016 at 15:39, Lukas Wunner wrote:
> > +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev)
> > +{
> > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
> Not
on older HW.
>
>
> commit a7442b93cf32c1e1ddb721a26cd1f92302e2a222
> Author: Lukas Wunner
> Date: Wed Mar 9 12:52:53 2016 +0100
>
> drm/i915: Fix races on fbdev
>
> The ->lastclose callback invokes intel_fbdev_restore_mode()
This should make the code less fragile by synchronizing only up to the
relevant cookie. Otherwise we risk deadlocks particularly during suspend
and resume.
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbdev.c | 14 +-
2 files
Hi Gabriel,
On Thu, Mar 31, 2016 at 10:42:37AM +0300, Gabriel Feceoru wrote:
> On 31.03.2016 00:35, Lukas Wunner wrote:
> >On Wed, Mar 30, 2016 at 08:20:26PM +0300, Gabriel Feceoru wrote:
> >>This commit causes a hang while running kms suspend tests
> >>(kms_pipe_crc_
Hi Chris,
On Thu, Mar 31, 2016 at 05:13:55PM +0100, Chris Wilson wrote:
> On Thu, Mar 31, 2016 at 07:05:21PM +0300, Joonas Lahtinen wrote:
> > On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > > void intel_fbdev_restore_mode(struct drm_device *dev)
> > > {
> > > - int ret;
> > > - struct
Hi Tomi,
On Thu, Mar 31, 2016 at 10:21:16AM +0300, Tomi Sarvela wrote:
> The problem with the results in your link is that there is no HSW, ILK, IVB
> or SNB results. This might give the impression that everything is well.
>
> Most damning is lack of HSW-gt2 and SNB-dellxps: those machines hang o
Hi Bastien,
On Tue, Apr 05, 2016 at 06:59:40PM +0200, Bastien Nocera wrote:
> I tested the runtime patches for Radeon on top of 4.6.0-rc2, and
> writing DIGD failed. I also saw a number of messages with the
> vga_switcheroo core in the kernel trying to switch GPUs but failed
> because "client 1" w
Hi Ville,
On Tue, Oct 13, 2015 at 06:04:40PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 30, 2015 at 10:06:27AM +0100, Lukas Wunner wrote:
> > From: Tvrtko Ursulin
> >
> > We had two failure modes here:
> >
> > 1.
> > Deadlock in in
Hi Ville,
On Thu, Oct 15, 2015 at 08:34:23PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 15, 2015 at 07:14:35PM +0200, Lukas Wunner wrote:
> > Hi Ville,
> >
> > On Tue, Oct 13, 2015 at 06:04:40PM +0300, Ville Syrjälä wrote:
> > > On Tue, Jun 30, 2015 at 10:06:
ve to free the memory occupied
by the fb and disable the crtc; the fbcon will be unusable anyway
at this point and if X11 is able to start up without errors,
it should be able to reinitialize the crtc.)
Browsable on GitHub:
https://github.com/l1k/linux/commits/intel_fbdev_fixes
Lukas Wunn
216 pre-retina]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer
[MBP 11,3 2013 intel HSW + nvidia GK107 retina]
Fixes: a8bb6818270c ("drm/i915: Fi
In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails,
the bo is unrefed twice: By drm_framebuffer_remove() and once more by
drm_gem_object_unreference(). Fix it.
Reported-by: Ville Syrjälä
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_fbdev.c | 5 ++---
1 file
quires the lock."]
v2:
* Reformat commit msg to 72 chars. (Lukas Wunner)
* Add third failure mode. (Lukas Wunner)
v5:
* Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
rephrase commit message. (Jani Nicula)
v6:
* In intelfb_alloc, if __intel_framebuffer_create faile
vertheless we should try to get it right.
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_fbdev.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 12597b5..b8c11a1 100644
---
Hi,
On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote:
> From: Chris Wilson
>
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS framebuffer and reusing its address i
Another observation that occurred to me only after sending away my
previous message (sorry):
On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote:
> From: Chris Wilson
>
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGT
Hi Ville,
On Fri, Sep 18, 2015 at 08:03:45PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Keep single 'lvds_reg' and 'lvds' variable around in
> intel_lvds_init(), and read it just once at the start.
Hm, is it intentional that you didn't also replace this register reado
n i915, nouveau and radeon.
Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl,
virtio and mgag200.
Already removed from the latter with cc59487a05b1 ("drm/mgag200:
'fbdev_list' in 'struct mga_fbdev' is not used").
Remove it from the others.
Signed-off-by: Lukas
Minor fixup to d0669d007542 ("drm/i915: Clean up LVDS register
handling") which intended to read lvds_reg just once at the
beginning of intel_lvds_init() and use that throughout the rest
of the function but accidentally missed one register readout.
Cc: Ville Syrjälä
Signed-off-by: Lu
ined a 4th patch, a new version of which I'll submit separately.
Thanks,
Lukas
Lukas Wunner (2):
drm/i915: On fb alloc failure, unref gem object where it gets refed
drm/i915: Fix double unref in intelfb_alloc failure path
Tvrtko Ursulin (1):
drm/i915: Fix failure paths aroun
216 pre-retina]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer
[MBP 11,3 2013 intel HSW + nvidia GK107 retina]
Fixes: a8bb6818270c ("drm/i915: Fi
In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails,
the bo is unrefed twice: By drm_framebuffer_remove() and once more by
drm_gem_object_unreference(). Fix it.
Reported-by: Ville Syrjälä
Signed-off-by: Lukas Wunner
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915
hould instead track
the vma directly, but oh well we don't."]
v2:
* Reformat commit msg to 72 chars. (Lukas Wunner)
* Add third failure mode. (Lukas Wunner)
v5:
* Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
rephrase commit message. (Jani Nicula)
v6:
* In in
, intel_fbdev_output_poll_changed(),
intel_fbdev_restore_mode().
The patches are also browsable on GitHub:
https://github.com/l1k/linux/commits/intel_fbdev_fixes
Best regards,
Lukas
Lukas Wunner (2):
drm/i915: Fix oops caused by fbdev initialization failure
drm/i915: Tear
the fbdev was destroyed with intel_fbdev_fini(), the driver
will oops on mst hotplug events.
Fix it.
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/i915_debugfs.c | 24 +---
drivers/gpu/drm/i915/intel_dp_mst.c | 10 --
drivers/gpu/drm/i915/intel_fbdev.c | 16 ++
ramebuffer_unreference() (if fb was not
inherited from BIOS), call intel_fbdev_fini().
Cc: Daniel Vetter
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/i915_dma.c| 1 +
drivers/gpu/drm/i915/intel_fbdev.c | 9 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff
Hi Ville,
On Fri, Nov 06, 2015 at 03:08:33PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Reading the driver load/unload code leaves one confused as there's
> an async_schedule() in the load, but not async_synchronize_full()
> in sight. In fact it's hidden inside intel_f
Hi Ville,
On Mon, Nov 09, 2015 at 01:00:50PM +0200, Ville Syrjälä wrote:
> On Sun, Nov 08, 2015 at 05:44:37PM +0100, Lukas Wunner wrote:
> > Hi Ville,
> >
> > On Fri, Nov 06, 2015 at 03:08:33PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Vil
1 - 100 of 202 matches
Mail list logo
