linux-snps-arc.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: alexandre.belloni@bootlin.com (Alexandre Belloni)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 4/7] dt-bindings: chosen: Add clocksource and clockevent selection
Date: Tue, 10 Sep 2019 17:10:55 +0200	[thread overview]
Message-ID: <20190910151055.GX21254@piout.net> (raw)
In-Reply-To: <20190910150826.GA18308@e107533-lin.cambridge.arm.com>

On 10/09/2019 16:08:26+0100, Sudeep Holla wrote:
> On Tue, Sep 10, 2019@02:51:50PM +0000, Claudiu.Beznea@microchip.com wrote:
> > 
> > 
> > On 10.09.2019 17:32, Sudeep Holla wrote:
> > > External E-Mail
> > > 
> > > 
> > > On Tue, Sep 10, 2019@04:47:13PM +0300, Claudiu Beznea wrote:
> > >> From: Alexandre Belloni <alexandre.belloni at bootlin.com>
> > >>
> > >> Some timer drivers may behave either as clocksource or clockevent
> > >> or both. Until now, in case of platforms with multiple hardware
> > >> resources of the same type, the drivers were chosing the first
> > >> registered hardware resource as clocksource/clockevent and the
> > >> next one as clockevent/clocksource. Other were using different
> > >> compatibles (one for each functionality, although its about the
> > >> same hardware). Add DT bindings to be able to choose the
> > >> functionality of a timer.
> > >>
> > > 
> > > Is the piece of hardware not capable of serving as both clocksource
> > > and clockevent or is it just the platform choice ?
> > 
> > In my case, the hardware is not capable of serving at the same time
> > a clocksource device and a clockevent device.
> > 
> > First, I published v1 for a hardware device having this behavior at
> > [1] requesting 1st probed hardware device to work as clocksource and
> > the 2nd one to work as clockevent. The discussion at [1] ended up with
> > the idea of having a mechanism to specify which hardware device behaves
> > as clocksource and which one behaves as clockevent.
> >
> 
> In that case, why can't we identify capability that with the compatibles
> for this timer IP ?
> 
> IOW, I don't like the proposal as it's hardware limitation.
> 

To be clear, bot timers are exactly the same but can't be clocksource
and clockevent at the same time. Why would we have different compatibles
for the exact same IP?


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2019-09-10 15:10 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10 13:47 [PATCH 0/7] add support for clocksource/clockevent DT selection Claudiu Beznea
2019-09-10 13:47 ` [PATCH 1/7] clocksource/drivers/c-sky: request timer_of_init only for probing CPU Claudiu Beznea
2019-09-10 13:47 ` [PATCH 2/7] clocksource: change timer registration macros Claudiu Beznea
2019-09-10 14:49   ` Marc Zyngier
2019-09-10 14:57     ` Claudiu.Beznea
2019-09-10 13:47 ` [PATCH 3/7] clocksource/timer_of: use BIT() macro Claudiu Beznea
2019-09-10 13:47 ` [PATCH 4/7] dt-bindings: chosen: Add clocksource and clockevent selection Claudiu Beznea
2019-09-10 14:32   ` Sudeep Holla
2019-09-10 14:51     ` Claudiu.Beznea
2019-09-10 15:08       ` Sudeep Holla
2019-09-10 15:10         ` Alexandre Belloni [this message]
2019-09-11  0:03           ` Linus Walleij
2019-09-11  7:18             ` Claudiu.Beznea
2019-09-12 14:18               ` Linus Walleij
2019-09-30 14:32               ` Rob Herring
2019-10-02 13:32                 ` Claudiu.Beznea
2019-09-11  7:34   ` Neil Armstrong
2019-09-11  9:14     ` Alexandre Belloni
2019-09-10 13:47 ` [PATCH 5/7] clocksource/drivers/timer-of: add support support for timer's functionalities Claudiu Beznea
2019-09-10 13:47 ` [PATCH 6/7] drivers/clocksource/timer-of: keep declaration on one line Claudiu Beznea
2019-09-10 13:47 ` [PATCH 7/7] clocksource/drivers/integrator-ap: parse the chosen node Claudiu Beznea
2019-09-10 23:48   ` Linus Walleij
2019-09-11  7:14     ` Claudiu.Beznea
2019-09-10 16:05 ` [PATCH 0/7] add support for clocksource/clockevent DT selection John Stultz
2019-09-11  6:52   ` Claudiu.Beznea
2019-09-11 16:06     ` John Stultz
2019-09-25 17:19 ` Daniel Lezcano
2019-09-26  8:42   ` Claudiu.Beznea
2019-10-02 13:35     ` Claudiu.Beznea
2019-10-03 10:43       ` Claudiu.Beznea
2019-10-13 18:16         ` Daniel Lezcano
     [not found]           ` <7071b6fa-f7ed-c879-4a43-44100dbe6121@microchip.com>
2019-10-18 20:24             ` Daniel Lezcano
2019-10-21  8:58               ` Claudiu.Beznea
2019-10-21 14:17                 ` Daniel Lezcano

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=20190910151055.GX21254@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=linux-snps-arc@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).