search

jfwells / linux-asus-t100ta

Getting Linux (Esp. Ubuntu) up and running well on the Asus Transformer T100
GNU General Public License v2.0
235 stars 103 forks source link

I finally found why this Camera driver won't work on an unmodded ASUS laptop-BIOS #4

Open rmast opened 6 years ago

rmast commented 6 years ago

The manual prescribes this step:

Enable ISP for Linux in BIOS When booting Bayley Bay target machine, the BIOS must be set with the right ISP PCI device. In the BIOS settings under "Uncore Configuration" set:

"ISP Enable/Disable" to Enable "ISP PCI Device" to B0D3F0

This option is not available in a baytrail BIOS. jfwells Bayley Bay board was some early prototype-board for the later shipped Baytrail-machines. The only way to get the Linux camera running the way described here is thus by modding the BIOS, so that requirement puts an enormous roadblock for getting support from anyone on this idea until the required BIOS mod is available and becomes such a quality that people dare to risk such a BIOS upgrade.

rmast commented 2 months ago

Kernel-Deb's built from a bigger PC are installable in MX Linux. Building modules in-tree from a non-git kernel source and then installing them is a bumpy road.

I'm now attempting an in-tree build starting from a deb-build on the bigger PC, with a T100ta-make localmodconfig-set of modules, together with the ATOMISP-parameters EasyNetDev mentioned. Some 8812au dkms WiFi driver popped up at installing the kernel, probably something MX Linux prefers on the T100ta, I had to install the newest from Git.

And all that just to try to add one line of code to atomisp-mt9m114.c

mirh commented 2 months ago

Maybe don't use distros with horrible build systems next time...

rmast commented 2 months ago

Just like Mauro did for the ov2680 to get it show any sign of life for the first time I added 

    power_up(sd);

