[PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock

[Jason Cooper]

On Mon, Jan 28, 2013 at 11:31:48PM +0100, Simon Baatz wrote:
> Hi Jason,
> 
> On Sun, Jan 27, 2013 at 10:24:31AM -0500, Jason Cooper wrote:
> > On Sun, Jan 27, 2013 at 03:53:53PM +0100, Sebastian Hesselbarth wrote:
> > > On 01/27/2013 03:46 PM, Jason Cooper wrote:
> > > >>I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
> > > >>post a follow-up patch to Jason's cleanup patches that will also
> > > >>grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
> > > >>does work just fine here on Dove.
> > > >
> > > >I believe Simon's issue is that the mv643xx_eth driver is not loaded at
> > > >boot, it's clocks get gated, then when he loads the driver, there is no
> > > >mac address.  Is that correct Simon?  I don't think unloading the driver
> > > >after boot will trigger this regression.
> > > 
> > > Loading and unloading the driver module hangs because of the missing
> > > clk_prepeare_enable in shared driver part. This should be fixed by the
> > > patch I sent you.
> > > 
> > > Dove and Kirkwood have the same gbe internally and I can boot into Dove
> > > without mv643xx_eth, load, unload, reload the module and it always finds
> > > its MAC address.
> > > 
> > > I just want Simon to confirm that Kirkwood's gbe is really loosing the
> > > contents of its MAC address registers during gated clocks, which is from
> > > a HW point of view very unlikely.
> > 
> > Ok, I just wanted to make sure we understood his problem correctly, and
> > if possible, reproduce it.
> > 
> > Simon, can you give us some steps to reproduce this on our side so we
> > can see exactly what's happening?
> 
> Nothing special here. My config originally based on a Debian config
> for a Kirkwood kernel.  Thus, amongst other drivers, mv643xx_eth is
> build as a module and is loaded from an initrd.
> Because all relevant drivers are loaded as modules, I need my
> runit patch to boot at all.

Let's back up.  If you config early printk and COMMON_CLK_DEBUG and a
vanilla v3.8-rc5 with your current config, what happens?

Could you also please try kirkwood_defconfig and tell us if it boots?

thx,

Jason.

> 
> Here are my findings with various patches: ("non-DT" means booting
> the IBNAS6210 with machine ID 1680 “Marvell DB-88F6281-BP
> Development Board”, which works reasonably well)
> 
> 3.8-rc5 + runit patch:
> 
> DT: Hangs at boot (when loading mv643xx_eth)
> non-DT: Boots ok
> 
> 3.8-rc5 + runit patch + ge00/ge01 patch:
> 
> DT: Boots ok
> non-DT: Boots ok
> 
> 3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
> legacy clock names):
> 
> DT: Boots, but no MAC
> non-DT: Boots ok
> 
> 3.8-rc5 + runit + using Sebastians patch + clks not ticking at module
> load:
> 
> DT: Boots, but no MAC
> non-DT: Boots, but no MAC
> 
> 
> hth,
>   Simon
> 
>