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.

EasyNetDev 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 no clue. I can't find anything in /sys/firmware/efi/efivars/

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

Is there one that isn't here?

Hm .. I didn't know is already in Kernel Firmware tree. At the time when I started to dig-in for this issue I couldn't find them in Kernel firmware tree. Looks like they been added on 2024-02-29.

Here is my full dmesg after my last DKMS submit:

ASUS-T100TAM-atom-isp-kernel-messages.txt

EasyNetDev 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.

I can blacklist it in /etc/modprobe.d/

rmast commented 1 month ago

Hans has provided a starter-patch for T100ta above, with development goals.

rmast commented 1 month ago

I tried Hansg's starter patch, but have not seen a picture yet, as nothing is coming out I can even pipe to stdout:

GST_DEBUG=3 gst-launch-1.0 -v v4l2src num-buffers=200 Setting pipeline to PAUSED Pipeline is live and does not need PREROLL WARN VIDIOC_CROPCAP failed WARN Pipeline is PREROLLED
Setting pipeline to PLAYING ... WARN v4112bufferpool Uncertain or not enough buffer enabling copy threshold

EasyNetDev commented 1 month ago

I tried Hansg's starter patch, but have not seen a picture yet, as nothing is coming out I can even pipe to stdout: GST_DEBUG=3 gst-launch-1.0 -v v4l2src num-buffers=200 Setting pipeline to PAUSED Pipeline is live and does not need PREROLL WARN VIDIOC_CROPCAP failed WARN Pipeline is PREROLLED Setting pipeline to PLAYING ... WARN v4112bufferpool Uncertain or not enough buffer enabling copy threshold

On which Kernel version you tried? Can you point me the patch? Today Debian Trixie updated the kernel from 6.10.11 to 6.11.2. My DKMS automatically installed the drivers. I want to try it also.

rmast commented 1 month ago

I use Hansg's kernel https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/tree/?h=media-atomisp The patch is mentioned above by Hansg, alias jwrdegoede 3 days ago.

EasyNetDev commented 1 month ago

I did a diff between https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/?h=media-atomisp and Linux kernel 6.11.3 and 6.11.4. There are differences. I check drivers/staging/media/atomisp/pci/ directory. Directories drivers/platform/x86/intel/atomisp2/ are identical.

rmast commented 1 month ago

I not only enabled the v4l2-debugging by putting the text 0x1f in /sys/class/video4linux/video0/dev_debug but also enabled the dynamic debugging by using

/etc/modprobe.d/atomisp.conf: options mt9m114 dyndbg=+pfm options atomisp_mt9m114 dyndbg=+pfm options atomisp dyndbg=+pfm

together with CONFIG_DYNAMIC_DEBUG=y CONFIG_DYNAMIC_DEBUG_CORE=y

This statement GST_DEBUG=3 gst-launch-1.0 -m -v -e v4l2src num-buffers=1 ! "video/x-raw,format=UYVY,width=640,height=480" ! jpegenc ! filesink location=atomisp.jpg sync=true async=false >uitvoergst.txt 2>&1

resulted in the following logging details: uitvoergst.txt journaluitvoer.txt

The outputfile stays empty, so the next step is zooming in at the spot where the process seems to stall.

rmast commented 1 month ago

This one should be completely transferrable to the atomisp_mt9m114.c as it's commit message states this ov2680 change was tested on Baytrail ACPI:

https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/commit/drivers/staging/media/atomisp/i2c/atomisp-ov2680.c?h=media-atomisp&id=b7e155e16601b0c6f34e3345b9eca6a2efc5bc5d

rmast commented 1 month ago

This one answers the question whether atomisp_gmin_platform is intended to stay or to go as a source for parsing the DSDT or providing hardware specific constants otherwise: https://github.com/torvalds/linux/commit/947550f8c08ec68db637dbb27f80dbb922536a82

rmast commented 1 month ago

The _DSM of the T100ta responds with 11P2SF208 at the GUID of the Sensor. ChatGPT thinks it's type code is similar to known VCM's, but it gives no hit on Google. The mt9m114 documentation does say it's fixed focus, so a VCM is probably just a ghost value. For the T100ta I guess it should just expect the GUID 377ba76a-f390-4aff-ab38-9b1bf33a3015 for the INT33F0 - value.

rmast commented 1 month ago

The mt9m114.c contains hardcoded PLL constant that seems to require an Extclk to be 24 MHz instead of the 19.2 MHz assumption in the current atomisp code. It's accepted range is only between 20 and 24 MHz, so also the default 25 MHz is out of range.

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

From: Robert Mast @.> Sent: Thursday, October 24, 2024 6:41:07 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 mt9m114 documentation does say it's fixed focus, so it’s probably just a ghost value.

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

