devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Yinbo Zhu <zhuyinbo@loongson.cn>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Jianmin Lv <lvjianmin@loongson.cn>, Yun Liu <liuyun@loongson.cn>,
	Yang Li <yang.lee@linux.alibaba.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	loongarch@lists.linux.dev, zhuyinbo@loongson.cn
Subject: Re: [PATCH v11 1/3] clocksource: loongson2_hpet: add hpet driver support
Date: Fri, 02 Dec 2022 10:04:12 +0100	[thread overview]
Message-ID: <87bkomqir7.ffs@tglx> (raw)
In-Reply-To: <c46e5ebf-5293-5123-52d3-b3594c6e9244@loongson.cn>

On Fri, Dec 02 2022 at 12:36, Yinbo Zhu wrote:
> 在 2022/12/1 19:29, Thomas Gleixner 写道:
>>
>>> +static DEFINE_SPINLOCK(hpet_lock);
>> This wants to be a raw spinlock if at all. But first you have to explain
>> the purpose of this lock.
>>
>>> +DEFINE_PER_CPU(struct clock_event_device, hpet_clockevent_device);
>> Why needs this to be global and why is it needed at all?
>>
>> This code does support exactly _ONE_ clock event device.
>
> This is consider that the one hardware clock_event_device is used for 
> multiple cpu cores,
>
> and earch cpu cores has a device from its perspective, so add 
> DEFINE_SPINLOCK(hpet_lock)
>
> and DEFINE_PER_CPU(struct clock_event_device, hpet_clockevent_device),
>
> the use of locks described below is also this reason .

You cannot use _ONE_ clock event device as per CPU clock event device
for multiple CPUs. That simply cannot work ever.

There are two types of clockevent devices:

      1) strictly per CPU, i.e. one distinct device per CPU

      2) global broadcast device

The global broadcast device is used if there are less physical devices
than CPUs or to handle the cases where the per CPU device stops in
deep idle states.

For the case that there are less physical devices than CPUs, you have to
install dummy per CPU devices. Grep for CLOCK_EVT_FEAT_DUMMY.

The core code will use the broadcast device to provide timer interrupts
and it propagates them to the CPUs which are backed by a dummy per CPU
device via IPIs.

None of this needs a lock in the driver code unless the hardware is
really dumb designed and has a register shared with something else.

The serialization for all clockevent devices is completely provided by
the core code.

>> Seriously, this is not how it works. Instead of copy & paste, we create
>> shared infrastructure and just keep the real architecture specific
>> pieces separate.
>
> I don't find the shared infrastructure in LoongArch, I want to support  
> hpet for LoongArch

Of course you can't find shared infrastructure because there is none.

That's the whole point. Instead of creating copies of code, you rework
the code so that the common parts can be shared between x86, longson and
loongarch. Then you have the architecture/platform specific pieces which
deal with the specific enumeration/initialization and use the shared
infrastructure.

Thanks,

        tglx





      reply	other threads:[~2022-12-02  9:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-29  3:09 [PATCH v11 1/3] clocksource: loongson2_hpet: add hpet driver support Yinbo Zhu
2022-11-29  3:09 ` [PATCH v11 2/3] LoongArch: time: add timer_probe in time_init Yinbo Zhu
2022-11-29  3:09 ` [PATCH v11 3/3] dt-bindings: hpet: add loongson-2 hpet Yinbo Zhu
2022-12-01 11:29 ` [PATCH v11 1/3] clocksource: loongson2_hpet: add hpet driver support Thomas Gleixner
2022-12-02  4:36   ` Yinbo Zhu
2022-12-02  9:04     ` Thomas Gleixner [this message]

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=87bkomqir7.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=chenhuacai@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=kernel@xen0n.name \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liuyun@loongson.cn \
    --cc=loongarch@lists.linux.dev \
    --cc=lvjianmin@loongson.cn \
    --cc=robh+dt@kernel.org \
    --cc=yang.lee@linux.alibaba.com \
    --cc=zhuyinbo@loongson.cn \
    /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).