R3000Z Laptop Status

[Bruno Ducrot]

On Mon, Mar 21, 2005 at 03:28:32PM -0800, Astrodog wrote:
> On Mon, 21 Mar 2005 17:53:29 -0500, Jung-uk Kim <jkim at niksun.com> wrote:
> > On Monday 21 March 2005 05:48 pm, Nicolas Blais wrote:
> > > What about the PowerNow! kernel module? Is that still required?
> > 
> > If you are okay with 800MHz, no. ;-)  You can grab the latest
> > powernow-k8 driver from:
> > 
> > http://www.poupinou.org/cpufreq/bsd/powernow.tar.gz
> > 
> > Jung-uk Kim
> > 
> > > Thanks,
> > > Nicolas.
> > >
> > > On March 21, 2005 10:49, Jung-uk Kim wrote:
> > > > On Monday 21 March 2005 08:36 am, Astrodog wrote:
> > > > > I was wondering if the R3000Z fixes have been committed to the
> > > > > RELENG_5 branch, I don't see anything on the lists about it.
> > > > > Should I expect 5.4 to work with the R3000 line?
> > > >
> > > > Yes.  hint.atkbd.0.flags="0x9" is all you need now.  Try the
> > > > latest snapshot and let us know.
> > > >
> > > > Thanks,
> > > >
> > > > Jung-uk Kim
> > > >
> > > > > --- Harrison Grundy
> > _______________________________________________
> > freebsd-amd64 at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
> > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe at freebsd.org"
> > 
> 
> Powernow works great, by the way. I'm upgrading to 6-CURRENT now
> because I need the ath driver for AMD64 for a wireless card I have,
> but I tested things out in 5.4-PRERELEASE, and it works great once
> these few, relatively easy to fix issues are resolved.

The powernow driver have just been updated btw, would be fine if I got
some feedback.  It's close to be committed I believe.


There is though an unlikely situation where a kernel panic
happens if using acpi_perf driver at kldload time (it happens due
to known BIOS bugs), and since acpi_perf is compiled now statically,
the ACPI path will be taken at first in the powernow driver (this should
not be an issue for releng_5 and powernow alone).

The below patch (which maybe already committed, who knows)
fix this.

Index: acpi_perf.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_perf.c,v
retrieving revision 1.16
diff -u -p -r1.16 acpi_perf.c
--- acpi_perf.c	20 Mar 2005 03:51:18 -0000	1.16
+++ acpi_perf.c	24 Mar 2005 12:52:17 -0000
@@ -244,6 +244,7 @@ acpi_perf_evaluate(device_t dev)
 	ACPI_OBJECT *pkg, *res;
 	ACPI_STATUS status;
 	int error, i, j;
+	int count;
 	uint32_t *p;
 
 	/* Get the control values and parameters for each state. */
@@ -272,27 +273,31 @@ acpi_perf_evaluate(device_t dev)
 	 * BusMasterLatency, ControlVal, StatusVal}, sorted from highest
 	 * performance to lowest.
 	 */
-	for (i = 0; i < sc->px_count; i++) {
+	for (count = 0, i = 0; i < sc->px_count; i++) {
 		res = &pkg->Package.Elements[i];
 		if (!ACPI_PKG_VALID(res, 6)) {
 			device_printf(dev, "invalid _PSS package\n");
 			continue;
 		}
 
-		/*
-		 * Check for some impossible frequencies that some systems
-		 * use to indicate they don't actually support Px states.
-		 */
 		p = &sc->px_states[i].core_freq;
-		if (*p == 9999 || *p == 0xffff)
-			goto out;
-
 		/* Parse the rest of the package into the struct. */
 		for (j = 0; j < 6; j++, p++)
 			acpi_PkgInt32(res, j, p);
+
+		/*
+		 * Check for some impossible frequencies that some systems
+		 * use to indicate they don't actually support this Px state.
+		 */
+		if (sc->px_states[i].core_freq == 9999 ||
+		    sc->px_states[i].core_freq == 0xffff)
+			continue;
+		count++;
 	}
 	AcpiOsFree(buf.Pointer);
 
+	sc->px_count = count;
+
 	/* Get the control and status registers (one of each). */
 	buf.Pointer = NULL;
 	buf.Length = ACPI_ALLOCATE_BUFFER;

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.