From owner-freebsd-current@FreeBSD.ORG Tue Mar 16 22:50:57 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 98CEC1065670 for ; Tue, 16 Mar 2010 22:50:57 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by mx1.freebsd.org (Postfix) with ESMTP id 0FE0B8FC08 for ; Tue, 16 Mar 2010 22:50:56 +0000 (UTC) Received: by fxm7 with SMTP id 7so512552fxm.3 for ; Tue, 16 Mar 2010 15:50:56 -0700 (PDT) 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=chi9PwJnLiiMCCk7j+L7GBBqg0Y9EYP9xmJjaU36690=; b=jBAOOxp4dGKnkGCO6UkGKsfzG4uo+aG/s0PKGO9zQ3pPuIQ7rxsjd3oGpcRX9/E2H3 /WLAbViP+P8w++cQ70njfnAundH6L9r6OUH+K30Pwg5DLyGV664fU/BA8WqvFsevpZHj NEFGK7C4ELGU8YAE2yD8x2gIBy1r54GZkUUfg= 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=goCPNnQU9nCFf08i1qzrZzP1T7RryvCBln1JQ0E53dsjquf9bJ+G/j6rLscqKPEot8 htUnUVyJa2MMD00UsrKXNEOy5cnybtF8hbGbClcUB6ycbptN4Jc306lGo2yBeAudj2PU YdvQwpvU/8IRy/FLBXtf7naIKDo0GLRKSN2hE= Received: by 10.87.29.8 with SMTP id g8mr154599fgj.157.1268779855834; Tue, 16 Mar 2010 15:50:55 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 13sm4359691fxm.10.2010.03.16.15.50.52 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Mar 2010 15:50:54 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Tue, 16 Mar 2010 15:51:13 -0700 From: Weongyo Jeong Date: Tue, 16 Mar 2010 15:51:13 -0700 To: Alex RAY Message-ID: <20100316225113.GF88159@weongyo> Mail-Followup-To: Alex RAY , Alexandr Rybalko , current@freebsd.org References: <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> <20100314005558.GB88159@weongyo> <20100315004357.fca53c7f.ray@ddteam.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100315004357.fca53c7f.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: Tue, 16 Mar 2010 22:50:57 -0000 On Mon, Mar 15, 2010 at 12:43:57AM +0200, Alex RAY wrote: > On Sat, 13 Mar 2010 16:55:58 -0800 > Weongyo Jeong wrote: > > > 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. > > Yes, You're right. I found another way. > We can use SBtoPCITranslation2 (Offset 0x108) register, in that way we > can access to SSB without coreswitching. > (Page 42) > > Initial access for copy SPROM and preconfigure make via BAR0, then > setup SBtoPCITranslation2 and access to SSB direct. According to the specification, as you mentioned SBtoPCITranslation2 has a field UpperAddress but on field 31:30. It looks 2 bit fields are too limited to use so don't know how to implement it you mentioned. Could you please elaborate or show me details? regards, Weongyo Jeong