to atomisp-mt9m114.c just before the first _write_reg_array( within _set_fmt (https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/tree/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c?h=media-atomisp#n672)

and now there are new errors, no PMIC registered: image

So Mauro's code for the ov2680 must somewhere register a PMIC, whatever that may be.

rmast commented 2 months ago

Last days I've put the commits for the ov2680 and mt9m114 in chronological order in an Excel-sheet. atomisp-ov2680.xlsx Column G "atomisp" has the following encoding: XI= atomisp-specific, including "atomisp-" X=atomisp-specific, but before they got the "atomisp-" specifier in the name N=Not atomisp-specific.

rmast commented 2 months ago

Mauro made the ov2680 see the light around May 20 2020, however I'm afraid on Cherry Trail.

rmast commented 2 months ago

https://patches.linaro.org/project/linux-acpi/patch/20221213123454.11404-1-hdegoede@redhat.com/ that PMIC-message is close to a solution on Bay Trail...

rmast commented 2 months ago

As the power of the camera still didn't go on: There is a proven possibility to turn it off, the way to put it back on should be close:

https://github.com/intel/idxd-driver/blob/master/drivers/platform/x86/intel_atomisp2_pm.c

The PMIC-stuff might have been placed in between because of the wish to compensate gain with libcamera, but it's probably not essential for getting a first picture from the CCD.

rmast commented 2 months ago

Or this newer one:

https://www.graphics-muse.org/archives/pibox/current/archives/rpi2/kernel/git/drivers/platform/x86/intel_atomisp2_led.c

rmast commented 2 months ago

Laurent explaining developing toward libcamera: https://www.youtube.com/watch?v=x9ndjdvXPl0

But we're not having libcamera support yet

rmast commented 2 months ago

That Baytrail file is still a kernel configurable file, so I guess all of these should be off, except CONFIG_BYTCRC_PMIC_OPREGION: image

rmast commented 2 months ago

In my kernel I2C_DESIGNWARE_PLATFORM was built as module, however to get this option for baytrail visible in make menuconfig it needs I2C_DESIGNWARE_PLATFORM=y to be able to configure INTEL_SOC_PMIC

config INTEL_SOC_PMIC bool "Support for Crystal Cove PMIC" depends on HAS_IOMEM && I2C=y && GPIOLIB && COMMON_CLK depends on (X86 && ACPI) || COMPILE_TEST depends on I2C_DESIGNWARE_PLATFORM=y || COMPILE_TEST select MFD_CORE select REGMAP_I2C select REGMAP_IRQ help Select this option to enable support for Crystal Cove PMIC on some Intel SoC systems. The PMIC provides ADC, GPIO, thermal, charger and related power management functions on these systems.

      This option is a bool as it provides an ACPI OpRegion which must be
      available before any devices using it are probed. This option also
      causes the designware-i2c driver to be builtin for the same reason.
rmast commented 2 months ago

The debian build system for a deb creates subversions for new modifications that makes a module incompatible. I don't know easier systems for updateable usb-installs. The debian live usb has another tool to compose them, cubic, but that also ran into incompatibilities. I hope in tree of out of tree module build on a host will provide a solution, but dkms should be a lot easier.

I now ran my custom linux kernel 6.11.0-rc2+ ge2dc5f33a288 built from hansg's media-atomisp branch installed with cubic on a debian-live-testing-amd64-xfce.iso. In the test environment it runs the custom kernel. (Edit: only after hacking a bootia32.efi into the resulting image it booted on the T100ta, and only with a @@@@@@-bootmenu. The top unreadable @@@@@@-menuitem didn't persist my actions. I'm now trying the 12.7 bookworm live and add some persistence with rufus.)

I did not manage to reduce the modules, make localmodconfig seems to trash essential modules. But when I continue with in tree builds as long as I don't change the kernel config I believe this can be a stable testing path. The MX Linux somehow keeps already tried kernels on the linuxfs, and I guess needs remastering and rolling back that linuxfs each iteration. MX cleanup refuses to clean the already tried kernel to be able to replace it.

There are two reasons I want to do this on an external USB-stick:

rmast commented 1 month ago

I decided to set up a full sata SSD bootable with debian testing via usb to optimize iteration speed. Such a SSD should be bootable as if it was an USB-flashdrive, and still provide full regular kernel upgradeability.

rmast commented 1 month ago

Unfortunately, studying getting that SSD to boot took too long for today. I used cubic without rufus to provide bookworm with hansg's media-atomisp branch kernel. With rufus to create persistence some zstd corruption of initrd interfered. The bookworm-bootmenu is not readable, but the first item went through.

I manually added a writable partition to add swap and have some persistance. I maintained the extra power_up line in atomisp-mt9m114.c this build, I will remove that in the next iteration, as the messages now seem to stem from other causes.

The dmesg now contains lots of hardware module messages coming from the newly added kernel modules for Bay Trail. I saw a crystalcove message. I chose the crystalcove kernel config for my T100ta, but there is also a kernel config for dollar cove on the T100taf, My device has only T100ta on the sticker, but I'm not absolutely sure. These are the different crystal and dollar cove devices: https://github.com/jwrdegoede/sunxi-fedora-scripts/blob/master/x86-tablet-info

These are the dmesg and the kernel config with which it is reached: dmesg.txt config.txt

rmast commented 1 month ago

This line of dmesg seems to have handled/mentioned the camera power, as the led driver does:

byt_gpio INT33FC:02: [Firmware Bug]: Pin 8: DIRECT_IRQ_EN set without trigger (CONF0: 0x2803cc00), clearing

Could that be a response to my illegal attempt to power it up outside v4l?

It's coming from https://github.com/torvalds/linux/blob/master/drivers/pinctrl/intel/pinctrl-baytrail.c

rmast commented 1 month ago

The issue with no bootia32.efi at the right place has two causes:

https://groups.google.com/g/linux.debian.bugs.dist/c/y3OCRUltjvY

https://wiki.debian.org/UEFI#Booting_from_removable_media

I applied the next steps on a Debian 12.7 install with calamares installer from the live iso in VirtualBox with EFI-support.

To get a bootia32.efi afterward: either (grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin mokutil shim-helpers-amd64-signed shim-signed shim-signed-common shim-unsigned had previously been installed)

sudo apt-get install grub-efi-ia32-bin sudo apt-get install grub-pc

(efi partition is mounted to /boot/efi) sudo grub-mkconfig -o /boot/efi/EFI/BOOT/grub.cfg

This second trial didn't boot wel yet in VirtualBox, and also took too long to boot on the T100ta: sudo apt install grub-efi-ia32 sudo grub-install --target=i386-efi --efi-directory=/boot/efi --removable sudo update-grub

I'm afraid this last step won't survive a reordering of grub menu due to a new kernel install without reapplying this step to the external medium.

I think these install steps for preparing a test environment could be automated with vagrant.

rmast commented 1 month ago

I ran into this error, which gives a quite clear status of the development about 4 months ago: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11081

Hans' workaround is "to build the BayTrail Crystal Cove PMIC GPIO + PWM into the kernel while having i915 be a module." "Bay Trail / Cherry Trail tablets use either the LPSS-PWM or the Crystal Cove (crc) PMIC PWM and as I tried to explain it already is not necessary to build in the LPSS-PWM driver.Actually even without @jani's -EPROBE_DEFER patches the PWM-s do not need to be built in. Bay Trail / Cherry Trail tablets use either the LPSS-PWM or the Crystal Cove (crc) PMIC PWM and as I tried to explain it already is not necessary to build in the LPSS-PWM driver."

rmast commented 1 month ago

I think I now have cleared the dmesg-log from all too obvious errors. But v4l2-ctl -l is still not opening /dev/video0. dmesg3.txt config.txt

rmast commented 1 month ago

The main issue now probably is the message ACPI: \: failed to evaluate _DSM 4f6c2fdc-5b04-1d4f-97b9-882a6860a4be (0x1001)

It might be a mixup of little endian-big endian. This patch https://lkml.indiana.edu/hypermail/linux/kernel/2006.0/05074.html

mentions

  1. Support for newer board-specific data (like Asus T101HA support) uses a DMI match table to retrieve sensor's data, using hard-coded values. It sounds feasible to retrieve those data directly from ACPI via _DSM tables (like this one, associated with CAM1 at the above mentioned hardware): Name (C1CD, Buffer (0x0220){}) Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If ((Arg0 == ToUUID ("dc2f6c4f-045b-4f1d-97b9-882a6860a4be")))
rmast commented 1 month ago

This is the dsdt.dsl of my Asus T100ta:

dsdt.dsl.txt

rmast commented 1 month ago

This is the corresponding acpidump of the one the Kernel refers to: https://gist.github.com/jdkbx/dabe0d000330dd2a04acf8d870e0e06f

rmast commented 1 month ago

The corresponding response for the mentioned UUID is then { Local0 = Package (0x12) { "CamId", "OV2680", "CamType", "1", "CsiPort", "0", "CsiLanes", "1", "CsiFmt", "15", "CsiBayer", "0", "CamClk", "1", "Regulator1p8v", "0", "Regulator2p8v", "0" } Return (Local0) }

The DSDT-CAM0 entry of the T100ta doesn't seem to have all those details. So they should probably not be fetched from ACPI DSDT, but hardcoded instead, like here: https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/tree/drivers/staging/media/atomisp/i2c/mt9m114.h?h=media-atomisp

rmast commented 1 month ago

Then this part of drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c should be active and tested: image https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/tree/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c?h=media-atomisp

rmast commented 1 month ago

This file, at line 1037 seems to give the error "[ 14.693625] atomisp-isp2 0000:00:03.0: no camera attached or fail to detect"

from atomisp_register_device_nodes: https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/tree/drivers/staging/media/atomisp/pci/atomisp_v4l2.c?h=media-atomisp

from atomisp_notifier_complete https://github.com/archlinux/linux/blob/master/drivers/staging/media/atomisp/pci/atomisp_csi2_bridge.c#L676

rmast commented 1 month ago

https://stackoverflow.com/questions/24330671/v4l2-kernel-space-debugging

CONFIG_VIDEO_ADV_DEBUG should also be set

rmast commented 1 month ago

As there was some reason with this debian 12.7 setup for not responding to writing 1 to /sys/class/leds/atomisp2::camera/brightness

Something interferentie by already turning off the camera before the bootmenu.

I'm reverting to Fedora Core 33, which supports kernel 5.8, the kernel around the time Mauro succeeded to turn on the Cherry Trail camera with the mentioned trick.

At boot the light stays on and the atomisp2 module isn't compiled in, so I'll also build an adapted kernel.

Adapting the kernel to 5.14.18 and starting from a make localmodconfig did result in a bootable kernel, though this issue was created: https://www.uwsg.indiana.edu/hypermail/linux/kernel/2111.1/01491.html

This is the resulting minimal config, that will be a fine entrypoint for successive builds: https://github.com/user-attachments/files/17350595/config.txt

Recently Hans has made some changes to the powering.

https://patchwork.kernel.org/project/linux-media/patch/20230123125205.622152-5-hdegoede@redhat.com/

With that in mind I'm now trying a recent Fedora to see whether it behaves similarly at boot.

rmast commented 1 month ago

Fedora 40, installed from a live ISO to the USB-SATA-SSD via VirtualBox with 128MB Videoram and EFI on, supports switching the camera on/off with writing 1 or 0 to /sys/class/leds/atomisp:camera/brightness right out of the box! Unfortunately the rest of the modules has to be compiled. I'll first try hansg's media-atomisp branch with my stripped T100ta-config as oldconfig, as that already showed some signs of /dev/video-endpoints, even in dmesg.

Verzonden vanaf Outlook voor Androidhttps://aka.ms/AAb9ysg

From: Robert Mast @.> Sent: Tuesday, October 8, 2024 7:22:49 AM To: jfwells/linux-asus-t100ta @.>; jfwells/linux-asus-t100ta @.> Cc: Mention @.> Subject: Re: [jfwells/linux-asus-t100ta] I finally found why this Camera driver won't work on an unmodded ASUS laptop-BIOS (#4)

As there was some reason with this debian 12.7 setup for not responding to writing 1 to /sys/class/leds/atomisp2::camera/brightness

Something interferentie by already turning off the camera before the bootmenu.

I'm reverting to Fedora Core 33, which supports kernel 5.8, the kernel around the time Mauro succeeded to turn on the Cherry Trail camera with the mentioned trick.

At boot the light stays on and the atomisp2 module isn't compiled in, so I'll also build an adapted kernel.

Verzonden vanaf Outlook voor Androidhttps://aka.ms/AAb9ysg

From: Robert Mast @.> Sent: Friday, October 4, 2024 5:39:13 PM To: jfwells/linux-asus-t100ta @.>; jfwells/linux-asus-t100ta @.> Cc: Mention @.> Subject: Re: [jfwells/linux-asus-t100ta] I finally found why this Camera driver won't work on an unmodded ASUS laptop-BIOS (#4)

The main issue now probably is the message ACPI: \: failed to evaluate _DSM 4f6c2fdc-5b04-1d4f-97b9-882a6860a4be (0x1001)

Verzonden vanaf Outlook voor Androidhttps://aka.ms/AAb9ysg

From: Robert Mast @.> Sent: Thursday, October 3, 2024 7:03:15 AM To: jfwells/linux-asus-t100ta @.>; jfwells/linux-asus-t100ta @.> Cc: Mention @.> Subject: Re: [jfwells/linux-asus-t100ta] I finally found why this Camera driver won't work on an unmodded ASUS laptop-BIOS (#4)

The issue with no bootia32.efi at the right place has two causes:

https://groups.google.com/g/linux.debian.bugs.dist/c/y3OCRUltjvY

https://wiki.debian.org/UEFI#Booting_from_removable_media

Verzonden vanaf Outlook voor Androidhttps://aka.ms/AAb9ysg

From: Robert Mast @.> Sent: Sunday, September 29, 2024 2:38:45 PM To: jfwells/linux-asus-t100ta @.>; jfwells/linux-asus-t100ta @.> Cc: Mention @.> Subject: Re: [jfwells/linux-asus-t100ta] I finally found why this Camera driver won't work on an unmodded ASUS laptop-BIOS (#4)

This source doesn't address GPIO_LOOKUP_IDX("INT33FC:02

Of the baytrail T100ta in the led.c source:

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/i915/display/intel_dsi_vbt.c

But it does address the cherry trail T100chi.

Verzonden vanaf Outlook voor Androidhttps://aka.ms/AAb9ysg

From: Robert Mast @.> Sent: Sunday, September 29, 2024 1:42:43 PM To: jfwells/linux-asus-t100ta @.>; jfwells/linux-asus-t100ta @.> Cc: Mention @.> Subject: Re: [jfwells/linux-asus-t100ta] I finally found why this Camera driver won't work on an unmodded ASUS laptop-BIOS (#4)

Or this newer one:

https://www.graphics-muse.org/archives/pibox/current/archives/rpi2/kernel/git/drivers/platform/x86/intel_atomisp2_led.c

Verzonden vanaf Outlook voor Androidhttps://aka.ms/AAb9ysg

From: Robert Mast @.> Sent: Sunday, September 29, 2024 9:52:37 AM To: jfwells/linux-asus-t100ta @.>; jfwells/linux-asus-t100ta @.> Cc: Mention @.> Subject: Re: [jfwells/linux-asus-t100ta] I finally found why this Camera driver won't work on an unmodded ASUS laptop-BIOS (#4)

As the power of the camera still didn't go on: There is a proven possibility to turn it off, the way to put it back on should be close:

https://github.com/intel/idxd-driver/blob/master/drivers/platform/x86/intel_atomisp2_pm.c

The mipi-stuff might have been placed in between because of the wish to compensate gain with libcamera, but it's probably not essential for getting a first picture from the CCD.

EasyNetDev commented 1 month ago

Hi all,

I've finish the DKMS drivers for Atom ISP. For now has 6.10.14 driver for all 6.10 Kernels, 6.11.3 for all 6.11 Kernels and 6.12-r2 for all 6.12 Kernels.

The DKMS is auto-detecting which kernel you have and in case you have a Kernel below 6.10 or above 6.12 will skip compilation. This feature I've added to not create issues when upgrades are done via apt upgrade for the DKMS to exit with an error.

Here are the sources and also the .deb files https://github.com/EasyNetDev/atomisp-6.10-dkms

This type of DKMS is very nice because as soon as you add a new driver under atomisp/X.YY dpkg-buildpackage -b will automatically change BUILD_EXCLUSIVE_KERNEL_MIN and BUILD_EXCLUSIVE_KERNEL_MAX. The structure for the directories is the same, can be copied and only the last directories can be overwritten.

EasyNetDev commented 1 month ago

As soon a new Kernel is coming out, I will add a new diver to the sources. I used the same trick for my NTFS3 DKMS driver https://github.com/EasyNetDev/ntfs3-dkms (in case anybody is interested in original Linux NTFS3 driver) which also is not compiled by default in Debian.

rmast commented 1 month ago

Great! I looked at the default Kernel-config of Fedora 40. Most of the GPIO, PWM, PMIC etc. for BayTrail are available, so I'll try your dkms modules. I don't expect IPU3 and IPU6 to be of any influence, those are for newer SOC's..

However, the default kernel of fc40 is too old (6.8) to cooperate with your dkms

Fc41 is in beta, but there also are precompiled testing kernels for fc40: https://bodhi.fedoraproject.org/updates/?packages=kernel

The default kernel for FC41 beta iso is 6.11.0.0 rc5 at the moment, and the default kernel config is quite similar to that of fc40.

I have to update to kernel-6.11.3-300.fc41 for the dkms-dependency: sudo dnf install kernel-devel dwarves https://bodhi.fedoraproject.org/updates/FEDORA-2024-b8b5224019

Unfortunately, the kernel source installed here doesn't contain the mt9m114. Fortunately the kernel from the media-atomisp branch of hansg, built with make rpm-pkg is also able to switch the led in Fedora 41.

EasyNetDev commented 1 month ago

My T100TAM is using ipu_bridge. But I've added all 3 PCI modules for anyone who needs for newer hardware. Also all modules under staging are build by the DKMS. In my case I have these modules compiled by DKMS:

root@t100tam:/home/easynet# ls -1 /lib/modules/6.10.11-amd64/updates/dkms/
atomisp-gc0310.ko.xz
atomisp-gc2235.ko.xz
atomisp-libmsrlisthelper.ko.xz
atomisp-mt9m114.ko.xz
atomisp-ov2722.ko.xz
atomisp.ko.xz
atomisp_gmin_platform.ko.xz
intel-ipu6-isys.ko.xz
intel-ipu6.ko.xz
ipu-bridge.ko.xz
ipu3-cio2.ko.xz
ntfs3.ko.xz

And loaded:

root@t100tam:/home/easynet# lsmod | grep "atomisp\|intel.ipu\|ipu.bridge"
intel_atomisp2_pm      12288  0
atomisp_mt9m114        36864  0
atomisp               995328  0
atomisp_gmin_platform    36864  2 atomisp,atomisp_mt9m114
v4l2_fwnode            32768  1 atomisp
videobuf2_vmalloc      20480  1 atomisp
videobuf2_v4l2         36864  1 atomisp
videobuf2_common       81920  4 atomisp,videobuf2_vmalloc,videobuf2_v4l2,videobuf2_memops
v4l2_async             32768  2 atomisp,v4l2_fwnode
videodev              364544  5 atomisp,v4l2_async,v4l2_fwnode,videobuf2_v4l2,atomisp_mt9m114
mc                     94208  6 atomisp,v4l2_async,videodev,videobuf2_v4l2,videobuf2_common,atomisp_mt9m114
ipu_bridge             16384  1 atomisp

But in the logs I'm getting the error with "no camera":

root@t100tam:/home/easynet# dmesg | grep "atomisp\|intel.ipu\|ipu.bridge\|mt9"
[   12.698113] ipu_bridge: loading out-of-tree module taints kernel.
[   12.698126] ipu_bridge: module verification failed: signature and/or required key missing - tainting kernel
[   13.095300] atomisp-isp2 0000:00:03.0: Didn't find ACPI _DSM table.
[   13.095485] atomisp-isp2 0000:00:03.0: Failed to find EFI variable gmin_HpllFreq
[   13.095491] atomisp-isp2 0000:00:03.0: HpllFreq: using default (2000)
[   13.095495] atomisp-isp2 0000:00:03.0: ISP HPLL frequency base = 2000 MHz
[   13.511567] atomisp-isp2 0000:00:03.0: no camera attached or fail to detect
[   13.617007] mt9m114 i2c-INT33F0:00: gmin: power management provided via Crystal Cove PMIC (i2c addr 0x6e)
[   13.617021] mt9m114 i2c-INT33F0:00: gmin_subdev_add: ACPI path is \_SB.I2C4.CAM0
[   13.617362] mt9m114 i2c-INT33F0:00: Failed to find EFI variable INT33F0:00_ClkSrc
[   13.617369] mt9m114 i2c-INT33F0:00: ClkSrc: using default (1)
[   13.617393] mt9m114 i2c-INT33F0:00: Found DMI entry for 'INT33F0:00_CsiPort'
[   13.617399] mt9m114 i2c-INT33F0:00: Found DMI entry for 'INT33F0:00_CsiLanes'
[   13.617486] mt9m114 i2c-INT33F0:00: will handle gpio0 via ACPI
[   13.617536] mt9m114 i2c-INT33F0:00: will handle gpio1 via ACPI
[   13.617706] mt9m114 i2c-INT33F0:00: Failed to find EFI gmin variable gmin_V1P8GPIO
[   13.617712] mt9m114 i2c-INT33F0:00: V1P8GPIO: using default (-1)
[   13.617877] mt9m114 i2c-INT33F0:00: Failed to find EFI gmin variable gmin_V2P8GPIO
[   13.617881] mt9m114 i2c-INT33F0:00: V2P8GPIO: using default (-1)
[   13.617894] mt9m114 i2c-INT33F0:00: Will use CLK1 (pmc_plt_clk_1)
[   13.749049] mt9m114 i2c-INT33F0:00: camera pdata: port: 0 lanes: 1 order: 00000000
[   15.688532] atomisp-isp2 0000:00:03.0: no camera attached
[  107.955690] atomisp-isp2 0000:00:03.0: no camera attached
[  113.469280] atomisp-isp2 0000:00:03.0: no camera attached
[  297.120290] atomisp-isp2 0000:00:03.0: no camera attached
[  302.228179] atomisp-isp2 0000:00:03.0: no camera attached
[ 1187.657824] atomisp-isp2 0000:00:03.0: no camera attached
[ 1206.499330] atomisp-isp2 0000:00:03.0: no camera attached
[ 1209.295526] atomisp-isp2 0000:00:03.0: no camera attached
[ 1224.741937] atomisp-isp2 0000:00:03.0: no camera attached
[ 3740.490941] atomisp-isp2 0000:00:03.0: no camera attached

I can see /dev/video0 but I can't open it.

EasyNetDev commented 1 month ago

I have a question regarding the 2 firmware files. We are allowed to distribute them public? I have them extracted from that device and I was thinking to create a package with them, but I have no clue if we are allowed to distribute them.

rmast commented 1 month ago

That _PM driver in my remembrance excludes the functional atomisp, so that should be blacklisted I believe. For this thread about getting light in the T100ta camera I'm afraid not much people will try something else than the mt9m114, except probably the little t200ta's left, those had two different camera's. I'm not aware of that allowance, so you could pick the one I linked that someone else had put on Github. But if Intel people are involved in getting this driver to function they could probably also shed some light on the availability of those firmwares.

rmast commented 1 month ago

By the way, you should probably try with the camera-led on. I don't see the intel_atomisp2_led in your lsmod.

rmast commented 1 month ago

There is a risk with that dmesg-filtering, you could miss relevant messages outside your filter.

EasyNetDev commented 1 month ago

By the way, you should probably try with the camera-led on. I don't see the intel_atomisp2_led in your lsmod.

I don't have any modules named intel_atomisp2_led / intel-atomisp2-led in my system. There is no compilation module in Debian by default:

# CONFIG_INTEL_ATOMISP2_LED is not set

Damn! Let me try to se if I can build out-of-tree.

EasyNetDev commented 1 month ago

These are default Debian Kernel symbols for _PMIC and and ATOMISP, with a quick filter:

grep "ATOMISP\|PMIC" /boot/config-6.10.11-amd64 
CONFIG_PMIC_OPREGION=y
CONFIG_BYTCRC_PMIC_OPREGION=y
CONFIG_CHTCRC_PMIC_OPREGION=y
CONFIG_XPOWER_PMIC_OPREGION=y
CONFIG_BXT_WC_PMIC_OPREGION=y
CONFIG_CHT_WC_PMIC_OPREGION=y
CONFIG_CHT_DC_TI_PMIC_OPREGION=y
# CONFIG_TPS68470_PMIC_OPREGION is not set
# CONFIG_INTEL_BXT_PMIC_THERMAL is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_PMIC_DA903X is not set
CONFIG_INTEL_SOC_PMIC=y
CONFIG_INTEL_SOC_PMIC_BXTWC=m
CONFIG_INTEL_SOC_PMIC_CHTWC=y
CONFIG_INTEL_SOC_PMIC_CHTDC_TI=m
# CONFIG_INTEL_ATOMISP is not set
CONFIG_INTEL_ATOMISP2_PDX86=y
# CONFIG_INTEL_ATOMISP2_LED is not set
CONFIG_INTEL_ATOMISP2_PM=m
# CONFIG_INTEL_BXTWC_PMIC_TMU is not set
EasyNetDev commented 1 month ago

Ok. Let's see which drivers we need to add in the DKMS. I filtered config-6.10.11-amd64 with all config symbols found in /opt/devel/kernel/atomisp-6.10-dkms/atomisp/6.10/drivers/platform/x86/intel/Kconfig:

$ for i in `grep "^config " Kconfig | cut -f2 -d" "`; do echo "Search for symbol $i"; grep "$i" /boot/config-6.10.11-amd64; done
$ for i in `grep "^config " Kconfig | cut -f2 -d" "`; do echo "Search for symbol $i"; grep "^CONFIG_${i}" /boot/config-6.10.11-amd64; done
Search for symbol INTEL_HID_EVENT
CONFIG_INTEL_HID_EVENT=m
Search for symbol INTEL_VBTN
CONFIG_INTEL_VBTN=m
Search for symbol INTEL_INT0002_VGPIO
CONFIG_INTEL_INT0002_VGPIO=m
Search for symbol INTEL_OAKTRAIL
CONFIG_INTEL_OAKTRAIL=m
Search for symbol INTEL_BXTWC_PMIC_TMU
Search for symbol INTEL_BYTCRC_PWRSRC
Search for symbol INTEL_CHTDC_TI_PWRBTN
Search for symbol INTEL_CHTWC_INT33FE
CONFIG_INTEL_CHTWC_INT33FE=m
Search for symbol INTEL_ISHTP_ECLITE
Search for symbol INTEL_MRFLD_PWRBTN
Search for symbol INTEL_PUNIT_IPC
Search for symbol INTEL_RST
CONFIG_INTEL_RST=m
Search for symbol INTEL_SDSI
CONFIG_INTEL_SDSI=m
Search for symbol INTEL_SMARTCONNECT
CONFIG_INTEL_SMARTCONNECT=m
Search for symbol INTEL_TPMI
CONFIG_INTEL_TPMI=m
Search for symbol INTEL_TURBO_MAX_3
CONFIG_INTEL_TURBO_MAX_3=y
Search for symbol INTEL_VSEC
CONFIG_INTEL_VSEC=m

and from drivers/platform/x86/intel/atomisp2:

Search for symbol INTEL_ATOMISP2_PDX86
CONFIG_INTEL_ATOMISP2_PDX86=y
Search for symbol INTEL_ATOMISP2_LED
Search for symbol INTEL_ATOMISP2_PM
CONFIG_INTEL_ATOMISP2_PM=m

Seems that:

INTEL_BXTWC_PMIC_TMU
INTEL_BYTCRC_PWRSRC
INTEL_CHTDC_TI_PWRBTN
INTEL_ISHTP_ECLITE
INTEL_MRFLD_PWRBTN
INTEL_PUNIT_IPC
INTEL_ATOMISP2_LED

Are missing.

Which one are needed by the camera? BYTCRC symbols are for BayTrail chips.

rmast commented 1 month ago

Exactly, so INTEL_BYTCRC_PWRSRC and INTEL_ATOMISP2_LED would be helpful as modules. The rest don't ring any bells yet.

rmast commented 1 month ago

With the updated fc41 kernel-devel your dkms make is running fine.

mirh commented 1 month ago

[ 13.617706] mt9m114 i2c-INT33F0:00: Failed to find EFI gmin variable gmin_V1P8GPIO

So do you have V1P8GPIO or V2P8GPIO between your efi variables?

I have a question regarding the 2 firmware files. We are allowed to distribute them public?

Is there one that isn't here?

rmast commented 1 month ago

It appears that the redistributability has been taken care of!.

I once read those voltages were only meant for an old prototyping board. The DSDT contains them in the Power-section. I wasn't able to read them via ACPI yet though.

Verzonden vanaf Outlook voor Androidhttps://aka.ms/AAb9ysg

From: mirh @.> Sent: Saturday, October 12, 2024 10:10:18 PM To: jfwells/linux-asus-t100ta @.> Cc: rmast @.>; Mention @.> Subject: Re: [jfwells/linux-asus-t100ta] I finally found why this Camera driver won't work on an unmodded ASUS laptop-BIOS (#4)

[ 13.617706] mt9m114 i2c-INT33F0:00: Failed to find EFI gmin variable gmin_V1P8GPIO

So do you have V1P8GPIO or V2P8GPIO between your efi variables?

I have a question regarding the 2 firmware files. We are allowed to distribute them public?

Is there one that isn't herehttps://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/intel/ipu?

— Reply to this email directly, view it on GitHubhttps://github.com/jfwells/linux-asus-t100ta/issues/4#issuecomment-2408687339, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAZPZ5VWURAWVEF7MWO7QOLZ3F62VAVCNFSM6AAAAABJOYBMS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGY4DOMZTHE. You are receiving this because you were mentioned.Message ID: @.***>

rmast commented 1 month ago

How would one interpret this: "We could switch to using pr_warn for dev == NULL instead, but as comments in the source indicate, the check for these 2 special gmin variables with a NULL device is a workaround for 2 specific evaluation boards, so completely silencing the missing warning for these actually is a good thing."

https://lore.kernel.org/lkml/20170528123040.18555-1-hdegoede@redhat.com/T/

EasyNetDev commented 1 month ago

OK, I remade the DKMS and now I have these drivers loaded:

# lsmod | grep "intel\|atom\|ipu\|ivsc"
intel_soc_dts_thermal    16384  0
intel_soc_dts_iosf     16384  1 intel_soc_dts_thermal
intel_powerclamp       16384  0
kvm_intel             413696  0
kvm                  1343488  1 kvm_intel
intel_rapl_msr         20480  0
ghash_clmulni_intel    16384  0
aesni_intel           364544  4
intel_atomisp2_led     12288  0
snd_intel_sst_acpi     16384  1
crypto_simd            16384  1 aesni_intel
snd_intel_sst_core     73728  1 snd_intel_sst_acpi
cryptd                 28672  3 crypto_simd,ghash_clmulni_intel
snd_soc_sst_atom_hifi2_platform   122880  2 snd_intel_sst_core
intel_cstate           24576  0
intel_pmc_bxt          16384  1 iTCO_wdt
intel_bytcrc_pwrsrc    12288  0
snd_soc_acpi_intel_match   106496  1 snd_intel_sst_acpi
snd_soc_acpi           16384  3 snd_soc_sst_bytcr_rt5640,snd_soc_acpi_intel_match,snd_intel_sst_acpi
snd_intel_dspcfg       36864  1 snd_intel_sst_acpi
snd_intel_sdw_acpi     16384  1 snd_intel_dspcfg
snd_soc_core          413696  6 snd_soc_rt5651,snd_soc_sst_bytcr_rt5640,snd_soc_rt5670,snd_soc_rt5640,snd_soc_sst_atom_hifi2_platform,snd_soc_rt5645
btintel                69632  1 hci_uart
intel_rapl_common      49152  2 intel_rapl_msr,processor_thermal_rapl
intel_atomisp2_pm      12288  0
bluetooth            1069056  34 btrtl,btqca,btintel,hci_uart,btbcm,bnep,rfcomm
snd_pcm               188416  10 snd_soc_rt5651,snd_soc_sst_bytcr_rt5640,snd_soc_rt5670,snd_soc_rt5640,snd_compress,snd_hdmi_lpe_audio,snd_soc_sst_atom_hifi2_platform,snd_soc_core,snd_soc_rt5645,snd_pcm_dmaengine
intel_int0002_vgpio    12288  1
snd                   147456  22 snd_ctl_led,snd_seq,snd_soc_sst_bytcr_rt5640,snd_seq_device,snd_timer,snd_compress,snd_hdmi_lpe_audio,snd_soc_sst_atom_hifi2_platform,snd_soc_core,snd_pcm
atomisp_mt9m114        36864  0
atomisp               995328  0
atomisp_gmin_platform    36864  2 atomisp,atomisp_mt9m114
v4l2_fwnode            32768  1 atomisp
videobuf2_vmalloc      20480  1 atomisp
videobuf2_v4l2         36864  1 atomisp
videobuf2_common       81920  4 atomisp,videobuf2_vmalloc,videobuf2_v4l2,videobuf2_memops
v4l2_async             32768  2 atomisp,v4l2_fwnode
videodev              364544  5 atomisp,v4l2_async,v4l2_fwnode,videobuf2_v4l2,atomisp_mt9m114
mc                     94208  6 atomisp,v4l2_async,videodev,videobuf2_v4l2,videobuf2_common,atomisp_mt9m114
ipu_bridge             16384  1 atomisp
crc32c_intel           16384  3

Tomorrow I will upload the new version of the DKMS driver on my github.

rmast commented 1 month ago

I guess you should totally get rid of intel_atomisp2_pm as it's sole purpose was to shut the camera led off without the aim getting it on again during uptime. https://www.kernelconfig.io/config_intel_atomisp2_pm

You miss the latest commits, there is a sh_css_dvs_info.h in your tree that was removed on the 6th of september in hansg's media-atomisp-branch.

rmast commented 1 month ago

After enabling both mt9m114 modules and and the baytrail powermanager modules the led doesn't respond to intel_atomisp2_led anymore, so I guess one interferes with the other.

I also wonder whether there are two interfering atomisp-drivers. If so it might be necessary to transplant stuff. If atomisp and mt9m114 are allowed, while atomisp-mt9m114 is blacklisted the intel_atomisp2_led is respected.

mt9m114 is not automatically inserted and if modprobed doesn't show up in dmesg or journalctl for as far as I can see, so I doubt it does do anything.

As soon as atomisp-mt9m114 is modprobed instead the value 1 in /sys/class/leds/atomisp2::camera/brightness

is ignored and the led is shut off. /dev/video0 is there and unresponsive.

rmast commented 1 month ago

As I expect the rewritten Onsemi driver to abide closer to the new v4l2 I'm curious what would happen if I add { "INT33F0" } to the of_device_id call. It has a slightly different name from the acpi_device_id call in the old driver.

jwrdegoede commented 1 month ago

See: https://lore.kernel.org/linux-media/20241013154056.12532-1-hdegoede@redhat.com/ https://lore.kernel.org/platform-driver-x86/b6374c77-b192-4c54-9504-5806f00a11da@redhat.com/

jwrdegoede commented 1 month ago

As I expect the rewritten Onsemi driver to abide closer to the new v4l2 I'm curious what would happen if I add { "INT33F0" } to the of_device_id call. It has a slightly different name from the acpi_device_id call in the old driver.

Unfortunately things are not that easy, I have a pretty good idea what the minimum necessary changes are, to get things to work at a minimum the following mt9m114 driver changes are required:

  1. Add the ACPI and support for ACPI based enumeration in general which may require further changes.
  2. Waiting for the fwnode endpoint to show up before continuing with probing
  3. Special handling for the clk, devm_get_clk() is expected to fail since the clk is managed by ACPI
  4. Maybe handling of a second (powerdown) GPIO
  5. atomisp changes to deal with the standard v4l2 driver offering multiple mbus formats instead of only offering a single raw bayer format.
EasyNetDev commented 1 month ago

Hi all,

I've uploaded a new version of DKMS for Atom ISP. I created a script (build-dkms) which is searches all drivers under atomisp sub-directory, gets all necessary symbols and modules names and it creates automatically files for dpkg-buildpackage and DKMS.

If the modules and paths for modules are the same, is keeping the same package. If not, is creates a new package which contains the similar drivers in terms of modules and paths.

In this way perhaps is easier to install the modules, change locally and recompile them, if is needed. Not recompiling the whole kernel.