linux-kernel - Re: [PATCH 1/2] Mips: ls2k1000: dts: add the display controller device node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <32a56a81-e9b5-138b-4dff-35c2525cc0b6@loongson.cn>
Date:   Thu, 23 Feb 2023 11:19:25 +0800
From:   Sui jingfeng <suijingfeng@...ngson.cn>
To:     Krzysztof Kozlowski <krzk@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc:     linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/2] Mips: ls2k1000: dts: add the display controller
 device node

Hi,

On 2023/2/23 02:32, Krzysztof Kozlowski wrote:
> On 22/02/2023 17:55, suijingfeng wrote:
>> The display controller is a pci device, it's pci vendor id is
>> 0x0014, it's pci device id is 0x7a06.
>>
>> Signed-off-by: suijingfeng <suijingfeng@...ngson.cn>
>> ---
>>   .../boot/dts/loongson/loongson64-2k1000.dtsi  | 21 +++++++++++++++++++
>>   1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
>> index 8143a61111e3..a528af3977d9 100644
>> --- a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
>> +++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
>> @@ -31,6 +31,18 @@ memory@...000 {
>>   			<0x00000001 0x10000000 0x00000001 0xb0000000>; /* 6912 MB at 4352MB */
>>   	};
>>   
>> +	reserved-memory {
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +
>> +		display_reserved: framebuffer@...00000 {
>> +			compatible = "shared-dma-pool";
>> +			reg = <0x0 0x30000000 0x0 0x04000000>; /* 64M */
>> +			linux,cma-default;
>> +		};
>> +	};
>> +
>>   	cpu_clk: cpu_clk {
>>   		#clock-cells = <0>;
>>   		compatible = "fixed-clock";
>> @@ -198,6 +210,15 @@ sata@8,0 {
>>   				interrupt-parent = <&liointc0>;
>>   			};
>>   
>> +			display-controller@6,0 {
>> +				compatible = "loongson,ls2k1000-dc";
>> +
>> +				reg = <0x3000 0x0 0x0 0x0 0x0>;
>> +				interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
>> +				interrupt-parent = <&liointc0>;
>> +				memory-region = <&display_reserved>;
> NAK.
Err :(,  please give me a chance to explain
> Test your code against the bindings you send.

I can guarantee to you that I test may code more than twice. The code 
used to testing is listed at link [1].

This patchset  mainly used to illustrate how  we made the driver in [1] 
usable on our SoC platform.

> It's the same
> patchset. You basically send something which the same moment is incorrect.

Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and ls2k2000 etc), it even has been included in Loongson BMC(ls2k0500 bmc)
products.

When use this driver on Loongson embedded platform(say ls2k2000, 
ls2k1000 and ls2k0500)  ,

the PMON/Uboot firmware(my company using pmon most of time) will pass a 
DT to the kernel.

Different boards will pass different DTs. But when using this driver on 
Loongson server and

PC platform( ls3c5000/ls3a5000+ls7a1000/ls7a2000), there will no DT 
supplied. The firmware

and kernel side developer of Loongson choose ACPI+UEFI for such 
platform, more discussion

can be found at [2]. Therefore, on such a situation we decide to send 
the patch at separate patchset.

It is not like the arm  and risc-v, as the binding would not be always 
exits. If we put those patches

into a same patchset, some reviewers would suggest us to revise our code.

To a form that the code *ALWAYS*  probed from the DT, this is not desired.

Besides, the driver code + dt support is petty large, separate it is 
more easy to review and manage.

Finally,  Thanks your kindly guiding and valuable reviews.

[1] https://patchwork.freedesktop.org/patch/523409/?series=113566&rev=4

[2] https://lkml.org/lkml/2022/7/15/135

> Best regards,
> Krzysztof