[PATCH 1/3] arm: omap2: Export devconf1 bypass and acbias.

Tony Lindgren tony at atomide.com
Thu Dec 12 14:19:08 EST 2013


On Thu, Dec 12, 2013 at 09:31:02AM +0100, Belisko Marek wrote:
> Hi Tony,
> 
> On Tue, Dec 10, 2013 at 11:46 PM, Tony Lindgren <tony at atomide.com> wrote:
> > * Belisko Marek <marek.belisko at gmail.com> [131210 14:13]:
> >> On Tue, Nov 12, 2013 at 12:31 AM, Tony Lindgren <tony at atomide.com> wrote:
> >> >
> >> > It would be best to set it up as omap-ctrl.c driver under drivers
> >> > somewhere with few functions exported for DSS and MMC drivers.
> >>
> >> I create small dummy driver based on phy-omap-control which can be
> >> used but before sending patch (with more updates) I would like to get
> >> some feedback if my direction is correct.
> >
> > Cool thanks. Yeah what you have can easily be combined with the patches
> > Balaji has posted to make HSMMC use drivers/mfd/syscon.c via regmap
> > for the SCM register access. Maybe take a look at the work in progress
> > patches in thread:
> >
> > [PATCH v4 0/7] mmc: omap_hsmmc: pbias dt and cleanup
> >
> > And also see my comments regarding using the SCM GENERAL register area
> > as base for the syscon.c driver. That should work for your driver too,
> > right? And then you can access the SYSCON1 register that way from your
> > consumer driver ;)
>
> If I understand correclty I can use syscon driver (it will have in
> range also devconf1 register) ad get rid of my custom driver
> and then get regmap from syscon and update bits that I need for venc, right?

Yeah something like that. Or since the sysconf1 register is shared, it might
be best to still provide specific functions to access it if we cannot map
just specific bits of it separately for drivers using regmap.

But anyways this should for most part remove the need for a custom driver(s)
unless the register is a regulator or a clock.

Regards,

Tony



More information about the linux-arm-kernel mailing list