- 26 Dec, 2021 13 commits
-
-
Bharat Jauhari authored
In case of device reset, the driver does a force trigger on all waiting users to release them from waiting. However, the driver does not handle error scenario while waiting. hl_interrupt_wait_ioctl() now exits the wait in case of an error with abort status. Signed-off-by:
Bharat Jauhari <bjauhari@habana.ai> Reviewed-by:
Oded Gabbay <ogabbay@kernel.org> Signed-off-by:
-
Ohad Sharabi authored
Once we read indication of whether f/w is doing the reset, we don't want to clear it, until the next time we read this indication. Otherwise, we might be in a state of wrong indication. Signed-off-by:
Ohad Sharabi <osharabi@habana.ai> Reviewed-by:
-
Ohad Sharabi authored
Using a variable poll interval for fw loading allows us to support much slower environments (emulation) while changing only a single line in the code, instead of choosing a different interval in each function that polls. Signed-off-by:
-
Ohad Sharabi authored
Up until now the driver stored indication if Linux was loaded on the device CPU. This was needed in order to coordinate some tasks that are performed by the Linux. In future ASICs, many of those tasks will be performed by the boot fit, so now we need the same indication of boot fit load status. Signed-off-by:
-
Yuri Nudelman authored
The PCI MMU cache is two layered. The upper layer, memcache, uses cache lines, the bottom layer doesn't. Hence, after PMMU map operation we have to invalidate memcache, to avoid the situation where the new entry is already in the cache due to its cache line being fully in the cache. However, we do not have to invalidate the lower cache, and here we can optimize, since cache invalidation is time consuming. Signed-off-by:
Yuri Nudelman <ynudelman@habana.ai> Reviewed-by:
-
Yuri Nudelman authored
The enum vm_type was abused, used once as a value (indication memory type for map) and once as a flag (for cache invalidation). This makes it hard to add new and still keep it meaningful, hence it is better to split into one enum for values and one for flags. Signed-off-by:
-
Yuri Nudelman authored
Currently LAST_MASK is a global, but really it is an MMU implementation specific. We need this change for future ASICs. Signed-off-by:
-
Yuri Nudelman authored
VA blocks are currently stored in an inconsistent way. Sometimes block end is inclusive, sometimes exclusive. This leads to wrong size calculations in certain cases, plus could lead to a segmentation fault in case mapping process fails in the middle and we try to roll it back. Need to make this consistent - start inclusive till end inclusive. For example, the regions table may now look like this: 0x0000 - 0x1fff : allocated 0x2000 - 0x2fff : free 0x3000 - 0x3fff : allocated Signed-off-by: -
Guy Zadicario authored
Do not use a dma channel for debugfs requested transfer if it's QM is not idle. Signed-off-by:
Guy Zadicario <gzadicario@habana.ai> Reviewed-by:
-
Ohad Sharabi authored
The boot status flag "SRAM available" can be set by f/w Linux (in the general case) or by f/w uboot (in some specific debug scenario) but never by f/w preboot. Hence, when polling the boot status flags in the preboot stage we do not want to poll on "SRAM Avialable". The special case in which uboot set this flag is when we are running special debug scenario without Linux. In this case, at some point during the boot, the uboot relocates its code to the DRAM and then set the specified flag. Signed-off-by:
-
Yuri Nudelman authored
VA range info could assist in debugging VA allocation bugs. Signed-off-by:
-
Oded Gabbay authored
There are rare cases where the device CPU's watchdog has expired and as a result, the watchdog reset has happened and the CPU will now move to running its preboot f/w. When that happens, the driver will only know that a heartbeat failure occurred. As a result, the driver will send a message to the CPU's main f/w asking it to reset the device, but because the CPU is now running preboot, it won't respond and the re-initialization process will later fail when trying to load the f/w. The solution is to send the request to the preboot as well, only if the reset was caused because of HB failure. Signed-off-by: -
Ohad Sharabi authored
In the dynamic FW load protocol the boot status is updated to "Ready to Boot" once uboot is active. Polling on other boot status values is a residue of code duplication from the static protocol and should be removed. Signed-off-by:
-
- 22 Dec, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Merge tag 'iio-for-5.17a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next Jonathan writes: 1st set of IIO new device support, features and cleanup for 5.17 Includes some fixes that were either late breaking, low priority or complex enough to not be good to rush in late in the cycle. Tree rebased today to fix up some trivial issues + pull in a fix that was previously on the fixes-togreg branch. Vast majority have been in linux-next for some time now. New device support * adi,ad7293 - New driver and bindings for this Power Amplifier drain current controller. A complex device with various related monitoring functions. * adi,ad75513R - New driver and bindings for this combined ADC and DAC device. - A few follow up fixes. * adi,admv8818 - New driver (and type) for this 2-18GHz filter device. Includes bindings and ABI documentation to allow clk_notifier based auto adjustment of the filters in appropriate applications. * liteon,ltr501 - Support for the ltr303. ID and chip specific info table. * xilinx,ams - New generic firmware function fwnode_iomap() as used in this driver. - New driver and bindings for this ADC and on-chip sensors as found in various Xilinx devices. Core * Introduced IIO_VAL_INT_64 which uses val and val2 in IIO callbacks to form a 64 bit integer when higher precision needed. * Allow IIO_ENUM_AVAILABLE to be used with different shared values. * Fix a long term issue with scheduling whilst atomic when iio_trig_poll() is called but no trigger consumers are actually enabled and hence the trigger may be reenabled from the interrupt handler. Seen in the wild on the tsc2046. * Mark iio_device_type const. * buffer: Use a separate index variable to simplify code. * buffer-dma: Clear out unused struct iio_buffer_block * buffer-dmaengine: Switch to cheaper round_down() as power of 2 values. Tests/tools * format_value - Check against NULL returns from allocations in tests. - Add IIO_VAL_INT_64 test case. * event_monitor - Flush the output after event to given more consistent latency when tool output piped to other programs. Driver Features * axp20x - Add support for NTC thermistor channel and document TS pin binding. * arm,scmi - Add reading of raw channel values (using IIO_VAL_INT_64) * liteon,ltr501 - Add proximity-near-level support and dt-binding. Tree wide cleanup * Remove no-op trigger ops from multiple drivers. * Stop using dev_get_drvdata() on the iio_dev->dev in various drivers and then stop assigning it to allow this to be used for other purposes. We can always get to the indio_dev using dev_to_iio_dev() which is a container_of() based approach. Also cleanup up some related unnecessary convoluted cases. - atmel,at91-sam5d2 - nxp,imx7d - meas,ms5611 - st,st_sensors * Where available (or easy to introduce) use the scan_type.* values in place of a second copy for read_raw and similar paths. - adi,ad7266 - bosch,bma220 - fsl,mac3110 - fsl,mma7455 - fsl,mpl3115 - kionix,kcjk-1013 - sensortek,stk8ba50 - sensortek,stk8312 - ti,adc12138 - ti,ads1015 - vti,sca3000 - xilinx,xadc-core * Switch drives over to generic firmware properties including appropriate header changes to avoid including of.h - Various DACs had false CONFIG_OF dependencies. - dpot-dac - envelope-detector - adi,ad5755 - adi,ad5758 - capella,cm3605 - maxim,max9611 - microchip,mcp41010 - microchip,mcp3911 - ti,adc12138 * Trivial clang warning fixes for W=1 warnings. Driver specific cleanup and minor fixes * adi,ad7606 - Comment fixes. * ams,ad3935 - Drop pointless cast to the same type. * atmel,at91-sama5d2 - Fix wrong cast of iio_dev->dev to platform_device that happened to be harmless. * fsl,mma7660 - Stop i2c remove() function returning an error code. Part of a rework to eventually stop returning anything from these. * fsl,mma8452 - Use correct type for local irqreturn_t. * nxp,imx8mq - Maintainer email address update. * nxp,lpc18xx_adc - Ensure clk_prepare_enable() called before clk_get_rate(). - Switch of.h for mod_devicetable.h to reflect no of specific functions, just the id table. * renesas,rzg2l - Drop a dev_err() that just duplicates error printed in platform_get_irq() * sgx,vz89x - Drop pointless cast. * st,lsm6dsx - Make it possible to disable the sensorhub from DT to avoid a corner case where the address of a slave device many be accidentally modified. * st,stm32-adc - Stop leaking an of_node in an error path. * st,stmp2 - Avoid wrong sized type for bit field which could result in over-reading (harmless). Precursor to enabling -Warray-bounds. * ti,adc081c - Put back some ACPI support for non standards compliant ADC081C ID because it is known to be in the wild on some Aaeon boards. * ti,ads8688 - Cleanup redundant local ret variable assignment. * ti,ina2xx-adc - Use helper macro kthread_run() to replace some boilerplate. - Avoid double reference counting. - Drop pointless cast. * xilinx,xadc - Make the IRQ optional as not always wired to the host system. * tag 'iio-for-5.17a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (103 commits) iio: adc: ti-adc081c: Partial revert of removal of ACPI IDs iio:addac:ad74413r: Fix uninitialized ret in a path that won't be hit. MAINTAINERS: Add maintainer for xilinx-ams dt-bindings: iio: adc: Add Xilinx AMS binding documentation iio: adc: Add Xilinx AMS driver device property: Add fwnode_iomap() iio:accel:kxcjk-1013: Mark struct __maybe_unused to avoid warning. iio:accel:bmc150: Mark structure __maybe_unused as only needed with for pm ops. iio:dummy: Drop set but unused variable len. iio:magn:ak8975: Suppress clang W=1 warning about pointer to enum conversion. iio:imu:inv_mpu6050: Suppress clang W=1 warning about pointer to enum conversion. iio:imu:inv_icm42600: Suppress clang W=1 warning about pointer to enum conversion. iio:dac:mcp4725: Suppress clang W=1 warning about pointer to enum conversion. iio:amplifiers:hmc425a: Suppress clang W=1 warning about pointer to enum conversion. iio:adc:ti-ads1015: Suppress clang W=1 warning about pointer to enum conversion. iio:adc:rcar: Suppress clang W=1 warning about pointer to enum conversion. iio:adc:ina2xx-adc: Suppress clang W=1 warning about pointer to enum conversion. iio:accel:bma180: Suppress clang W=1 warning about pointer to enum conversion. drivers:iio:dac: Add AD3552R driver support dt-bindings: iio: dac: Add adi,ad3552r.yaml ...
-
- 21 Dec, 2021 26 commits
-
-
Jonathan Cameron authored
Unfortuanately a non standards compliant ACPI ID is known to be in the wild on some AAEON boards. Partly revert the removal of these IDs so that ADC081C will again work + add a comment to that affect for future reference. Whilst here use generic firmware properties rather than the ACPI specific handling previously found in this driver. Reported-by:
Kunyang Fan <Kunyang_Fan@aaeon.com.tw> Fixes: c458b7ca ("iio:adc:ti-adc081c: Drop ACPI ids that seem very unlikely to be official.") Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Kunyang Fan <Kunyang_Fan@aaeon.com.tw> #UP-extremei11 Link: https://lore.kernel.org/r/20211205172728.2826512-1-jic23@kernel.org Cc: <Stable@vger.kernel.org>
-
Jonathan Cameron authored
I don't believe it's possible to hit this, because we drop out of __iio_update_buffers() earlier in the event of an empty list. However, that is not visible to the compiler so lets return an error if we do hit the loop with an empty bitmask. Fixes: 5d97d9e9 ("iio: addac: ad74413r: fix off by one in ad74413r_parse_channel_config()") Signed-off-by:
-
Anand Ashok Dumbre authored
Add maintaner entry for xilinx-ams driver. Signed-off-by:
Anand Ashok Dumbre <anand.ashok.dumbre@xilinx.com> Link: https://lore.kernel.org/r/20211203212358.31444-6-anand.ashok.dumbre@xilinx.comSigned-off-by:
-
Anand Ashok Dumbre authored
Xilinx AMS have several ADC channels that can be used for measurement of different voltages and temperatures. Document the same in the bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211203212358.31444-5-anand.ashok.dumbre@xilinx.comSigned-off-by:
-
Anand Ashok Dumbre authored
The AMS includes an ADC as well as on-chip sensors that can be used to sample external voltages and monitor on-die operating conditions, such as temperature and supply voltage levels. The AMS has two SYSMON blocks. PL-SYSMON block is capable of monitoring off chip voltage and temperature. PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring from an external master. Out of these interfaces currently only DRP is supported. Other block PS-SYSMON is memory mapped to PS. The AMS can use internal channels to monitor voltage and temperature as well as one primary and up to 16 auxiliary channels for measuring external voltages. The voltage and temperature monitoring channels also have event capability which allows to generate an interrupt when their value falls below or raises above a set threshold. Co-developed-by:
Manish Narani <manish.narani@xilinx.com> Signed-off-by:
-
Anand Ashok Dumbre authored
This patch introduces a new helper routine - fwnode_iomap(), which allows to map the memory mapped IO for a given device node. This implementation does not cover the ACPI case and may be expanded in the future. The main purpose here is to be able to develop resource provider agnostic drivers. Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20211203212358.31444-2-anand.ashok.dumbre@xilinx.comSigned-off-by:
-
Jonathan Cameron authored
This structure is only used in PM ops, so may not be used depending on build configuration. Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211128172445.2616166-13-jic23@kernel.org
-
Jonathan Cameron authored
If CONFIG_PM not set then clang warns this structure is unused. Signed-off-by:
-
Jonathan Cameron authored
Not sure what the thinking was here, as lost to history, but the variable is clearly not used so get rid of it. Warning seen with clang W=1 tests (may be present with other compilers and build options). Signed-off-by:
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
-
Jonathan Cameron authored
Cast to a uintptr_t rather than directly to the enum. As per the discussion in below linked media patch. Link: https://lore.kernel.org/linux-media/CAK8P3a2ez6nEw4d+Mqa3XXAz0RFTZHunqqRj6sCt7Y_Eqqs0rw@mail.gmail.com/Signed-off-by:
-
Yang Guang authored
Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid opencoding it. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
David Yang <davidcomponentone@gmail.com> Signed-off-by:
Yang Guang <yang.guang5@zte.com.cn> Link: https://lore.kernel.org/r/cb14f9e6e86cf8494ed2ddce6eec8ebd988908d9.1640077704.git.yang.guang5@zte.com.cnSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
William Breathitt Gray authored
A bug exists if the user executes a COUNTER_ADD_WATCH_IOCTL ioctl call, and then executes a COUNTER_DISABLE_EVENTS_IOCTL ioctl call. Disabling the events should disable the 104-QUAD-8 interrupts, but because of this bug the interrupts are not disabling. The reason this bug is occurring is because quad8_events_configure() is called when COUNTER_DISABLE_EVENTS_IOCTL is handled, but the next_irq_trigger[] array has not been cleared before it is checked in the loop. This patch fixes the bug by removing the next_irq_trigger array and instead utilizing a different algorithm of walking the events_list list for the current requested events. When a COUNTER_DISABLE_EVENTS_IOCTL is handled, events_list will be empty and thus all device channels end up with interrupts disabled. Fixes: 7aa2ba0d ("counter: 104-quad-8: Add IRQ support for the ACCES 104-QUAD-8") Cc: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/5fd5731cec1c251acee30eefb7c19160d03c9d39.1640072891.git.vilhelm.gray@gmail.comSigned-off-by:
-
Uwe Kleine-König authored
Using counter->priv is a memory read and so more expensive than container_of which is only an addition. (In this case even a noop because the offset is 0.) So container_of is expected to be a tad faster, it's type-safe, and produces smaller code (ARCH=arm allmodconfig): $ source/scripts/bloat-o-meter drivers/counter/ti-eqep.o-pre drivers/counter/ti-eqep.o add/remove: 0/0 grow/shrink: 0/9 up/down: 0/-108 (-108) Function old new delta ti_eqep_position_enable_write 132 120 -12 ti_eqep_position_enable_read 260 248 -12 ti_eqep_position_ceiling_write 132 120 -12 ti_eqep_position_ceiling_read 236 224 -12 ti_eqep_function_write 220 208 -12 ti_eqep_function_read 372 360 -12 ti_eqep_count_write 312 300 -12 ti_eqep_count_read 236 224 -12 ti_eqep_action_read 664 652 -12 Total: Before=4598, After=4490, chg -2.35% Acked-by:
David Lechner <david@lechnology.com> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Yanteng Si authored
Since commit aaec1a0f ("counter: Internalize sysfs interface code") introduce a warning as: linux-next/Documentation/driver-api/generic-counter:234: ./include/linux/counter.h:43: WARNING: Unexpected indentation. linux-next/Documentation/driver-api/generic-counter:234: ./include/linux/counter.h:45: WARNING: Block quote ends without a blank line; unexpected unindent. Add the necessary colons and indents. Fixes: aaec1a0f ("counter: Internalize sysfs interface code") Signed-off-by:
Yanteng Si <siyanteng@loongson.cn> Signed-off-by:
-
Rob Herring authored
With 'unevaluatedProperties' support implemented, the following warnings are generated in the nvmem examples: Documentation/devicetree/bindings/nvmem/st,stm32-romem.example.dt.yaml: efuse@1fff7800: Unevaluated properties are not allowed ('reg' was unexpected) Documentation/devicetree/bindings/nvmem/rmem.example.dt.yaml: nvram@10000000: Unevaluated properties are not allowed ('reg' was unexpected) Documentation/devicetree/bindings/nvmem/brcm,nvram.example.dt.yaml: nvram@1eff0000: Unevaluated properties are not allowed ('reg' was unexpected) Add the missing 'reg' property definition. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Rafał Miłecki <rafal@milecki.pl> Cc: Saenz Julienne <nsaenzjulienne@suse.de> Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-arm-kernel@lists.infradead.org Reviewed-by:Fabrice Gasnier <fabrice.gasnier@foss.st.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211209174235.14049-5-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Chunfeng Yun authored
In order to support nvmem bits property, should support minimum 1 byte read stride and minimum 1 byte read granularity at the same time. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by:
-
Chunfeng Yun authored
Add compatible for mt8195 Acked-by:
-
Chunfeng Yun authored
Add support bits property, will satisfy more consumers. Acked-by:
-
Minghao Chi authored
Return value from ocxl_context_attach() directly instead of taking this in another redundant variable. Reported-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20211215060438.441918-1-chi.minghao@zte.com.cnSigned-off-by:
-
