- Sep 20, 2022
-
-
Pierre-Louis Bossart authored
Simplify signature before further code reshuffling. Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Rander Wang <rander.wang@intel.com> Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220919175721.354679-6-yung-chuan.liao@linux.intel.com Signed-off-by:
Vinod Koul <vkoul@kernel.org>
-
Pierre-Louis Bossart authored
Start regrouping functionality in high-level functions. Signed-off-by:
-
Pierre-Louis Bossart authored
These two steps can and should be done before starting up the clock and the bus operation. This is a first step before re-grouping functionality in well-defined callbacks. Signed-off-by:
-
Pierre-Louis Bossart authored
We already use devm_ for memory allocation but not for component/DAI registration. The resource management can be based on devm_ in all cases. Signed-off-by:
-
Pierre-Louis Bossart authored
The call to intel_register_dai() may fail because of memory allocation issues or problems reported by the ASoC core. In all cases, when a error is thrown the component is not registered, it's invalid to unregister it. Signed-off-by:
-
Richard Fitzgerald authored
There's no need to goto an exit label to return from cdns_xfer_msg(). It doesn't do any cleanup, only a return statement. Replace the gotos with returns. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Reviewed-by:
-
Richard Fitzgerald authored
_cdns_xfer_msg() returns an sdw_command_response value, not a negative error code. Signed-off-by:
-
Richard Fitzgerald authored
_cdns_xfer_msg() must add the fragment offset to msg->addr to get the base target address of each FIFO chunk. Otherwise every chunk will be written to the first 32 register addresses. Signed-off-by:
-
Richard Fitzgerald authored
for_each_set_bit() gives the bit-number counting from 0 (LSbit==0). When processing INTSTAT2, bit 0 is DP4 so the port number is (bit + 4). Likewise for INTSTAT3 bit 0 is DP11 so port number is (bit + 11). Signed-off-by:
-
Srinivas Kandagatla authored
Device0 can not be in alert status. And for consistency reasons do not send status of device0 to core. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by:
-
Srinivas Kandagatla authored
By default autoenumeration is enabled on QCom SoundWire controller which means the core should not be dealing with device 0 w.r.t enumeration. During Enumeration if SoundWire core sees status[0] as SDW_SLAVE_ATTACHED and start programming the device id, however reading DEVID registers return zeros which does not match to any of the slaves in the list and the core attempts to park this device to Group 13. This results in adding SoundWire device with enumeration address 0:0:0:0 Fix this by not passing device 0 status to SoundWire core. Signed-off-by:
-
Richard Fitzgerald authored
The buf passed in struct sdw_msg must only be written for a READ, in that case the RDATA part of the response is the data value of the register. For a write command there is no RDATA, and buf should be assumed to be const and unmodifable. The original caller should not expect its data buffer to be corrupted by an sdw_nwrite(). Signed-off-by:
-
Richard Fitzgerald authored
Only exit sdw_handle_slave_status() right after calling sdw_program_device_num() if it actually programmed an ID into at least one device. sdw_handle_slave_status() should protect itself against phantom device #0 ATTACHED indications. In that case there is no actual device still on #0. The early exit relies on there being a status change to ATTACHED on the reprogrammed device to trigger another call to sdw_handle_slave_status() which will then handle the status of all peripherals. If no device was actually programmed with an ID there won't be a new ATTACHED indication. This can lead to the status of other peripherals not being handled. The status passed to sdw_handle_slave_status() is obviously always from a point of time in the past, and may indicate accumulated unhandled events (depending how the bus manager operates). It's possible that a device ID is reprogrammed but the last PING status captured state just before that, when it was still reporting on ID #0. Then sdw_handle_slave_status() is called with this PING info, just before a new PING status is available showing it now on its new ID. So sdw_handle_slave_status() will receive a phantom report of a device on #0, but it will not find one. Signed-off-by:
-
Richard Fitzgerald authored
The correct way to handle interrupts is to clear the bits we are about to handle _before_ handling them. Thus if the condition then re-asserts during the handling we won't lose it. This patch changes cdns_update_slave_status_work() to do this. The previous code cleared the interrupts after handling them. The problem with this is that when handling enumeration of devices the ATTACH statuses can be accidentally cleared and so some or all of the devices never complete their enumeration. Thus we can have a situation like this: - one or more devices are reverting to ID #0 - accumulated status bits indicate some devices attached and some on ID #0. (Remember: status bits are sticky until they are handled) - Because of device on #0 sdw_handle_slave_status() programs the device ID and exits without handling the other status, expecting to get an ATTACHED from this reprogrammed device. - The device immediately starts reporting ATTACHED in PINGs, which will assert its CDNS_MCP_SLAVE_INTSTAT_ATTACHED bit. - cdns_update_slave_status_work() clears INTSTAT0/1. If the initial status had CDNS_MCP_SLAVE_INTSTAT_ATTACHED bit set it will be cleared. - The ATTACHED change for the device has now been lost. - cdns_update_slave_status_work() clears CDNS_MCP_INT_SLAVE_MASK so if the new ATTACHED state had set it, it will be cleared without ever having been handled. Unless there is some other state change from another device to cause a new interrupt, the ATTACHED state of the reprogrammed device will never cause an interrupt so its enumeration will not be completed. Signed-off-by:
-
Richard Fitzgerald authored
Don't re-enumerate a peripheral on #0 until we have seen and handled an UNATTACHED notification for that peripheral. Without this, it is possible for the UNATTACHED status to be missed and so the slave->status remains at ATTACHED. If slave->status never changes to UNATTACHED the child driver will never be notified of the UNATTACH, and the code in sdw_handle_slave_status() will skip the second part of enumeration because the slave->status has not changed. This scenario can happen because PINGs are handled in a workqueue function which is working from a snapshot of an old PING, and there is no guarantee when this function will run. A peripheral could report attached in the PING being handled by sdw_handle_slave_status(), but has since reverted to device #0 and is then found in the loop in sdw_program_device_num(). Previously the code would not have updated slave->status to UNATTACHED because it had not yet handled a PING where that peripheral had UNATTACHED. This situation happens fairly frequently with multiple peripherals on a bus that are intentionally reset (for example after downloading firmware). Signed-off-by:
-
Richard Fitzgerald authored
Ensure that if sdw_handle_slave_status() sees a peripheral has dropped off the bus it reports it to the client driver. If there are any devices reporting on address 0 it bails out after programming the device IDs. So it never reaches the second loop that calls sdw_update_slave_status(). If the missing device is one that is now showing as unenumerated it has been given a device ID so will report as attached next time sdw_handle_slave_status() runs. With the previous code the client driver would only see another ATTACHED notification because the UNATTACHED state was lost when sdw_handle_slave_status() bailed out after programming the device ID. This shows up most when the peripheral has to be reset after downloading updated firmware and there are multiple of these peripherals on the bus. They will all return to unenumerated state after the reset, and then there is a mix of unattached, attached and unenumerated PING states from the peripherals, as each is reset and they reboot. Signed-off-by:
-
Simon Trimmer authored
The cadence IP explicitly reports slave status changes with bits for each possible change. The function cdns_update_slave_status() attempts to translate this into the current status of each of the slaves. However when there are multiple peripherals on a bus any slave that did not have a status change when the work function ran would not have it's status updated - the array is initialised to a value that equates to UNATTACHED and this can cause spurious reports that slaves had dropped off the bus. In the case where a slave has no status change or has multiple status changes the value from the last PING command is used. Signed-off-by:
Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by:
-
- Sep 01, 2022
-
-
Pierre-Louis Bossart authored
Regroup offset and bitfield definitions. Signed-off-by:
-
Pierre-Louis Bossart authored
Regroup offset and bitfield definitions Signed-off-by:
-
Pierre-Louis Bossart authored
Regroup offset and bitfield definitions. Signed-off-by:
-
Pierre-Louis Bossart authored
Regroup offset and bitfield definitions. Signed-off-by:
-
Pierre-Louis Bossart authored
Regroup offset and bitfields Signed-off-by:
-
Pierre-Louis Bossart authored
add comment and newline to mark out control stream capabilities and chmap. These registers are unused by the driver, only dumped in debugfs. Signed-off-by:
-
Pierre-Louis Bossart authored
We removed PDM support a long time ago but kept the definitions. Signed-off-by:
-
Pierre-Louis Bossart authored
Regroup offset and bitfields, no functionality change Signed-off-by:
-
Pierre-Louis Bossart authored
This read-only register only defines an offset which is known already and a version which isn't used. Remove unused definition. Signed-off-by:
-
Pierre-Louis Bossart authored
No functionality change, just regroup offset and bitfield definitions. Signed-off-by:
-
Pierre-Louis Bossart authored
Add definition in header file rather than hidden in code. Signed-off-by:
-
- Aug 30, 2022
-
-
Pierre-Louis Bossart authored
The allowed values for SoundWire device numbers are between 1 and 11 (inclusive). HDaudio/iDISP codecs typically use SDI values 0..3 (inclusive). To allow for a unique peripheral SDI/dev_number across HDaudio and SoundWire buses, we set the minimum base to 4. This still allows for 8 SoundWire peripherals in the system, currently more than needed in actual products. Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by:
-
Pierre-Louis Bossart authored
The SoundWire specification allows the device number to be allocated at will. When a system includes multiple SoundWire links, the device number scope is limited to the link to which the device is attached. However, for integration/debug it can be convenient to have a unique device number across the system. This patch adds a 'dev_num_ida_min' field at the bus level, which when set will be used to allocate an IDA. The allocation happens when a hardware device reports as ATTACHED. If any error happens during the enumeration, the allocated IDA is not freed - the device number will be reused if/when the device re-joins the bus. The IDA is only freed when the Linux device is unregistered. Signed-off-by:
-
Pierre-Louis Bossart authored
To avoid confusions with follow-up patches using a IDA mechanism for peripheral 'device number' allocation, rename sdw_ida as sdw_bus_ida. Pure rename, no functionality change. Signed-off-by:
-
- Aug 24, 2022
-
-
Pierre-Louis Bossart authored
The module and function information can be added with 'modprobe foo dyndbg=+pmf' Suggested-by:
Greg KH <gregkh@linuxfoundation.org> Signed-off-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by:
-
Pierre-Louis Bossart authored
The module and function information can be added with 'modprobe foo dyndbg=+pmf' Suggested-by:
-
Pierre-Louis Bossart authored
The DSDT for this device has a number of problems: a) it lists rt711 on link0 and link1, but link1 is disabled b) the rt711 entry on link0 uses the wrong v2 instead of v3 (SDCA) c) the rt1316 amplifier on link3 is not listed. Add a remapping table to work-around these BIOS shenanigans. BugLink: https://github.com/thesofproject/sof/issues/5955 Signed-off-by:
-
Khalid Masum authored
The capabilities enabled for multi-link are required as part of the programming sequences, even when a stream uses a single link we still use the syncArm/syncGo sequences. Therefore the TODO is no longer necessary. Suggested-by:
Khalid Masum <khalid.masum.92@gmail.com> Link: https://lore.kernel.org/r/20220817074859.4759-1-khalid.masum.92@gmail.com Signed-off-by:
-
Srinivasa Rao Mandadapu authored
Update error prints to debug prints to avoid redundant logging in kernel boot time, as these prints are informative prints in irq handler. Signed-off-by:
Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Reviewed-by:
Andrew Halaney <ahalaney@redhat.com> Reviewed-by:
-
- Aug 15, 2022
-
-
Linus Torvalds authored
-
Yury Norov authored
Radix tree header includes gfp.h for __GFP_BITS_SHIFT only. Now we have gfp_types.h for this. Fixes powerpc allmodconfig build: In file included from include/linux/nodemask.h:97, from include/linux/mmzone.h:17, from include/linux/gfp.h:7, from include/linux/radix-tree.h:12, from include/linux/idr.h:15, from include/linux/kernfs.h:12, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/pci.h:35, from arch/powerpc/kernel/prom_init.c:24: include/linux/random.h: In function 'add_latent_entropy': >> include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'? 25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy)); | ^~~~~~~~~~~~~~ | add_latent_entropy include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in Reported-by:kernel test robot <lkp@intel.com> CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Yury Norov <yury.norov@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs lseek fix from Al Viro: "Fix proc_reg_llseek() breakage. Always had been possible if somebody left NULL ->proc_lseek, became a practical issue now" * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: take care to handle NULL ->proc_lseek()
-
Al Viro authored
Easily done now, just by clearing FMODE_LSEEK in ->f_mode during proc_reg_open() for such entries. Fixes: 868941b1 "fs: remove no_llseek" Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
