From owner-freebsd-acpi@FreeBSD.ORG Sun Feb 22 18:08:24 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 432ED91F for ; Sun, 22 Feb 2015 18:08:24 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E7B8FC6 for ; Sun, 22 Feb 2015 18:08:23 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 251FAD13C9 for ; Sun, 22 Feb 2015 10:08:17 -0800 (PST) Date: Sun, 22 Feb 2015 10:08:17 -0800 From: hiren panchasara To: freebsd-acpi@freebsd.org Subject: No acpi_dell(4) Message-ID: <20150222180817.GD27984@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 18:08:24 -0000 --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've just got a lightweight dell e7240 which is pretty nice with very good batterylife.=20 Only trouble is none of the buttons work. Is there any hackery people do to make them work? Time permitting, I'd like to see if we can get something together which looks like acpi_ibm. cheers, Hiren --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJU6hsQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lz+8H/0imY5029rQhT361Io3LnoeK t9J7DyiQFZeJSJ7Ko4MlhMkpcdfgwJDt5r6vqphKaEUvYObTFvA4LPq5djnzGn38 3Pyfcd7TMUqr2HK4zmE11KZNK0Rbr66KCzseL8aFOTOdkXhliEBV74yr3nUWlEEH xxLaVYdhIb7jY6IZlke9W3+FWrOr1JEabUuuOvyj/RTZHOUmnPh5J/yQTIgl1sI3 vC1WF7sZsaj/OLN7G6vr5p/B2OQD2O9pLdqq4wDdaUgh6uP4Oy4Z1ydfuYuKFIfY hefvLX78iY83OwzKuSXWEq2oF15eDGo2w9guZrIcE2c4SpgL1fMvKOj1Jq4L/S0= =0tGn -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59-- From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 23 20:23:05 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05FA051A for ; Mon, 23 Feb 2015 20:23:05 +0000 (UTC) Received: from nm6-vm4.bullet.mail.ne1.yahoo.com (nm6-vm4.bullet.mail.ne1.yahoo.com [98.138.91.166]) (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 BA4339F2 for ; Mon, 23 Feb 2015 20:23:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1424722978; bh=ABHd//6dSu1gCLmst2DE/i+Y286Ykf94dAvH8cl6rcs=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=siB4GvkHk6Cz6DuiwcnK/J1qIbMQ2M+Xeg7to+sC1s8zZinfdug2D2u3Mkmi7uglohRS5g9HlDb73RVv6XMQFYbrBT1UGsybrGRPiuujbf3uf8a74q0FM9IKphlMpQE8m5mgJqF+7tjnRMzSKMTT23D/EYa7uyWhRTicf5f+Ja8= Received: from [98.138.100.116] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 23 Feb 2015 20:22:58 -0000 Received: from [98.138.226.132] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 23 Feb 2015 20:22:58 -0000 Received: from [127.0.0.1] by smtp219.mail.ne1.yahoo.com with NNFMP; 23 Feb 2015 20:22:58 -0000 X-Yahoo-Newman-Id: 513267.94420.bm@smtp219.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dqi_ftwVM1lZZbV7frVm3.Cg9uSjx6dPoxCWKFF.3cxJmO2 2mzCFspu9ErneXmPiqSrd5tPKY5D3j0bTdLT46O.jAzs1H5K2.1Ma9FDShuL FpTdZcKipoS2yhnfK_vYpeMuL.PpVcVhUQj7Na9iB5f92zo.o3jSCB10GBeO XHeAeQRaJZfqf4ORjBPnDr_vT3M7tsehzN3xifvRXnvBmjRmmYiR8aX1C26h 4LrNhRMQ70HwiB4F9fO4wWG2YictGHtsd6mZ_osyXZcsvOBYUikPlRaNMgLI EMr8i4UO8Tkk9YIiYuHIv7gEUAVZeWnbpPbK37GijfeEx7qmS2IR5DazbOSs s0gbg9qcI88LNMO9NurVjKkiKzJrHrHE8dC_EyXvGIVi_qaqnYri8voABJSp RNcV2SoLPYvSUCXBj6B3s3xQEVASRBA9huwzL17EU6X8ztKwfYi7VOs4uSCf Khd13u.pUSX6vfsQXaam0xdVKQXWKDKfU6BFgw1KlyZv7e3fCNw9n0hEHARA 3wr6x2u5eIZpyiB.ToupRtntNpgAQcbEo_JzsVYvevUS18Q-- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <54EB8C21.2080600@att.net> Date: Mon, 23 Feb 2015 15:22:57 -0500 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: hiren panchasara Subject: Re: No acpi_dell(4) References: <20150222180817.GD27984@strugglingcoder.info> In-Reply-To: <20150222180817.GD27984@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 20:23:05 -0000 On 02/22/2015 01:08 PM, hiren panchasara wrote: > I've just got a lightweight dell e7240 which is pretty nice with very > good batterylife. > > Only trouble is none of the buttons work. > > Is there any hackery people do to make them work? Time permitting, I'd > like to see if we can get something together which looks like acpi_ibm. Some machines throw acpi_wmi(4) events when those special buttons are pushed. Load acpi_wmi(4) driver and cat /proc/wmistat0. The WMI objects with hex numbers in the EVENT column *might* be for your keys. My HP Envy Sleekbook uses WMI for the radios key, but I haven't figured out how to get events for the LCD brightness control keys (although my brightness controls *do* work). I used a Linux driver as a reference tho... I'd like to make the acpi_wmi(4) interface easier to use, but my backlog of contributions I'm sitting on is only growing. Anthony > cheers, > Hiren From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 25 21:50:14 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A81F92A for ; Wed, 25 Feb 2015 21:50:14 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21BF5E2D for ; Wed, 25 Feb 2015 21:50:14 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 14368B9B4; Wed, 25 Feb 2015 16:50:13 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Subject: Re: No acpi_dell(4) Date: Wed, 25 Feb 2015 14:53:53 -0500 Message-ID: <2401337.2oUs7iAbtB@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54EB8C21.2080600@att.net> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 25 Feb 2015 16:50:13 -0500 (EST) Cc: Anthony Jenkins X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 21:50:14 -0000 On Monday, February 23, 2015 03:22:57 PM Anthony Jenkins wrote: > On 02/22/2015 01:08 PM, hiren panchasara wrote: > > I've just got a lightweight dell e7240 which is pretty nice with very > > good batterylife. > > > > Only trouble is none of the buttons work. > > > > Is there any hackery people do to make them work? Time permitting, I'd > > like to see if we can get something together which looks like acpi_ibm. > > Some machines throw acpi_wmi(4) events when those special buttons are > pushed. Load acpi_wmi(4) driver and cat /proc/wmistat0. The WMI > objects with hex numbers in the EVENT column *might* be for your keys. > My HP Envy Sleekbook uses WMI for the radios key, but I haven't figured > out how to get events for the LCD brightness control keys (although my > brightness controls *do* work). I used a Linux driver as a reference tho... > > I'd like to make the acpi_wmi(4) interface easier to use, but my backlog > of contributions I'm sitting on is only growing. I've been waiting to see if you were going to post an update to rev 3 of your CMOS patch after Ian's last round of feedback FWIW. Much of his feedback seemed relevant (and I know you've already accepted some other rounds of feedback on that patch before then, hence 'v3') -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 26 15:36:16 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9482A189 for ; Thu, 26 Feb 2015 15:36:16 +0000 (UTC) Received: from nm19-vm5.bullet.mail.ne1.yahoo.com (nm19-vm5.bullet.mail.ne1.yahoo.com [98.138.91.241]) (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 5BED07F8 for ; Thu, 26 Feb 2015 15:36:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1424964969; bh=vGhXhqxxOu6XRPlOcqfrLhh2e0Coz7sYnZalrff7sdw=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=IWvdw6pOPYvQMODcsTxvFio8fdQxBm1cpXwiaUM8k5ODpzZXvVlUWYfLpj7tv063JWWbTHroioiPdZUKbHuQ3sjlwvoc0uijuvTOzcvF/qsbnGK0nu0MKNuymo2cdAHXOWR+Ep5/jnBu/ArPQ+hJJe1u1ixSfQoxCvXHyncs27w= Received: from [98.138.226.176] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 26 Feb 2015 15:36:09 -0000 Received: from [98.138.84.47] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 26 Feb 2015 15:36:09 -0000 Received: from [127.0.0.1] by smtp115.mail.ne1.yahoo.com with NNFMP; 26 Feb 2015 15:36:09 -0000 X-Yahoo-Newman-Id: 88036.80543.bm@smtp115.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6RT25sAVM1m81un04FJOiFfSGARCzeqJC0P5NeTYLshRVoP yqWV7in6Z5gkPI7j7Q0i.bpFqmh1KNfP7WtEjEAVcWegFmRxt3ywUumol2UG FszDUYIdQVJ88_oSytTs1guP90mWd6kj4ZzaQRZ.58kRnbRj_wzqYh84D6s9 C0tzfKecgXTbAKQsKVw4pMhRUpNowQwyJzindYtDgr14EGZ3Pbs1wOntCKj5 aM3oUVDLuN8WLV5eqq3zPctfWe.5TAYXqri9EXVyXJvmBWjPfQfBHeVZ24cZ VnquFUM0z_9fxkop5u.m6fMwsxYyoYn9RfWDeBSx55iZxmlBciQVx40t6vkz ttJFFwVHcxOKuDbDVY43iF3L0Bevywm9ePTmgsMs5bX5yjbjiut5AYPkZOzk gxYBpLZNfhRdBwbcZSdkUiSNwKJn24PieqLk_gOLhGom34gNgmXEw186OHGa MwZ7Ja0BAQsrmZjePAdComLT0Swhsk2S23NGOm7SdItT1Oqu3lwnG4BWyF.M Q1s5usParPKqvS6OyL39qA2sm2BEydWyO0wWtxU8JoJ9D5ySZ X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <54EF3D5D.4010106@att.net> Date: Thu, 26 Feb 2015 10:35:57 -0500 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: John Baldwin , freebsd-acpi@freebsd.org Subject: Re: No acpi_dell(4) References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> In-Reply-To: <2401337.2oUs7iAbtB@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 15:36:16 -0000 On 02/25/2015 02:53 PM, John Baldwin wrote: > On Monday, February 23, 2015 03:22:57 PM Anthony Jenkins wrote: >> On 02/22/2015 01:08 PM, hiren panchasara wrote: >>> I've just got a lightweight dell e7240 which is pretty nice with very >>> good batterylife. >>> >>> Only trouble is none of the buttons work. >>> >>> Is there any hackery people do to make them work? Time permitting, I'd >>> like to see if we can get something together which looks like acpi_ibm. >> Some machines throw acpi_wmi(4) events when those special buttons are >> pushed. Load acpi_wmi(4) driver and cat /proc/wmistat0. The WMI >> objects with hex numbers in the EVENT column *might* be for your keys. >> My HP Envy Sleekbook uses WMI for the radios key, but I haven't figured >> out how to get events for the LCD brightness control keys (although my >> brightness controls *do* work). I used a Linux driver as a reference tho... >> >> I'd like to make the acpi_wmi(4) interface easier to use, but my backlog >> of contributions I'm sitting on is only growing. > I've been waiting to see if you were going to post an update to rev 3 of your > CMOS patch after Ian's last round of feedback FWIW. Much of his feedback > seemed relevant (and I know you've already accepted some other rounds of > feedback on that patch before then, hence 'v3') > I am... I've just been stalling, mostly because it "works for me" and I didn't understand some of the critiques, particularly the "pessimization" one (over my head I think). I'll toss what I have out there for further review; I'll shoot for today or tomorrow. One of the things I felt I had to do in the CMOS handler was allow ACPI to perform multibyte accesses to the CMOS region, but the existing CMOS read/write functions were only byte accessors, and each byte access was locked. A multibyte access would lock, read/write a byte, unlock, lock, read/write a byte, unlock.... So I wrote multibyte accessors (which had some issues I think I corrected) and had the original RTC CMOS accessor functions call the multibyte ones. The multibyte accessors performed the locking, so a multibyte access would lock, read/write a byte, read/write a byte..., unlock. I believe one of the recommendations was to "put it back the way it was", which I did, along with failing any attempt by ACPIBIOS to access multiple bytes. I think the reason behind having an ACPI CMOS handler is to give the OS a say when ACPIBIOS wants to access CMOS, to prevent it from stepping on the toes of an RTC CMOS driver who's also twiddling CMOS registers and (presumably) knows the state of the device. Anthony From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 27 14:53:16 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AD4B336; Fri, 27 Feb 2015 14:53:16 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D725F6AE; Fri, 27 Feb 2015 14:53:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t1REr5SI052357; Sat, 28 Feb 2015 01:53:05 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 28 Feb 2015 01:53:04 +1100 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)] In-Reply-To: <54EF3D5D.4010106@att.net> Message-ID: <20150227222203.P38620@sola.nimnet.asn.au> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 14:53:16 -0000 On Thu, 26 Feb 2015 10:35:57 -0500, Anthony Jenkins wrote: > On 02/25/2015 02:53 PM, John Baldwin wrote: > > On Monday, February 23, 2015 03:22:57 PM Anthony Jenkins wrote: [.. omissions reflecting change of subject ..] > >> I'd like to make the acpi_wmi(4) interface easier to use, but my backlog > >> of contributions I'm sitting on is only growing. > > I've been waiting to see if you were going to post an update to rev 3 of your > > CMOS patch after Ian's last round of feedback FWIW. Much of his feedback > > seemed relevant (and I know you've already accepted some other rounds of > > feedback on that patch before then, hence 'v3') > > > I am... I've just been stalling, mostly because it "works for me" and I > didn't understand some of the critiques, particularly the > "pessimization" one (over my head I think). I'll toss what I have out > there for further review; I'll shoot for today or tomorrow. > > One of the things I felt I had to do in the CMOS handler was allow ACPI > to perform multibyte accesses to the CMOS region, but the existing CMOS > read/write functions were only byte accessors, and each byte access was > locked. A multibyte access would lock, read/write a byte, unlock, lock, > read/write a byte, unlock.... So I wrote multibyte accessors (which had > some issues I think I corrected) and had the original RTC CMOS accessor > functions call the multibyte ones. The multibyte accessors performed > the locking, so a multibyte access would lock, read/write a byte, > read/write a byte..., unlock. > > I believe one of the recommendations was to "put it back the way it > was", which I did, along with failing any attempt by ACPIBIOS to access > multiple bytes. You can safely ignore the deeper and rather sideways discussion Bruce and I engaged in; I was bewildered by the idea of 'good pessimisations' too, which is why I pursued it, arguably too far, but I learned things. However the takeaway was agreement that for multiple reasons, multibyte acpi_cmos access should loop on using the system rtcin() and writertc() as is - modulo your useful macros esp. IO_DELAY() documenting inb(0x84) - and that setting bit 7 on IO_RTC_ADDR, _possibly_ disabling NMI on some older hardware, is inadvisable. As you pointed out, PNP0B00 only wants to access CMOS from 0x00-0x3f anyway, so why not just mask reg with 0x3f while calling rtcin()/writertc() ? Don't worry about any extra locking; this is going to be used at boot and/or resume we assume; atrtc_settime() for one is called by default every 1800 seconds if running ntpd, and it doesn't bother holding the lock through multiple writertc() calls. Any (optional) user of the RTC as an interval timer source, particularly at high rates, will appreciate the existing pre-selection of last register used, as Bruce explained. I'm unsure whether any stats or profiling still uses the RTC at all? kern.clockrate: { hz = 1000, tick = 1000, profhz = 8126, stathz = 127 } So I would suggest: . reading any bytes except 0x0c is safe (though in the case of time or date bytes, possibly invalid if read while what the datasheet calls the UIP bit is set): #define RTC_STATUSA 0x0a /* status register A */ #define RTCSA_TUP 0x80 /* time update, don't look now */ . the only conceivable bytes permissable to allow writing are: . below 0x10: bytes 1, 3 and 5 (alarm seconds, minute, hour). While they're no use whilever we don't support wake on alarm and should also be written during non-update periods, should be safe enough. . 0x10 - 0x2f: none, unless you're prepared to copy the procedure in /sys/dev/nvram/nvram.c to calculate and write the checksum to 0x2e and 0x2f. I think we should just deny and log such access, unless and until someone shows log messages demonstrating a perceived need. . 0x30 through 0x3f: I guess you could allow write access, at least I haven't heard of anything using that area for anything, but check .. I recall reading that we don't use this, at least on x86: #define RTC_CENTURY 0x32 /* current century */ . in any case, log all access, accepted or denied, at kern.notice ono. > acpi_rtc_cmos_handler: READ 01 address=0006 value=00000006 > acpi_rtc_cmos_handler: READ 01 address=0004 value=00000015 > acpi_rtc_cmos_handler: READ 01 address=0002 value=00000006 Bruce called them ugly, but I'm happy such access is so obvious .. > I think the reason behind having an ACPI CMOS handler is to give the OS > a say when ACPIBIOS wants to access CMOS, to prevent it from stepping on > the toes of an RTC CMOS driver who's also twiddling CMOS registers and > (presumably) knows the state of the device. Indeed. Virtually all of the state, apart from the default reset state, is stored in RTC status/control registers, though different consumers presumably know more. I haven't explored the code that may use the RTC as an eventtimer - albeit of quality 0. The OS needs more than a 'say'; once booted it's in charge of time and any functions relating to the RTC, and may choose to provide services to ACPI AML code, which is, far all the kernel knows, untrustworthy code; vendor, TLA? and user-updateable. "Let's be careful out there .." cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 28 02:56:22 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19664B7 for ; Sat, 28 Feb 2015 02:56:22 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id B6F2D222 for ; Sat, 28 Feb 2015 02:56:21 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id BC9D14242A7; Sat, 28 Feb 2015 13:56:18 +1100 (AEDT) Date: Sat, 28 Feb 2015 13:56:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Smith Subject: Re: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)] In-Reply-To: <20150227222203.P38620@sola.nimnet.asn.au> Message-ID: <20150228125857.D1277@besplex.bde.org> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Za4kaKlA c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=Mutz-B-Jl4nSLhCWpJ8A:9 a=LYubwcqQZwfGt1ix:21 a=Vo-5cW9kjHq5j94D:21 a=CjuIK1q_8ugA:10 Cc: Anthony Jenkins , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 02:56:22 -0000 On Sat, 28 Feb 2015, Ian Smith wrote: > On Thu, 26 Feb 2015 10:35:57 -0500, Anthony Jenkins wrote: > > On 02/25/2015 02:53 PM, John Baldwin wrote: > > > On Monday, February 23, 2015 03:22:57 PM Anthony Jenkins wrote: > [.. omissions reflecting change of subject ..] > > >> I'd like to make the acpi_wmi(4) interface easier to use, but my backlog > > >> of contributions I'm sitting on is only growing. > > > > I've been waiting to see if you were going to post an update to rev 3 of your > > > CMOS patch after Ian's last round of feedback FWIW. Much of his feedback > > > seemed relevant (and I know you've already accepted some other rounds of > > > feedback on that patch before then, hence 'v3') > > > > > I am... I've just been stalling, mostly because it "works for me" and I > > didn't understand some of the critiques, particularly the > > "pessimization" one (over my head I think). I'll toss what I have out > > there for further review; I'll shoot for today or tomorrow. > > > > One of the things I felt I had to do in the CMOS handler was allow ACPI > > to perform multibyte accesses to the CMOS region, but the existing CMOS > > read/write functions were only byte accessors, and each byte access was > > locked. A multibyte access would lock, read/write a byte, unlock, lock, > > read/write a byte, unlock.... So I wrote multibyte accessors (which had > > some issues I think I corrected) and had the original RTC CMOS accessor > > functions call the multibyte ones. The multibyte accessors performed > > the locking, so a multibyte access would lock, read/write a byte, > > read/write a byte..., unlock. > > > > I believe one of the recommendations was to "put it back the way it > > was", which I did, along with failing any attempt by ACPIBIOS to access > > multiple bytes. > > You can safely ignore the deeper and rather sideways discussion Bruce > and I engaged in; I was bewildered by the idea of 'good pessimisations' > too, which is why I pursued it, arguably too far, but I learned things. "Good pessimization" = a good thing to do if you want to pessimize the software to sell new hardware. > However the takeaway was agreement that for multiple reasons, multibyte > acpi_cmos access should loop on using the system rtcin() and writertc() > as is - modulo your useful macros esp. IO_DELAY() documenting inb(0x84) > - and that setting bit 7 on IO_RTC_ADDR, _possibly_ disabling NMI on > some older hardware, is inadvisable. As you pointed out, PNP0B00 only > wants to access CMOS from 0x00-0x3f anyway, so why not just mask reg > with 0x3f while calling rtcin()/writertc() ? I don't really like IO_NDELAY() even though it is clearer. 386BSD had a macro for this, at least in asm code. It was named cryptically as DUMMY_NOPS. It was sprinkled ad nauseum for 3 reasons: - the author didn't understand some i386 complications related to the 8259 interrupt controller, and delays reduced the bugs - some delays were actually needed - some delays were used due to FUD. All these inb(0x84) delays have gone away except for a few in the RTC routines and 1 in the i8254 timer part DELAY(). The delays in the RTC routines are probably now FUD even if they were needed in 1990. The delay in DELAY() really is still needed, to fake DELAY(1) when the i8254 is unavailable locked out. There the code is ifdefed for pc98 so as to use 0x5f instead of 0x84. The RTC routines never used 0x5f or even avoided using 0x84. The delays were more needed in 1990 than now. Now the ISA bus is behind a PCI bus or two, or possibly faked. Accessing it tends to take about twice as long as in a 1990's system configured with minimal ISA delays, and modern hardware shouldn't need such long delays anyway, or can be smarter and force them iff necessary. > Don't worry about any extra locking; this is going to be used at boot > and/or resume we assume; atrtc_settime() for one is called by default > every 1800 seconds if running ntpd, and it doesn't bother holding the > lock through multiple writertc() calls. Any (optional) user of the RTC > as an interval timer source, particularly at high rates, will appreciate > the existing pre-selection of last register used, as Bruce explained. atrtc_settime() is too buggy to use except in emergency. One of its bugs is that it is sloppy about setting times. atrtc_gettime() (spelling?) is also sloppy about getting times. The combined error is about 1-2 seconds. So it is useless to set the clock unless it it has changed by more than 1 second. But in 1800 seconds, the RTC should not have drifted more than a few milliseconds. The next of its bugs is that it has no locking. Races from this can result in writing its registers inconsistently. This makes witing to it unless it has changed by more than 1 second worse than useless. Except the next write is likely to fix it up after losing a race on the previous write. It would be a reasonable fix to read after write to check that the write worked. This only loses if the system crashes just after a write that doesn't work or if another process reads the bad result before it can be fixed. > I'm unsure whether any stats or profiling still uses the RTC at all? > kern.clockrate: { hz = 1000, tick = 1000, profhz = 8126, stathz = 127 } Non power-of-2 rates for profhz and stathz on i386 indicate that the lapic timer is being used for them (and the RTC is not used for anything except initialization). > So I would suggest: > > . reading any bytes except 0x0c is safe (though in the case of time or > date bytes, possibly invalid if read while what the datasheet calls > the UIP bit is set): > #define RTC_STATUSA 0x0a /* status register A */ > #define RTCSA_TUP 0x80 /* time update, don't look now */ > > . the only conceivable bytes permissable to allow writing are: > > . below 0x10: bytes 1, 3 and 5 (alarm seconds, minute, hour). While > they're no use whilever we don't support wake on alarm and should > also be written during non-update periods, should be safe enough. > > . 0x10 - 0x2f: none, unless you're prepared to copy the procedure in > /sys/dev/nvram/nvram.c to calculate and write the checksum to 0x2e > and 0x2f. I think we should just deny and log such access, unless > and until someone shows log messages demonstrating a perceived need. > > . 0x30 through 0x3f: I guess you could allow write access, at least I > haven't heard of anything using that area for anything, but check .. > I recall reading that we don't use this, at least on x86: > #define RTC_CENTURY 0x32 /* current century */ > > . in any case, log all access, accepted or denied, at kern.notice ono. > > acpi_rtc_cmos_handler: READ 01 address=0006 value=00000006 > > acpi_rtc_cmos_handler: READ 01 address=0004 value=00000015 > > acpi_rtc_cmos_handler: READ 01 address=0002 value=00000006 > Bruce called them ugly, but I'm happy such access is so obvious .. Er, I would call that either debugging cruft or spamming the logs :-). > > I think the reason behind having an ACPI CMOS handler is to give the OS > > a say when ACPIBIOS wants to access CMOS, to prevent it from stepping on > > the toes of an RTC CMOS driver who's also twiddling CMOS registers and > > (presumably) knows the state of the device. > > Indeed. Virtually all of the state, apart from the default reset state, > is stored in RTC status/control registers, though different consumers > presumably know more. I haven't explored the code that may use the RTC > as an eventtimer - albeit of quality 0. > > The OS needs more than a 'say'; once booted it's in charge of time and > any functions relating to the RTC, and may choose to provide services to > ACPI AML code, which is, far all the kernel knows, untrustworthy code; > vendor, TLA? and user-updateable. "Let's be careful out there .." Bruce From owner-freebsd-acpi@FreeBSD.ORG Sat Feb 28 04:26:29 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CA041C9 for ; Sat, 28 Feb 2015 04:26:29 +0000 (UTC) Received: from nm5-vm3.bullet.mail.gq1.yahoo.com (nm5-vm3.bullet.mail.gq1.yahoo.com [98.136.218.178]) (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 D8767E77 for ; Sat, 28 Feb 2015 04:26:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1425097582; bh=Ez+DRs+8ss41hAHJ6/4FCZoHcSva+lwN73TV2FaGTF8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=TlM3THKVKHDh6joVSSUrxNHMo98TFZsVoFl8696zJEr/p7wodRGG/EKkC6iGKZWlvOHi6d8PhRSSGHPMrkRDCyLGHJpnEAaNrpVQzWWFIq2J6Y9dGTlPiXfnOw5n6O/Jn9Q/arBatxYkC8jT1JyCr+zbt9UJ9ulgEBlXT7Bxil4= Received: from [98.137.12.59] by nm5.bullet.mail.gq1.yahoo.com with NNFMP; 28 Feb 2015 04:26:22 -0000 Received: from [98.138.226.63] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 28 Feb 2015 04:26:21 -0000 Received: from [127.0.0.1] by smtp214.mail.ne1.yahoo.com with NNFMP; 28 Feb 2015 04:26:21 -0000 X-Yahoo-Newman-Id: 830181.24320.bm@smtp214.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4HXArZsVM1lqPWqrUQuZ3boRlYvoEncEs6b15be4.jdHqvl AaZXwO2yorBdYc1Wf20u.zhC.QKzLrO4x.60dvSG6K9LkRl0VDH83..B9ZGw 8NPwu8gZ9b55k5vjFYZia0qh9bguOoUCtVcc1e_cqUFlF6bCML.9nw3gxILq XaYQnHaNrGd2D59uGSdfjQQFWyg.QF2ryiuenGcWuSApKSlNPwtTMFtgSbZV VleDX9mmOcIYIDtgQn_5XriMiTKhwM0Px5RBhvJc0y4RCTUODUbtcA1EHnzV aSvITNkTxF7n_dLWSLmACFT6.iVus2ysiNmLrzpU8l3uuWDERvM.gTcK3_jS lc18BBD6wFIaxEs6CWhr1gcmWTa1ve2QkU5Wqhka96wB2X4tmTtUeG2aZkXX GyeH_dmX3vLy783qNZdutxznEGOGyMmX2K3pRujQT0ki3e5ep2ddfTGfTU59 yYx4xFnBA7lUG4wi03h4FEUOk_O7BwPDppKWVErbtDO0Z1NRWGLgB02VGlXh 4usul8B1.40wGQhCOgLkwTKOcAKFZQb1AgfiMxtkdDdw6IS8L8xM- X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <54F14368.4020807@att.net> Date: Fri, 27 Feb 2015 23:26:16 -0500 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bruce Evans , Ian Smith Subject: Re: [PATCH] ACPI CMOS region support rev. 3 [was Re: No acpi_dell(4)] References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> In-Reply-To: <20150228125857.D1277@besplex.bde.org> Content-Type: multipart/mixed; boundary="------------030205080106070406040103" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 04:26:29 -0000 This is a multi-part message in MIME format. --------------030205080106070406040103 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 02/27/15 21:56, Bruce Evans wrote: > On Sat, 28 Feb 2015, Ian Smith wrote: > >> On Thu, 26 Feb 2015 10:35:57 -0500, Anthony Jenkins wrote: >> > On 02/25/2015 02:53 PM, John Baldwin wrote: >> > > On Monday, February 23, 2015 03:22:57 PM Anthony Jenkins wrote: >> [.. omissions reflecting change of subject ..] >> > >> I'd like to make the acpi_wmi(4) interface easier to use, but my >> backlog >> > >> of contributions I'm sitting on is only growing. >> >> > > I've been waiting to see if you were going to post an update to >> rev 3 of your >> > > CMOS patch after Ian's last round of feedback FWIW. Much of his >> feedback >> > > seemed relevant (and I know you've already accepted some other >> rounds of >> > > feedback on that patch before then, hence 'v3') >> > > >> > I am... I've just been stalling, mostly because it "works for me" >> and I >> > didn't understand some of the critiques, particularly the >> > "pessimization" one (over my head I think). I'll toss what I have out >> > there for further review; I'll shoot for today or tomorrow. >> > >> > One of the things I felt I had to do in the CMOS handler was allow >> ACPI >> > to perform multibyte accesses to the CMOS region, but the existing >> CMOS >> > read/write functions were only byte accessors, and each byte access >> was >> > locked. A multibyte access would lock, read/write a byte, unlock, >> lock, >> > read/write a byte, unlock.... So I wrote multibyte accessors >> (which had >> > some issues I think I corrected) and had the original RTC CMOS >> accessor >> > functions call the multibyte ones. The multibyte accessors performed >> > the locking, so a multibyte access would lock, read/write a byte, >> > read/write a byte..., unlock. >> > >> > I believe one of the recommendations was to "put it back the way it >> > was", which I did, along with failing any attempt by ACPIBIOS to >> access >> > multiple bytes. >> >> You can safely ignore the deeper and rather sideways discussion Bruce >> and I engaged in; I was bewildered by the idea of 'good pessimisations' >> too, which is why I pursued it, arguably too far, but I learned things. > > "Good pessimization" = a good thing to do if you want to pessimize the > software to sell new hardware. Meh... sounds like it's bad (TM), whatever it is... > >> However the takeaway was agreement that for multiple reasons, multibyte >> acpi_cmos access should loop on using the system rtcin() and writertc() >> as is - modulo your useful macros esp. IO_DELAY() documenting inb(0x84) >> - and that setting bit 7 on IO_RTC_ADDR, _possibly_ disabling NMI on >> some older hardware, is inadvisable. As you pointed out, PNP0B00 only >> wants to access CMOS from 0x00-0x3f anyway, so why not just mask reg >> with 0x3f while calling rtcin()/writertc() ? > > I don't really like IO_NDELAY() even though it is clearer. 386BSD had > a macro for this, at least in asm code. It was named cryptically as > DUMMY_NOPS. It was sprinkled ad nauseum for 3 reasons: > - the author didn't understand some i386 complications related to the > 8259 interrupt controller, and delays reduced the bugs > - some delays were actually needed > - some delays were used due to FUD. > All these inb(0x84) delays have gone away except for a few in the RTC > routines and 1 in the i8254 timer part DELAY(). The delays in the RTC > routines are probably now FUD even if they were needed in 1990. The > delay in DELAY() really is still needed, to fake DELAY(1) when the > i8254 is unavailable locked out. There the code is ifdefed for pc98 > so as to use 0x5f instead of 0x84. The RTC routines never used 0x5f > or even avoided using 0x84. > > The delays were more needed in 1990 than now. Now the ISA bus is behind > a PCI bus or two, or possibly faked. Accessing it tends to take about > twice as long as in a 1990's system configured with minimal ISA delays, > and modern hardware shouldn't need such long delays anyway, or can be > smarter and force them iff necessary. > I don't mind pulling the inb(0x84) calls, if we're assuming FreeBSD won't be running on circa 1990 hardware. I don't really want to maintain atrtc(4), just stick an ACPI window on it. I can if I must though. >> Don't worry about any extra locking; this is going to be used at boot >> and/or resume we assume; Bleah... I hate assumptions like that. >> atrtc_settime() for one is called by default >> every 1800 seconds if running ntpd, and it doesn't bother holding the >> lock through multiple writertc() calls. Any (optional) user of the RTC >> as an interval timer source, particularly at high rates, will appreciate >> the existing pre-selection of last register used, as Bruce explained. > > atrtc_settime() is too buggy to use except in emergency. One of its > bugs is that it is sloppy about setting times. atrtc_gettime() > (spelling?) is also sloppy about getting times. The combined error > is about 1-2 seconds. So it is useless to set the clock unless it it > has changed by more than 1 second. But in 1800 seconds, the RTC > should not have drifted more than a few milliseconds. The next of its > bugs is that it has no locking. Races from this can result in writing > its registers inconsistently. This makes witing to it unless it has > changed by more than 1 second worse than useless. Except the next > write is likely to fix it up after losing a race on the previous write. > It would be a reasonable fix to read after write to check that the > write worked. This only loses if the system crashes just after a > write that doesn't work or if another process reads the bad result > before it can be fixed. I reverted that part and am calling the original atrtc() CMOS byte accessors in a loop from my ACPI accessors. > >> I'm unsure whether any stats or profiling still uses the RTC at all? >> kern.clockrate: { hz = 1000, tick = 1000, profhz = 8126, stathz = 127 } > > Non power-of-2 rates for profhz and stathz on i386 indicate that the > lapic timer is being used for them (and the RTC is not used for anything > except initialization). > >> So I would suggest: >> >> . reading any bytes except 0x0c is safe (though in the case of time or >> date bytes, possibly invalid if read while what the datasheet calls >> the UIP bit is set): >> #define RTC_STATUSA 0x0a /* status register A */ >> #define RTCSA_TUP 0x80 /* time update, don't look now */ >> >> . the only conceivable bytes permissable to allow writing are: >> >> . below 0x10: bytes 1, 3 and 5 (alarm seconds, minute, hour). While >> they're no use whilever we don't support wake on alarm and should >> also be written during non-update periods, should be safe enough. >> >> . 0x10 - 0x2f: none, unless you're prepared to copy the procedure in >> /sys/dev/nvram/nvram.c to calculate and write the checksum to 0x2e >> and 0x2f. I think we should just deny and log such access, unless >> and until someone shows log messages demonstrating a perceived need. >> >> . 0x30 through 0x3f: I guess you could allow write access, at least I >> haven't heard of anything using that area for anything, but check .. >> I recall reading that we don't use this, at least on x86: >> #define RTC_CENTURY 0x32 /* current century */ Right now I'm still just blocking all writes... I'll have to see if I'm throwing a kernel message in those cases. No wait, I take that back, I'm allowing writes to 0x00-0x09 and 0x0E-0xFF. I'll adjust that. I'm not printing any errors, just returning AE_BAD_PARAMETER. >> >> . in any case, log all access, accepted or denied, at kern.notice ono. >> > acpi_rtc_cmos_handler: READ 01 address=0006 value=00000006 >> > acpi_rtc_cmos_handler: READ 01 address=0004 value=00000015 >> > acpi_rtc_cmos_handler: READ 01 address=0002 value=00000006 >> Bruce called them ugly, but I'm happy such access is so obvious .. > > Er, I would call that either debugging cruft or spamming the logs :-). Yeah that was for my own edification :-) How would I make those tunable/quieter? > >> > I think the reason behind having an ACPI CMOS handler is to give >> the OS >> > a say when ACPIBIOS wants to access CMOS, to prevent it from >> stepping on >> > the toes of an RTC CMOS driver who's also twiddling CMOS registers and >> > (presumably) knows the state of the device. >> >> Indeed. Virtually all of the state, apart from the default reset state, >> is stored in RTC status/control registers, though different consumers >> presumably know more. I haven't explored the code that may use the RTC >> as an eventtimer - albeit of quality 0. >> >> The OS needs more than a 'say'; once booted it's in charge of time and >> any functions relating to the RTC, and may choose to provide services to >> ACPI AML code, which is, far all the kernel knows, untrustworthy code; >> vendor, TLA? and user-updateable. "Let's be careful out there .." Agreed. Thanks again for reviewing this stuff, sorry for sitting on it so long. I just wasn't sure how to voice my uncertainty. Also I'm not sure what the coding standard for FreeBSD is (e.g. whitespace formatting). Anthony > > Bruce > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" --------------030205080106070406040103 Content-Type: text/x-patch; name="atrtc.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="atrtc.c.diff" Index: sys/x86/isa/atrtc.c =================================================================== --- sys/x86/isa/atrtc.c (revision 278930) +++ sys/x86/isa/atrtc.c (working copy) @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include "opt_isa.h" +#include "opt_acpi.h" #include #include @@ -53,9 +54,17 @@ #include #include "clock_if.h" +#include +#include +#include + #define RTC_LOCK do { if (!kdb_active) mtx_lock_spin(&clock_lock); } while (0) #define RTC_UNLOCK do { if (!kdb_active) mtx_unlock_spin(&clock_lock); } while (0) +#define IO_DELAY() (void)inb(0x84) +#define IO_RTC_ADDR (IO_RTC + 0) +#define IO_RTC_DATA (IO_RTC + 1) + int atrtcclock_disable = 0; static int rtc_reg = -1; @@ -73,10 +82,10 @@ RTC_LOCK; if (rtc_reg != reg) { - inb(0x84); + IO_DELAY(); outb(IO_RTC, reg); rtc_reg = reg; - inb(0x84); + IO_DELAY(); } val = inb(IO_RTC + 1); RTC_UNLOCK; @@ -89,16 +98,36 @@ RTC_LOCK; if (rtc_reg != reg) { - inb(0x84); + IO_DELAY(); outb(IO_RTC, reg); rtc_reg = reg; - inb(0x84); + IO_DELAY(); } outb(IO_RTC + 1, val); - inb(0x84); + IO_DELAY(); RTC_UNLOCK; } +static void +acpi_cmos_read(ACPI_PHYSICAL_ADDRESS address, UINT8 *buf, UINT32 buflen) +{ + UINT32 offset; + + for (offset = 0; offset < buflen; ++offset) { + buf[offset] = rtcin(address + offset) & 0xff; + } +} + +static void +acpi_cmos_write(ACPI_PHYSICAL_ADDRESS address, const UINT8 *buf, UINT32 buflen) +{ + UINT32 offset; + + for (offset = 0; offset < buflen; ++offset) { + writertc(address + offset, buf[offset]); + } +} + static __inline int readrtc(int port) { @@ -161,9 +190,58 @@ struct resource *intr_res; void *intr_handler; struct eventtimer et; + ACPI_HANDLE acpi_handle; /* Handle of the PNP0B00 node */ }; static int +acpi_check_rtc_byteaccess(int is_read, u_long addr) +{ + int retval = 1; /* Success */ + + if (is_read) { + /* Reading 0x0C will muck with interrupts */ + if (addr == 0x0C) + retval = 0; + } else { + if (!((addr <= 0x05 && (addr & 0x01)) || + (addr >= 0x30 && addr < 0x40))) + retval = 0; + } + return retval; +} + +static ACPI_STATUS +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, + UINT32 width, UINT64 *value, void *context, void *region_context) +{ + struct atrtc_softc *sc; + + sc = (struct atrtc_softc *)context; + if (!value || !sc) + return AE_BAD_PARAMETER; + if (width > 32 || (width & 0x07) || address >= 64) + return AE_BAD_PARAMETER; + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) + return AE_BAD_PARAMETER; + + switch (function) { + case ACPI_READ: + acpi_cmos_read(address, (UINT8 *)value, width >> 3); + break; + case ACPI_WRITE: + acpi_cmos_write(address, (const UINT8 *)value, + width >> 3); + break; + default: + return AE_BAD_PARAMETER; + } + printf("%s: %-5s%02u address=%04lx value=%08x\n", + __FUNCTION__, function == ACPI_READ ? "READ" : "WRITE", width >> 3, + address, *((UINT32 *)value)); + return AE_OK; +} + +static int rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period) { @@ -245,10 +323,17 @@ int i; sc = device_get_softc(dev); + sc->acpi_handle = acpi_get_handle(dev); sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); if (sc->port_res == NULL) device_printf(dev, "Warning: Couldn't map I/O.\n"); + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler, NULL, sc))) + { + device_printf(dev, "Error registering ACPI CMOS address space handler.\n"); + return 0; + } atrtc_start(); clock_register(dev, 1000000); bzero(&sc->et, sizeof(struct eventtimer)); @@ -286,6 +371,15 @@ return(0); } +static int atrtc_detach(device_t dev) +{ + struct atrtc_softc *sc; + + sc = device_get_softc(dev); + AcpiRemoveAddressSpaceHandler(sc->acpi_handle, ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler); + return bus_generic_detach(dev); +} + static int atrtc_resume(device_t dev) { @@ -366,7 +460,7 @@ /* Device interface */ DEVMETHOD(device_probe, atrtc_probe), DEVMETHOD(device_attach, atrtc_attach), - DEVMETHOD(device_detach, bus_generic_detach), + DEVMETHOD(device_detach, atrtc_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), DEVMETHOD(device_suspend, bus_generic_suspend), /* XXX stop statclock? */ --------------030205080106070406040103--