All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Turquette <mturquette@linaro.org>
To: "Mohammed, Afzal" <afzal@ti.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Subject: Re: RE: RE: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Date: Fri, 25 Jan 2013 14:35:24 -0800	[thread overview]
Message-ID: <20130125223524.10623.29375@quantum> (raw)
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA93851@DBDE01.ent.ti.com>

Quoting Mohammed, Afzal (2013-01-25 04:06:41)
> Hi Mike,
> 
> On Thu, Jan 24, 2013 at 22:36:30, Mike Turquette wrote:
> > Quoting Mohammed, Afzal (2013-01-24 03:29:15)
> 
> > > It is a functional constraint: divider has 8 bits and it can have
> > > all possible values (0 to 255) and divider value corresponds to
> > > value set in the 8 bits. But depending on the modes the minimum
> > > value that can be configured (to get display working) varies.
> > > Eg. For raster mode (which the driver is presently supporting), it
> > > can take a minimum value of 2, while in LIDD (LCD interface display
> > > driver) mode it can take a min value of 1.
> > > 
> > > Here min rate is not a constraint w.r.t divider in LCDC IP, but
> > > rather min divider.
> 
> > Just so I understand correctly... you are saying that the functional
> > constraint is not caused by the clock rate, but instead by the divider
> > value?  For the different modes (raster vs LIDD) is the clock rate the
> > same, or is the clock rate different?
> 
> > What is the clock output rate of the divider in raster mode?  What is
> > the clock output rate of the divider in LIDD mode?
> 
> Yes, functional constraint in caused by divider value.
> 
> clock output rate can defined for both modes as follows,
> 
> p_clk (clock output rate) = lcd_clk (input clock rate) / div,
> 
> to configure "div", we have r/w 8 bits, so div values can
> range from 0-255,
> 
> And IP spec says value "0" and "1" should not be written, in
> raster mode. Further it says if in LIDD mode it can have values
> from 0-255, but effect of writing "0" is same as "1".
> 

Afzal,

Thank you for the information.  In short, the way you program your clock
depend on the configuration of your lcdc device.

As such I am not sure the basic divider is the right choice for you.
You might be better off creating a clock for your IP which takes into
account these details.  Luckily it is possible to inherit from the basic
clock types and create a new type.

An example of this is the MXS divider.  It uses the basic divider as a
"parent class" and adds a busy bit.  This is a better approach than
putting every feature into the basic divider type.  You can see how it
was done in drivers/clk/mxs/clk-div.c

Let me know what you think.

Regards,
Mike

> Effect of divider value on output rate is in the same way for
> both modes as per above expression (except for writing "0" in
> LIDD mode).
> 
> The driver supports only raster mode.
> 
> Regards
> Afzal
> 
> Note: link to trm has been mentioned in the earlier reply.

WARNING: multiple messages have this Message-ID (diff)
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] clk: divider: prepare for minimum divider
Date: Fri, 25 Jan 2013 14:35:24 -0800	[thread overview]
Message-ID: <20130125223524.10623.29375@quantum> (raw)
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA93851@DBDE01.ent.ti.com>

Quoting Mohammed, Afzal (2013-01-25 04:06:41)
> Hi Mike,
> 
> On Thu, Jan 24, 2013 at 22:36:30, Mike Turquette wrote:
> > Quoting Mohammed, Afzal (2013-01-24 03:29:15)
> 
> > > It is a functional constraint: divider has 8 bits and it can have
> > > all possible values (0 to 255) and divider value corresponds to
> > > value set in the 8 bits. But depending on the modes the minimum
> > > value that can be configured (to get display working) varies.
> > > Eg. For raster mode (which the driver is presently supporting), it
> > > can take a minimum value of 2, while in LIDD (LCD interface display
> > > driver) mode it can take a min value of 1.
> > > 
> > > Here min rate is not a constraint w.r.t divider in LCDC IP, but
> > > rather min divider.
> 
> > Just so I understand correctly... you are saying that the functional
> > constraint is not caused by the clock rate, but instead by the divider
> > value?  For the different modes (raster vs LIDD) is the clock rate the
> > same, or is the clock rate different?
> 
> > What is the clock output rate of the divider in raster mode?  What is
> > the clock output rate of the divider in LIDD mode?
> 
> Yes, functional constraint in caused by divider value.
> 
> clock output rate can defined for both modes as follows,
> 
> p_clk (clock output rate) = lcd_clk (input clock rate) / div,
> 
> to configure "div", we have r/w 8 bits, so div values can
> range from 0-255,
> 
> And IP spec says value "0" and "1" should not be written, in
> raster mode. Further it says if in LIDD mode it can have values
> from 0-255, but effect of writing "0" is same as "1".
> 

Afzal,

Thank you for the information.  In short, the way you program your clock
depend on the configuration of your lcdc device.

As such I am not sure the basic divider is the right choice for you.
You might be better off creating a clock for your IP which takes into
account these details.  Luckily it is possible to inherit from the basic
clock types and create a new type.

An example of this is the MXS divider.  It uses the basic divider as a
"parent class" and adds a busy bit.  This is a better approach than
putting every feature into the basic divider type.  You can see how it
was done in drivers/clk/mxs/clk-div.c

Let me know what you think.

Regards,
Mike

> Effect of divider value on output rate is in the same way for
> both modes as per above expression (except for writing "0" in
> LIDD mode).
> 
> The driver supports only raster mode.
> 
> Regards
> Afzal
> 
> Note: link to trm has been mentioned in the earlier reply.

  reply	other threads:[~2013-01-25 22:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23 11:38 [PATCH v2 1/2] clk: divider: prepare for minimum divider Afzal Mohammed
2013-01-23 11:38 ` Afzal Mohammed
2013-01-23 11:38 ` Afzal Mohammed
2013-01-23 11:39 ` [PATCH v2 2/2] clk: divider: handle " Afzal Mohammed
2013-01-23 11:39   ` Afzal Mohammed
2013-01-23 11:39   ` Afzal Mohammed
2013-01-23 21:40 ` [PATCH v2 1/2] clk: divider: prepare for " Mike Turquette
2013-01-23 21:40   ` Mike Turquette
2013-01-23 21:40   ` Mike Turquette
2013-01-24 11:29   ` Mohammed, Afzal
2013-01-24 11:29     ` Mohammed, Afzal
2013-01-24 11:29     ` Mohammed, Afzal
2013-01-24 17:06     ` Mike Turquette
2013-01-24 17:06       ` Mike Turquette
2013-01-25 12:06       ` Mohammed, Afzal
2013-01-25 12:06         ` Mohammed, Afzal
2013-01-25 12:06         ` Mohammed, Afzal
2013-01-25 22:35         ` Mike Turquette [this message]
2013-01-25 22:35           ` Mike Turquette
2013-01-28  9:18           ` RE: " Mohammed, Afzal
2013-01-28  9:18             ` Mohammed, Afzal
2013-01-28  9:18             ` Mohammed, Afzal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130125223524.10623.29375@quantum \
    --to=mturquette@linaro.org \
    --cc=afzal@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=sboyd@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.