From owner-freebsd-embedded@FreeBSD.ORG Sun Dec 4 13:01:33 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28C5E1065688 for ; Sun, 4 Dec 2011 13:01:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA3E08FC08 for ; Sun, 4 Dec 2011 13:01:32 +0000 (UTC) Received: by iafi7 with SMTP id i7so2120386iaf.13 for ; Sun, 04 Dec 2011 05:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Rzy05RHR1E7+l2qOSWG6eZYlNwAfRIPO2lxMKGAfL0Q=; b=beEIInmoS+8FZXTUi173Ri49jGdUmPFrqqCI5Uuo4EUcLiKK91xO6CFsCV1lyyliAN 1LhtmdjQZGKeldFqAAq0NIkkeGH2BI8yGHTsjuF7Ft+DGEyG0e/mBFEHo4Wm3tsie4yt 4M8N5wWWJ1+lnZzLkonD/qZZEQURU/ASC1X7s= MIME-Version: 1.0 Received: by 10.42.161.10 with SMTP id r10mr5952442icx.22.1323003692254; Sun, 04 Dec 2011 05:01:32 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.50.42.196 with HTTP; Sun, 4 Dec 2011 05:01:32 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Dec 2011 21:01:32 +0800 X-Google-Sender-Auth: pyaE9thlqhfeWGVhVqUcOSrdPsA Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-embedded@freebsd.org Subject: Re: ar71xx_gpio.c touches SPI_CS1 and 2? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 13:01:33 -0000 Well, the real question is whether the SPI CS pins are actually the ones being used or not. I'm pretty sure the SPI flash is actually being talked to via bitbanged GPIO, rather than the actual ar71xx/ar91xx SPI interface. So those chip selects aren't strictly needed. They may be needed for the mikrotik routerboard's though, I recall gonzo@ talking about something like that. I think we can just work around this by having a boot-time machine dependent "function mask" hint which we set to define which on-board peripherals are enabled. It can be machdep rather than generic, as we'd likely set it up early - eg, ar71xx_machdep.c::platform_start(). The only downside which i haven't yet thought through is whether to: * just write a raw value to the function register, which means we would override whatever the bootloader revision says; or * have two hints - one "clear these bits" and one "set these bits" in the GPIO function register, so we can override what the bootloader code does at startup. That way if it, for example, initialises the sound pins, we don't have to know that unless we want to use the GPIO pins shared by the sound interface. How's that sound? Too dirty? :) Adrian