summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2023-08-10drm/i915/irq: add dedicated intel_display_irq_init()Jani Nikula
Continue splitting display from the rest. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/45c247c9f5104f3e25bd8913644402a11ec3afaf.1691509966.git.jani.nikula@intel.com
2023-08-10drm/i915/gt: Apply workaround 22016122933 correctlyJonathan Cavitt
WA_22016122933 was recently applied to all MeteorLake engines, which is simultaneously too broad (should only apply to Media engines) and too specific (should apply to all platforms that use the same media engine as MeteorLake). Correct this in cases where coherency settings are modified. There were also two additional places where the workaround was applied unconditionally. The change was confirmed as necessary for all platforms, so the workaround label was removed. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Acked-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801153242.2445478-4-jonathan.cavitt@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20230807121957.598420-4-andi.shyti@linux.intel.com
2023-08-10drm/i915: Make i915_coherent_map_type GT-centricJonathan Cavitt
Refactor i915_coherent_map_type to be GT-centric rather than device-centric. Each GT may require different coherency handling due to hardware workarounds. Since the function now takes a GT instead of the i915, the function is renamed and moved to the gt folder. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Acked-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801153242.2445478-3-jonathan.cavitt@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20230807121957.598420-3-andi.shyti@linux.intel.com
2023-08-10drm/i915/gt: Simplify shmem_create_from_object map_type selectionJonathan Cavitt
The object pin created for shmem_create_from_object is just a single use mapping with the sole purpose of reading the contents of the whole object in bulk. And the whole source object is also even a throw-away. Ergo, the additional logic required by i915_coherent_map_type can be safely dropped and simplified. Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801153242.2445478-2-jonathan.cavitt@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20230807121957.598420-2-andi.shyti@linux.intel.com
2023-08-10driver core: cpu: Make cpu_show_not_affected() staticBorislav Petkov (AMD)
Fix a -Wmissing-prototypes warning and add the gather_data_sampling() stub macro call for real. Fixes: 0fddfe338210 ("driver core: cpu: Unify redundant silly stubs") Closes: https://lore.kernel.org/oe-kbuild-all/202308101956.oRj1ls7s-lkp@intel.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/202308101956.oRj1ls7s-lkp@intel.com
2023-08-10mlxbf-bootctl: Support setting the ARM boot state to "OS up"Asmaa Mnebhi
The BlueField has internal registers to store the ARM boot states. Support setting the BlueField ARM boot state to "OS up". Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20230809162857.21243-3-asmaa@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-08-10mlxbf-bootctl: Support the large icmc write/readAsmaa Mnebhi
Enable reading and writing the size of the memory region associated with the large ICM carveout. The max size of the large ICM carveout is 1TB, has a granularity of 128MB and will be passed and printed in hex. The size unit is MB. Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Reviewed-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20230809162857.21243-2-asmaa@nvidia.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-08-10driver core: cpu: Unify redundant silly stubsBorislav Petkov (AMD)
Make them all a weak function, aliasing to a single function which issues the "Not affected" string. No functional changes. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Link: https://lore.kernel.org/r/20230809102700.29449-3-bp@alien8.de
2023-08-10pinctrl: qcom: Add intr_target_width field to support increased number of ↵Ninad Naik
interrupt targets SA8775 and newer target have added support for an increased number of interrupt targets. To implement this change, the intr_target field, which is used to configure the interrupt target in the interrupt configuration register is increased from 3 bits to 4 bits. In accordance to these updates, a new intr_target_width member is introduced in msm_pingroup structure. This member stores the value of width of intr_target field in the interrupt configuration register. This value is used to dynamically calculate and generate mask for setting the intr_target field. By default, this mask is set to 3 bit wide, to ensure backward compatibility with the older targets. Fixes: 4b6b18559927 ("pinctrl: qcom: add the tlmm driver sa8775p platforms") Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8775p-ride Signed-off-by: Ninad Naik <quic_ninanaik@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Link: https://lore.kernel.org/r/20230809100634.3961-1-quic_ninanaik@quicinc.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-10platform/x86/siemens: simatic-ipc-batt: fix logical error for BX-59Axingtong.wu
The variable "priv.devmode" is missing from if statement that leads to a logical error. Add the missing variable to the if condition. Fixes: c56beff20375 ("platform/x86/siemens: simatic-ipc-batt: add support for module BX-59A") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202308010001.BGYCSQrl-lkp@intel.com/ Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: xingtong.wu <xingtong.wu@siemens.com> Link: https://lore.kernel.org/r/20430802173844.2483-1-xingtong_wu@163.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-08-10platform/x86/siemens: simatic-ipc: fix logical error for BX-59Axingtong.wu
The variable "ledmode" is missing from if statement that leads to a logical error. Add the missing variable to the if condition. Fixes: b8af77951941 ("platform/x86/siemens: simatic-ipc: add new models BX-56A/BX-59A") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307312322.Aa8upHWK-lkp@intel.com/ Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: xingtong.wu <xingtong.wu@siemens.com> Link: https://lore.kernel.org/r/20430802173515.2363-2-xingtong_wu@163.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-08-10pinctrl: nsp-gpio: Silence probe deferral messagesFlorian Fainelli
We can have gpiochip_add_data() return -EPROBE_DEFER which will make us produce the "unable to add GPIO chip" message which is confusing. Use dev_err_probe() to silence probe deferral messages. Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230808180733.2081353-3-florian.fainelli@broadcom.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-10pinctrl: iproc-gpio: Silence probe deferral messagesFlorian Fainelli
We can have gpiochip_add_data() return -EPROBE_DEFER which will make us produce the "unable to add GPIO chip" message which is confusing. Use dev_err_probe() to silence probe deferral messages. Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230808180733.2081353-2-florian.fainelli@broadcom.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-10pinctrl: single: Add compatible for ti,am654-padconfTony Lindgren
Use the "ti,am654-padconf" compatible to enable the use of wake-up enable and event bits on K3 SOCs that support the daisychain feature Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20230808102207.130177-3-d-gole@ti.com [Alphabetized the compatible list] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-10i2c: synquacer: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230808012954.1643834-10-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10i2c: imx-lpi2c: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230808012954.1643834-9-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10i2c: dln2: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230808012954.1643834-8-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10i2c: pxa: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230808012954.1643834-7-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10i2c: qcom-cci: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230808012954.1643834-6-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10i2c: hisi: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20230808012954.1643834-5-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10i2c: xlp9xx: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230808012954.1643834-4-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10i3c: master: svc: Do not check for 0 return after calling platform_get_irq()Ruan Jinjie
It is not possible for platform_get_irq() to return 0. Use the return value from platform_get_irq(). Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20230803085149.149248-1-ruanjinjie@huawei.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2023-08-10i2c: mlxbf: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230808012954.1643834-3-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10pinctrl: stm32: set default gpio line names using pin namesValentin Caron
Add stm32_pctrl_get_desc_pin_from_gpio function to find a stm32 pin descriptor which is matching with a gpio. Most of the time pin number is equal to pin index in array. So the first part of the function is useful to speed up. And during gpio bank register, we set default gpio names with pin names. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Acked-by: Alexandre TORGUE <alexandre.torgue@foss.st.com> Link: https://lore.kernel.org/r/20230620104349.834687-1-valentin.caron@foss.st.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-10i2c: bcm2835: Use dev_err_probe in probe functionLiao Chang
Use the dev_err_probe function instead of dev_err in the probe function so that the printed message includes the return value and also handles -EPROBE_DEFER nicely. Signed-off-by: Liao Chang <liaochang1@huawei.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20230808012954.1643834-2-liaochang1@huawei.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2023-08-10pinctrl: stmfx: Do not check for 0 return after calling platform_get_irq()Ruan Jinjie
Since commit ce753ad1549c ("platform: finally disallow IRQ0 in platform_get_irq() and its ilk"), there is no possible for platform_get_irq() to return 0. Use the return value from platform_get_irq(). Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230803094304.733371-1-ruanjinjie@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-10pinctrl: at91-pio4: drop useless check in atmel_conf_pin_config_dbg_show()Sergey Shtylyov
In atmel_conf_pin_config_dbg_show(), checking atmel_pioctrl->pins[pin_id] against being NULL doesn't make any sense as it gets derefenced first and the driver's probe() method immediately returns -ENOMEM when devm_kzalloc() returns NULL for any atmel_pioctrl->pins[] element anyway, thus failing to register the device... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/4ab2f59f-45c1-76a2-94da-3331e8ec4e35@omp.ru Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-10pinctrl: mcp23s08: check return value of devm_kasprintf()Claudiu Beznea
devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Fixes: 0f04a81784fe ("pinctrl: mcp23s08: Split to three parts: core, I²C, SPI") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230621100409.1608395-1-claudiu.beznea@microchip.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-08-10rtc: remove redundant of_match_ptr()Zhu Wang
Signed-off-by: Zhu Wang <wangzhu9@huawei.com> Link: https://lore.kernel.org/r/20230808115213.154377-2-wangzhu9@huawei.com Link: https://lore.kernel.org/r/20230808115213.154377-3-wangzhu9@huawei.com Link: https://lore.kernel.org/r/20230808115213.154377-4-wangzhu9@huawei.com Link: https://lore.kernel.org/r/20230808115213.154377-5-wangzhu9@huawei.com Link: https://lore.kernel.org/r/20230808115213.154377-6-wangzhu9@huawei.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2023-08-10i3c/master: cmd_v1: Fix the exit criteria for the daa procedureBilly Tsai
The exit criteria for the DAA should check if the data length is equal to 1, instead of checking if the response status is equal to 1. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Link: https://lore.kernel.org/r/20230802100909.2568215-1-billy_tsai@aspeedtech.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2023-08-10rtc: sunplus: Clean up redundant dev_err_probe()Chen Jiahao
Referring to platform_get_irq()'s definition, the return value has already been checked if ret < 0, and printed via dev_err_probe(). Calling dev_err_probe() one more time outside platform_get_irq() is obviously redundant. Removing dev_err_probe() outside platform_get_irq() to clean up above problem. Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> Link: https://lore.kernel.org/r/20230802093650.976352-1-chenjiahao16@huawei.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2023-08-10rtc: stm32: remove incorrect #ifdef checkArnd Bergmann
After a previous commit changed the driver over to SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(), the suspend/resume functions must no longer be hidden behind an #ifdef: In file included from include/linux/clk.h:13, from drivers/rtc/rtc-stm32.c:8: drivers/rtc/rtc-stm32.c:927:39: error: 'stm32_rtc_suspend' undeclared here (not in a function); did you mean 'stm32_rtc_probe'? 927 | SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(stm32_rtc_suspend, stm32_rtc_resume) | ^~~~~~~~~~~~~~~~~ include/linux/kernel.h:58:44: note: in definition of macro 'PTR_IF' 58 | #define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL) | ^~~ include/linux/pm.h:329:26: note: in expansion of macro 'pm_sleep_ptr' 329 | .suspend_noirq = pm_sleep_ptr(suspend_fn), \ | ^~~~~~~~~~~~ Fixes: fb9a7e5360dc8 ("rtc: stm32: change PM callbacks to "_noirq()"") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20230801105932.3738430-1-arnd@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2023-08-10drm/i915: debug log when GMD ID indicates there's no displayJani Nikula
Debug log similar to the device id based identification of no display. Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804084600.1005818-2-jani.nikula@intel.com
2023-08-10drm/i915: fix display probe for IVB Q and IVB D GT2 serverJani Nikula
The current display probe is unable to differentiate between IVB Q and IVB D GT2 server, as they both have the same device id, but different subvendor and subdevice. This leads to the latter being misidentified as the former, and should just end up not having a display. However, the no display case returns a NULL as the display device info, and promptly oopses. As the IVB Q case is rare, and we're anyway moving towards GMD ID, handle the identification requiring subvendor and subdevice as a special case first, instead of unnecessarily growing the intel_display_ids[] array with subvendor and subdevice. [ 5.425298] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 5.426059] #PF: supervisor read access in kernel mode [ 5.426810] #PF: error_code(0x0000) - not-present page [ 5.427570] PGD 0 P4D 0 [ 5.428285] Oops: 0000 [#1] PREEMPT SMP PTI [ 5.429035] CPU: 0 PID: 137 Comm: (udev-worker) Not tainted 6.4.0-1-amd64 #1 Debian 6.4.4-1 [ 5.429759] Hardware name: HP HP Z220 SFF Workstation/HP Z220 SFF Workstation, BIOS 4.19-218-gb184e6e0a1 02/02/2023 [ 5.430485] RIP: 0010:intel_device_info_driver_create+0xf1/0x120 [i915] [ 5.431338] Code: 48 8b 97 80 1b 00 00 89 8f c0 1b 00 00 48 89 b7 b0 1b 00 00 48 89 97 b8 1b 00 00 0f b7 fd e8 76 e8 14 00 48 89 83 50 1b 00 00 <48> 8b 08 48 89 8b c4 1b 00 00 48 8b 48 08 48 89 8b cc 1b 00 00 8b [ 5.432920] RSP: 0018:ffffb8254044fb98 EFLAGS: 00010206 [ 5.433707] RAX: 0000000000000000 RBX: ffff923076e80000 RCX: 0000000000000000 [ 5.434494] RDX: 0000000000000260 RSI: 0000000100001000 RDI: 000000000000016a [ 5.435277] RBP: 000000000000016a R08: ffffb8254044fb00 R09: 0000000000000000 [ 5.436055] R10: ffff922d02761de8 R11: 00657361656c6572 R12: ffffffffc0e5d140 [ 5.436867] R13: ffff922d00b720d0 R14: 0000000076e80000 R15: ffff923078c0cae8 [ 5.437646] FS: 00007febd19a18c0(0000) GS:ffff92307c000000(0000) knlGS:0000000000000000 [ 5.438434] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.439218] CR2: 0000000000000000 CR3: 000000010256e002 CR4: 00000000001706f0 [ 5.440009] Call Trace: [ 5.440824] <TASK> [ 5.441611] ? __die+0x23/0x70 [ 5.442394] ? page_fault_oops+0x17d/0x4c0 [ 5.443173] ? exc_page_fault+0x7f/0x180 [ 5.443949] ? asm_exc_page_fault+0x26/0x30 [ 5.444756] ? intel_device_info_driver_create+0xf1/0x120 [i915] [ 5.445652] ? intel_device_info_driver_create+0xea/0x120 [i915] [ 5.446545] i915_driver_probe+0x7f/0xb60 [i915] [ 5.447431] ? drm_privacy_screen_get+0x15c/0x1a0 [drm] [ 5.448240] local_pci_probe+0x45/0xa0 [ 5.449013] pci_device_probe+0xc7/0x240 [ 5.449748] really_probe+0x19e/0x3e0 [ 5.450464] ? __pfx___driver_attach+0x10/0x10 [ 5.451172] __driver_probe_device+0x78/0x160 [ 5.451870] driver_probe_device+0x1f/0x90 [ 5.452601] __driver_attach+0xd2/0x1c0 [ 5.453293] bus_for_each_dev+0x88/0xd0 [ 5.453989] bus_add_driver+0x116/0x220 [ 5.454672] driver_register+0x59/0x100 [ 5.455336] i915_init+0x25/0xc0 [i915] [ 5.456104] ? __pfx_i915_init+0x10/0x10 [i915] [ 5.456882] do_one_initcall+0x5d/0x240 [ 5.457511] do_init_module+0x60/0x250 [ 5.458126] __do_sys_finit_module+0xac/0x120 [ 5.458721] do_syscall_64+0x60/0xc0 [ 5.459314] ? syscall_exit_to_user_mode+0x1b/0x40 [ 5.459897] ? do_syscall_64+0x6c/0xc0 [ 5.460510] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 5.461082] RIP: 0033:0x7febd20b0eb9 [ 5.461648] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 2f 1f 0d 00 f7 d8 64 89 01 48 [ 5.462905] RSP: 002b:00007fffabb1ba78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 5.463554] RAX: ffffffffffffffda RBX: 0000561e6304f410 RCX: 00007febd20b0eb9 [ 5.464201] RDX: 0000000000000000 RSI: 00007febd2244f0d RDI: 0000000000000015 [ 5.464869] RBP: 00007febd2244f0d R08: 0000000000000000 R09: 000000000000000a [ 5.465512] R10: 0000000000000015 R11: 0000000000000246 R12: 0000000000020000 [ 5.466124] R13: 0000000000000000 R14: 0000561e63032b60 R15: 000000000000000a [ 5.466700] </TASK> [ 5.467271] Modules linked in: i915(+) drm_buddy video crc32_pclmul sr_mod hid_generic wmi crc32c_intel i2c_algo_bit sd_mod cdrom drm_display_helper cec usbhid rc_core ghash_clmulni_intel hid sha512_ssse3 ttm sha512_generic xhci_pci ehci_pci xhci_hcd ehci_hcd nvme ahci drm_kms_helper nvme_core libahci t10_pi libata psmouse aesni_intel scsi_mod crypto_simd i2c_i801 scsi_common crc64_rocksoft_generic cryptd i2c_smbus drm lpc_ich crc64_rocksoft crc_t10dif e1000e usbcore crct10dif_generic usb_common crct10dif_pclmul crc64 crct10dif_common button [ 5.469750] CR2: 0000000000000000 [ 5.470364] ---[ end trace 0000000000000000 ]--- [ 5.470971] RIP: 0010:intel_device_info_driver_create+0xf1/0x120 [i915] [ 5.471699] Code: 48 8b 97 80 1b 00 00 89 8f c0 1b 00 00 48 89 b7 b0 1b 00 00 48 89 97 b8 1b 00 00 0f b7 fd e8 76 e8 14 00 48 89 83 50 1b 00 00 <48> 8b 08 48 89 8b c4 1b 00 00 48 8b 48 08 48 89 8b cc 1b 00 00 8b [ 5.473034] RSP: 0018:ffffb8254044fb98 EFLAGS: 00010206 [ 5.473698] RAX: 0000000000000000 RBX: ffff923076e80000 RCX: 0000000000000000 [ 5.474371] RDX: 0000000000000260 RSI: 0000000100001000 RDI: 000000000000016a [ 5.475045] RBP: 000000000000016a R08: ffffb8254044fb00 R09: 0000000000000000 [ 5.475725] R10: ffff922d02761de8 R11: 00657361656c6572 R12: ffffffffc0e5d140 [ 5.476405] R13: ffff922d00b720d0 R14: 0000000076e80000 R15: ffff923078c0cae8 [ 5.477124] FS: 00007febd19a18c0(0000) GS:ffff92307c000000(0000) knlGS:0000000000000000 [ 5.477811] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.478499] CR2: 0000000000000000 CR3: 000000010256e002 CR4: 00000000001706f0 Fixes: 69d439818fe5 ("drm/i915/display: Make display responsible for probing its own IP") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8991 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230804084600.1005818-1-jani.nikula@intel.com
2023-08-10drm/test: drm_exec: fix memory leak on object prepareDanilo Krummrich
drm_exec_prepare_obj() and drm_exec_prepare_array() both reserve dma-fence slots and hence a dma_resv_list without ever freeing it. Make sure to call drm_gem_private_object_fini() for each GEM object passed to drm_exec_prepare_obj()/drm_exec_prepare_array() throughout the test to fix this up. While at it, remove some trailing empty lines. Fixes: 9710631cc8f3 ("drm: add drm_exec selftests v4") Signed-off-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230809225034.8803-1-dakr@redhat.com Signed-off-by: Christian König <christian.koenig@amd.com>
2023-08-10drm: atmel-hlcdc: Support inverting the pixel clock polarityMiquel Raynal
On the SoC host controller, the pixel clock can be: * standard: data is launched on the rising edge * inverted: data is launched on the falling edge Some panels may need the inverted option to be used so let's support this DRM flag. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230609144843.851327-1-miquel.raynal@bootlin.com
2023-08-10drm/panfrost: Sync IRQ by job's timeout handlerDmitry Osipenko
Panfrost IRQ handler may stuck for a long time, for example this happens when there is a bad HDMI connection and HDMI handler takes a long time to finish processing, holding Panfrost. Make Panfrost's job timeout handler to sync IRQ before checking fence signal status in order to prevent spurious job timeouts due to a slow IRQ processing. Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> # MediaTek MT8192 and MT8195 Chromebooks Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807000444.14926-1-dmitry.osipenko@collabora.com
2023-08-10drm/exec: add test case for using a drm_exec multiple timesChristian König
Not really a common use case, but let's make sure that we don't accidentially break that somehow. CC: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230731123625.3766-2-christian.koenig@amd.com
2023-08-10drm/shmem-helper: Reset vma->vm_ops before calling dma_buf_mmap()Boris Brezillon
The dma-buf backend is supposed to provide its own vm_ops, but some implementation just have nothing special to do and leave vm_ops untouched, probably expecting this field to be zero initialized (this is the case with the system_heap implementation for instance). Let's reset vma->vm_ops to NULL to keep things working with these implementations. Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf") Cc: <stable@vger.kernel.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Tested-by: Roman Stratiienko <r.stratiienko@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230724112610.60974-1-boris.brezillon@collabora.com
2023-08-10bus: ti-sysc: Fix a build warning with W=1 for sysconfigTony Lindgren
Dhruva reported a build warning with W=1 for "Function parameter or member 'sysconfig' not described in 'sysc'". Let's document sysconfig to fix this. Reported-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-08-10bus: ti-sysc: Configure uart quirks for k3 SoCTony Lindgren
Enable the uart quirks similar to the earlier SoCs. Let's assume we are likely going to need a k3 specific quirk mask separate from the earlier SoCs, so let's not start changing the revision register mask at this point. Note that SYSC_QUIRK_LEGACY_IDLE will be needed until we can remove the need for pm_runtime_irq_safe() from 8250_omap driver. Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-08-10bus: ti-sysc: Build driver for TI K3 SoCsTony Lindgren
Allow building ti-sysc also for K3 SoCs. This allows configuring the wkup domain devices for SYSCONFIG register wake-up events in a generic way. As this is an interconnect level driver, default to built-in on K3 SoCs to probe the devices connected to the wkup domain like gpio, uart and timers. Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-08-10bus: ti-sysc: Fix build warning for 64-bit buildTony Lindgren
Fix "warning: cast from pointer to integer of different size" on 64-bit builds. Note that this is a cosmetic fix at this point as the driver is not yet used for 64-bit systems. Fixes: feaa8baee82a ("bus: ti-sysc: Implement SoC revision handling") Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-08-10media: i2c: Add driver for DW9719 VCMDaniel Scally
Add a driver for the DW9719 VCM. The driver creates a v4l2 subdevice and registers a control to set the desired focus. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Daniel Scally <djrscally@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-08-10media: atomisp: csi2-bridge: Add support for VCM I2C-client instantiationHans de Goede
Fill sensor->vcm_type and call intel_cio2_bridge_instantiate_vcm() from the v4l2-async bound op so that an I2C-client will be instatiated for the VCM. Note unfortunately on atomisp the _DSM to get the VCM type sometimes returns a VCM even though there is none. Since VCMs are typically only used together with certain sensors, work around this by adding a vcm field to atomisp_sensor_config and only check for a VCM when that is set. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-08-10media: atomisp: csi2-bridge: Add dev_name() to acpi_handle_info() loggingHans de Goede
acpi_handle_info() uses the ACPI path to the handle as prefix for messages e.g. : "\_SB_.I2C2.CAM8". This makes it hard for users to figure out which csi2-bridge messages belong to which sensor since the actual sensor drivers uses the ACPI device name (typically "HID:00") for logging. Extend the acpi_handle_info() (and err and warn) logging to also log the device name to make it easier to match csi2-bridge messages with sensor driver log messages. Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-08-10media: atomisp: csi2-bridge: Switch to new common ipu_bridge_init()Hans de Goede
Remove the duplicate IPU ACPI bridge code and use the new shared ipu_bridge_init() functionality. Note this will also use / assume v4l2-async device instantiation for ov5693 sensors on atomisp devices since ipu_supported_sensors[] already contains a match for this. This is fine since recent atomisp improvements allow the atomisp code to work with generic v4l2 sensor drivers and using an unmodified drivers/media/i2c/ov5693.c has been successfully tested on an Acer Iconia W4 820 tablet with an ISP2400 + OV5693 sensor. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-08-10media: ipu-bridge: Add a runtime-pm device-link between VCM and sensorHans de Goede
In most cases when a VCM is used there is a single integrated module with the sensor + VCM + lens. This means that the sensor and VCM often share regulators and possibly also something like a powerdown pin. In the ACPI tables this is modelled as a single ACPI device with multiple I2cSerialBus resources. On atomisp devices the regulators and clks are modelled as ACPI power-resources, which are controlled by the (ACPI) power state of the sensor. So the sensor must be in D0 power state for the VCM to work. To make this work add a device-link with DL_FLAG_PM_RUNTIME flag so that the sensor will automatically be runtime-resumed whenever the VCM is runtime-resumed. This requires the probing of the VCM and thus the creation of the VCM I2C-client to be delayed till after the sensor driver has bound. Move the instantiation of the VCM I2C-client to the v4l2_async_notifier bound op, so that it is done after the sensor driver has bound; and add code to add the device-link. This fixes the problem with the shared ACPI power-resources on atomisp2 and this avoids the need for VCM related workarounds on IPU3 / IPU6. E.g. until now the dw9719 driver needed to get and control a Vsio (V sensor IO) regulator since that needs to be enabled to enable I2C pass-through on the PMIC on the sensor module. So the driver was controlling this regulator even though the actual dw9719 chip has no Vsio pin / power-plane. This also removes the need for ipu_bridge_init() to return -EPROBE_DEFER since the VCM is now instantiated later. Reviewed-by: Andy Shevchenko <andy@kernel.org> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Tested-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-08-10media: ipu-bridge: Add GalaxyCore GC0310 to ipu_supported_sensors[]Hans de Goede
The GalaxyCore GC0310 is used together with the atomisp on various devices, add it to ipu_supported_sensors[]. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-08-10media: ipu-bridge: Move ipu-bridge.h to include/media/Hans de Goede
Move ipu-bridge.h to include/media/, so that it can also be used by the atomisp code. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-29 17:55:12 +0000