Re: merge for gt(4) and Marvell SoC

[KIYOHARA Takashi <kiyohara%kk.iij4u.or.jp@localhost>]

From: Robert Swindells <rjs%fdy2.demon.co.uk@localhost>
Subject: Re: merge for gt(4) and Marvell SoC
Date: Thu, 20 Aug 2009 21:46:41 +0100 (BST)

> 
> Simon Burge <simonb%NetBSD.org@localhost> wrote:
> >KIYOHARA Takashi wrote:
> >> From: Simon Burge <simonb%NetBSD.org@localhost>
> >> Subject: Re: merge for gt(4) and Marvell SoC 
> >> Date: Tue, 11 Aug 2009 21:30:43 +1000
> >> 
> >> > KIYOHARA Takashi wrote:
> >> > 
> >> > > I put newer patch.
> >> > > 
> >> > >   
> >> > > ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/orion_nas/marvell-20090809.diff
> >> > >   
> >> > > ftp://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/orion_nas/marvell-20090809.tar.gz
> >> > > 
> >> > > mvsata(4) and mvgbe(4) were moved to dev/marvell.
> >> > > Next, I merged mvtwsi.  Ooops, gti2c(4) will not work.  It have more 
> >> > > bug.
> >> > > Howver, EV64260 not use gti2c...
> >> > > 
> >> > > gt0 at mvsoc0 addr 0xf1000000
> >> > 
> >> > What is "gt0" in this context?  The existing uses of "gt" for drivers
> >> > in NetBSD are for the Galileo Technology system controllers found in
> >> > some MIPS and PowerPC boards (like the EV64260).  Marvell bought Galileo
> >> > Technology which is why these appear in sys/dev/marvell.
> >> > 
> >> > I suspect you want a different parent bus name for the ARM-based Marvell
> >> > SoC chips - it looks like this bus is called the Mbus, at least in the
> >> > 88F5181.
> >> 
> >> I have the possibility of not understanding Mbus.
> >> However, what implementing does the driver of Mbus become?  I was not
> >> found the difference of the inclusion of this in gt.
> >
> >The problem is that dev/marvell/gt.c is the driver for Galileo
> >Technology system controllers, as used in at least the EV64260 board
> >in the evbppc port.  It's entirely possible that the GT drivers and
> >the ARM SoC drivers might be able to share code, but the front end for
> >the ARM SoC drivers shouldn't be in dev/marvell/gt.c and isn't a "GT
> >system controller driver" as the comment at the top of gt.c currently
> >says.  If you modify gt.c in the way that you've proposed, will the
> >EV64260 board that uses the current form of gt.c still work?
> 
> I'm probably to blame for this, I thought that the same Gigabit
> Ethernet controller was in the Discovery chipset used in ofppc as in
> the Orion and Kirkwood SoCs, and suggested moving the driver out of
> sys/arch/arm/marvell. I wasn't thinking that the ARM drivers would
> hang off "gt".
> 
> I was expecting to split the Gigabit Ethernet driver into a file for
> the core then attachment shims for Orion, Kirkwood and Discovery.
> 
> Maybe define a "mvsoc" device that is implemented by "orion" or
> "kirkwood" then attach all the ARM drivers to this ?

Yes.  I think 'mvsoc' is name of SoC for Orion/Discovery Inovation/Kirkwood.
By the way, what is 'the ARM drivers' that you say?
I think all (ie. CESA, IDMA, and PCI, etc) to be the same one as the driver
of gt.  Moreover, it exists some PCI already has pegasospci besides gtpci
and mvpci.  Moreover, cobalt and MALTA has pci under
sys/arch/{cobalt/evbmips/malta/dev}.


However, can you allow mvsoc_attach() to call gt_attach_common() for
instance?


> I would put move sys/dev/marvell/mvsata_gt.c back to sys/arch/arm/marvell
> and rename it to mvsata_orion.c, it is Orion specific.

I have look 'MV76100/78100/78200 Functional Specifications'.  It is
specifies to Discovery Inovation.  I found 'Main Interrupt Cause/Mask
and Window Control/Base registers.
I think it is perhaps equal though I do not certainly have specifications
of Discovery VI.

Thanks,
--
kiyohara