From owner-freebsd-current@FreeBSD.ORG Sun Mar 14 00:55:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAB821065672 for ; Sun, 14 Mar 2010 00:55:42 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 78E0C8FC16 for ; Sun, 14 Mar 2010 00:55:42 +0000 (UTC) Received: by gyf2 with SMTP id 2so1095601gyf.13 for ; Sat, 13 Mar 2010 16:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=WBo8d1UHVcCwGcsTG3R1VpI+h2VPocIDBSKPHyg5EZQ=; b=X4mMZBvEJSQLYu/QRRHwXO46UDTiUXtgWcCzwm3iToGIketOTmvTFs20ygKJwh8NXn t8RKZBBx3B8Rbkivm/Ldw7mgd1VptD2eDJ/2JyJRQAl2qW8df26MsKiBooJEiHTJ1fxl T28UkqcNgrQJj6sIOcvvMCNjOG2yxWpVpkw38= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=etMoDxDoJ6ZXhamXDXKDPiA/04XAXu9RSCHddo7EIt4DrplcataUZ+tq9zcjIxAvnz uTozzc1OHSb4R+rdmxIT7IfL8IB5uS+ecHv9YYLWsRRsxP+RokTWvKvleoOIcr0fn+eJ tF025O8rQ1Z5OCMHypuhkhd6b58/PD8i0hID0= Received: by 10.101.9.19 with SMTP id m19mr4582530ani.134.1268528141713; Sat, 13 Mar 2010 16:55:41 -0800 (PST) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 22sm1028793ywh.1.2010.03.13.16.55.40 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Mar 2010 16:55:41 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Sat, 13 Mar 2010 16:55:58 -0800 From: Weongyo Jeong Date: Sat, 13 Mar 2010 16:55:58 -0800 To: Alex RAY Message-ID: <20100314005558.GB88159@weongyo> Mail-Followup-To: Alex RAY , Alexandr Rybalko , current@freebsd.org References: <20091223035331.GA1293@weongyo> <4b31cb29.9413f30a.5f4a.ffff8382@mx.google.com> <20100226005115.GP14937@weongyo> <20100227011535.ed3f2486.ray@ddteam.net> <20100228095259.GB3536@weongyo> <20100301103240.3a4aac8a.ray@dlink.ua> <20100303082833.GB22865@weongyo> <20100303111014.6564ea1e.ray@dlink.ua> <20100312231333.GZ1295@weongyo> <20100313231205.5e68a89a.ray@ddteam.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100313231205.5e68a89a.ray@ddteam.net> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Alexandr Rybalko , current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 00:55:42 -0000 On Sat, Mar 13, 2010 at 11:12:05PM +0200, Alex RAY wrote: > On Fri, 12 Mar 2010 15:13:34 -0800 > Weongyo Jeong wrote: > > > > > I thought that your opinion was right and if mem is > > 0xf4000000-0xf4003fff (16 Kb) I thought the device has 4 cores. However > > it looks this was wrong according to the below document: > > > > http://voodoowarez.com/bcm5365p.pdf > > > > Please see Section 3: PCI Core, PCI Bus (Page 34) that it indicates that > > 16Kb, maybe 8 Kb in the old devices is core register region. > > > > "Accesses to the lower half of the core register region are translated > > into system backplane accesses using the PCIBAR0Window register" > > "Accesses to offsets 0x1000 to 0x17FF of this region initiate a direct > > access to the external SPROM" > > > > If we just access memory using offset + core and bus_space_read_x > > interfaces it would actually not access core register region. > > > > So without solving this problem it looks it could not remove coreswitch > > routines. > > > > regards, > > Weongyo Jeong > > > > Hi, > > this document about SoC BCM5365P, not about PCI device with PCI to SSB > bridge. Yes it's about SoC BCM5365P but I think the basic concept of Silicon Backplane would be same at a PCI device with PCI to SSB bridge. > I know in SoC`s like BSM5365 (I test it in BCM5354 and BCM5836) core > switching is not required. > > BCM5354 - http://lists.freebsd.org/pipermail/freebsd-mips/2009-June/000421.html > BCM5836 - http://lists.freebsd.org/pipermail/freebsd-mips/2010-February/000635.html The above URLs you mentioned indicates that siba0: at mem 0x18000000-0x18006fff on nexus0 siba_cc0: at mem 0x18000000-0x18000fff irq 0 on siba0 bfe0: at mem 0x18001000-0x18001fff irq 1 on siba0 siba_mips0: at mem 0x18002000-0x18002fff on siba0 ohci0: at mem 0x18003000-0x18003fff irq 4 on siba0 siba0 used memory region at starting 0x18000000 that I think this is a reason why it doesn't require core switching and each cores have their own memory region at starting 0x1800xxxx. But in a case of PCI device with PCI to SSB bridge, it normally used 0xf4000000, 0xfe200000 or other address which reserved by parent PCI bridge. > With PCI device, when device report memory window > 0xf4000000-0xf4003fff, why we can`t use full window? Because I'm not a Silicon Backplane expert I could not answer this question. But I'd like to make sure that memory window at 0xf4000000 (size 16 Kbytes) comes from PCI BAR0 when pci(4) attached device. Moreover I believe size of memory window also comes from PCI BAR0 size testing of pci(4). Of course I think we can try to remap full memory window after calculating numbers of core but it looks meaning would be little bit different. > May be You can test your code without core switching? I tried to remove core switching code in siba_bwn bridge but after moment I got stuck to go forward. For example, I have 1 device which attached with bwn(4) and it has 4 cores: 0x18000000-0x18000fff ChipCommon 0x18001000-0x18001fff EMAC 0x18002000-0x18002fff PCI 0x18003000-0x18003fff PCMCIA When it attached at siba_bwn it shows its memory region at 0xfe2fe000 - 0xfe2fffff (8 Kbytes). Initial PCI BAR0 value was 0x18002000. If your opinion is right the memory region for full window should be 0xfe2fe000 - 0xfe301fff (16 Kb for 4 core, each core consumes 0x1000 size) Even if I tried to remap memory region from 0xfe2fe000 to 0xfe301fff and setting PCI BAR0 to 0x18000000, another problem is occurred for reading SPROM data. To access external SPROM it could be possible to access bus_space_read_2(bt, bh, 0x1000 ~ 0x17ff) at ChipCommon core. But accessing register in a core could not over 0xfff because maximum size of a core limited within 0x1000. That means internally in Silicon Backplane it has a special meaning if it try to access over 0x1000 or 0x2000 which mentioned a quote at Section 3: PCI Core, PCI Bus (Page 34). I guess you're thinking that we could access EMAC core using bus_space_read_2(bt, bh, 0x1000 ~ 0x1fff) after setting full memory window. But it looks it's not possible. regards, Weongyo Jeong