From owner-freebsd-x11@freebsd.org Thu Sep 3 22:38:01 2015 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E61A9C966C for ; Thu, 3 Sep 2015 22:38:01 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from nm42-vm8.bullet.mail.ne1.yahoo.com (nm42-vm8.bullet.mail.ne1.yahoo.com [98.138.120.214]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 037EDF42 for ; Thu, 3 Sep 2015 22:38:00 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441319526; bh=gW14ToBaNIyaEoUc8YSUJP9vT/dadnCCN5xt20n0wI8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=TgFyVoreKhbdMtFxjUNs9G27icZn2jQNBXIb1j27M2n8InMtUShMRYaGPcMgPDF5COzL/58MuKS/+fXUJ9Kyxf1BfJ+CEJozVD2PBjKJRlm4NuCEfH3437dmb2QPnBwZkUVImNRm+fpg9rFn/3PVdePClGSpV4c6x+02rAuOzT28hcQi+ayOJVvGy9GJRF7UWkMkpLo4u4aebB0KA8cDcLr843qycoUC+AhCyyfENCoT8Wh54EDe/RCzeiM6ZJZ7UKKtDPj/G6ImdKN3bBVuqn2jn9QhDDQfCkLsrJiCqdKPlPZkkbzz2ODvV8hdLG7gNVu5MCr8Jls33p1lRuYplQ== Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 03 Sep 2015 22:32:06 -0000 Received: from [98.138.100.116] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 03 Sep 2015 22:29:19 -0000 Received: from [98.139.170.178] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 03 Sep 2015 22:29:19 -0000 Received: from [98.139.213.9] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 03 Sep 2015 22:29:19 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 03 Sep 2015 22:29:19 -0000 X-Yahoo-Newman-Id: 541456.34245.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-4 X-YMail-OSG: eY53I60VM1l9CNOhUln8nh6hka8AIDQbay84txpX7.bzOum .1kCNUMkLTqynxSYzyEpj4YbGRDd63NhCAfRL__Cq_gfdVSPwCb_XXWIzRyo rkGM5w.qmRfLpBPQti.jSRuaZSHwM5rtJjggcJ9BwKOBEhbGHRSJMKH88w8. KMXgxI3UAt4W4Q16LQ2OllCR_XA0N17ZtLPIoDFuNgOnLEQfLrc62rDqmMzA lLFnm95q7oC0LNjel6JxqOfwu6nXdpZ_mpe.AZShwaYQt2MFMr.ViHnHXVmQ GXr4Ji27zKWhekQZhgEb77Y2zDAFxlwMib2CkIC9eP8Z4hjnGsqUZJ5j3C4I xa2CHMH4Jy9YkUUJS9RSkLHcaG0J9zmB8J2Wl2L.FGzkHHgYZfR8sJY7R6hi GeauGunDyzl0U3KJkWd9HRdkXRu1oJgMt.3g3C2ShZhnR9q.KOMtdIQREufU l1EABgf0gibSE0nI5swqcj7gXBZbUjdm5pY7my53_AQAfnYdAbOLtSns3z4b UfjUVI9bQA4BW2LHMxi_U3Z9A5Ip_Vtq3LAapCZ7WIDcMYQM- X-Yahoo-SMTP: 9sPoSQ2swBBlERuQ.0vs8XLc_MeClW0- Message-ID: <55E8C9BE.2060202@yahoo.com> Date: Thu, 03 Sep 2015 18:29:18 -0400 From: Anthony Jenkins Organization: VTilt Digital, LLC User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adrian Chadd , Andriy Gapon CC: "freebsd-acpi@freebsd.org" , FreeBSD Current , Garrett Cooper , freebsd-x11 Subject: Re: acpi suspend debugging techniques? References: <55E3F098.9060806@FreeBSD.org> <55E88860.8020404@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 22:38:01 -0000 My Radeon card comes back from resume, but the backlight doesn't (it stays off). Think this patch might help with that? I was gonna start a separate thread to ask for help debugging my backlight issue... Thanks, Anthony On 09/03/15 16:06, Adrian Chadd wrote: > oioo, would you please put that radeon patch into a review? > > I have an older machine with a radeon card in it that doesn't yet > suspend/resume; I can now test it out! > > > -a > > > On 3 September 2015 at 10:50, Andriy Gapon wrote: >> On 31/08/2015 11:53, Adrian Chadd wrote: >>> Try disabling hardware one at a time. Ie, unload usb; unload wifi; >>> leave kms loaded for mostly obvious reasons. >> Adrian, Garrett, >> >> thank you very much for your tips. >> Turned out that it was radeonkms that was causing the problem :-) >> >> BTW, here is another tool for the toolkit: on sufficiently recent system devctl >> suspend and devctl resume can be used to test individual drivers. >> >> So, I noticed that I could suspend/resume drmn0 device just fine but with >> vgapci0 I had a trouble suspending. One thing led to another and here is a >> patch that seems to fix the problem for me: >> ------------------------------------------------------------------------------- >> commit fecb5e8a90631f06600d87165cc8b6de3e035dfc >> Author: Andriy Gapon >> Date: Thu Sep 3 17:24:23 2015 +0300 >> >> radeon_suspend_kms: don't mess with pci state that's managed by the bus >> >> The pci bus driver handles the power state and configuration state saving >> and restoring for its child devices. >> >> diff --git a/sys/dev/drm2/radeon/radeon_device.c >> b/sys/dev/drm2/radeon/radeon_device.c >> index e5c676b11ed47..73b2f4c51ada2 100644 >> --- a/sys/dev/drm2/radeon/radeon_device.c >> +++ b/sys/dev/drm2/radeon/radeon_device.c >> @@ -1342,14 +1342,10 @@ int radeon_suspend_kms(struct drm_device *dev) >> >> radeon_agp_suspend(rdev); >> >> - pci_save_state(device_get_parent(dev->dev)); >> #ifdef FREEBSD_WIP >> if (state.event == PM_EVENT_SUSPEND) { >> /* Shut down the device */ >> pci_disable_device(dev->pdev); >> -#endif /* FREEBSD_WIP */ >> - pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3); >> -#ifdef FREEBSD_WIP >> } >> console_lock(); >> #endif /* FREEBSD_WIP */ >> @@ -1380,10 +1376,6 @@ int radeon_resume_kms(struct drm_device *dev) >> >> #ifdef FREEBSD_WIP >> console_lock(); >> -#endif /* FREEBSD_WIP */ >> - pci_set_powerstate(device_get_parent(dev->dev), PCI_POWERSTATE_D0); >> - pci_restore_state(device_get_parent(dev->dev)); >> -#ifdef FREEBSD_WIP >> if (pci_enable_device(dev->pdev)) { >> console_unlock(); >> return -1; >> ------------------------------------------------------------------------------- >> >> However, I am not sure about an exact mechanism of the hard system hang that I >> experienced without the patch. >> >> BTW, I noticed that only very few drivers make explicit calls to >> pci_set_powerstate and pci_save_state/pci_restore_state. >> sys/dev/usb/controller/ohci_pci.c looks like a good use of pci_set_powerstate. >> sys/dev/ixgbe/if_ix.c looks like an incorrect / redundant use of the functions. >> >> -- >> Andriy Gapon > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- Anthony Jenkins Software Engineer VTilt Digital, LLC