From owner-freebsd-ppc@FreeBSD.ORG  Wed Apr  9 16:57:03 2008
Return-Path: <owner-freebsd-ppc@FreeBSD.ORG>
Delivered-To: freebsd-ppc@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id ADE8E106567D
	for <freebsd-ppc@freebsd.org>; Wed,  9 Apr 2008 16:57:03 +0000 (UTC)
	(envelope-from grehan@freebsd.org)
Received: from azure.onthenet.com.au (azure.OntheNet.com.au [203.13.68.11])
	by mx1.freebsd.org (Postfix) with ESMTP id 6DDF78FC13
	for <freebsd-ppc@freebsd.org>; Wed,  9 Apr 2008 16:57:03 +0000 (UTC)
	(envelope-from grehan@freebsd.org)
Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57])
	by azure.onthenet.com.au (Postfix) with ESMTP id 4D537122E5;
	Thu, 10 Apr 2008 02:57:01 +1000 (EST)
Received: from peter-grehans-power-mac-g5.local (dsl-63-249-90-35.cruzio.com
	[63.249.90.35]) by dommail.onthenet.com.au (MOS 3.7.5a-GA)
	with ESMTP id DUU16419 (AUTH peterg@ptree32.com.au);
	Thu, 10 Apr 2008 02:56:57 +1000 (EST)
Message-ID: <47FCF557.1090002@freebsd.org>
Date: Wed, 09 Apr 2008 09:56:55 -0700
From: Peter Grehan <grehan@freebsd.org>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Nathan Whitehorn <nathanw@uchicago.edu>
References: <47FCE919.4070502@uchicago.edu>
In-Reply-To: <47FCE919.4070502@uchicago.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-ppc@freebsd.org
Subject: Re: BMAC Ethernet Driver
X-BeenThere: freebsd-ppc@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: grehan@freebsd.org
List-Id: Porting FreeBSD to the PowerPC <freebsd-ppc.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
	<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
	<mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Apr 2008 16:57:03 -0000

Hi Nathan,

>  >  This would get my vote. I would think the gpio device would register 
> itself, perhaps with it's macio parent, and clients would access it 
> through kobj methods. These would include interrupt forwarding, and GPIO 
> toggling.
> 
> The trouble here is that SMU isn't a macio child, so it wouldn't pick up 
> the GPIO kobj methods.

  In this case, the kobj methods wouldn't be part of the device 
hierarchy, but accessible directly through a device_t.

  Have a look at kern/subr_rtc.c for a similar case where a real-time 
clock device exports kobj methods via a registration and wrapper routines.

>  >  How does the SMU use the GPIO's ? Just toggling ?
> 
> Yeah. It also reads them from time to time, which the onboard audio 
> stuff does too (to sense headphone connections and the like).

  OK, that could be handled through exported toggle methods.

>  >  Hopefully it is a one-way path with the gpio device knowing nothing 
> about the users that call it.
> 
> Yes, I think that would be ideal. I'm not quite sure how to do it 
> though. Having a second gpio driver for each device that attaches to 
> macgpio and can find its partner by internal logic could work.

  For macio devices, the methods could be exported by the parent. For 
non-macio devices, something like the subr_rtc.c style could be used.

> Or global calls into macgpio.

  That should be a last resort :)

> Also, is there a way to find a FreeBSD device given an OF phandle? For 
> SMU, the GPIO lines it needs to care about are listed as device handles 
> under /smu. So an SMU attachment would need to figure out the macgpio 
> device and GPIO line to watch from the OF handle. I don't know how this 
> works for PMU.

  This could be ugly :( Do you have any examples of the devices that the 
SMU handles end up pointing to ?

later,

Peter.