All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	SH-Linux <linux-sh@vger.kernel.org>,
	john stultz <johnstul@us.ibm.com>,
	"Simon Horman [Horms]" <horms@verge.net.au>,
	Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] clocksource: sh_cmt: 32-bit control register support
Date: Tue, 18 Jun 2013 10:35:39 +0000	[thread overview]
Message-ID: <1531456.g1EpKAjrma@avalon> (raw)
In-Reply-To: <CANqRtoSnBfr5sfSiYayKCmyw0EpY4+kq7pnQ1BJQt6wagTe8eQ@mail.gmail.com>

Hi Magnus,

On Tuesday 18 June 2013 14:39:38 Magnus Damm wrote:
> On Tue, Jun 18, 2013 at 3:37 AM, Laurent Pinchart wrote:
> > On Monday 17 June 2013 15:40:52 Magnus Damm wrote:
> >> From: Magnus Damm <damm@opensource.se>
> >> 
> >> Add support for CMT hardware with 32-bit control and counter
> >> registers, as found on r8a73a4 and r8a7790. To use the CMT
> >> with 32-bit hardware a second I/O memory resource needs to
> >> point out the CMSTR register and it needs to be 32 bit wide.
> > 
> > Is a memory second resource required ? Can't we use a single resource that
> > will contain all the registers ?
> 
> The CMT hardware block comes with a shared timer start stop register
> that historically has been left out of the resource. The location of
> this register has so far been pointed out by the "channel offset"
> platform data member, together with information about which bit that
> happens to be assigned to the timer channel. This start stop register
> has happened to be kept in the same page of I/O memory as the main
> timer channel resource, so at this point we're sort of "lucky" that a
> single ioremap() has covered all cases.
> 
> With this patch it becomes optional to instead of platform data use a
> second resource to point out the timer start/stop register. While we
> do that we can also use the size of that resource to determine the I/O
> access width, which happens to be something that is needed to enable
> the driver on certain SoCs.

OK, I get it now. I've had a quick look at the documentation, and I'm 
wondering whether we shouldn't register a single platform device that span all 
the channels contained in the CMT, instead of registering one platform device 
per channel.

> > Time to switch to devm_* managed functions ? :-)
> 
> Yes, indeed. That among other things, like converting the driver to in
> a more optimal way support clock source only or clock event only
> configurations. Also, some more modern CMT hardware versions have
> extended registers with 48-bit counters, and we can also often use
> more high frequency clocks to improve timer resolution.
> 
> As you can tell, in general there are many things that can be improved
> with this driver. I thought a first shot could be to make it actually
> work on more recent CMT hardware with 32-bit only registers. So that's
> what this patch does!

-- 
Regards,

Laurent Pinchart


WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	SH-Linux <linux-sh@vger.kernel.org>,
	john stultz <johnstul@us.ibm.com>,
	"Simon Horman [Horms]" <horms@verge.net.au>,
	Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] clocksource: sh_cmt: 32-bit control register support
Date: Tue, 18 Jun 2013 12:35:39 +0200	[thread overview]
Message-ID: <1531456.g1EpKAjrma@avalon> (raw)
In-Reply-To: <CANqRtoSnBfr5sfSiYayKCmyw0EpY4+kq7pnQ1BJQt6wagTe8eQ@mail.gmail.com>

Hi Magnus,

On Tuesday 18 June 2013 14:39:38 Magnus Damm wrote:
> On Tue, Jun 18, 2013 at 3:37 AM, Laurent Pinchart wrote:
> > On Monday 17 June 2013 15:40:52 Magnus Damm wrote:
> >> From: Magnus Damm <damm@opensource.se>
> >> 
> >> Add support for CMT hardware with 32-bit control and counter
> >> registers, as found on r8a73a4 and r8a7790. To use the CMT
> >> with 32-bit hardware a second I/O memory resource needs to
> >> point out the CMSTR register and it needs to be 32 bit wide.
> > 
> > Is a memory second resource required ? Can't we use a single resource that
> > will contain all the registers ?
> 
> The CMT hardware block comes with a shared timer start stop register
> that historically has been left out of the resource. The location of
> this register has so far been pointed out by the "channel offset"
> platform data member, together with information about which bit that
> happens to be assigned to the timer channel. This start stop register
> has happened to be kept in the same page of I/O memory as the main
> timer channel resource, so at this point we're sort of "lucky" that a
> single ioremap() has covered all cases.
> 
> With this patch it becomes optional to instead of platform data use a
> second resource to point out the timer start/stop register. While we
> do that we can also use the size of that resource to determine the I/O
> access width, which happens to be something that is needed to enable
> the driver on certain SoCs.

OK, I get it now. I've had a quick look at the documentation, and I'm 
wondering whether we shouldn't register a single platform device that span all 
the channels contained in the CMT, instead of registering one platform device 
per channel.

> > Time to switch to devm_* managed functions ? :-)
> 
> Yes, indeed. That among other things, like converting the driver to in
> a more optimal way support clock source only or clock event only
> configurations. Also, some more modern CMT hardware versions have
> extended registers with 48-bit counters, and we can also often use
> more high frequency clocks to improve timer resolution.
> 
> As you can tell, in general there are many things that can be improved
> with this driver. I thought a first shot could be to make it actually
> work on more recent CMT hardware with 32-bit only registers. So that's
> what this patch does!

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2013-06-18 10:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-14  5:55 [PATCH] clocksource: sh_cmt: 32-bit control register access prototype Magnus Damm
2013-06-17  6:40 ` [PATCH] clocksource: sh_cmt: 32-bit control register support Magnus Damm
2013-06-17  6:40   ` Magnus Damm
2013-06-17 18:37   ` Laurent Pinchart
2013-06-17 18:37     ` Laurent Pinchart
2013-06-18  5:39     ` Magnus Damm
2013-06-18  5:39       ` Magnus Damm
2013-06-18 10:35       ` Laurent Pinchart [this message]
2013-06-18 10:35         ` Laurent Pinchart
2013-06-18 11:54         ` Magnus Damm
2013-06-18 11:54           ` Magnus Damm
2013-06-18 12:30           ` Laurent Pinchart
2013-06-18 12:30             ` Laurent Pinchart
2013-06-18 13:27             ` Magnus Damm
2013-06-18 13:27               ` Magnus Damm
2013-06-19 12:31               ` Simon Horman
2013-06-19 12:31                 ` Simon Horman
2013-06-19 12:58                 ` Laurent Pinchart
2013-06-19 12:58                   ` Laurent Pinchart
2013-06-20 12:30                   ` Simon Horman
2013-06-20 12:30                     ` Simon Horman
  -- strict thread matches above, loose matches on Subject: below --
2013-07-19  4:35 [GIT] Renesas ARM based clocksource updates for v3.12 Simon Horman
2013-07-19  4:36 ` [PATCH] clocksource: sh_cmt: 32-bit control register support Simon Horman
2013-07-19  4:36   ` Simon Horman
2013-07-22  4:04   ` Daniel Lezcano
2013-07-22  4:04     ` Daniel Lezcano
2013-07-24  0:26     ` Simon Horman
2013-07-24  0:26       ` Simon Horman
2013-08-04 19:23       ` Olof Johansson
2013-08-04 19:23         ` Olof Johansson
2013-08-05  1:40         ` Simon Horman
2013-08-05  1:40           ` Simon Horman

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=1531456.g1EpKAjrma@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=horms@verge.net.au \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=shinya.kuribayashi.px@renesas.com \
    --cc=tglx@linutronix.de \
    /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.