- 09 Jun, 2017 14 commits
-
-
Mika Westerberg authored
We will be forwarding notifications received from the control channel to the connection manager implementations. This way they can decide what to do if anything when a notification is received. To be able to use control channel messages from other files, move them to tb_msgs.h. No functional changes intended. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Yehezkel Bernat <yehezkel.bernat@intel.com> Reviewed-by:
Michael Jamet <michael.jamet@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Andreas Noever <andreas.noever@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mika Westerberg authored
The device DROM contains name of the vendor and device among other things. Extract this information and expose it to the userspace via two new attributes. Signed-off-by:
-
Lukas Wunner authored
Currently tb_drom_parse_entry() is only able to parse drom entries of type TB_DROM_ENTRY_PORT. Rename it to tb_drom_parse_entry_port(). Fold tb_drom_parse_port_entry() into it. Its return value is currently ignored. Evaluate it and abort parsing on error. Change tb_drom_parse_entries() to accommodate for parsing of other entry types than TB_DROM_ENTRY_PORT. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Mika Westerberg authored
There are devices out there where CRC32 of the DROM is not correct. One reason for this is that the ICM firmware does not validate it and it seems that neither does the Apple driver. To be able to support such devices we continue parsing the DROM contents regardless of whether CRC32 failed or not. We still keep the warning there. Signed-off-by:
-
Mika Westerberg authored
All non-root switches are expected to have DROM so if the operation fails, it might be due the user unlugging the device. There is no point continuing adding the switch further in that case. Just bail out. For root switches (hosts) the DROM is either retrieved from a EFI variable, NVM or hard-coded. Signed-off-by:
-
Mika Westerberg authored
Thunderbolt domain consists of switches that are connected to each other, forming a bus. This will convert each switch into a real Linux device structure and adds them to the domain. The advantage here is that we get all the goodies from the driver core, like reference counting and sysfs hierarchy for free. Also expose device identification information to the userspace via new sysfs attributes. In order to support internal connection manager (ICM) we separate switch configuration into its own function (tb_switch_configure()) which is only called by the existing native connection manager implementation used on Macs. Signed-off-by:
-
Mika Westerberg authored
Thunderbolt fabric consists of one or more switches. This fabric is called domain and it is controlled by an entity called connection manager. The connection manager can be either internal (driven by a firmware running on the host controller) or external (software driver). This driver currently implements support for the latter. In order to manage switches and their properties more easily we model this domain structure as a Linux bus. Each host controller adds a domain device to this bus, and these devices are named as domainN where N stands for index or id of the current domain. We then abstract connection manager specific operations into a new structure tb_cm_ops and convert the existing tb.c to fill those accordingly. This makes it easier to add support for the internal connection manager in subsequent patches. Signed-off-by:
-
Mika Westerberg authored
Following the usual pattern used in many places, we allow passing NULL pointer to tb_ctl_free(). Then the user can call the function regardless if it has allocated control channel or not making the code bit simpler. Suggested-by:
-
Mika Westerberg authored
Organization of the capabilities in switches and ports is not so random after all. Rework the capability handling functionality so that it follows how capabilities are organized and provide two new functions (tb_switch_find_vse_cap() and tb_port_find_cap()) which can be used to extract capabilities for ports and switches. Then convert the current users over these. Signed-off-by:
-
Mika Westerberg authored
Intel Thunderbolt controllers support up to 16 MSI-X vectors. Using MSI-X is preferred over MSI or legacy interrupt and may bring additional performance because there is no need to check the status registers which interrupt was triggered. While there we convert comments in structs tb_ring and tb_nhi to follow kernel-doc format more closely. This code is based on the work done by Amir Levy and Michael Jamet. Signed-off-by:
-
Mika Westerberg authored
DROM version 2 is compatible with the previous generation so no need to warn about that. Signed-off-by:
-
Mika Westerberg authored
At least Falcon Ridge when in host mode does not have any kind of DROM available and reading DROM offset returns 0 for these. Do not try to read DROM any further in that case. Signed-off-by:
-
Mika Westerberg authored
The root switch is part of the host controller and cannot be physically removed, so there is no point of reading UID again on resume in order to check if the root switch is still the same. Suggested-by:
-
Mika Westerberg authored
These functions should not (and do not) modify the argument in any way so make it const. Signed-off-by:
-
- 03 Jun, 2017 26 commits
-
-
Philipp Zabel authored
This adds a driver for mmio-based syscon multiplexers controlled by bitfields in a syscon register range. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Philipp Zabel authored
This adds device tree binding documentation for mmio-based syscon multiplexers controlled by a bitfields in a syscon register range. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peter Rosin authored
Analog Devices ADG792A/G is a triple 4:1 mux. Reviewed-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Peter Rosin authored
Analog Devices ADG792A/G is a triple 4:1 mux. Acked-by:
-
Peter Rosin authored
This is a general purpose i2c mux that uses a multiplexer controlled by the multiplexer subsystem to do the muxing. The user can select if the mux is to be mux-locked and parent-locked as described in Documentation/i2c/i2c-topology. Acked-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Peter Rosin authored
Describe how a general purpose multiplexer controller is used to mux an i2c bus. Acked-by:
-
Peter Rosin authored
When a multiplexer changes how an iio device behaves (for example by feeding different signals to an ADC), this driver can be used to create one virtual iio channel for each multiplexer state. Depends on the generic multiplexer subsystem. Cache any ext_info values from the parent iio channel, creating a private copy of the ext_info attributes for each multiplexer state/channel. Reviewed-by:
-
Peter Rosin authored
Describe how a multiplexer can be used to select which signal is fed to an io-channel. Acked-by:
-
Peter Rosin authored
Extend the inkern api with functions for reading and writing ext_info of iio channels. Acked-by:
-
Peter Rosin authored
The driver builds a single multiplexer controller using a number of gpio pins. For N pins, there will be 2^N possible multiplexer states. The GPIO pins can be connected (by the hardware) to several multiplexers, which in that case will be operated in parallel. Reviewed-by:
-
Peter Rosin authored
Add a new minimalistic subsystem that handles multiplexer controllers. When multiplexers are used in various places in the kernel, and the same multiplexer controller can be used for several independent things, there should be one place to implement support for said multiplexer controller. A single multiplexer controller can also be used to control several parallel multiplexers, that are in turn used by different subsystems in the kernel, leading to a need to coordinate multiplexer accesses. The multiplexer subsystem handles this coordination. Thanks go out to Lars-Peter Clausen, Jonathan Cameron, Rob Herring, Wolfram Sang, Paul Gortmaker, Dan Carpenter, Colin Ian King, Greg Kroah-Hartman and last but certainly not least to Philipp Zabel for helpful comments, reviews, patches and general encouragement! Reviewed-by:
-
Peter Rosin authored
Allow specifying that a single multiplexer controller can be used to control several parallel multiplexers, thus enabling sharing of the multiplexer controller by different consumers. Add a binding for a first mux controller in the form of a GPIO based mux controller. Acked-by:
-
Peter Rosin authored
Everything else is indented with two spaces, so fix the odd one out. Acked-by:
-
Robert Lippert authored
This driver enables the LPC snoop hardware on the ASPEED BMC which generates an interrupt upon every write to an I/O port by the host. This is typically used to monitor BIOS boot progress by listening to well-known debug port 80h. The functionality in this commit just saves all snooped values to a circular 2K buffer in the kernel, subsequent commits can act on the values to do things with them. Signed-off-by:
Robert Lippert <rlippert@google.com> Signed-off-by:
-
Arvind Yadav authored
clk_prepare_enable() can fail here and we must check its return value. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Kiran Gunda authored
Currently the SPMI interrupt will not wake the device. Enable this interrupt as a wakeup source. Signed-off-by:
Nicholas Troast <ntroast@codeaurora.org> Signed-off-by:
Kiran Gunda <kgunda@codeaurora.org> Signed-off-by:
-
Abhijeet Dharmapurikar authored
PMIC bus arbiter v3 supports 512 SPMI peripherals. Add the v3 operators to support this new arbiter version. Signed-off-by:
Abhijeet Dharmapurikar <adharmap@codeaurora.org> Signed-off-by:
-
Abhijeet Dharmapurikar authored
The driver currently invokes the apid handler (periph_handler()) once it sees that the summary status bit for that apid is set. However the hardware is designed to set that bit even if the apid interrupts are disabled. The driver should check whether the apid is indeed enabled before calling the apid handler. Signed-off-by:
-
Abhijeet Dharmapurikar authored
The current code uses handle_level_irq flow handler even if the trigger type of the interrupt is edge. This can lead to missing of an edge transition that happens when the interrupt is being handled. The level flow handler masks the interrupt while it is being handled, so if an edge transition happens at that time, that edge is lost. Use an edge flow handler for edge type interrupts which ensures that the interrupt stays enabled while being handled - at least until it triggers at which point the flow handler sets the IRQF_PENDING flag and only then masks the interrupt. That IRQF_PENDING state indicates an edge transition happened while the interrupt was being handled and the handler is called again. Signed-off-by:
-
Abhijeet Dharmapurikar authored
PMIC interrupts each have an internal latched status bit which is not visible from any register. This status bit is set as soon as the conditions specified in the interrupt type and polarity registers are met even if the interrupt is not enabled. When it is set, nothing else changes within the PMIC and no interrupt notification packets are sent. If the internal latched status bit is set when an interrupt is enabled, then the value is immediately propagated into the interrupt latched status register and an interrupt notification packet is sent out from the PMIC over SPMI. This PMIC hardware behavior can lead to a situation where the handler for a level triggered interrupt is called immediately after enable_irq() is called even though the interrupt physically triggered while it was disabled within the genirq framework. This situation takes place if the the interrupt fires twice after calling disable_irq(). The first time it fires, the level flow handler will mask and disregard it. Unfortunately, the second time it fires, the internal latched status bit is set within the PMIC and no further notification is received. When enable_irq() is called later, the interrupt is unmasked (enabled in the PMIC) which results in the PMIC immediately sending an interrupt notification packet out over SPMI. This breaks the semantics of level triggered interrupts within the genirq framework since they should be completely ignored while disabled. The PMIC internal latched status behavior also affects how interrupts are treated during suspend. While entering suspend, all interrupts not specified as wakeup mode are masked. Upon resume, these interrupts are unmasked. Thus if any of the non-wakeup PMIC interrupts fired while the system was suspended, then the PMIC will send interrupt notification packets out via SPMI as soon as they are unmasked during resume. This behavior violates genirq semantics as well since non-wakeup interrupts should be completely ignored during suspend. Modify the qpnpint_irq_unmask() function so that the interrupt latched status clear register is written immediately before the interrupt enable register. This clears the internal latched status bit of the interrupt so that it cannot trigger spuriously immediately upon being enabled. Also, while resuming an irq, an unmask could be called even if it was not previously masked. So, before writing these registers, check if the interrupt is already enabled within the PMIC. If it is, then no further register writes are required. This condition check ensures that a valid latched status register bit is not cleared until it is properly handled. Signed-off-by:
-
Abhijeet Dharmapurikar authored
irq_enable is called when the device resumes. Note that the irq_enable is called regardless of whether the interrupt was marked enabled/disabled in the descriptor or whether it was masked/unmasked at the controller while resuming. The current driver unconditionally clears the interrupt in its irq_enable callback. This is dangerous as any interrupts that happen right before the resume could be missed. Remove the irq_enable callback and use mask/unmask instead. Also remove struct pmic_arb_irq_spec as it serves no real purpose. It is used only in the translate function and the code is much cleaner without it. Signed-off-by:
-
Abhijeet Dharmapurikar authored
We see a unmapped irqs trigger right around bootup. This could likely be because the bootloader exited leaving the interrupts in an unknown or unhandled state. Ack and mask the interrupt if one is found. A request_irq later will unmask it and also setup proper mapping structures. Also the current driver ensures that no read/write transaction is in progress while it makes changes to the interrupt regions. This is not necessary because read/writes over spmi and arbiter interrupt control are independent operations. Hence, remove the synchronized accesses to interrupt region. Signed-off-by:
-
Abhijeet Dharmapurikar authored
The current driver uses a mix of radix tree and a fwd lookup table to translate between apid and ppid. It is buggy and confusing. Instead simply use a radix tree for v1 hardware and use the forward lookup table for v2. Signed-off-by:
-
Abhijeet Dharmapurikar authored
The driver currently uses "apid" and "chan" to mean apid. Remove the use of chan and use only apid. On a SPMI bus there is allocation to manage up to 4K peripherals. However, in practice only few peripherals are instantiated and only few among the instantiated ones actually interrupt. APID is CPU's way of keeping track of peripherals that could interrupt. There is a table that maps the 256 interrupting peripherals to a number between 0 and 255. This number is called APID. Information about that interrupting peripheral is stored in registers offset by its corresponding apid. Signed-off-by:
-
Abhijeet Dharmapurikar authored
Usually *_dev best used for structures that embed a struct device in them. spmi_pmic_arb_dev doesn't embed one. It is simply a driver data structure. Use an appropriate name for it. Also there are many places in the driver that left shift the bit to generate a bit mask. Replace it with the BIT() macro. Signed-off-by:
-
Abhijeet Dharmapurikar authored
The system crashes due to bad access when reading from an non configured peripheral and when writing to peripheral which is not owned by current ee. This patch verifies ownership to avoid crashing on write. For reads, since the forward mapping table, data_channel->ppid, is towards the end of the block, we use the core size to figure the max number of ppids supported. The table starts at an offset of 0x800 within the block, so size - 0x800 will give us the area used by the table. Since each table is 4 bytes long (core_size - 0x800) / 4 will gives us the number of data_channel supported. This new protection is functional on hw v2. Signed-off-by:
-
