[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130322203715.834.30085@quantum>
Date: Fri, 22 Mar 2013 13:37:15 -0700
From: Mike Turquette <mturquette@...aro.org>
To: Sekhar Nori <nsekhar@...com>, Sekhar Nori <nsekhar@...com>
Cc: Kevin Hilman <khilman@...prootsystems.com>,
<davinci-linux-open-source@...ux.davincidsp.com>,
<linux@....linux.org.uk>, <sshtylyov@...sta.com>, <arnd@...db.de>,
<linus.walleij@...aro.org>, <linux-kernel@...r.kernel.org>,
<rob.herring@...xeda.com>, <linux-keystone@...t.ti.com>,
<viresh.linux@...il.com>, <akpm@...ux-foundation.org>,
<shawn.guo@...aro.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 02/11] clk: davinci - add PSC clock driver
Quoting Sekhar Nori (2013-03-22 04:20:28)
> Mike,
>
> On 11/28/2012 6:52 PM, Sekhar Nori wrote:
> > On 11/27/2012 10:59 PM, Mike Turquette wrote:
>
> >> Also have you looked into regmap? Since you are defining your own clock
> >> type that might be something nice for you.
> >
> > No, haven't looked at regmap yet. Will look at that.
>
> I could get to this only now. regmap needs a valid struct device. We
> aren't modelling psc clocks as device so regmap cannot be used here.
>
According to Murali's reply back in November it was still not known if
the PTCMD register was going to be concurrently accessed by sources
outside the clock framework. If this is so then neither the existing
framework-level lock (e.g. enable_lock) nor the shared clock driver lock
(e.g. spinlock in struct clk_psc) are adequate. You may need a device
driver which represents the PSC and use accessor functions to write to
those register which provide coordination.
Regards,
Mike
> Thanks,
> Sekhar
--
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