[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=zrr4==Uatq3zbdE1K+1_9ELOBZQ@mail.gmail.com>
Date: Wed, 18 May 2011 14:21:00 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: viresh kumar <viresh.kumar@...com>
Cc: "Koul, Vinod" <vinod.koul@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
Armando VISCONTI <armando.visconti@...com>,
Shiraz HASHIM <shiraz.hashim@...com>,
"viresh.linux@...il.com" <viresh.linux@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dw_dmac: Replace subsys_init() with arch_initcall()
2011/5/17 viresh kumar <viresh.kumar@...com>:
> SPI bus is required for regulators and so probably he can't have
> module_init() for amba-pl022.
Nope. Regulators have to be at subsystem_init() because lots
of drivers called in module_init() == driver_init() will need
to enable them to even be able to talk to the hardware they
are regulating.
e.g. an externally powered I2C device. If you cannot put power
to it you cannot probe it.
Then you end up in a dependency: we need to have SPI
to enble the regulators - the SPI device containing the
regulators is a device that is self-powered.
So then of course the SPI bus controller has to be
available, so it has to be subsys_initcall() as well.
Luckily as it happens it is earlier in the linkfile than
regulators, so using the same initlevel as regulators
will work (else we would be in hell).
But since the PL022 uses DMA, we have to have DMA
before SPI, and it is currently linked *after* SPI in the
Makefile.
> @Linus: What do you say? Can we get back to module_init() for amba-pl022?
> And subsys_initcall() for DMA.
No, but I sent a patch that will make it possible to have both
as subsys_init(), check it out, it seems to work for me.
Can you test it? (Sorry forgot to add you on CC, title is
"[PATCH] dmaengine: move link order".
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists