LKML Archive on lore.kernel.org
 help / color / Atom feed
From: <Claudiu.Beznea@microchip.com>
To: <daniel.lezcano@linaro.org>, <alexandre.belloni@bootlin.com>
Cc: <mark.rutland@arm.com>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <Ludovic.Desroches@microchip.com>,
	<robh+dt@kernel.org>, <tglx@linutronix.de>,
	<linux-arm-kernel@lists.infradead.org>,
	<arnd.bergmann@linaro.org>
Subject: Re: Re: [PATCH 2/5] clocksource/drivers/timer-microchip-pit64b: add Microchip PIT64B support
Date: Thu, 13 Jun 2019 14:12:53 +0000
Message-ID: <5e3d783e-7bcc-64c1-c814-eaf99a6aa205@microchip.com> (raw)
In-Reply-To: <7267f37b-4f80-97e3-7a8e-bc1a9a28b995@linaro.org>

Hi Daniel,

On 31.05.2019 13:41, Daniel Lezcano wrote:
> 
> Hi Claudiu,
> 
> 
> On 30/05/2019 09:46, Claudiu.Beznea@microchip.com wrote:
>> Hi Daniel,
>>
>> Taking into account the discussion on this tread and the fact that we have
>> no answer from Rob on this topic (I'm talking about [1]), what do you think
>> it would be best for this driver to be accepted the soonest? Would it be OK
>> for you to mimic the approach done by:
>>
>> drivers/clocksource/timer-integrator-ap.c
>>
>> with the following bindings in DT:
>>
>> aliases {
>> 	arm,timer-primary = &timer2;
>> 	arm,timer-secondary = &timer1;
>> };
>>
>> also in PIT64B driver?
>>
>> Or do you think re-spinning the Alexandre's patches at [2] (which seems to
>> me like the generic way to do it) would be better?
> 
> This hardware / OS connection problem is getting really annoying for
> everyone and this pattern is repeating itself since several years. It is
> time we fix it properly.
> 
> The first solution looks hackish from my POV. The second approach looks
> nicer and generic as you say. So I would vote for [2]
> flagging approach proposed by Mark [3].

With this flagging approach this would mean a kind unification of
clocksource and clockevent functionalities under a single one, right? So
that the driver would register to the above layers only one device w/ 2
functionalities (clocksource and clockevent)? Please correct me if I'm
wrong? If so, from my point of view this would require major re-working of
clocksource and clockevent subsystems. Correctly if I wrongly understood,
please.

At the moment we register different functionalities (clocksource and
clockevent) to the above layers for hardware blocks (e.g. with
clocksource_register_hz() or clockevents_config_and_register()). If
hardware can support clocksource and clockevent we register both these
functionalities, if only one is supported we register only one of these.
The above layers would choose the best clocksource/clockevent device from
the available ones based on rating field for each clocksource/clockevent we
register. In all this current behavior I don't see how these flags would
interact with clocksource/clockevent subsystem. Could you please let me
know how do you see these and the way these new flags would interact with
the layers above the drivers?

Thank you,
Claudiu Beznea

> 
> I added Arnd in Cc in order to have its opinion.
> 
> [3]
> https://lore.kernel.org/lkml/20171215113242.skmh5nzr7wqdmvnw@lakrids.cambridge.arm.com/
> 
>> [1]
>> https://lore.kernel.org/lkml/20190408151155.20279-1-alexandre.belloni@bootlin.com/#t
>> [2]
>> https://lore.kernel.org/lkml/20171213185313.20017-1-alexandre.belloni@free-electrons.com/
>>
> 
> 
> 
> 
> 
> 

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14 16:26 [PATCH 0/2] add Microchip PIT64B timer Claudiu.Beznea
2019-03-14 16:26 ` [PATCH 1/5] dt-bindings: arm: atmel: add bindings for PIT64B Claudiu.Beznea
2019-03-31  6:40   ` Rob Herring
2019-04-01  8:41   ` Nicolas.Ferre
2019-03-14 16:26 ` [PATCH 2/5] clocksource/drivers/timer-microchip-pit64b: add Microchip PIT64B support Claudiu.Beznea
2019-04-01  8:40   ` Nicolas.Ferre
2019-04-08  8:43   ` Daniel Lezcano
2019-04-08 11:48     ` Claudiu.Beznea
2019-04-08 12:11     ` Alexandre Belloni
2019-04-08 12:35       ` Daniel Lezcano
2019-04-08 12:42         ` Alexandre Belloni
2019-04-08 13:22           ` Daniel Lezcano
2019-04-08 14:01             ` Alexandre Belloni
2019-05-30  7:46       ` Claudiu.Beznea
2019-05-31 10:41         ` Daniel Lezcano
2019-06-13 14:12           ` Claudiu.Beznea [this message]
2019-06-20  8:53             ` Daniel Lezcano
2019-06-21 10:34               ` Claudiu.Beznea
2019-06-24  8:06                 ` Daniel Lezcano
2019-03-14 16:26 ` [PATCH 3/5] MAINTAINERS: change section name to be more generic Claudiu.Beznea
2019-04-01  8:41   ` Nicolas.Ferre
2019-03-14 16:26 ` [PATCH 4/5] MAINTAINERS: add myself as maintainer Claudiu.Beznea
2019-04-01  8:41   ` Nicolas.Ferre
2019-03-14 16:26 ` [PATCH 5/5] MAINTAINERS: add timer-microchip-pit64c.c Claudiu.Beznea
2019-04-01  8:41   ` Nicolas.Ferre

Reply instructions:

You may reply publically 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=5e3d783e-7bcc-64c1-c814-eaf99a6aa205@microchip.com \
    --to=claudiu.beznea@microchip.com \
    --cc=Ludovic.Desroches@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd.bergmann@linaro.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git