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.
During a recent trip into windows-land, I noticed that Lenovo posted a
firmware update for the c630. I downloaded and installed that, leaving my
machine running 2.06. There don't appear to be any new menu options, and
no description of the changes were available.
I'm happy to run any diagnostic tooling for anyone that can't but is
interested, if that information would be helpful to the cause.
Hi All,
My notes from talking to Lee this week
--------------------------------------
+ DTB Loader v2.1 from Leif is available:
http://git.linaro.org/people/leif.lindholm/edk2.git/log/?h=dtbloader
+ Allows dual boot Linux and Windows.
+ EBBR compliant.
+ Kernel command line options:
+ efi=novamap is required for DT and ACPI
+ This can only be fixed in firmware.
+ console=tty0, pd_ignore_unused, clk_ignore_unused
+ not required on both DT and ACPI
+ A Ubuntu kernel build with latest laptop patches is available:
https://launchpad.net/~aarch64-laptops/+archive/ubuntu/linux-kernel/+build/…https://launchpad.net/~aarch64-laptops/+archive/ubuntu/linux-kernel-meta/+b…
best regards,
Richard
--
Richard.Henwood(a)arm.com
Server Software Eco-System
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.
From: Rob Clark <robdclark(a)chromium.org>
The aarch64 laptops which ship with windows, have the display by the
bootloader, and efifb (yah!). But unlike x86 laptops, device power
management isn't handled via ACPI[1]. Currently the CCF and genpd
frameworks will turn off power domains and clocks that they think are
unused. This is rather unfortunate, as it kills efifb scanout before
getting to userspace and getting to the point where we can try to
probe the real display driver.
Also it has a few side-effects in that we can't set rate on running
clocks (in many cases).
The first two patches let us flag clocks and power domains which
might have been enabled by the bootloader, so we know not to disable
them in late_initcall.
The next two update drm/msm to cleanly shut down clocks which might
already be running. *Eventually* we'll want to detect that scanout
is already running, and readback the hw state, to avoid briefly
disabling the screen while the driver loads. But that is a big pile
of (mostly) drm/msm work. (Windows also seems to have this problem,
it appears to do a modeset during boot.. so I guess the first step
is to at least not suck more than windows ;-))
The last patch updates the bridge driver to handle the case where
display is already active. (AFAICT it is the same bridge chip used
so far on all the aarch64 laptops.) Because the bridge driver can
be probed before the drm driver, and in fact you might end up with
a bridge driver but no drm driver, care must be taken to not disable
the bridge until the drm driver is ready to go, so:
* Request enable gpio ASIS to avoid pulling down the enable
gpio
* Defer enabling runpm in the case that the bridge is already
running until bridge->attach(). This is a point where we
know the drm driver is ready to do a modeset.
(There are a couple related cleanups in drm/msm to avoid touching
the hw until we are past the point where we might -EPROBE_DEFER[2]
which I sent seperately as they are probably interesting to fewer
people.)
This has been tested on a lenovo yoga c630. I've a wip/c630 branch[3]
with this and various other work-in-progress stuff for this laptop.
Next step, figuring out how to pick the proper panel driver, from
the two or three possibilites that ship on this laptop ;-)
[1] On windows, they use a "Platform Extension Plugin" (PEP) driver
[2] https://patchwork.freedesktop.org/series/62999/
[3] https://github.com/freedreno/kernel-msm/commits/wip/c630
Rob Clark (5):
clk: inherit clocks enabled by bootloader
genpd/gdsc: inherit display powerdomain from bootloader
drm/msm/dsi: split clk rate setting and enable
drm/msm/dsi: get the clocks into OFF state at init
drm/bridge: ti-sn65dsi86: support booloader enabled display
drivers/base/power/domain.c | 10 ++++
drivers/clk/clk.c | 48 +++++++++++++++++++
drivers/clk/qcom/common.c | 25 ++++++++++
drivers/clk/qcom/dispcc-sdm845.c | 24 +++++-----
drivers/clk/qcom/gcc-sdm845.c | 3 +-
drivers/clk/qcom/gdsc.c | 5 ++
drivers/clk/qcom/gdsc.h | 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 ++++-
drivers/gpu/drm/msm/dsi/dsi.h | 2 +
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 3 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c | 56 +++++++++++++++++-----
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 1 +
include/linux/clk-provider.h | 10 ++++
include/linux/pm_domain.h | 4 ++
15 files changed, 178 insertions(+), 27 deletions(-)
--
2.20.1
Hi All,
My notes from talking to Lee this week
--------------------------------------
+ latest laptop kernel is the Master branch here:
+ https://github.com/aarch64-laptops/linux
+ kernel 5.3 looking good wrt ACPI:
+ UFS and I2C has been accepted.
+ a patch to avoid booting with acpi=force also accepted.
+ Leif has a working DTB loader V2. Lee is going to try this out.
+ Jobs list has been updated there:
https://github.com/aarch64-laptops/build/blob/master/README.md
best regards,
Richard
--
Richard.Henwood(a)arm.com
Server Software Eco-System
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 All,
Mailing list created! Welcome all!
My notes from talking to Lee this week
--------------------------------------
- ACPI:
- UFS patches have been sent upstream.
- With a patch, battery and AC power detection work!
- General
- It seems ISO9660 images will boot, but only from USB 3.1 dev.
- Unable to reproduce the trackpad problems - it works fine now.
- Maybe this is because of a firmware update?
Distros:
- Ubuntu
- 18.04: missing grub 4k alignment patch.
- 19.04: boots to grub, kernel does not boot.
- Leif's
- openSUSE
- missing grub 4k alignment patch.
- Fedora Rawhide
- grub boots. Installer hangs with '_' (see below)
Open task items for this week's update
--------------------------------------
Please ping this list to share your interest in items so we can avoid
duplication of effort.
- Linux support for ACPI PNP0D80 (PEP)
- The PNP0D80 is a System Power Management Controller
- Very little support resides in Linux at the moment
- Thus no ACPI Power Management can currently take place
- Accelerated Graphics also depends on it
- UEFI Boot Variables investigation
- Grub fails to manipulate them during install
- Is it possible for Linux to change them at run-time?
- DMA crash investigation
- CRASH IMAGE: https://photos.app.goo.gl/2MGJEALZMyoowr9d6
- HACK PATCH: https://tinyurl.com/y5cnln2j
- Upstream Kernel ACPI check
- ACPI tables incorrectly advertise themselves as v5.0
- Kernel should check the presence of PSCI instead
- PATCH: https://tinyurl.com/yyq76m47
- NB: Assuming Ard will handle this - needs to be done soon
- Upstream ACPI Battery and AC Power support
- Simply a matter of not depending on CONFIG_X86
- PATCH: https://tinyurl.com/yx9kf7e8
- NB: Assuming Ard will handle this - needs to be done soon
- Debug Fedora Rawhide
- Kernel currently boots to a black screen with white '_'
- NB: Assuming Peter will handle this
- Create UEFI module for persistently loading DTB
- We have one which handles this for a single boot
- NB: Assuming Leif will handle this
- Test ISO9660 based installers booting from USB
- Must be done by someone who has not updated Windows
- Fedora Rawhide ISO is a good image to use for testing
- LINK: https://tinyurl.com/y2l6bvp9
- If it boots to the Fedora (Grub) menu, it works
- Current belief is that USB 3.1 sticks are required
- Need to test USB 2.0 and 3.0 sticks too
- Create and upstream a Live Arch Linux ISO/installer for AArch64
- AArch64 support is provided by copying a pre-built roofs to UFS
- This is clunky and needs a proper installer like other distos
- Get in touch with Richard Henwood directly if you can help.
best regards,
Richard
PS. Don't forget to visit #aarch64-laptops on freenode IRC.
--
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.