[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201302202127.09979.arnd@arndb.de>
Date: Wed, 20 Feb 2013 21:27:09 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Alexander Shiyan <shc_work@...l.ru>
Cc: Dong Aisheng <dong.aisheng@...aro.org>,
linux-kernel@...r.kernel.org, Samuel Ortiz <sameo@...ux.intel.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: Re[14]: [PATCH v3] mfd: syscon: Add non-DT support
On Wednesday 20 February 2013, Alexander Shiyan wrote:
> > On Wednesday 20 February 2013, Alexander Shiyan wrote:
> > > No. Target have a three SYSCON registers and two SYSFLG. All these registers
> > > can be combined into three syscon devices.
> > > Only these registers will be handled via syscon device, so it is not only one.
> > > Or you mean about handle all register via syscon? It is not it.
> >
> > Yes, I was expecting that you would list all three pages in the resource
> > for the syscon device, basically making all of the core clps711x
> > registers available this way.
>
> All other will be passed as resource to drivers, as for other drivers.
> And this change replaces clps_read/write.
Ok, I see.
> > > > treat the absence of DT information as an error, and a call to
> > > > syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle
> > > > will always return the syscon device that was registered first, or
> > > > -EPROBE_DEFER for any error.
> > >
> > > The initial idea is search desired syscon device from drivers only by one function
> > > (i.e. search syscon device by compatible string or by specific alias) and no depend
> > > on DT or non-DT. I.e. define syscon device always at machine start (even if we run
> > > machine from DTS), because device should be always present in system.
> >
> > I don't understand yet what the advantage for clps711x is over just a single
> > register area that would get registered at boot time and replace all the
> > clps_readl/clps_writel calls.
>
> This cause a serious perfomance impact. Only SYSCON and SYSFLG is used
> in several places and should be protected by spinlocks. Other registers
> can be used without locks. And, as say before, clps_read/write will be replaced with
> read/write when registers will passed as resource. First example of this change I
> sent to you before (patchset for serial driver).
Yes, that makes sense. I have no fundamental objections then. I'll wait
for the next version of your patch and then comment on any details I still
find sticking out.
Arnd
--
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