Re: [PATCH v14 1/2] drm: add kms driver for loongson display controller

From: WANG Xuerui
Date: Mon May 22 2023 - 12:40:45 EST

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.

--
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/