summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-08-30irqchip/mmp: Mask off interrupts from other coresAndres Salomon
On mmp3, there's an extra set of ICU registers (ICU2) that handle interrupts on the extra cores. When masking off interrupts on MP1, these should be masked as well. We add a new interrupt controller via device tree to identify when we're looking at an mmp3 machine via compatible field of "marvell,mmp3-intc". [lkundrak@v3.sk: Changed "mrvl,mmp3-intc" compatible strings to "marvell,mmp3-intc". Tidied up the subject line a bit.] Signed-off-by: Andres Salomon <dilinger@queued.net> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20190822092643.593488-9-lkundrak@v3.sk -- Changes since v1: - Moved mmp3-specific mmp_icu2_base initialization from mmp_init_bases() to mmp3_of_init() so that we don't have to check for marvell,mmp3-intc compatibility twice. - Drop an superfluous call to irq_set_default_host() arch/arm/mach-mmp/regs-icu.h | 3 +++ drivers/irqchip/irq-mmp.c | 48 ++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+) Signed-off-by: Andres Salomon <dilinger@queued.net> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20190822092643.593488-9-lkundrak@v3.sk
2019-08-30irqchip/mmp: Add missing chained_irq_{enter,exit}()Lubomir Rintel
The lack of chained_irq_exit() leaves the muxed interrupt masked on MMP3. For reasons unknown this is not a problem on MMP2. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20190822092643.593488-8-lkundrak@v3.sk
2019-08-30irqchip/mmp: Do not use of_address_to_resource() to get mux regsLubomir Rintel
The "regs" property of the "mrvl,mmp2-mux-intc" devices are silly. They are offsets from intc's base, not addresses on the parent bus. At this point it probably can't be fixed. On an OLPC XO-1.75 machine, the muxes are children of the intc, not the axi bus, and thus of_address_to_resource() won't work. We should treat the values as mere integers as opposed to bus addresses. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20190822092643.593488-7-lkundrak@v3.sk
2019-08-30iommu/dma: Fix for dereferencing before null checkingYunsheng Lin
The cookie is dereferenced before null checking in the function iommu_dma_init_domain. This patch moves the dereferencing after the null checking. Fixes: fdbe574eb693 ("iommu/dma: Allow MSI-only cookies") Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30Merge branch 'arm/smmu' into arm/mediatekJoerg Roedel
2019-08-30irqchip/meson-gpio: Add support for meson sm1 SoCsJerome Brunet
The meson sm1 SoCs uses the same type of GPIO interrupt controller IP block as the other meson SoCs, A total of 100 pins can be spied on: - 223:100 undefined (no interrupt) - 99:97 3 pins on bank GPIOE - 96:77 20 pins on bank GPIOX - 76:61 16 pins on bank GPIOA - 60:53 8 pins on bank GPIOC - 52:37 16 pins on bank BOOT - 36:28 9 pins on bank GPIOH - 27:12 16 pins on bank GPIOZ - 11:0 12 pins in the AO domain Mapping is the same as the g12a family but the sm1 controller allows to trig an irq on both edges of the input signal. This was not possible with the previous SoCs families Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Link: https://lore.kernel.org/r/20190829161635.25067-3-jbrunet@baylibre.com
2019-08-30dt-bindings: interrupt-controller: New binding for the meson sm1 SoCsJerome Brunet
Update the dt-binding to add support for the sm1 SoC family in the amlogic GPIO interrupt controller driver. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20190829161635.25067-2-jbrunet@baylibre.com
2019-08-30iommu/mediatek: Clean up struct mtk_smi_iommuYong Wu
Remove the "struct mtk_smi_iommu" to simplify the code since it has only one item in it right now. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30memory: mtk-smi: Get rid of need_larbidYong Wu
The "mediatek,larb-id" has already been parsed in MTK IOMMU driver. It's no need to parse it again in SMI driver. Only clean some codes. This patch is fit for all the current mt2701, mt2712, mt7623, mt8173 and mt8183. After this patch, the "mediatek,larb-id" only be needed for mt2712 which have 2 M4Us. In the other SoCs, we can get the larb-id from M4U in which the larbs in the "mediatek,larbs" always are ordered. Correspondingly, the larb_nr in the "struct mtk_smi_iommu" could also be deleted. CC: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Fix VLD_PA_RNG register backup when suspendYong Wu
The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB mode support for mt2712. this patch add it. Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30memory: mtk-smi: Add bus_sel for mt8183Yong Wu
There are 2 mmu cells in a M4U HW. we could adjust some larbs entering mmu0 or mmu1 to balance the bandwidth via the smi-common register SMI_BUS_SEL(0x220)(Each larb occupy 2 bits). In mt8183, For better performance, we switch larb1/2/5/7 to enter mmu1 while the others still keep enter mmu0. In mt8173 and mt2712, we don't get the performance issue, Keep its default value(0x0), that means all the larbs enter mmu0. Note: smi gen1(mt2701/mt7623) don't have this bus_sel. And, the base of smi-common is completely different with smi_ao_base of gen1, thus I add new variable for that. CC: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30memory: mtk-smi: Invoke pm runtime_callback to enable clocksYong Wu
This patch only move the clk_prepare_enable and config_port into the runtime suspend/resume callback. It doesn't change the code content and sequence. This is a preparing patch for adjusting SMI_BUS_SEL for mt8183. (SMI_BUS_SEL need to be restored after smi-common resume every time.) Also it gives a chance to get rid of mtk_smi_larb_get/put which could be a next topic. CC: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Add mmu1 supportYong Wu
Normally the M4U HW connect EMI with smi. the diagram is like below: EMI | M4U | smi-common | ----------------- | | | | ... larb0 larb1 larb2 larb3 Actually there are 2 mmu cells in the M4U HW, like this diagram: EMI --------- | | mmu0 mmu1 <- M4U | | --------- | smi-common | ----------------- | | | | ... larb0 larb1 larb2 larb3 This patch add support for mmu1. In order to get better performance, we could adjust some larbs go to mmu1 while the others still go to mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220). mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default value of that register is 0 which means all the larbs go to mmu0 defaultly. This is a preparing patch for adjusting SMI_BUS_SEL for mt8183. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Add mt8183 IOMMU supportYong Wu
The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use the ARM Short-descriptor like mt8173, and most of the HW registers are the same. Here list main differences between mt8183 and mt8173/mt2712: 1) mt8183 has only one M4U HW like mt8173 while mt2712 has two. 2) mt8183 don't have the "bclk" clock, it use the EMI clock instead. 3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB mode". 4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent the bit[33:32] in the physical address of the pgtable base, But the standard ttbr0[1] means the S bit which is enabled defaultly, Hence, we add a mask. 5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support. 6) mt8183 need reset_axi like mt8173. 7) the larb-id in smi-common is remapped. M4U should add its larbid_remap. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30memory: mtk-smi: Add gals supportYong Wu
In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module which can help synchronize for the modules in different clock frequency. It can be seen as a "asynchronous fifo". This is a example diagram: M4U | ---------- | | gals0-rx gals1-rx | | | | gals0-tx gals1-tx | | ------------ SMI Common ------------ | +-----+--------+-----+- ... | | | | | gals-rx gals-rx | | | | | | | | | | gals-tx gals-tx | | | | | larb1 larb2 larb3 larb4 GALS only help transfer the command/data while it doesn't have the configuring register, thus it has the special "smi" clock and doesn't have the "apb" clock. From the diagram above, we add "gals0" and "gals1" clocks for smi-common and add a "gals" clock for smi-larb. This patch adds gals clock supporting in the SMI. Note that some larbs may still don't have the "gals" clock like larb1 and larb4 above. This is also a preparing patch for mt8183 which has GALS. CC: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Move vld_pa_rng into plat_dataYong Wu
Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address range) register while mt2712 have. Move it into the plat_data. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Move reset_axi into plat_dataYong Wu
In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while it is REG_MMU_CTRL in the other SoCs, and the bits meaning is completely different with the REG_MMU_STANDARD_AXI_MODE. This patch moves this property to plat_data, it's also a preparing patch for mt8183. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Refine protect memory definitionYong Wu
The protect memory setting is a little different in the different SoCs. In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault protect) shift bit is normally 4 while it shift 5 bits only in the mt8173. This patch delete the complex MACRO and use a common if-else instead. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Add larb-id remapped supportYong Wu
The larb-id may be remapped in the smi-common, this means the larb-id reported in the mtk_iommu_isr isn't the real larb-id, Take mt8183 as a example: M4U | --------------------------------------------- | SMI common | -0-----7-----5-----6-----1-----2------3-----4- <- Id remapped | | | | | | | | larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU disp vdec img cam venc img cam As above, larb0 connects with the id 0 in smi-common. larb1 connects with the id 7 in smi-common. ... If the larb-id reported in the isr is 7, actually it's larb1(vdec). In order to output the right larb-id in the isr, we add a larb-id remapping relationship in this patch. If there is no this larb-id remapping in some SoCs, use the linear mapping array instead. This also is a preparing patch for mt8183. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Add bclk can be supported optionallyYong Wu
In some SoCs, M4U doesn't have its "bclk", it will use the EMI clock instead which has always been enabled when entering kernel. Currently mt2712 and mt8173 have this bclk while mt8183 doesn't. This also is a preparing patch for mt8183. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Adjust the PA for the 4GB ModeYong Wu
After extending the v7s support PA[33:32] for MediaTek, we have to adjust the PA ourself for the 4GB mode. In the 4GB Mode, the PA will remap like this: CPU PA -> M4U output PA 0x4000_0000 0x1_4000_0000 (Add bit32) 0x8000_0000 0x1_8000_0000 ... 0xc000_0000 0x1_c000_0000 ... 0x1_0000_0000 0x1_0000_0000 (No change) 1) Always add bit32 for CPU PA in ->map. 2) Discard the bit32 in iova_to_phys if PA > 0x1_4000_0000 since the iommu consumer always use the CPU PA. Besides, the "oas" always is set to 34 since v7s has already supported our case. Both mt2712 and mt8173 support this "4GB mode" while the mt8183 don't. The PA in mt8183 won't remap. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/io-pgtable-arm-v7s: Extend to support PA[33:32] for MediaTekYong Wu
MediaTek extend the arm v7s descriptor to support up to 34 bits PA where the bit32 and bit33 are encoded in the bit9 and bit4 of the PTE respectively. Meanwhile the iova still is 32bits. Regarding whether the pagetable address could be over 4GB, the mt8183 support it while the previous mt8173 don't, thus keep it as is. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/io-pgtable-arm-v7s: Rename the quirk from MTK_4GB to MTK_EXTYong Wu
In previous mt2712/mt8173, MediaTek extend the v7s to support 4GB dram. But in the latest mt8183, We extend it to support the PA up to 34bit. Then the "MTK_4GB" name is not so fit, This patch only change the quirk name to "MTK_EXT". Signed-off-by: Yong Wu <yong.wu@mediatek.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/io-pgtable-arm-v7s: Use ias/oas to check the valid iova/paYong Wu
Use ias/oas to check the valid iova/pa. Synchronize this checking with io-pgtable-arm.c. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpersYong Wu
Add two helper functions: paddr_to_iopte and iopte_to_paddr. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Fix iova_to_phys PA start for 4GB modeYong Wu
In M4U 4GB mode, the physical address is remapped as below: CPU Physical address: ==================== 0 1G 2G 3G 4G 5G |---A---|---B---|---C---|---D---|---E---| +--I/O--+------------Memory-------------+ IOMMU output physical address: ============================= 4G 5G 6G 7G 8G |---E---|---B---|---C---|---D---| +------------Memory-------------+ The Region 'A'(I/O) can not be mapped by M4U; For Region 'B'/'C'/'D', the bit32 of the CPU physical address always is needed to set, and for Region 'E', the CPU physical address keep as is. something looks like this: CPU PA -> M4U OUTPUT PA 0x4000_0000 0x1_4000_0000 (Add bit32) 0x8000_0000 0x1_8000_0000 ... 0xc000_0000 0x1_c000_0000 ... 0x1_0000_0000 0x1_0000_0000 (No change) Additionally, the iommu consumers always use the CPU phyiscal address. The PA in the iova_to_phys that is got from v7s always is u32, But from the CPU point of view, PA only need add BIT(32) when PA < 0x4000_0000. Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range for 4GB mode") Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30memory: mtk-smi: Use a struct for the platform data for smi-commonYong Wu
Use a struct as the platform special data instead of the enumeration. Also there is a minor change that moving the position of "enum mtk_smi_gen" definition, this is because we expect define "struct mtk_smi_common_plat" before it is referred. This is a preparing patch for mt8183. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30memory: mtk-smi: Use a general config_port interfaceYong Wu
The config_port of mt2712 and mt8183 are the same. Use a general config_port interface instead. In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which are not the normal larb, their register space are different from the normal one. thus, we can not call the general config_port. In mt8183, IPU0/1 and CCU connect with smi-common directly, they also are not the normal larb. Hence, we add a "larb_direct_to_common_mask" for these larbs which connect to smi-commmon directly. This is also a preparing patch for adding mt8183 SMI support. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/mediatek: Use a struct as the platform dataYong Wu
Use a struct as the platform special data instead of the enumeration. This is a prepare patch for adding mt8183 iommu support. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMIYong Wu
This patch adds decriptions for mt8183 IOMMU and SMI. mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which uses ARM Short-Descriptor translation table format. The mt8183 M4U-SMI HW diagram is as below: EMI | M4U | ---------- | | gals0-rx gals1-rx | | | | gals0-tx gals1-tx | | ------------ SMI Common ------------ | +-----+-----+--------+-----+-----+-------+-------+ | | | | | | | | | | gals-rx gals-rx | gals-rx gals-rx gals-rx | | | | | | | | | | | | | | | | | | gals-tx gals-tx | gals-tx gals-tx gals-tx | | | | | | | | larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU disp vdec img cam venc img cam All the connections are HW fixed, SW can NOT adjust it. Compared with mt8173, we add a GALS(Global Async Local Sync) module between SMI-common and M4U, and additional GALS between larb2/3/5/6 and SMI-common. GALS can help synchronize for the modules in different clock frequency, it can be seen as a "asynchronous fifo". GALS can only help transfer the command/data while it doesn't have the configuring register, thus it has the special "smi" clock and it doesn't have the "apb" clock. From the diagram above, we add "gals0" and "gals1" clocks for smi-common and add a "gals" clock for smi-larb. >From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera Control Unit) is connected with smi-common directly, we can take them as "larb2", "larb3" and "larb7", and their register spaces are different with the normal larb. Signed-off-by: Yong Wu <yong.wu@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu: Revisit iommu_insert_resv_region() implementationEric Auger
Current implementation is recursive and in case of allocation failure the existing @regions list is altered. A non recursive version looks better for maintainability and simplifies the error handling. We use a separate stack for overlapping segment merging. The elements are sorted by start address and then by type, if their start address match. Note this new implementation may change the region order of appearance in /sys/kernel/iommu_groups/<n>/reserved_regions files but this order has never been documented, see commit bc7d12b91bd3 ("iommu: Implement reserved_regions iommu-group sysfs file"). Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30iommu/vt-d: Fix wrong analysis whether devices share the same busNadav Amit
set_msi_sid_cb() is used to determine whether device aliases share the same bus, but it can provide false indications that aliases use the same bus when in fact they do not. The reason is that set_msi_sid_cb() assumes that pdev is fixed, while actually pci_for_each_dma_alias() can call fn() when pdev is set to a subordinate device. As a result, running an VM on ESX with VT-d emulation enabled can results in the log warning such as: DMAR: [INTR-REMAP] Request device [00:11.0] fault index 3b [fault reason 38] Blocked an interrupt request due to source-id verification failure This seems to cause additional ata errors such as: ata3.00: qc timeout (cmd 0xa1) ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) These timeouts also cause boot to be much longer and other errors. Fix it by checking comparing the alias with the previous one instead. Fixes: 3f0c625c6ae71 ("iommu/vt-d: Allow interrupts from the entire bus for aliased devices") Cc: stable@vger.kernel.org Cc: Logan Gunthorpe <logang@deltatee.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Joerg Roedel <joro@8bytes.org> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Nadav Amit <namit@vmware.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30Merge tag 'gpio-v5.3-rc7-fixes-for-linus' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes gpio fixes for v5.3-rc7 - two patches fixing a regression in the pca953x driver
2019-08-30iommu/iova: Avoid false sharing on fq_timer_onEric Dumazet
In commit 14bd9a607f90 ("iommu/iova: Separate atomic variables to improve performance") Jinyu Qi identified that the atomic_cmpxchg() in queue_iova() was causing a performance loss and moved critical fields so that the false sharing would not impact them. However, avoiding the false sharing in the first place seems easy. We should attempt the atomic_cmpxchg() no more than 100 times per second. Adding an atomic_read() will keep the cache line mostly shared. This false sharing came with commit 9a005a800ae8 ("iommu/iova: Add flush timer"). Signed-off-by: Eric Dumazet <edumazet@google.com> Fixes: 9a005a800ae8 ('iommu/iova: Add flush timer') Cc: Jinyu Qi <jinyuqi@huawei.com> Cc: Joerg Roedel <jroedel@suse.de> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-08-30i2c: mediatek: disable zero-length transfers for mt8183Hsin-Yi Wang
Quoting from mt8183 datasheet, the number of transfers to be transferred in one transaction should be set to bigger than 1, so we should forbid zero-length transfer and update functionality. Reported-by: Alexandru M Stan <amstan@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Qii Wang <qii.wang@mediatek.com> [wsa: shortened commit message a little] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-08-30i2c: iproc: Stop advertising support of SMBUS quick cmdLori Hikichi
The driver does not support the SMBUS Quick command so remove the flag that indicates that level of support. By default the i2c_detect tool uses the quick command to try and detect devices at some bus addresses. If the quick command is used then we will not detect the device, even though it is present. Fixes: e6e5dd3566e0 (i2c: iproc: Add Broadcom iProc I2C Driver) Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-08-30MAINTAINERS: i2c mv64xxx: Update documentation pathDenis Efremov
Update MAINTAINERS record to reflect the file move from i2c-mv64xxx.txt to marvell,mv64xxx-i2c.yaml. Fixes: f8bbde72ef44 ("dt-bindings: i2c: mv64xxx: Add YAML schemas") Signed-off-by: Denis Efremov <efremov@linux.com> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-08-30perf/x86/amd/ibs: Fix sample bias for dispatched micro-opsKim Phillips
When counting dispatched micro-ops with cnt_ctl=1, in order to prevent sample bias, IBS hardware preloads the least significant 7 bits of current count (IbsOpCurCnt) with random values, such that, after the interrupt is handled and counting resumes, the next sample taken will be slightly perturbed. The current count bitfield is in the IBS execution control h/w register, alongside the maximum count field. Currently, the IBS driver writes that register with the maximum count, leaving zeroes to fill the current count field, thereby overwriting the random bits the hardware preloaded for itself. Fix the driver to actually retain and carry those random bits from the read of the IBS control register, through to its write, instead of overwriting the lower current count bits with zeroes. Tested with: perf record -c 100001 -e ibs_op/cnt_ctl=1/pp -a -C 0 taskset -c 0 <workload> 'perf annotate' output before: 15.70 65: addsd %xmm0,%xmm1 17.30 add $0x1,%rax 15.88 cmp %rdx,%rax je 82 17.32 72: test $0x1,%al jne 7c 7.52 movapd %xmm1,%xmm0 5.90 jmp 65 8.23 7c: sqrtsd %xmm1,%xmm0 12.15 jmp 65 'perf annotate' output after: 16.63 65: addsd %xmm0,%xmm1 16.82 add $0x1,%rax 16.81 cmp %rdx,%rax je 82 16.69 72: test $0x1,%al jne 7c 8.30 movapd %xmm1,%xmm0 8.13 jmp 65 8.24 7c: sqrtsd %xmm1,%xmm0 8.39 jmp 65 Tested on Family 15h and 17h machines. Machines prior to family 10h Rev. C don't have the RDWROPCNT capability, and have the IbsOpCurCnt bitfield reserved, so this patch shouldn't affect their operation. It is unknown why commit db98c5faf8cb ("perf/x86: Implement 64-bit counter support for IBS") ignored the lower 4 bits of the IbsOpCurCnt field; the number of preloaded random bits has always been 7, AFAICT. Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: "Arnaldo Carvalho de Melo" <acme@kernel.org> Cc: <x86@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "Borislav Petkov" <bp@alien8.de> Cc: Stephane Eranian <eranian@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: "Namhyung Kim" <namhyung@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lkml.kernel.org/r/20190826195730.30614-1-kim.phillips@amd.com
2019-08-30perf/x86/intel: Restrict period on NehalemJosh Hunt
We see our Nehalem machines reporting 'perfevents: irq loop stuck!' in some cases when using perf: perfevents: irq loop stuck! WARNING: CPU: 0 PID: 3485 at arch/x86/events/intel/core.c:2282 intel_pmu_handle_irq+0x37b/0x530 ... RIP: 0010:intel_pmu_handle_irq+0x37b/0x530 ... Call Trace: <NMI> ? perf_event_nmi_handler+0x2e/0x50 ? intel_pmu_save_and_restart+0x50/0x50 perf_event_nmi_handler+0x2e/0x50 nmi_handle+0x6e/0x120 default_do_nmi+0x3e/0x100 do_nmi+0x102/0x160 end_repeat_nmi+0x16/0x50 ... ? native_write_msr+0x6/0x20 ? native_write_msr+0x6/0x20 </NMI> intel_pmu_enable_event+0x1ce/0x1f0 x86_pmu_start+0x78/0xa0 x86_pmu_enable+0x252/0x310 __perf_event_task_sched_in+0x181/0x190 ? __switch_to_asm+0x41/0x70 ? __switch_to_asm+0x35/0x70 ? __switch_to_asm+0x41/0x70 ? __switch_to_asm+0x35/0x70 finish_task_switch+0x158/0x260 __schedule+0x2f6/0x840 ? hrtimer_start_range_ns+0x153/0x210 schedule+0x32/0x80 schedule_hrtimeout_range_clock+0x8a/0x100 ? hrtimer_init+0x120/0x120 ep_poll+0x2f7/0x3a0 ? wake_up_q+0x60/0x60 do_epoll_wait+0xa9/0xc0 __x64_sys_epoll_wait+0x1a/0x20 do_syscall_64+0x4e/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fdeb1e96c03 ... Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: acme@kernel.org Cc: Josh Hunt <johunt@akamai.com> Cc: bpuranda@akamai.com Cc: mingo@redhat.com Cc: jolsa@redhat.com Cc: tglx@linutronix.de Cc: namhyung@kernel.org Cc: alexander.shishkin@linux.intel.com Link: https://lkml.kernel.org/r/1566256411-18820-1-git-send-email-johunt@akamai.com
2019-08-30Merge branch 'for-next/atomics' into for-next/coreWill Deacon
* for-next/atomics: (10 commits) Rework LSE instruction selection to use static keys instead of alternatives
2019-08-30Merge branches 'for-next/52-bit-kva', 'for-next/cpu-topology', ↵Will Deacon
'for-next/error-injection', 'for-next/perf', 'for-next/psci-cpuidle', 'for-next/rng', 'for-next/smpboot', 'for-next/tbi' and 'for-next/tlbi' into for-next/core * for-next/52-bit-kva: (25 commits) Support for 52-bit virtual addressing in kernel space * for-next/cpu-topology: (9 commits) Move CPU topology parsing into core code and add support for ACPI 6.3 * for-next/error-injection: (2 commits) Support for function error injection via kprobes * for-next/perf: (8 commits) Support for i.MX8 DDR PMU and proper SMMUv3 group validation * for-next/psci-cpuidle: (7 commits) Move PSCI idle code into a new CPUidle driver * for-next/rng: (4 commits) Support for 'rng-seed' property being passed in the devicetree * for-next/smpboot: (3 commits) Reduce fragility of secondary CPU bringup in debug configurations * for-next/tbi: (10 commits) Introduce new syscall ABI with relaxed requirements for pointer tags * for-next/tlbi: (6 commits) Handle spurious page faults arising from kernel space
2019-08-30spi: bcm-qspi: Make BSPI default modeRayagonda Kokatanur
The spi-nor controller defaults to BSPI mode, hence switch back to its default mode after MSPI operations (write or erase) are completed. Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Kamal Dasu <kdasu.kdev@gmail.com> Link: https://lore.kernel.org/r/1567139325-7912-1-git-send-email-rayagonda.kokatanur@broadcom.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30spi: npcm-fiu: add NPCM FIU controller driverTomer Maimon
Add Nuvoton NPCM BMC Flash Interface Unit(FIU) SPI master controller driver using SPI-MEM interface. The FIU supports single, dual or quad communication interface. the FIU controller can operate in following modes: - User Mode Access(UMA): provides flash access by using an indirect address/data mechanism. - direct rd/wr mode: maps the flash memory into the core address space. - SPI-X mode: used for an expansion bus to an ASIC or CPLD. Signed-off-by: Tomer Maimon <tmaimon77@gmail.com> Link: https://lore.kernel.org/r/20190828142513.228556-3-tmaimon77@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30dt-binding: spi: add NPCM FIU controllerTomer Maimon
Added device tree binding documentation for Nuvoton BMC NPCM Flash Interface Unit(FIU) SPI master controller using SPI-MEM interface. Signed-off-by: Tomer Maimon <tmaimon77@gmail.com> Link: https://lore.kernel.org/r/20190828142513.228556-2-tmaimon77@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30spi: dw-pci: Add MODULE_DEVICE_TABLEJarkko Nikula
MODULE_DEVICE_TABLE is missing from the PCI part of the driver. Add it so userspace can autoload the the driver when it is built as module. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20190829125000.26303-1-jarkko.nikula@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30MAINTAINERS: Add keyword pattern on regulator_get_optional()Mark Brown
In an effort to try to contain abuses of regulator_get_optional() add a keyword entry to the MAINTAINERS stanza for the regulator API so that the regulator maintainers get CCed on new usages. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20190829125435.48770-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30regulator: sy8824x: add prefixes to BUCK_EN and MODE macrosJisheng Zhang
Add prefixes to BUCK_EN and MODE macros to namespace them. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190829143927.395d0385@xhacker.debian Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30regulator: sy8824x: use c++style for the comment block near SPDXJisheng Zhang
Update the entire comment block to be C++ style so it looks consistent. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20190829143749.4b42bc65@xhacker.debian Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30regulator: mt6358: Add BROKEN dependency while waiting for MFD to mergeMark Brown
The mt6358 driver was merged in error, it depends on an existing MFD rather than a newly added one and needs updates to that driver. Disable the build until those are merged. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-30iommu/amd: Silence warnings under memory pressureQian Cai
When running heavy memory pressure workloads, the system is throwing endless warnings, smartpqi 0000:23:00.0: AMD-Vi: IOMMU mapping error in map_sg (io-pages: 5 reason: -12) Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019 swapper/10: page allocation failure: order:0, mode:0xa20(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0,4 Call Trace: <IRQ> dump_stack+0x62/0x9a warn_alloc.cold.43+0x8a/0x148 __alloc_pages_nodemask+0x1a5c/0x1bb0 get_zeroed_page+0x16/0x20 iommu_map_page+0x477/0x540 map_sg+0x1ce/0x2f0 scsi_dma_map+0xc6/0x160 pqi_raid_submit_scsi_cmd_with_io_request+0x1c3/0x470 [smartpqi] do_IRQ+0x81/0x170 common_interrupt+0xf/0xf </IRQ> because the allocation could fail from iommu_map_page(), and the volume of this call could be huge which may generate a lot of serial console output and cosumes all CPUs. Fix it by silencing the warning in this call site, and there is still a dev_err() later to notify the failure. Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Joerg Roedel <jroedel@suse.de>
generated by cgit (git 2.34.1) at 2025-09-23 14:26:14 +0000