From: Robert Mast @.> Sent: Thursday, October 24, 2024 5:53:11 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 _DSM of the T100ta responds with 11P2SF208 at the GUID of the VCM. ChatGPT thinks it's type code is similar to known VCM's, but it gives no hit on Google.

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

From: Robert Mast @.> Sent: Saturday, October 19, 2024 11:12:53 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 one will have to be transferred:

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

From: EasyNet @.> Sent: Thursday, October 17, 2024 11:25:09 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)

I did a diff between https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/?h=media-atomisp and Linux kernel 6.11.3 and 6.11.4. There are differences. I check drivers/staging/media/atomisp/pci/ directory. Directories drivers/platform/x86/intel/atomisp2/ are identical.

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

rmast commented 1 month ago

Some camera driver guidelines: https://github.com/torvalds/linux/blob/master/Documentation/driver-api/media/camera-sensor.rst

rmast commented 1 month ago

It appears in the new config-6.11.5-300.fc41.x86_64 for Fedora 41 these are correct: CONFIG_DRM_I915=m CONFIG_PWM_CRC=y CONFIG_GPIO_CRYSTAL_COVE=y so with this kernel an attempt to get DKMS to work for us would probably work. With all those fast updates on the system it's hard to get the system stable for a period of time. I might have the clocks in sync now in my local version, but DFS 200 is refused to get written.

I believe since my Fedora 41 upgrade last wednesday evening my mt9m114 probe via ACPI is not triggered anymore, so I'll try to get DKMS to work.

EasyNetDev commented 1 month ago

Seems that Debian ships Kernel without GPIO_CRYSTAL_COVE:

grep "CONFIG_DRM_I915[ =]\|CONFIG_PWM_CRC\|CONFIG_GPIO_CRYSTAL_COVE" /boot/config-6.11.4-amd64 
# CONFIG_GPIO_CRYSTAL_COVE is not set
CONFIG_DRM_I915=m
CONFIG_PWM_CRC=y
EasyNetDev commented 1 month ago

But also looks like GPIO_CRYSTAL_COVE can be build as module:

GPIO_CRYSTAL_COVE [=m]

In case this module is needed by the AtomISP, I can include it the driver.

rmast commented 4 weeks ago

I guess the Fedora choice for

CONFIG_DRM_I915=m CONFIG_PWM_CRC=y CONFIG_GPIO_CRYSTAL_COVE=y

Is because of a backlight bug, mentioned by Hans before, with a reference in this thread.

Without those y in the built kernel the order of the modules is faulty.

rmast commented 4 weeks ago

By the way, sudo make install (in Fedora) appears to result in 'extra' modules in Fedora 41 that get probed without using the dkms-command. I forked your repo and extended the 6.11 directory with my current status. For some reason mt9m114 doesn't probe though, that is something I have to backtrack.

The HpllFreq was raised on the wrong moment. If HpllFreq is set to 3840 then low DFS 200 is not accepted by the HW, so both should be handled in the same power management event handling, more like is done for Cherry Trail in the atomisp_csi2_bridge.

rmast commented 4 weeks ago

I think the right timings for DFS, HpllFreq and ExtClk are still in question.

I thought to put DFS on 400, HpllFreq on 3840 and ExtClk to 19,2 MHz, but as soon as link-Freq is set to 3840 the probe of mt9m114 is hanging the system.

I somewhere read there were other DFS tables with the Yocto project mentioning HpllFreq 1600 and DFS 320.

So, as the order of events is not completely in control yet, I don't know if I reached those high targets, or if something interfered that made the clocks out of sync.

I guess we should aim for the lowest possible frequencies first to put the system at minimal risk. I saw HpllFreq is accepted with DFS 200.

This is the Yocto file with HpllFreq 1600 the mention was talking about: https://github.com/intel-aero/meta-intel-aero/blob/4ebb7cc829f57306b9895f20af8fd17987089392/recipes-kernel/linux/linux-yocto/0013-temp-atomisp-support.patch

rmast commented 4 weeks ago

I guess the lock up might also be occurring in the power_on right after setting link speed.

My next attempt will be iterating with the new dkms-version in my repo on the Fedora core 41 kernel around this turning on the camera, right after setting the link speed neatly copying stuff from ov2680.c and cherry trail to mt9m114.c and baytrail each step, also to the atomisp-csi2-bridge.

rmast commented 1 week ago

With a little direction of Hans de Goede the first signs of light are coming through, though lots has to be done.

See https://github.com/jfwells/linux-asus-t100ta/issues/6 for getting atomisp-mt9m114 to show some dark image with some hacks: