public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Conor Dooley <conor@kernel.org>,
	krzk+dt@kernel.org, mturquette@baylibre.com, sboyd@kernel.org,
	robh@kernel.org, conor+dt@kernel.org, matthias.bgg@gmail.com,
	jassisinghbrar@gmail.com, garmin.chang@mediatek.com,
	houlong.wei@mediatek.com, Jason-ch.Chen@mediatek.com,
	amergnat@baylibre.com, Elvis.Wang@mediatek.com,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, kernel@collabora.com
Subject: Re: [PATCH 3/3] dt-bindings: mailbox: mediatek: Avoid clock-names on MT8188 GCE
Date: Thu, 20 Jun 2024 10:32:36 +0200	[thread overview]
Message-ID: <c154527b-90c3-4834-a4a0-cff4524de5f1@collabora.com> (raw)
In-Reply-To: <20240620-district-bullring-c028e0183925@wendy>

Il 20/06/24 10:22, Conor Dooley ha scritto:
> On Thu, Jun 20, 2024 at 10:01:18AM +0200, AngeloGioacchino Del Regno wrote:
>> Il 19/06/24 19:49, Conor Dooley ha scritto:
>>> On Wed, Jun 19, 2024 at 10:53:22AM +0200, AngeloGioacchino Del Regno wrote:
>>>> Add mediatek,mt8188-gce to the list of compatibles for which the
>>>> clock-names property is not required.
>>>
>>> Because, I assume, it has some internal clock? Why do either of these
>>> things have no clock? Doesn't the internal logic require one?
>>>
>>
>> Because there's no gce0/gce1 clock, there's only an infracfg_AO clock that is
>> for one GCE instance, hence there's no need to require clock-names.
> 
> clock-names, d'oh. I misread that completely yesterday.
> 
>> I can't remove the clock-names requirement from the older compatibles though,
>> because the (sorry about this word) driver (eh..) gets the clock by name for
>> the single GCE SoCs...
>>
>> ...and here comes a self-NACK for this commit, I have to fix the driver and
>> then stop requiring clock-names on all compatibles, instead of having this
>> ugly nonsense.
> 
> Is it not worth keeping the clock names, even if ugly or w/e, because
> things have been done that way for a while?

It's worth allowing clock-names, but *requiring* that is unnecessary because
there is, and there will always be, only one clock...!

> Also, what does U-Boot do on these systems to get the clocks?
> 

U-Boot doesn't support GCE at all (no driver - at least upstream)...!

>> Self-note: gce0/gce1 clocks lookup was implemented in the driver but never
>> used and never added to the binding - luckily.
>>
>> Sorry Conor, I just acknowledged that there's a better way of doing that.
>>
>> Thank you for making me re-read this stuff, I'll send the proper changes
>> later today, driver change + binding change in a separate series.
>>
>> As for the other two commits in this series, completely unrelated to GCE,
>> those are still fine, and are fixing dtbs_check warnings.




  reply	other threads:[~2024-06-20  8:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-19  8:53 [PATCH 1/3] arm64: dts: mediatek: mt8188: Fix VPPSYS0/1 node name/compatibles AngeloGioacchino Del Regno
2024-06-19  8:53 ` [PATCH 2/3] dt-bindings: clock: mediatek: Document reset cells for MT8188 sys AngeloGioacchino Del Regno
2024-06-19 17:51   ` Conor Dooley
2024-07-08 19:08   ` Stephen Boyd
2024-06-19  8:53 ` [PATCH 3/3] dt-bindings: mailbox: mediatek: Avoid clock-names on MT8188 GCE AngeloGioacchino Del Regno
2024-06-19 17:49   ` Conor Dooley
2024-06-20  8:01     ` AngeloGioacchino Del Regno
2024-06-20  8:22       ` Conor Dooley
2024-06-20  8:32         ` AngeloGioacchino Del Regno [this message]
2024-06-20 16:16           ` Conor Dooley
2024-06-20  8:49 ` [PATCH 1/3] arm64: dts: mediatek: mt8188: Fix VPPSYS0/1 node name/compatibles Fei Shao
2024-06-24 10:46 ` (subset) " AngeloGioacchino Del Regno

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=c154527b-90c3-4834-a4a0-cff4524de5f1@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=Elvis.Wang@mediatek.com \
    --cc=Jason-ch.Chen@mediatek.com \
    --cc=amergnat@baylibre.com \
    --cc=conor+dt@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=garmin.chang@mediatek.com \
    --cc=houlong.wei@mediatek.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.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