From owner-svn-src-all@freebsd.org Thu Nov 5 23:25:17 2015 Return-Path: Delivered-To: svn-src-all@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 DFBC5A27696 for ; Thu, 5 Nov 2015 23:25:16 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 B1CE41881 for ; Thu, 5 Nov 2015 23:25:16 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 5 Nov 2015 23:24:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tA5NP80L049542; Thu, 5 Nov 2015 16:25:08 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1446765908.91534.404.camel@freebsd.org> Subject: Re: svn commit: r290373 - head/sys/dev/ofw From: Ian Lepore To: Andreas Tobler , Nathan Whitehorn , Warner Losh Cc: src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Date: Thu, 05 Nov 2015 16:25:08 -0700 In-Reply-To: <563BDB8F.8090504@FreeBSD.org> References: <201511042246.tA4MkUYU010551@repo.freebsd.org> <563BB466.8020801@freebsd.org> <563BC911.5060804@FreeBSD.org> <563BCE7C.9020900@freebsd.org> <563BDB8F.8090504@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 23:25:17 -0000 On Thu, 2015-11-05 at 23:43 +0100, Andreas Tobler wrote: > On 05.11.15 22:47, Nathan Whitehorn wrote: > > On 11/05/15 13:24, Andreas Tobler wrote: > > > Hi Nathan, Warner, > > > > > > first, I had the feeling that I have to provide a fast solution > > > which > > > makes PowerMacs usable again. I am aware that the committed > > > version > > > doesn't win a prize. > > > > Thank you! > > > > > Also, I didn't know that we have AIM & FDT, Nathan which one? > > > > PS3 and POWER8 systems are AIM+FDT. Neither of these have I2C > > busses in > > their FDTs, so the impact is low for now, but it makes me a little > > nervous. > > Ah, maybe I have luck to convince my son to handover the PS3 to me. > He > has a PS4 too... > > About the POWER8, well, far away from my budget..... > > > > On 05.11.15 21:26, Warner Losh wrote: > > > > I'd suggested that this be driven off a global quirk like > > > > > > > > u_int fdt_quirks; > > > > #define FDT_QUIRK_8BIT_IIC_ADDR 1 > > > > ... > > > > > > In openfirm.h? > > > > I'd really prefer an explicit platform check in ofw_iicbus.c for > > this by > > looking at the compatible property of the root node. If this ever > > comes > > up on another system, we can modify it, but I think it won't. > > Attached a working proposal. > It does work with the Apple 8-bit I2C addresses and the fan > regulation > works. > > But I need a kind soul to test this on an arm board with Linux based > FDT > I2C devices which have 7-bit addresses. > > Ian? > Yeah, that looks good to me (strange that we have no helper function that can do all that compatible stuff given a node handle instead of a device_t). -- Ian > Thanks in advance, > Andreas > > > > > if (fdt_quirks & FDT_QUIRK_8BIT_IIC_ADDR) > > > > dinfo->opd_dinfo.addr = paddr; > > > > else > > > > dinfo->opd_dinfo.addr = paddr << 1; > > > > > > > > And the platform code, whatever that means, would set it when > > > > it "knows" > > > > this is the case. > > > > > > If I get that right, I'd have to set the fdt_quirk in each I2C > > > parent, > > > like kiic.c and smu.c? > > > > > > > On Thu, Nov 5, 2015 at 12:56 PM, Nathan Whitehorn > > > > > wrote: > > > > > > > > I'm not sure this is the best way to do this: we have AIM > > > > systems > > > > that use FDT, for example. Can we make it a quirk in the > > > > host-bus > > > > driver? Or do a run-time check to see if the root node has > > > > MacRISC > > > > in its compatible property? > > > > > > The 'compatible property' approach would be limited/isolated to > > > one > > > file (ofw_iicbus.c) in comparison to the quirk approach where I'd > > > have > > > to adapt at least (known now) four files. > > > > > > I can go either way, just my thoughts. > >