- 20 May, 2020 40 commits
-
-
Helen Koike authored
Move phy-rockchip-dphy-rx0 bindings to Documentation/devicetree/bindings/phy Verified with: make ARCH=arm64 dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml Signed-off-by:
Helen Koike <helen.koike@collabora.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Helen Koike authored
reg property is not used in Rockchip MIPI DPHY RX0 bindings, thus remove it. Suggested-by:
Johan Jonker <jbx6244@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Based on Yocto Aero's repository, the file name for the isp2401 is the same for the B0 release. So, unify it at the driver. Signed-off-by: -
Mauro Carvalho Chehab authored
The TODO list doesn't reflect the current status of the driver. Update it. Signed-off-by: -
Mauro Carvalho Chehab authored
When checking sh_css.c against the Yocto Aero's version, it can be noticed that some isp2401 dependencies may have been taken wrongly. Change the code to work like the Yocto Aero, as this driver was tested in the past with an ISP2401 device. Signed-off-by: -
Mauro Carvalho Chehab authored
Depending on the ISP-specific HAS_NO_INPUT_FORMATTER macro, some IRQs will be ignored by the driver. Yet, those keep happening, as reported by this debug print: [ 61.620746] atomisp-isp2 0000:00:03.0: atomisp_css_irq_enable: css irq info 0x00000004: disable. Causing this warning: [ 61.620749] atomisp-isp2 0000:00:03.0: atomisp_css_irq_enable:Invalid irq info. Well, if this is a normal situation, just ignore it without warnings. Signed-off-by: -
Mauro Carvalho Chehab authored
Add a debug printk to show what IRQ is popping up. Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of using it only if system memory is below 2GB, don't use it at all. The problem is that the code there is not compatible anymore with modern Kernels: [ 179.552797] virt_to_cache: Object is not a Slab page! [ 179.552821] WARNING: CPU: 0 PID: 1414 at mm/slab.h:475 cache_from_obj+0xab/0xf0 [ 179.552824] Modules linked in: ccm(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) ip6table_nat(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) libcrc32c(E) nf_defrag_ipv4(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ip_set(E) nf_tables(E) nfnetlink(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) cmac(E) bnep(E) sunrpc(E) vfat(E) fat(E) mei_hdcp(E) snd_soc_sst_cht_bsw_rt5645(E) gpio_keys(E) intel_rapl_msr(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) asus_nb_wmi(E) ath10k_pci(E) ghash_clmulni_intel(E) ath10k_core(E) intel_cstate(E) wdat_wdt(E) pcspkr(E) ath(E) mac80211(E) intel_chtdc_ti_pwrbtn(E) joydev(E) btusb(E) btrtl(E) btbcm(E) btintel(E) libarc4(E) bluetooth(E) cfg80211(E) ecdh_generic(E) ecc(E) mei_txe(E) mei(E) lpc_ich(E) [ 179.552887] hid_sensor_accel_3d(E) hid_sensor_gyro_3d(E) hid_sensor_trigger(E) hid_sensor_iio_common(E) industrialio_triggered_buffer(E) kfifo_buf(E) industrialio(E) atomisp_ov2680(CE) snd_soc_rt5645(E) snd_intel_sst_acpi(E) snd_soc_rl6231(E) snd_intel_sst_core(E) snd_soc_sst_atom_hifi2_platform(E) intel_hid(E) snd_soc_acpi_intel_match(E) spi_pxa2xx_platform(E) snd_soc_acpi(E) snd_soc_core(E) snd_compress(E) dw_dmac(E) snd_hdmi_lpe_audio(E) int3400_thermal(E) int3406_thermal(E) snd_seq(E) acpi_thermal_rel(E) int3403_thermal(E) atomisp(CE) snd_seq_device(E) snd_pcm(E) intel_int0002_vgpio(E) soc_button_array(E) acpi_pad(E) intel_xhci_usb_role_switch(E) snd_timer(E) videobuf_vmalloc(E) videobuf_core(E) snd(E) atomisp_gmin_platform(CE) soundcore(E) videodev(E) processor_thermal_device(E) intel_soc_dts_iosf(E) mc(E) intel_rapl_common(E) int340x_thermal_zone(E) ip_tables(E) hid_sensor_hub(E) intel_ishtp_loader(E) intel_ishtp_hid(E) mmc_block(E) hid_multitouch(E) crc32c_intel(E) i915(E) [ 179.552936] hid_asus(E) i2c_algo_bit(E) asus_wmi(E) sparse_keymap(E) rfkill(E) drm_kms_helper(E) intel_ish_ipc(E) intel_ishtp(E) drm(E) wmi(E) video(E) i2c_hid(E) pwm_lpss_platform(E) pwm_lpss(E) sdhci_acpi(E) sdhci(E) mmc_core(E) fuse(E) [ 179.552961] CPU: 0 PID: 1414 Comm: v4l2grab Tainted: G C EL 5.7.0-rc2+ #42 [ 179.552963] Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019 [ 179.552968] RIP: 0010:cache_from_obj+0xab/0xf0 [ 179.552973] Code: c3 31 c0 80 3d 1c 38 72 01 00 75 f0 48 c7 c6 20 12 06 9f 48 c7 c7 10 f3 37 9f 48 89 04 24 c6 05 01 38 72 01 01 e8 2c 99 e0 ff <0f> 0b 48 8b 04 24 eb ca 48 8b 57 58 48 8b 48 58 48 c7 c6 30 12 06 [ 179.552976] RSP: 0018:ffffaf1f00c3fae0 EFLAGS: 00010282 [ 179.552980] RAX: 0000000000000029 RBX: 00000000000003ff RCX: 0000000000000007 [ 179.552983] RDX: 00000000fffffff8 RSI: 0000000000000082 RDI: ffff9cb6bbc19cc0 [ 179.552985] RBP: 0000000001000000 R08: 00000000000005a4 R09: ffffaf1f00c3f970 [ 179.552988] R10: 0000000000000005 R11: 0000000000000000 R12: ffffffffc0713da0 [ 179.552991] R13: ffff9cb5a7bb1000 R14: 0000000001000000 R15: ffff9cb5a7bb1000 [ 179.552995] FS: 0000000000000000(0000) GS:ffff9cb6bbc00000(0000) knlGS:0000000000000000 [ 179.552998] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 179.553000] CR2: 00007fe780544400 CR3: 000000002480a000 CR4: 00000000001006f0 [ 179.553003] Call Trace: [ 179.553015] kmem_cache_free+0x19/0x180 [ 179.553070] mmu_l2_unmap+0xd1/0x100 [atomisp] [ 179.553113] ? __bo_merge+0x8f/0xa0 [atomisp] [ 179.553155] mmu_unmap+0xd0/0xf0 [atomisp] [ 179.553198] hmm_bo_unbind+0x62/0xb0 [atomisp] [ 179.553240] hmm_free+0x44/0x60 [atomisp] Signed-off-by: -
Mauro Carvalho Chehab authored
Calling acpi_bus_get_device() may end allocating resources that aren't freed. So, add a notice about that, as, if those drivers get out of staging, we may need some changes. Fixes: 0d64e942 ("media: atomisp: Add some ACPI detection info") Signed-off-by:
-
Mauro Carvalho Chehab authored
The memory management code for atomisp is complex: it has 2 extra pools (plus some ION-specific code). The code for those extra pools are complex, and there are even some parts of code over there that were forked from some mm/ code, probably from Kernel 3.10. Let's just use a single one, in order to make the driver simpler. Signed-off-by: -
Mauro Carvalho Chehab authored
Camera cannot be set on power off mode. Signed-off-by: -
Mauro Carvalho Chehab authored
Instead of trying to send multiple bytes at the same time, just go one by one, like the upstream driver does. Signed-off-by: -
Mauro Carvalho Chehab authored
This isn't really used, so get rid, in order to make the code simpler. Signed-off-by: -
Mauro Carvalho Chehab authored
There is an ov2680 driver mainstream. Use the read/write routines from it, as the ones inside this driver are generating some errors: ov2680 i2c-OVTI2680:00: ov2680_i2c_write: i2c write reg=0x3086, value 0x00, error -121 Maybe the code that changes from/to BE are not right. Signed-off-by: -
Mauro Carvalho Chehab authored
Change some code at ov2680 for it to better report what's happening there at sensor's level. Signed-off-by: -
Mauro Carvalho Chehab authored
The sensor should finish its init before atomisp driver, as otherwise the atomisp driver won't be able to talk with it. So, we need to turn atomisp_gmin_platform into a module again, for it to not depend on atomisp driver to finish probing, and add some delay at atomisp to let the sensor driver to finish probing. Yeah, this is hacky. The real solution here would be to use the async framework, but for now, our goal is to make the driver to work. So, let's postpone such change to be done later. Signed-off-by: -
Mauro Carvalho Chehab authored
The current code causes ISP2401 to power down and never return back to live, causing the driver to crash. Fix it by commenting out the bad code. It should be noticed that the Yocto Aero code has something similar to it. Maybe the issue is related to an ISP bug (or maybe PM is controlled on a different way for this hardware). Signed-off-by: -
Mauro Carvalho Chehab authored
The value returned by BIOS is 1. Fix it at the driver, as it won't read this from EFI. Signed-off-by: -
Mauro Carvalho Chehab authored
The mmu mapping logic uses a different logic depending on the RAM size: if it is lower than 2GB, it uses kmem_cache_zalloc(), but if memory is bigger than that, it uses its own way to allocate memory. Yet, when freeing, it uses kmem_cache_free() for any cases. On recent Kernels, slab tracks the memory allocated on it, with causes those warnings: virt_to_cache: Object is not a Slab page! WARNING: CPU: 0 PID: 758 at mm/slab.h:475 cache_from_obj+0xab/0xf0 Modules linked in: snd_soc_sst_cht_bsw_rt5645(E) mei_hdcp(E) gpio_keys(E) intel_rapl_msr(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) atomisp_ov2680(CE) intel_cstate(E) asus_nb_wmi(E) wdat_wdt(E) pcspkr(E) ath10k_pci(E) ath10k_core(E) intel_chtdc_ti_pwrbtn(E) ath(E) mac80211(E) btusb(E) joydev(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) libarc4(E) ecdh_generic(E) cfg80211(E) ecc(E) hid_sensor_gyro_3d(E) hid_sensor_accel_3d(E) hid_sensor_trigger(E) hid_sensor_iio_common(E) industrialio_triggered_buffer(E) kfifo_buf(E) industrialio(E) atomisp(CE) videobuf_vmalloc(E) videobuf_core(E) videodev(E) mc(E) snd_soc_rt5645(E) snd_soc_rl6231(E) snd_intel_sst_acpi(E) snd_intel_sst_core(E) snd_soc_sst_atom_hifi2_platform(E) snd_soc_acpi_intel_match(E) intel_hid(E) spi_pxa2xx_platform(E) snd_soc_acpi(E) snd_soc_core(E) snd_compress(E) dw_dmac(E) intel_xhci_usb_role_switch(E) int3406_thermal(E) snd_hdmi_lpe_audio(E) int3403_thermal(E) int3400_thermal(E) acpi_thermal_rel(E) snd_seq(E) intel_int0002_vgpio(E) soc_button_array(E) snd_seq_device(E) acpi_pad(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) lpc_ich(E) mei_txe(E) mei(E) processor_thermal_device(E) intel_soc_dts_iosf(E) intel_rapl_common(E) int340x_thermal_zone(E) ip_tables(E) hid_sensor_hub(E) intel_ishtp_loader(E) intel_ishtp_hid(E) mmc_block(E) hid_multitouch(E) crc32c_intel(E) i915(E) i2c_algo_bit(E) drm_kms_helper(E) hid_asus(E) asus_wmi(E) sparse_keymap(E) rfkill(E) drm(E) intel_ish_ipc(E) intel_ishtp(E) wmi(E) video(E) i2c_hid(E) sdhci_acpi(E) sdhci(E) mmc_core(E) pwm_lpss_platform(E) pwm_lpss(E) fuse(E) CPU: 0 PID: 758 Comm: v4l_id Tainted: G C E 5.7.0-rc2+ #40 Hardware name: ASUSTeK COMPUTER INC. T101HA/T101HA, BIOS T101HA.306 04/23/2019 RIP: 0010:cache_from_obj+0xab/0xf0 Code: c3 31 c0 80 3d 1c 38 72 01 00 75 f0 48 c7 c6 20 12 06 b5 48 c7 c7 10 f3 37 b5 48 89 04 24 c6 05 01 38 72 01 01 e8 2c 99 e0 ff <0f> 0b 48 8b 04 24 eb ca 48 8b 57 58 48 8b 48 58 48 c7 c6 30 12 06 RSP: 0018:ffffb0a4c07cfb10 EFLAGS: 00010282 RAX: 0000000000000029 RBX: 0000000000000048 RCX: 0000000000000000 RDX: ffffa004fbca5b80 RSI: ffffa004fbc19cc8 RDI: ffffa004fbc19cc8 RBP: 0000000000c49000 R08: 00000000000004f7 R09: 0000000000000001 R10: 0000000000aaaaaa R11: ffffffffb50e0600 R12: ffffffffc0be0a00 R13: ffffa003f2448000 R14: 0000000000c49000 R15: ffffa003f2448000 FS: 00007f9060c9cb80(0000) GS:ffffa004fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559fc55b8000 CR3: 0000000165b02000 CR4: 00000000001006f0 Call Trace: kmem_cache_free+0x19/0x180 mmu_l2_unmap+0xd1/0x100 [atomisp] mmu_unmap+0xd0/0xf0 [atomisp] hmm_bo_unbind+0x62/0xb0 [atomisp] hmm_free+0x44/0x60 [atomisp] ia_css_spctrl_unload_fw+0x30/0x50 [atomisp] ia_css_uninit+0x3a/0x90 [atomisp] atomisp_open+0x50b/0x5c0 [atomisp] v4l2_open+0x85/0xf0 [videodev] chrdev_open+0xdd/0x210 ? cdev_device_add+0xc0/0xc0 do_dentry_open+0x13a/0x380 path_openat+0xa9a/0xfe0 do_filp_open+0x75/0x100 ? __check_object_size+0x12e/0x13c ? __alloc_fd+0x44/0x150 do_sys_openat2+0x8a/0x130 __x64_sys_openat+0x46/0x70 do_syscall_64+0x5b/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Solve it by calling free_page() directly Signed-off-by: -
Mauro Carvalho Chehab authored
Simplify the hmm_bo a little bit by removing this macro. This will avoid printing twice errors when allocations happen. Signed-off-by: -
Mauro Carvalho Chehab authored
Those files seem to be firmware-dependent, probably being used by some debug interface. Well, their contents are not really used by atomisp, so let's just send them to the trash can, as it shouldn't have any usage upstream. Signed-off-by: -
Mauro Carvalho Chehab authored
When changing the IFs to select isp2401 at runtime, one of the conditions ended by being written wrong. Code double-checked on both Yocto Aero's driver version and against the previous code. Signed-off-by: -
Mauro Carvalho Chehab authored
There is an endif in the middle of a comment at ia_css_xnr3.host.c. Remove it. Signed-off-by: -
Mauro Carvalho Chehab authored
Use the version from intel_atomisp2_pm.c for power up/down, removing some code duplication and using just one kAPI call for modifying the ISPSSPM0 register. Signed-off-by: -
Mauro Carvalho Chehab authored
Changing to pci_enable_device() didn't produce the expected result. It could also eventually led to problems when driver is removed, due to object lifetime issues. So, let's just return to the previous behavior. Suggested-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
We need that to avoid trying to double-free the driver. Signed-off-by: -
Mauro Carvalho Chehab authored
This patch required lots of research and work. The existing atomisp driver at staging assumed that all Intel PMIC would be using regulators, but upstream didn't follow it. Instead, the intel_pmic.c driver added a hack, instead of using i2c_transfer, it writes I2C values directly via regmapped registers. Oh, well... At least, it provided a common API for doing that. The PMIC settings used here came from the driver at the yocto Aero distribution: https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/ The logic itself was re-written, in order to use the I2C address detected by the probing part. Signed-off-by:
-
Mauro Carvalho Chehab authored
The atomisp_gmin_platform.c is not a platform driver anymore, but it is, instead, part of the atomisp driver. Move it to be together with the driver. As a bonus, as the atomisp i2c drivers depends on its contents, probing them should load automatically the atomisp core. This should likely avoid some possible race conditions. Signed-off-by: -
Mauro Carvalho Chehab authored
Sub-device's power management can be provided via different ways. Instead of hardcoding it, add a code that would be detecting it. This uses a code similar to what's found at the atomisp driver inside the Intel Aero repository: https://github.com/intel-aero/meta-intel-aero.git (driver was removed on some commit, but it can be found on git history). Signed-off-by:
-
Mauro Carvalho Chehab authored
Right now, the driver supports just one VCM and just one flash device. Warn if more than one such devices were probed. Signed-off-by: -
Mauro Carvalho Chehab authored
This driver is really on bad shape. One of the problems is that, as soon as the I2C transfers start to happen, it timeouts detecting a camera: ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680 atomisp-isp2 0000:00:03.0: no camera attached or fail to detect ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data using PMIC regulator ... The right fix here would be to use defer probe, but driver is still on too bad shape. Signed-off-by: -
Mauro Carvalho Chehab authored
While the current code is hardcoded to just one specific type of PMIC, it can support several types. Those should be board-dependent. Instead of just printing a number, change the message to display what type of PMIC control is used at runtime. Signed-off-by: -
Mauro Carvalho Chehab authored
There are several device-specific data that are obtained either via DMI or EFI, with changes the driver's behavior. Display what has been detected, as such info may help identifying troubles at the driver. Signed-off-by: -
Mauro Carvalho Chehab authored
When someone would report problems with a new device, we need to know the DMI product ID and the ACPI name for the detected sensor. So, print them at dmesg. Signed-off-by: -
Mauro Carvalho Chehab authored
This driver still has lots of issues. Let's enable debug there inconditionally, as we need more information in order to address the pending issues. Signed-off-by: -
Mauro Carvalho Chehab authored
This setting is used only for one of te Merryfield PCI IDs. As this is an ISP2400, we can just get rid of a version test, writing the right value directly inside the struct. Signed-off-by: -
Mauro Carvalho Chehab authored
The atomisp probe error logic is incomplete. Add the missing bits to return the PCI device to its original state. Signed-off-by: -
Mauro Carvalho Chehab authored
As getting the exact version used by the driver is not easy, let's relax the version detection and hope for the best, producing just a warning. Signed-off-by: -
Mauro Carvalho Chehab authored
- Remove useless check if !dev at the probe function: if such function is called, the device is defined. - Cleanup the PCI ID table using macros. - Use the same macros at the version-dependent part of the atomisp_v4l2.c file; - Add print messages to help understand what model the driver detect; - If device is not valid, better explain why. Signed-off-by: -
Mauro Carvalho Chehab authored
changeset d5426f4c ("media: staging: atomisp: use clock framework for camera clocks") removed a platform-specific code to set the clock rate, in favor of using the Kernel clock framework. However, instead of passing the frequency for clk_set_rate(), it is passing either 0 or 1. Looking at the original patchset, it seems that there are two possible configurations for the ISP: 0 - it will use a 25 MHz XTAL to provide the clock; 1 - it will use a PLL with is set to 19.2 MHz (only for the CHT version?) Eventually, different XTALs and/or PLL frequencies might be possible some day, so, re-implent the logic for it to be more generic. Fixes: d5426f4c ("media: staging: atomisp: use clock framework for camera clocks") Signed-off-by:
-
