[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150129161817.GJ12209@pengutronix.de>
Date: Thu, 29 Jan 2015 17:18:17 +0100
From: Sascha Hauer <s.hauer@...gutronix.de>
To: Matthias Brugger <matthias.bgg@...il.com>
Cc: Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
Samuel Ortiz <sameo@...ux.intel.com>,
YH Chen (陳昱豪) <yh.chen@...iatek.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Henry Chen <henryc.chen@...iatek.com>,
Rob Herring <robh+dt@...nel.org>,
Yingjoe Chen (陳英洲)
<Yingjoe.Chen@...iatek.com>,
Eddie Huang <eddie.huang@...iatek.com>,
Lee Jones <lee.jones@...aro.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
James Liao <jamesjj.liao@...iatek.com>,
Mike Turquette <mturquette@...aro.org>,
Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: [PATCH v2] MediaTek PMIC support
On Thu, Jan 29, 2015 at 04:44:19PM +0100, Matthias Brugger wrote:
> 2015-01-29 15:27 GMT+01:00 Sascha Hauer <s.hauer@...gutronix.de>:
> > On Thu, Jan 29, 2015 at 01:39:42PM +0100, Matthias Brugger wrote:
> >> Hi Sascha,
> >>
> >> 2015-01-26 12:47 GMT+01:00 Sascha Hauer <s.hauer@...gutronix.de>:
> >> > Olof, Arnd,
> >> >
> >> > OK to put the driver into drivers/soc/mediatek? Can you take these
> >> > patches?
> >>
> >> How does this patches fit together with the one James clock framework patches?
> >> Both use the same compatible "mediatek,mt8135-infracfg" and
> >> "mediatek,mt8135-pericfg".
> >>
> >> I had a look on other implementations and they attach the reset
> >> controller to the clk driver, if they share the same hw block.
> >> Might we run into problems if we implement the clocks in the mfd, as
> >> we need the clocks early in boot (e.g. for the timer)?
> >
> > From my experience the clocks are needed by the timer before any driver
> > initializes.
> >
> >>
> >> In mt6589 pericfg apart from the clocks and reset controller provides
> >> registers for AXI bus control and USB wakeup and USB clock selection.
> >> The infracfg block provides top AXI bus fabric control signals and
> >> remap registers for the modem.
> >> Mike, Stephen, what do you think. Can we implement the clk in a mfd
> >> driver? Or do you prefer to implement the whole block in the clk
> >> driver?
> >
> > Currently the clk support uses regular CLK_OF_DECLARE which handles the
> > clock part of pericfg/infracfg and then later a regular driver for
> > pericfg/infracfg comes and handles the rest of the functionality. Since
> > both use separate registers in the device register space it should work
> > fine.
>
> It should work until some driver start to use request and map, as you
> provide the whole register space.
Why do you think so? The clock driver continues working after the
pericfg/infracfg drivers have probed.
> If you want to implement drivers for pericfg/infracfg like this, why
> don't you implement the reset controller in drivers/reset?
I want to have a single driver for pericfg/infracfg, the clk support
only bypasses this since it's needed so early. Otherwise I would
register the clocks from the pericfg/infracfg probe function.
BTW in earlier versions we had a syscon binding so that child devices
such as the reset driver could access the registers via regmap. Anyway,
since
bdb0066 mfd: syscon: Decouple syscon interface from platform devices
syscon devices no longer probe by themselves, so we can't put the reset
controller and stuff as child devices under the syscon node anymore.
>
> Anyway I'm not really happy with the solution of having several device
> drivers for the same dts compatible string.
Me neither, but what do you want to do about it?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
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