On Wed, Mar 03, 2010 at 11:10:14AM +0200, Alexandr Rybalko wrote:
> On Wed, 3 Mar 2010 00:28:33 -0800
> Weongyo Jeong <weongyo.je...@gmail.com> wrote:
>
> >> On Mon, Mar 01, 2010 at 10:32:40AM +0200, Alexandr Rybalko wrote:
> >> > On Sun, 28 Feb 2010 01:52:59 -0800
> >> > Weongyo Jeong <weongyo.je...@gmail.com> wrote:
> >> >
> >> > Can You test your driver without siba_switchcore, I see the device
> >> > have mapping for all cores on SSB?
> >>
> >> I see what you mean. siba_core.c which depends on PCI code would be
> >> compiled when it builds on SENTRY5. So it looks currently it needs a
> >> patch to compile siba bus code without PCI code. I'll try to make a
> >> patch.
>
> I now trying to make bus independent interface, not done yet.
> When finish, I send to You for review and maybe test.
It's my pleasure to test your patch.
>
> >>
> >> > > ssb0: <Broadcom BCM4315 802.11b/g Wireless> mem 0xf4000000-0xf4003fff
> >> > Think thre is 4 cores.
> >> > When SSB on nexus, we don`t need core switching, maybe on PCI too.
> >>
> >> I think this is a difference between siba(4) and siba_bwn currently and
> >> it's one of TODOs we should solve to merge two codes.
> >>
> >> AFAIK approach to access each cores isn't same; it looks siba(4) creates
> >> devices for each cores so it'd not need to switch cores. But siba_bwn
> >> doesn't do it like siba(4) so it needs to switch cores because all are
> >> handled on one device.
>
> Look into this line:
> ssb0: <Broadcom BCM4315 802.11b/g Wireless> mem 0xf4000000-0xf4003fff
> There we see, device have 0x4000 memory window. Each core required 0x1000.
> Your code to call required core move PCI window to appropriate 0x1000 block
> (if core - second, move to 0xf4001000).
> Maybe we can map full window, and then access to required core without
> core switching.
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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
