On 13.12.2024 9:50 AM, Pengyu Luo wrote: > Oh, I sent it by gamil wrongly(forgot cc to), I resend it by git send-email again > > On Fri, Dec 13, 2024 at 1:13 AM Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote: >> On 11.12.2024 4:37 PM, Pengyu Luo wrote: >>> Add an initial devicetree for the Huawei Matebook E Go, which is based on >>> sc8280xp. >>> >>> There are 3 variants, Huawei released first 2 at the same time. >>> Huawei Matebook E Go LTE(sc8180x), codename should be gaokun2. >>> Huawei Matebook E Go(sc8280xp@3.0GHz), codename is gaokun3. >>> Huawei Matebook E Go 2023(sc8280xp@2.69GHz). >>> >>> We add support for the latter two variants. >>> >>> This work started by Tianyu Gao and Xuecong Chen, they made the >>> devicetree based on existing work(i.e. the Lenovo X13s and the >>> Qualcomm CRD), it can boot with framebuffer. >>> >>> Original work: >> https://github.com/matalama80td3l/matebook-e-go-boot-works/blob/main/dts/sc8280xp-huawei-matebook-e-go.dts >>> >>> Later, I got my device, I continue their work. >>> >>> Supported features: >>> - adsp >>> - bluetooth (connect issue) >>> - charge (with a lower power) >>> - framebuffer >>> - gpu >>> - keyboard (via internal USB) >>> - pcie devices (wifi and nvme, no modem) >>> - speakers and microphones >>> - tablet mode switch >>> - touchscreen >>> - usb >>> - volume key and power key >>> >>> Some key features not supported yet: >>> - battery and charger information report (EC driver required) >>> - built-in display (cannot enable backlight yet) >>> - charging thresholds control (EC driver required) >>> - camera >>> - LID switch detection (EC driver required) >>> - USB Type-C altmode (EC driver required) >>> - USB Type-C PD (EC driver required) >> >> Does qcom_battmgr / pmic_glink not work? >> > > Unfortunately, different from many sc8280xp devices, device(PMGK) _STA is > Zero, > this device is quiet strange, also, it has no PM8008, > nor PMIC Battery Miniclass(PMBM), etc. So it's not used on windows.. but have you tried checking if it's still provided by the firwmare? [...] >> >>> + chosen { >>> + #address-cells =3D <2>; >>> + #size-cells =3D <2>; >>> + ranges; >>> + >>> + framebuffer0: framebuffer@c6200000 { >>> + compatible =3D "simple-framebuffer"; >>> + reg =3D <0x0 0xC6200000 0x0 0x02400000>; >>> + width =3D <1600>; >>> + height =3D <2560>; >>> + stride =3D <(1600 * 4)>; >>> + format =3D "a8r8g8b8"; >>> + }; >>> + }; >> >> This should be redundant, as you should have efifb >> > > I think no, it won't boot up without it(stuck at EFI stub: Booting Linux > Kernel) Do you have CONFIG_EFI and CONFIG_FB_EFI enabled? (also, your email client does something funny and posts 0x3d, which is ASCII for '=' after that symbol) > > [...] > >> >>> + >>> + wcd938x: audio-codec { >>> + compatible =3D "qcom,wcd9380-codec"; >>> + >>> + pinctrl-names =3D "default"; >>> + pinctrl-0 =3D <&wcd_default>; >> >> Please follow this order throughout the file: >> >> property-n >> property-names >> > > Do you mean I should arragne as following? If so, I actually keep > reference devicetree untouched. x13s and crd are written like this. Yeah, we try to unify the style as we progress and we still haven't gotten around to cleaning up files that have been in the tree for years.. > > pinctrl-0 =3D <&wcd_default>>; > pinctrl-names =3D "default"; Yes please [...] >>> + gpio-keys { >>> + compatible =3D "gpio-keys"; >>> + >>> + pinctrl-names =3D "default"; >>> + pinctrl-0 =3D <&mode_pin_active>, <&vol_up_n>; >>> + >>> + switch-mode { >>> + gpios =3D <&tlmm 26 GPIO_ACTIVE_HIGH>; >> >> This could use a label too - "Tablet Mode Switch", perhaps? >> > > This part I follow Lenovo Yoga C630 one (see [1]), it doesn't use it, > and this node is not referenced. So "label" could mean label: node-name@unit-address { property = "value"; }; when talking about DT nodes, but here I'm speaking of the "label" property (which you set to "Volume Up" in the node below). That is read by Linux and provides a nice human-readable name to the userspace. >> >>> + >>> + /* /lib/firmware/ath11k/WCN6855/hw2.1/board-2.bin >>> + * there is no calibrate data for huawei, >>> + * but they have the same subsystem-device id >>> + */ >>> + qcom,ath11k-calibration-variant =3D "LE_X13S"; >> >> Oh, this can be taken care of! See [2], [3]. >> > > I have a glance, now I know we should extract something or it won't be > there. > Question is how can I extract them? I have a quick search, got no luck. > As for windows drivers, in the folder > > bdwlan.e02 > bdwlan.e07 > bdwlan.e1d > bdwlan.e1e > bdwlan.e23 > bdwlan.e26 > bdwlan.e32 > bdwlan.e47 > bdwlan.e81 > bdwlan.e84 > bdwlan.e85 > bdwlan.e8c > bdwlan.e8e > bdwlan.e9f > bdwlan.ea3 > bdwlan.eb8 > bdwlan.elf > bdwlan.elf.g > bdwlang.e8b > bdwlang.e9f > bdwlang.ea3 > bdwlang.eb8 > bdwlang.elf > Data20.msc > Data.msc > m320.bin > m3.bin > qcwlan8280.cat > qcwlan8280.inf > qcwlan8280.sys > regdb.bin > wlanfw20.mbn > wlanfw.mbn Adding Dmitry who has gone through this multiple times and may be able to help Konrad
