From: Rob Clark <robdclark(a)chromium.org>
Now that we can deal gracefully with bootloader (firmware) initialized
display on aarch64 laptops[1], the next step is to deal with the fact
that the same model of laptop can have one of multiple different panels.
(For the yoga c630 that I have, I know of at least two possible panels,
there might be a third.)
This is actually a scenario that comes up frequently in phones and
tablets as well, so it is useful to have an upstream solution for this.
The basic idea is to add a 'panel-id' property in dt chosen node, and
use that to pick the endpoint we look at when loading the panel driver,
e.g.
/ {
chosen {
panel-id = <0xc4>;
};
ivo_panel {
compatible = "ivo,m133nwf4-r0";
power-supply = <&vlcm_3v3>;
no-hpd;
ports {
port {
ivo_panel_in_edp: endpoint {
remote-endpoint = <&sn65dsi86_out_ivo>;
};
};
};
};
boe_panel {
compatible = "boe,nv133fhm-n61";
power-supply = <&vlcm_3v3>;
no-hpd;
ports {
port {
boe_panel_in_edp: endpoint {
remote-endpoint = <&sn65dsi86_out_boe>;
};
};
};
};
sn65dsi86: bridge@2c {
compatible = "ti,sn65dsi86";
...
ports {
#address-cells = <1>;
#size-cells = <0>;
...
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
endpoint@c4 {
reg = <0xc4>;
remote-endpoint = <&boe_panel_in_edp>;
};
endpoint@c5 {
reg = <0xc5>;
remote-endpoint = <&ivo_panel_in_edp>;
};
};
};
}
};
Note that the panel-id is potentially a sparse-int. The values I've
seen so far on aarch64 laptops are:
* 0xc2
* 0xc3
* 0xc4
* 0xc5
* 0x8011
* 0x8012
* 0x8055
* 0x8056
At least on snapdragon aarch64 laptops, they can be any u32 value.
However, on these laptops, the bootloader/firmware is not populating the
chosen node, but instead providing an "UEFIDisplayInfo" variable, which
contains the panel id. Unfortunately EFI variables are only available
before ExitBootServices, so the second patch checks for this variable
before EBS and populates the /chosen/panel-id variable.
[1] https://patchwork.freedesktop.org/series/63001/
Rob Clark (4):
dt-bindings: chosen: document panel-id binding
efi/libstub: detect panel-id
drm: add helper to lookup panel-id
drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
Documentation/devicetree/bindings/chosen.txt | 69 ++++++++++++++++++++
drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++
drivers/firmware/efi/libstub/efistub.h | 2 +
drivers/firmware/efi/libstub/fdt.c | 9 +++
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +-
drivers/gpu/drm/drm_of.c | 21 ++++++
include/drm/drm_of.h | 7 ++
7 files changed, 160 insertions(+), 2 deletions(-)
--
2.20.1
These are cherrypicks from the aarch64-laptops [1] effort. I have
pinged those maintainers pointing out that these patches have not been
submitted upstream. In the future it should be... Otherwise, I'll keep
rebasing this.
This is useful on the AArch64 laptops [2] booting in ACPI mode, as they
are Win10 laptops they use/publish WMI, hence it should stop being x86
only and be enabled on arm64 too.
[1] https://github.com/aarch64-laptops/linux/tree/laptops-ubuntu
[2] ASUS NovaGo TP370QL, HP Envy x2, Lenovo Mixx 630 & Yoga C630, and
Samsung Book2
Ard Biesheuvel (2):
UBUNTU: SAUCE: acpi: move WMI subsystem to generic code
UBUNTU: SAUCE: acpi/wmi: move BMOF driver to generic code
Dimitri John Ledkov (1):
UBUNTU: [Config] Update WMI_BMOF annotations.
.../abi/5.3.0-0.1/arm64/generic.modules | 2 ++
debian.master/config/annotations | 4 +--
drivers/acpi/Kconfig | 33 +++++++++++++++++++
drivers/acpi/Makefile | 2 ++
drivers/{platform/x86 => acpi}/wmi-bmof.c | 0
drivers/{platform/x86 => acpi}/wmi.c | 0
drivers/platform/x86/Kconfig | 33 -------------------
drivers/platform/x86/Makefile | 2 --
8 files changed, 39 insertions(+), 37 deletions(-)
rename drivers/{platform/x86 => acpi}/wmi-bmof.c (100%)
rename drivers/{platform/x86 => acpi}/wmi.c (100%)
--
2.20.1
Hello, this appears to be a development-only mailing list, so pardon me if I’m disturbing anyone. I’m running a Samsung Galaxy Book 2 (using SD850 + QUALCOMM x20 modem + AMOLED touch screen, detachable KB, and stylus) and am wondering if the work being done mostly on Lenovo SD850 laptops apparently and older devices will apply to this hardware, or should I not hold my breath? Don’t worry, this isn’t an ETA or a complaint, I appreciate everything you’re doing and wish I knew more about programming so I could help out.
Sent from Mail for Windows 10
So, we still have sensor-hub and acpi-button disabled using kernel config.
I could patch the quirks into the kernel to skip loading those based
on DMI data.
However, that's a bit counter-productive as that's compiled in code
and enumerates SKUs.
Can I instead use kernel command line to skip initializing those
built-in and compiled modules?
Ie. would something like:
module_blacklist=hid-sensor-hub initcall_blacklist=acpi_button_driver_init
work, even when the kernel is configured with CONFIG_HID_SENSOR_HUB=m
and CONFIG_ACPI_BUTTON=y ?
Also not sure if I got the initcall function name right.
I am asking because, it may be easier for me to control cmdline
reliably, instead of distro kernel config.
--
Regards,
Dimitri.
From: Rob Clark <robdclark(a)chromium.org>
One of the challenges we need to handle to enable the aarch64 laptops
upstream is dealing with the fact that the bootloader enables the
display and takes the corresponding SMMU context-bank out of BYPASS.
Unfortunately, currently, the IOMMU framework attaches a DMA (or
potentially an IDENTITY) domain before the driver is probed and has
a chance to intervene and shutdown[1] scanout. Which makes things go
horribly wrong.
This also happens to solve a problem that is blocking us from supporting
per-context pagetables on the GPU, due to domain that is attached before
driver has a chance to attach it's own domain for the GPU.
But since the driver is managing it's own iommu domains directly, and
does not use dev->iommu_group->default_domain at all, the simple
solution to both problems is to just avoid attaching that domain in the
first place.
[1] Eventually we want to be able to do a seemless transition from
efifb to drm/msm... but first step is to get the core (iommu,
clk, genpd) pieces in place, so a first step of disabling the
display before first modeset enables us to get all of the
dependencies outside of drm/msm in place. And this at least
gets us parity with windows (which also appears to do a modeset
between bootloader and HLSO). After that there is a bunch of
drm/msm work that is probably not interesting to folks outside
of dri-devel.
Rob Clark (2):
iommu: add support for drivers that manage iommu explicitly
drm/msm: mark devices where iommu is managed by driver
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
drivers/iommu/iommu.c | 11 +++++++++++
include/linux/device.h | 3 ++-
6 files changed, 17 insertions(+), 1 deletion(-)
--
2.20.1
Hi All,
I was on leave last week. I just chatted with Lee and have this summary
of the last two weeks.
+ Tested on-disk install.
+ Update Windows to get latest firmware.
+ Disable 'S' mode and resize Windows partitions.
+ Boot up the Custom Ubuntu installer, and install.
+ With the latest windows firmware, most USB sticks work?
+ SanDisk looks problematic.
+ Reproduced and tested GPU stack.
+ Not working yet.
+ Believed to be a problem with an old Mesa version.
+ Rawhide doesn't boot to grub any more :(
Blocking and Todo issues:
+ Hack to disable DMA in Qualcomm's Gini driver is still required
+ Kernel command-line: 'efi=novamap' required until f/w is fixed
+ CONFIG_HID_SENSOR_HUB still breaks the keyboard
+ CONFIG_ACPI_BUTTON places us into suspend with no real way out
+ Trying to get DTB into 5.3 kernel.
best regards,
Richard
--
Richard.Henwood(a)arm.com
Server Software Eco-System
Tel: +1 512 410 9612
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I was able to follow the instructions in the following article and get Ubuntu booted successfully.
https://github.com/aarch64-laptops/build#Flashing-the-image
I understood that wireless network is not supported yet.
If i plugin a USB Wii-Lan Adapter, the adapter is not recognized as well.
Is there any other adapters that's known to work with ASUS Novago Laptop ?
Thanks,
Saravanan
On Fri, 5 Jul 2019 at 13:48, David Michael <fedora.dm0(a)gmail.com> wrote:
>
> The following are two use cases from Rajat Jain <rajatjain(a)juniper.net>:
>
> 1) We have a board that boots Linux and this board itself can be plugged into one of different chassis types. We need to pass different parameters to the kernel based on the "CHASSIS_TYPE" information that is passed by the bios in the DMI / SMBIOS tables.
>
> 2) We may have a USB stick that can go into multiple boards, and the exact kernel to be loaded depends on the machine information (PRODUCT_NAME etc) passed via the DMI.
>
> Signed-off-by: David Michael <fedora.dm0(a)gmail.com>
>
Another use case is aarch64 laptops effort. We have the same kernel,
and the same image bootable and usable across 4 different laptop
models, with the only difference between them being the DTB to load.
I was looking at how I can distinguish between the four models and
automatically pick the right dtb. I did see these patches and was very
sad when I found out that they didn't get merged.
Thank you for rebasing these on top of v2.04. I will try to cherrypick
them on top of Debian's experimental 2.04 grub and try to build an
installer "that just boots" without requiring users to pick a
particular dtb menuentry by hand. There are only dtbs in these images,
and only one right one for each model.
(Post install, we have flash-kernel mechanisms to continuously flash
and use the right dtb, this is needed for the installer's grub to be
able to detect models and thus boot the right dtb)
Whilst these laptops might become dtb-free in the future, I expect new
hardware to come out which would need dtb picker based on SMBIOS info
again.
--
Regards,
Dimitri.