[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAhV-H7yTDMrZiOCBs6U8+_K3pPDwk-S2boEy2aOJgTqoUGYGw@mail.gmail.com>
Date: Wed, 24 May 2023 10:52:18 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: WANG Xuerui <kernel@...0n.name>
Cc: Sui Jingfeng <15330273260@....cn>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, Li Yi <liyi@...ngson.cn>,
Sumit Semwal <sumit.semwal@...aro.org>,
Christian Koenig <christian.koenig@....com>,
Emil Velikov <emil.l.velikov@...il.com>,
loongson-kernel@...ts.loongnix.cn,
Geert Uytterhoeven <geert+renesas@...der.be>,
Nathan Chancellor <nathan@...nel.org>,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
Javier Martinez Canillas <javierm@...hat.com>,
linaro-mm-sig@...ts.linaro.org, Liu Peibao <liupeibao@...ngson.cn>,
linux-media@...r.kernel.org
Subject: Re: [PATCH v14 1/2] drm: add kms driver for loongson display controller
On Tue, May 23, 2023 at 4:14 PM WANG Xuerui <kernel@...0n.name> wrote:
>
> On 5/22/23 21:13, Sui Jingfeng wrote:
> > Hi,
> >
> > On 2023/5/22 18:25, WANG Xuerui wrote:
> >> On 2023/5/22 18:17, Sui Jingfeng wrote:
> >>> Hi,
> >>>
> >>> On 2023/5/22 18:05, WANG Xuerui wrote:
> >>>> On 2023/5/22 17:49, Sui Jingfeng wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 2023/5/22 17:28, WANG Xuerui wrote:
> >>>>>> On 2023/5/22 17:25, Sui Jingfeng wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> On 2023/5/21 20:21, WANG Xuerui wrote:
> >>>>>>>>> + * LS3A4000/LS3A5000/LS3A6000 CPU, they are equipped with
> >>>>>>>>> on-board video RAM
> >>>>>>>>> + * typically. While LS2K0500/LS2K1000/LS2K2000 are low cost
> >>>>>>>>> SoCs which share
> >>>>>>>>> + * the system RAM as video RAM, they don't has a dediacated
> >>>>>>>>> VRAM.
> >>>>>>>>
> >>>>>>>> CPU models are not typically prefixed with "LS", so "Loongson
> >>>>>>>> 3A4000/3A5000/3A6000".
> >>>>>>>>
> >>>>>>> Here is because when you do programming, variable name should
> >>>>>>> prefix with letters.
> >>>>>>
> >>>>>> Commit messages, comments, and log messages etc. are natural
> >>>>>> language, so it's better to treat them differently. No problem to
> >>>>>> keep code as-is IMO.
> >>>>>>
> >>>>> Then you get two name for a single chip, take LS7A1000 as an
> >>>>> example.
> >>>>>
> >>>>> You name it as Loongson 7A1000 in commit message, and then you
> >>>>> have to define another name in the code, say LS7A1000.
> >>>>>
> >>>>> "Loongson 7A1000" is too long, not as compact as LS7A1000.
> >>>>>
> >>>>> This also avoid bind the company name to a specific product,
> >>>>> because a company can produce many product.
> >>>>
> >>>> Nah, the existing convention is "LS7Xxxxx" for bridges and
> >>>> "Loongson 3Axxxx" for CPUs (SoCs like 2K fall under this category
> >>>> too). It's better to stick with existing practice so it would be
> >>>> familiar to long-time Loongson/LoongArch developers, but I
> >>>> personally don't think it will hamper understanding if you feel
> >>>> like doing otherwise.
> >>>>
> >>> Can you explain why it is better?
> >>>
> >>> is it that the already existing is better ?
> >>
> >> It's not about subjective perception of "better" or "worse", but
> >> about tree-wide consistency, and about reducing any potential
> >> confusion from newcomers. I remember Huacai once pointing out that
> >> outsiders usually have a hard time remembering "1, 2, and 3 are CPUs,
> >> some 2 are SoCs, 7 are bridge chips", and consistently referring to
> >> the bridge chips throughout the tree as "LS7A" helped.
> >>
> >> In any case, for the sake of consistency, you can definitely refer to
> >> the CPU models in natural language like "LS3Axxxx"; just make sure to
> >> refactor for example every occurrence in arch/loongarch and other
> >> parts of drivers/. That's a lot of churn, though, so I don't expect
> >> such changes to get accepted, and that's why the tree-wide
> >> consistency should be favored over the local one.
> >>
> > There are document[1] which named LS7A1000 bridge chip as Loongson
> > 7A1000 Bridge,
> >
> > which is opposed to what you have said "the existing convention is
> > LS7Xxxxx for bridges".
> >
> >
> > there are also plenty projects[2] which encode ls2k1000 as project
> > name, which simply
> >
> > don't fall into the category as you have mentioned("Loongson 3Axxxx").
> >
> >
> > See [1][2] for reference, how to explain this phenomenon then?
>
> Turn down the flames a little bit, okay? ;-)
>
> What I'm describing is simply the kernel convention. Try grepping the
> commit log of linux: you can see almost all mentions of "Loongson 7A" is
> just referring to the manual which is named like that; that "LS3A" only
> ever appear as part of some board name; and that "LS2K" only briefly
> appearing when mentioned together with LS7A, maybe that's emphasis on
> the SoC's bridge part. "Loongson [123]" and "LS7A" are clearly the
> majority there.
>
> But, as the convention was established by Huacai and I'm only
> reiterating his rules, you may instead just check with him and not
> continue the boring debate with me. Meanwhile maybe keeping all "LS3A"
> and/or "LS2K" is kind of acceptable, given such naming is etched right
> on the chip's packaging; I'd follow whatever Huacai mandates.
Yes, I can confirm that.
For CPU: we always use the full name, "Loongson-3A".
For Bridge: we only use the full name when referring to the manuals,
otherwise use the abbrev. name "LS7A".
For SoC: depending on scenarios, in architectural code we usually use
the full name "Loongson-2K", and in drivers it is allowed to call
"LS2K" to keep consistency, especially in DTS.
Huacai
>
> --
> WANG "xen0n" Xuerui
>
> Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
>
Powered by blists - more mailing lists