On Sun, 14 Apr 2024 18:36:13 +0200 Krzysztof Kozlowski wrote:
> 'struct lcd_ops' is not modified by core backlight code, so it can be
> made const for increased code safety.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Bruno Prémont
> ---
>
> Depends o
flag.
> >
> > Signed-off-by: Thomas Zimmermann
> > Cc: "Bruno Prémont"
> > Cc: Jiri Kosina
> > Cc: Benjamin Tissoires
> > Cc: linux-in...@vger.kernel.org
> > ---
> > drivers/hid/hid-picolcd_fb.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
>
> Reviewed-by: Javier Martinez Canillas
Acked-by: Bruno Prémont
eaning
> up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
>
> Signed-off-by: Thomas Zimmermann
> Cc: "Bruno Prémont"
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
Acked-by: Bruno Prémont
Cheers,
Bruno
> ---
> drivers/hid/hid-picolcd_fb.c
flict, but
adding Jiri to CC for the case there was any preference.
Acked-by: Bruno Prémont
> Cc: Bruno Prémont
> Cc: linux-in...@vger.kernel.org
> Reviewed-by: Daniel Vetter
> Signed-off-by: Jani Nikula
> ---
> drivers/hid/hid-picolcd_fb.c | 3 +--
> 1 file changed, 1
Hi Daniel,
On Mon, 25 Nov 2019 09:18:41 +0100 Daniel Vetter wrote:
> On Mon, Nov 25, 2019 at 9:08 AM Bruno Prémont wrote:
> > Trying a new kernel on old [NV04] system I get tons of
> > nouveau :01:00.0: gr: intr 0001 [NOTIFY] nsource 0040
> > [ILLEGAL_M
Hi,
Trying a new kernel on old [NV04] system I get tons of
nouveau :01:00.0: gr: intr 0001 [NOTIFY] nsource 0040
[ILLEGAL_MTHD] nstatus 4000 [PROTECTION_FAULT] ch 0
[DRM] subc 3 class 004a mthd 02fc data 0003
errors when operating on console.
As I updated from 4.3 k
On Wed, 12 Sep 2018 20:06:43 +0200 Takashi Iwai wrote:
> On Wed, 12 Sep 2018 19:46:58 +0200,
> Ville Syrjälä wrote:
> >
> > On Tue, Sep 11, 2018 at 03:50:13PM +0200, Bruno Prémont wrote:
> > > Hi,
> > >
> > > I have a system with multiple monit
Hi,
I have a system with multiple monitors and would like to send
notification sounds to the monitor on which corresponding
window is visible.
For a workstation and a tiny computer things look different:
- workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz):
00:02.0 VGA compatible controller [
Hi Lucas,
On Mon, 30 May 2016 12:24:46 +0200 Lukas Wunner wrote:
> On Mon, May 30, 2016 at 11:07:53AM +0200, Bruno Prémont wrote:
> > On Fri, 27 May 2016 14:23:02 +0200 Lukas Wunner wrote:
> > > Wilfried Klaebe has reported a deadlock in 4.6 which he bisected to
> > > my commit 704ab614ec12 ("d
Hi Lucas,
On Fri, 27 May 2016 14:23:02 +0200 Lukas Wunner wrote:
> Hi Bruno,
>
> Wilfried Klaebe has reported a deadlock in 4.6 which he bisected to
> my commit 704ab614ec12 ("drm/i915: Defer probe if gmux is present but
> its driver isn't"), but which is ultimately caused by your commit
> 4eebd5
On Mon, 4 Jan 2016 17:52:06 +0100 Lukas Wunner wrote:
> Document what I've learned so far about the gmux so that we can
> collaboratively reverse-engineer its remaining unknown bits
> without everyone having to start from scratch.
>
> The DOC sections are bound together in the gpu.tmpl DocBook
> u
Hi Greg, stable team,
Please apply this patch to stable (3.18 and 3.17).
It is commit ff4c0d5213b015e60aa87c1352604f10ba9c3e12 in linus's tree:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff4c0d5213b015e60aa87c1352604f10ba9c3e12
Thanks,
Bruno
On Sun, 21 Decembe
On Mon, 22 Dec 2014 08:46:48 -0500 Rob Clark wrote:
> On Sun, Dec 21, 2014 at 11:43 AM, Bruno Prémont wrote:
> > On !SMP systems spinlocks do not exist. Thus checking of they
> > are active will always fail.
> >
> > Use
> > assert_spin_locked(lock);
> > instead of
> > BUG_ON(!spin_is_locked(lo
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont
---
drivers/gpu/drm/omapdrm/omap_irq.c | 2 +-
1 file changed, 1 i
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont
---
drivers/gpu/drm/msm/mdp/mdp_kms.c | 2 +-
1 file changed, 1 in
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont
---
See also fdo bug #87552
drivers/gpu/drm/nouveau/core/core/eve
On Mon, 22 September 2014 Linus Torvalds
wrote:
> Adding proper people and mailing lists..
>
> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
> appropriate, but hopefully somebody does. The fact that it makes
> thing
Bjorn,
What is missing to get these two patches pushed to Linus?
Bruno
On Thu, 28 Aug 2014 22:47:50 +0200 Bruno Pr?mont wrote:
> On Tue, 26 August 2014 Andreas Noever wrote:
> > On Sun, Aug 24, 2014 at 11:09 PM, Bruno Pr?mont wrote:
> > > With commit 20cde694027e boot video device detection wa
On Tue, 26 August 2014 Andreas Noever wrote:
> On Sun, Aug 24, 2014 at 11:09 PM, Bruno Pr?mont wrote:
> > With commit 20cde694027e boot video device detection was moved from
> > efifb to x86 and ia64 pci/fixup.c.
> >
> > For dual-GPU Apple computers above change represents a regression as
> > code
Hi Daniel,
On Mon, 25 Aug 2014 14:16:02 +0200 Daniel Vetter wrote:
> Very often when something goes wrong with a kms driver we hang while doing
> the initial modeset. Which is all done while holding the console_lock
> (because fbdev+vt locking is just insane). You can try to get a closer
> look wi
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
Remove the left-over #ifndef check that will allways match since
the corresponding arch-specific define is gone with above patch.
Signed-off-by: Bruno Pr?mont
CC: Matthew Garrett
---
No funda
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
For dual-GPU Apple computers above change represents a regression as
code in efifb did forcefully override vga_default_device while the
merge did not (vgaarb happens prior to PCI fixup).
To impr
On Fri, 22 August 2014 Andreas Noever wrote:
> > For Andreas's system the discrete nvidia GPU has no I/O enabled
> > according to PCI_COMMAND flags while the integrated intel one does have
> > them (that's why the Intel GPU is chosen).
> >
> > Unfortunately I don't know what makes his system choke
On Thu, 21 Aug 2014 23:39:31 -0500 Bjorn Helgaas wrote:
> On Thu, Aug 21, 2014 at 4:34 PM, Bruno Pr?mont wrote:
>
> > A second step would then be to tune vgaarb's initial selection.
> > Bjorn, is it possible to verify which I/O ports are decoded by a PCI
> > device at the time of adding it to vgaa
On Thu, 21 August 2014 Andreas Noever wrote:
> dmesg with your patches and vga_set_default_device commented out
> (after "vgaarb: Boot video device...") as otherwise the system won't
> boot.
Do you know more precisely where your system hangs when it does not boot?
That's the part I can't find in
On Wed, 20 Aug 2014 07:55:08 +0200 Bruno Pr?mont wrote:
> On Tue, 19 Aug 2014 17:45:00 +0200 Andreas Noever wrote:
> > On Sat, Aug 16, 2014 at 7:21 PM, Bruno Pr?mont wrote:
> > > This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB
> > > vga_default_device() initialization to pci_vga
On Tue, 19 Aug 2014 17:45:00 +0200 Andreas Noever wrote:
> On Sat, Aug 16, 2014 at 7:21 PM, Bruno Pr?mont wrote:
> > This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB
> > vga_default_device() initialization to pci_vga_fixup()):
> > - cleanup remaining but always-true #ifndefs
> >
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
For dual-GPU Apple computers above above change represents a regression
as code in efifb did forcefully override vga_default_device while the
merge did not (changed ordering of actions).
This st
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.
Remove the left-over #ifndef check that will allways match since
the corresponding arch-specific define is gone with above patch.
Signed-off-by: Bruno Pr?mont
CC: Matthew Garrett
CC: stable at
This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB
vga_default_device() initialization to pci_vga_fixup()):
- cleanup remaining but always-true #ifndefs
- fix boot regression on dual-GPU Macs
Andreas, can you please test this series? It is a modification from
previous testing patc
On Sun, 10 August 2014 Andreas Noever wrote:
> On Sun, Aug 10, 2014 at 11:26 AM, Bruno Pr?mont wrote:
> > On Sun, 10 August 2014 Andreas Noever wrote:
> >
> >> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noeverwrote:
> >> > I just tried to run the latest kernel. It failed to boot and git
> >> > bise
On Sun, 10 August 2014 Andreas Noever wrote:
> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noever
> wrote:
> > On Sat, Jul 5, 2014 at 7:15 PM, Bjorn Helgaas
> > wrote:
> >> On Wed, Jun 25, 2014 at 12:55:01AM +0200, Bruno Pr?mont wrote:
> >>> With commit b4aa0163056b ("efifb: Implement vga_default
The fixup code for PCI VGA devices in ia64 and x86 is mostly identical.
Merge it into a single function called from both sides.
The common code is moved to vgaarb.c which makes in dependant on
CONFIG_VGA_ARB.
Tested-by: Anibal Francisco Martinez Cortina
Cc: Matthew Garrett
Signed-off-by: Bruno
With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
Matthew Garrett introduced a efifb vga_default_device() so that EFI
systems that do not load shadow VBIOS or setup VGA get proper value for
boot_vga PCI sysfs attribute on the corresponding PCI device.
Xorg is refusing to dete
On Mon, 02 June 2014 Bruno Pr?mont wrote:
> With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> Matthew Garrett introduced a efifb vga_default_device() so that EFI
> systems that do not load shadow VBIOS or setup VGA get proper value for
> boot_vga PCI sysfs attribute on the
On Tue, 17 Jun 2014 16:35:42 -0600 Bjorn Helgaas wrote:
> On Mon, Jun 02, 2014 at 08:19:26PM +0200, Bruno Pr?mont wrote:
> > With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
> > Matthew Garrett introduced a efifb vga_default_device() so that EFI
> > systems that do not load s
With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
Matthew Garrett introduced a efifb vga_default_device() so that EFI
systems that do not load shadow VBIOS or setup VGA get proper value for
boot_vga PCI sysfs attribute on the corresponding PCI device.
Xorg is refusing to dete
The fixup code for PCI VGA devices in ia64 and x86 is mostly identical.
Merge it into a single function called from both sides.
The common code is moved to vgaarb.c which makes in dependant on
CONFIG_VGA_ARB.
Signed-off-by: Bruno Pr?mont
---
arch/ia64/pci/fixup.c| 77 ++
On Tue, 27 May 2014 Bjorn Helgaas wrote:
> On Wed, May 14, 2014 at 10:43:39PM +0200, Bruno Pr?mont wrote:
> > With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
>
> I think there's an emerging convention to use reference commits as
> <12-char-SHA1> ("subject"), i.e.,
>
> b4a
With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
introduced a efifb vga_default_device() so that EFI systems that do not
load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
attribute on the corresponding PCI device.
Xorg is refusing to autodetect devices when
Hi Justin,
CC-ing dri-devel as more KMS/radeon people will see it there.
On Mon, 31 March 2014 "Justin Piszcz" wrote:
> Do I need some updated ATI firmware (I believe this might have happened in
> the past)..?
> I booted back to 3.13.6, Xorg starts up fine, but with 3.14 it does not
> start.
Co
With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
introduced a efifb vga_default_device() so that EFI systems that do not
load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
attribute on the corresponding PCI device.
Xorg is refusing to detect devices when boot
Hi David,
On Fri, 7 Mar 2014 00:41:05 +0100 David Herrmann wrote:
> On Thu, Mar 6, 2014 at 10:56 PM, Bruno Pr?mont wrote:
> > On Thu, 06 March 2014 David Herrmann wrote:
> >> On modern linux user-space, the VT subsystem is no longer needed for
> >> system consoles. Although most DEs will fail if V
Hi David,
On Thu, 06 March 2014 David Herrmann wrote:
> On modern linux user-space, the VT subsystem is no longer needed for
> system consoles. Although most DEs will fail if VTs are disabled, there
> are several gfx-systems that support this mode. Especially the lower
> system stack has been ext
[replaced Matthew's RedHat email with a recently used one]
> > On Sat, Nov 30, 2013 at 2:52 PM, Bruno Pr?mont wrote:
> >> With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
> >> introduced a efifb vga_default_device() so that EFI systems that do not
> >> load shadow VBIOS or setup
Hi Ilia,
On Thu, 5 Dec 2013 09:42:49 -0500 Ilia Mirkin wrote:
> All instances of drm_dev_register are followed by drm_dev_free on
> failure. Don't free dev->control/render/primary on failure, as they will
> be freed by drm_dev_free since commit 8f6599da8e (drm: delay minor
> destruction to drm_de
Hi Ilia,
On Wed, 4 Dec 2013 06:15:30 -0500 Ilia Mirkin wrote:
> On Wed, Dec 4, 2013 at 6:01 AM, Bruno Pr?mont wrote:
> > With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau:
> > [ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type
> > mismatch - Found [Integer
Hi,
With 3.13-rc1 and 3.13-rc2 kernel crashes/BUGs while loading nouveau:
[ 657.654915] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type
mismatch - Found [Integer], ACPI requires [Package] (20131115/nsarguments-95)
[ 657.655099] ACPI Warning: \_SB_.PCI0.IXVE.IGPU._DSM: Argument #4 type
With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret
introduced a efifb vga_default_device() so that EFI systems that do not
load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs
attribute on the corresponding PCI device.
Xorg is refusing to detect devices when boot
Hi David,
On Wed, 27 Nov 2013 21:40:39 +0100 David Herrmann wrote:
> On Mon, Nov 25, 2013 at 8:54 PM, Bruno Pr?mont wrote:
> > On a MacBookAir2,1, booting to Linux with EFI though having
> > no efifb built-in Xorg refuses to start with "no devices detected"
> > because for the only VGA device avai
On Mon, 25 November 2013 Bjorn Helgaas wrote:
> On Mon, Nov 25, 2013 at 12:54 PM, Bruno Pr?mont wrote:
> > On a MacBookAir2,1, booting to Linux with EFI though having
> > no efifb built-in Xorg refuses to start with "no devices detected"
> > because for the only VGA device available (NVidia Geforce
On a MacBookAir2,1, booting to Linux with EFI though having
no efifb built-in Xorg refuses to start with "no devices detected"
because for the only VGA device available (NVidia Geforce 9400M)
the sysfs attribute boot_vga is zero (instead of expected 1).
When CONFIG_FB_EFI is selected, efifb does p
On Sun, 08 September 2013 Daniel Vetter wrote:
> On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf
> wrote:
> > kexec calls:
> > printk(KERN_EMERG "Starting new kernel\n");
> > late before calling machine_shutdown().
> > However at this point the underlying fb device may have already been
> >
Hi Paul,
On Sun, 12 August 2012 Paul Menzel wrote:
> Dear Linux folks,
>
> regarding modelines problems with some TVs [1] and EDID quirks, Ian sent
> nice patches for [2], is there a way to test what modeline the DRM
> subsystem would choose without actually attaching the device?
>
> The proble
Hi Paul,
On Sun, 12 August 2012 Paul Menzel wrote:
> Dear Linux folks,
>
> regarding modelines problems with some TVs [1] and EDID quirks, Ian sent
> nice patches for [2], is there a way to test what modeline the DRM
> subsystem would choose without actually attaching the device?
>
> The proble
I can easily trigger a crash in nouveau interrupt handler by unbinding
and rebinding the GPU.
The command used:
echo $pci_device > nouveau/unbind && \
sleep 5 && \
echo $pci_device > nouveau/bind
Kernel is 3.4.0 with modular drm/nouveau.
GPU is NVidia nForce IGP (NV11)
Unbind
I can easily trigger a crash in nouveau interrupt handler by unbinding
and rebinding the GPU.
The command used:
echo $pci_device > nouveau/unbind && \
sleep 5 && \
echo $pci_device > nouveau/bind
Kernel is 3.4.0 with modular drm/nouveau.
GPU is NVidia nForce IGP (NV11)
Unbind
On Thu, 05 May 2011 Bruno Pr?mont wrote:
> With 2.6.39-rc6 I'm hitting the following (relevant part from objdump of
> drm_mm.o at bottom).
> Some part of node passed to drm_mm_remove_node() is being use after free
> and hits SLUB poison.
>
> Bruno
>
>
> [ 328.447498] drm: unregistered panic no
On Thu, 05 May 2011 Bruno Prémont wrote:
> With 2.6.39-rc6 I'm hitting the following (relevant part from objdump of
> drm_mm.o at bottom).
> Some part of node passed to drm_mm_remove_node() is being use after free
> and hits SLUB poison.
>
> Bruno
>
>
> [ 328
With 2.6.39-rc6 I'm hitting the following (relevant part from objdump of
drm_mm.o at bottom).
Some part of node passed to drm_mm_remove_node() is being use after free
and hits SLUB poison.
Bruno
[ 328.447498] drm: unregistered panic notifier
[ 328.447648] [drm] nouveau :02:00.0: 0xAFD8: Pa
With 2.6.39-rc6 I'm hitting the following (relevant part from objdump of
drm_mm.o at bottom).
Some part of node passed to drm_mm_remove_node() is being use after free
and hits SLUB poison.
Bruno
[ 328.447498] drm: unregistered panic notifier
[ 328.447648] [drm] nouveau :02:00.0: 0xAFD8: Pa
Hi,
Looks like you are using the wrong intel driver.
For intel modesetting you need
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
# CONFIG_DR
Hi,
Looks like you are using the wrong intel driver.
For intel modesetting you need
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
# CONFIG_DR
On Sun, 02 May 2010 Bruno Pr?mont wrote:
> On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
>
> When the system is able to suspend it takes an eternity (more than 3
> minutes to wake-up, the radeon apparently being responsible for quite
> a big share of that slowness.
>
>
> Duri
On Sun, 02 May 2010 Bruno Prémont wrote:
> On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
>
> When the system is able to suspend it takes an eternity (more than 3
> minutes to wake-up, the radeon apparently being responsible for quite
> a big sh
On Sun, 2 May 2010 17:59:17 -0400 (EDT) Alan Stern wrote:
> On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote:
>
> > > There's no way to fix the USB problem without knowing what goes
> > > wrong. Let's see how far you get before the system freezes on a
> > > kernel with CONFIG_USB_DEBUG enabled.
> >
On Sun, 2 May 2010 17:59:17 -0400 (EDT) Alan Stern wrote:
> On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote:
>
> > > There's no way to fix the USB problem without knowing what goes
> > > wrong. Let's see how far you get before the system freezes on a
> > > kernel with CONFIG_USB_DEBUG enabled.
> >
On Sun, 02 May 2010 "Rafael J. Wysocki" wrote:
> On Sunday 02 May 2010, Bruno Pr?mont wrote:
> > On Sun, 02 May 2010 Alan Stern wrote:
> > > On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote:
> > > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
> > > > It freezes during device s
On Sun, 02 May 2010 Alan Stern wrote:
> On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote:
> > On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
> > It freezes during device suspend (unless I rmmod everything USB
> > related) - usb fails even in pm_test case 'devices'.
> >
> > When t
Hi,
On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
It freezes during device suspend (unless I rmmod everything USB
related) - usb fails even in pm_test case 'devices'.
When the system is able to suspend it takes an eternity (more than 3
minutes to wake-up, the radeon apparently
On Sun, 02 May 2010 "Rafael J. Wysocki" wrote:
> On Sunday 02 May 2010, Bruno Prémont wrote:
> > On Sun, 02 May 2010 Alan Stern wrote:
> > > On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote:
> > > > On a IEI Kino 690S1 I'm having a hard time to get s2
On Sun, 02 May 2010 Alan Stern wrote:
> On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote:
> > On a IEI Kino 690S1 I'm having a hard time to get s2ram running.
> > It freezes during device suspend (unless I rmmod everything USB
> > related) - usb fails even in pm_test case 'devices'.
> >
> > When t
72 matches
Mail list logo
