Hi,
> From: [EMAIL PROTECTED] [mailto:linux-omap-
> [EMAIL PROTECTED] On Behalf Of Paul Walmsley
> between omap_clk_associate() and vclk, my preference is for the
> omap_clk_associate() approach.
>
> The core problem is that the vclk patches create clocks with multiple
> parents in a way that is
Hi Paul,
From: "ext Paul Walmsley" <[EMAIL PROTECTED]>
Subject: Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
Date: Wed, 15 Oct 2008 03:13:49 -0600 (MDT)
> Hello Hiroshi,
>
> On Tue, 14 Oct 2008, Hiroshi DOYU wrote:
>
> > I understood both points you ex
Hello Hiroshi,
On Tue, 14 Oct 2008, Hiroshi DOYU wrote:
> I understood both points you explained below, while I still think that
> standardizing clock names may be a little bit rigid.
Perhaps you can help me understand - are you referring to the use of the
TRM clocks, rather than creating a cus
Hi Paul,
I understood both points you explained below, while I still think that
standardizing clock names may be a little bit rigid.
Thank you for your review and comments.
Hiroshi DOYU
From: "ext Paul Walmsley" <[EMAIL PROTECTED]>
Subject: Re: [PATCH 1/3] [RFC] clk: introdu
Hi,
between omap_clk_associate() and vclk, my preference is for the
omap_clk_associate() approach.
The core problem is that the vclk patches create clocks with multiple
parents in a way that is hidden from the clock framework. This causes
both semantic and practical problems.
Semantically,
On Mon, Oct 06, 2008 at 11:42:08AM -0700, David Brownell wrote:
> They're all OMAP-specific drivers. They can know that they
> need to ask for both clocks. If perchance only one of them
> were actually needed, that would be exceptional ... and the
> driver should be able to assume the device was
On Thursday 02 October 2008, Hiroshi DOYU wrote:
> For some of the above drivers, omap's "functional clock" and
> "interface clock" doesn't make sense.
Actually, I thought OMAP was pretty consistent about having
both on all modules where it made sense.
> For such device drivers, those
> clocks
* Hiroshi DOYU <[EMAIL PROTECTED]> [081003 09:24]:
> Hi David,
>
> From: "ext David Brownell" <[EMAIL PROTECTED]>
> Subject: Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
> Date: Thu, 2 Oct 2008 13:50:02 -0700
>
> > On Wednesday 01 October 20
Hi David,
From: "ext David Brownell" <[EMAIL PROTECTED]>
Subject: Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
Date: Thu, 2 Oct 2008 13:50:02 -0700
> On Wednesday 01 October 2008, Hiroshi DOYU wrote:
> > Or, this feature itself can be covered by 'virtual c
On Thu, Oct 02, 2008 at 01:50:02PM -0700, David Brownell wrote:
> On Wednesday 01 October 2008, Hiroshi DOYU wrote:
> > Or, this feature itself can be covered by 'virtual clock(vclk)'?
> >
> > http://marc.info/?l=linux-omap&m=122066992729949&w=2
> >
> > which means that,
> > in this case, if
On Wednesday 01 October 2008, Hiroshi DOYU wrote:
> Or, this feature itself can be covered by 'virtual clock(vclk)'?
>
> http://marc.info/?l=linux-omap&m=122066992729949&w=2
>
> which means that,
> in this case, if 'vclk' just has a single child, not multiple, it can
> be used just as 'aliasi
From: "ext David Brownell" <[EMAIL PROTECTED]>
Subject: Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
Date: Wed, 1 Oct 2008 09:15:45 -0700
> On Wednesday 01 October 2008, Felipe Balbi wrote:
> > > So mirroring "at91_clock_associate()" ... maybe this
On Wednesday 01 October 2008, Felipe Balbi wrote:
> > So mirroring "at91_clock_associate()" ... maybe this
> > should be "omap_clock_associate()" not "clk_associate()".
>
> Well, I'm ok with that but I'd rather see clk_associate() moving to
> clk api so anyone who needs that, could use it.
Seems
On Wed, Oct 01, 2008 at 08:51:46AM -0700, David Brownell wrote:
> On Wednesday 01 October 2008, Felipe Balbi wrote:
> > +/**
> > + * clk_associate - associates a user to a clock so device drivers don't
> > + * have to care about clock names
> > + *
> > + * @id: clock id as defined in arch/arm/mach-
On Wednesday 01 October 2008, Felipe Balbi wrote:
> +/**
> + * clk_associate - associates a user to a clock so device drivers don't
> + * have to care about clock names
> + *
> + * @id: clock id as defined in arch/arm/mach-omapX/clk.h
> + * @dev: device pointer for the clock user
> + * @f: a fu
Introduce a new mechanism to omap's clk implementation to
associate the device with its clock during platform_device
registration. Also gives the clock a function name (like
mmc_fck, uart_fck, ehci_fck, etc) so drivers won't have to
care about clk names any longer.
With this mechanism we can also
16 matches
Mail list logo
