* [PATCH v5 00/22] vITS save/restore
From: Prakash B @ 2017-04-26 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-1-git-send-email-eric.auger@redhat.com>
Verified on Cavium ThunderX platform
Continousily migrated Guest more than 500 times b/w different hosts.
Please feel free to add Tested-by: Prakash, Brahmajyosyula
<Brahmajyosyula.Prakash@cavium.com>
^ permalink raw reply
* [PATCH 2/2] ARM: imx_v6_v7_defconfig: enable PCI_MSI
From: Lucas Stach @ 2017-04-26 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU2MG66ruQ87TmSrVCtWfHwGc3s=_NG-ysgV2uyJzzskiQ@mail.gmail.com>
Hi Tim,
Am Dienstag, den 11.04.2017, 09:05 -0700 schrieb Tim Harvey:
> On Wed, Apr 5, 2017 at 5:16 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> > Am Mittwoch, den 05.04.2017, 13:07 +0100 schrieb Joao Pinto:
> > [...]
> >> >>> Lucas,
> >> >>>
> >> >>> I feel a bit dumb here for forgetting about this issue and letting it
> >> >>> drop, but I've just spent a day debugging an issue with the ath9k
> >> >>> wireless driver only to realize it was that the ath9k card and/or
> >> >>> driver doesn't support MSI interrupts and thus no longer work on
> >> >>> mainline kernels that have MSI enabled. To be honest I'm not sure how
> >> >>> many PCIe devices out there can't support MSI because of hardware
> >> >>> limitations vs drivers that simply have not implemented it.
> >> >>>
> >> >>> To make matters worse 3ee803641e76bea76ec730c80dcc64739a9919ff makes
> >> >>> it such that you can't disable MSI on the IMX6.
> >> >>>
> >> >>> Is there some fix you can think of to make the IMX6 PCIe host
> >> >>> controller raise an interrupt for cards/drivers that use legacy irq's?
> >> >>> If not, then we need to allow MSI to be disabled for IMX6 and default
> >> >>> it to disabled for compatibility.
> >> >>>
> >> >>
> >> >> Joao / Jingoo,
> >> >>
> >> >> (Adding linux-pci to the list to pick up maintainers of other DWC PCIe
> >> >> core drivers)
> >> >>
> >> >> Is Luca's statement that 'legacy IRQs and MSIs can't be used together'
> >> >> true in general for the DW PCIe core? If any of the host controllers
> >> >> using this core can't support both legacy and MSI irqs together I
> >> >> still believe we shouldn't enable/require MSI as it breaks any
> >> >> card/driver that only supports legacy interrupts (such as ath9k).
> >> >
> >> > If there are 2 DW PCIe controllers, one controller can be used for legacy
> >> > and another controller can be used for MSI.
> >> >
> >> > But, I am not sure that one DW PCIe controller can support both MSI device
> >> > and legacy interrupt device at the same time.
> >> >
> >> > To Joao Pinto,
> >> > Will you confirm this?
> >> >
> >>
> >> Hi Jingoo,
> >> I confirm that if a RC has MSI enable, it won't support legacy interrupts.
> >
> > Okay, so the only way to solve this in a generic way, that I can see at
> > the moment is to defer MSI enable until the downstream device actually
> > requests an MSI irq.
> >
> > Also we need to disable the MSI capability if any bridge device turns up
> > during the bus topology scan, as we can have devices with conflicting
> > requirements connected to the RC in that case.
> >
> > I'll cook up some patches to implement this.
> >
>
> Lucas,
>
> Any thoughts yet? I'll likely want to backport this to stable although
> the restructuring to drivers/pci/dwc and subsequent changes since 4.10
> will likely require a re-written patch.
I have a fix for this, that I'm currently testing on different setups.
I'll probably send it out in a few hours.
Regards,
Lucas
^ permalink raw reply
* [PATCH v2] clk: sunxi-ng: Fix dependency on SUNXI_CCU_GATE
From: Corentin Labbe @ 2017-04-26 11:53 UTC (permalink / raw)
To: linux-arm-kernel
When CONFIG_SUNXI_CCU is set but no other SUNXI_CCU is selected i got
the following build error:
drivers/built-in.o: In function `ccu_pll_notifier_cb':
drivers/clk/sunxi-ng/ccu_common.c:71: undefined reference to `ccu_gate_helper_disable'
drivers/clk/sunxi-ng/ccu_common.c:73: undefined reference to `ccu_gate_helper_enable'
The problem is the function ccu_pll_notifier_cb in ccu_common.c need
some function from ccu_gate.c which is not compiled since SUNXI_CCU_GATE
is not selected.
This patch remove SUNXI_CCU_GATE and compile ccu_gate.c unconditionnaly
since all other combination of options select SUNXI_CCU_GATE finally.
Fixes: 02ae2bc6febd ("clk: sunxi-ng: Add clk notifier to gate then ungate PLL clocks")
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
Changes since v1:
- fix subject
drivers/clk/sunxi-ng/Kconfig | 11 -----------
drivers/clk/sunxi-ng/Makefile | 2 +-
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 8bee225..d7842f9 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -15,9 +15,6 @@ config SUNXI_CCU_DIV
config SUNXI_CCU_FRAC
bool
-config SUNXI_CCU_GATE
- bool
-
config SUNXI_CCU_MUX
bool
@@ -32,24 +29,19 @@ config SUNXI_CCU_PHASE
config SUNXI_CCU_NK
bool
- select SUNXI_CCU_GATE
config SUNXI_CCU_NKM
bool
- select SUNXI_CCU_GATE
config SUNXI_CCU_NKMP
bool
- select SUNXI_CCU_GATE
config SUNXI_CCU_NM
bool
select SUNXI_CCU_FRAC
- select SUNXI_CCU_GATE
config SUNXI_CCU_MP
bool
- select SUNXI_CCU_GATE
select SUNXI_CCU_MUX
# SoC Drivers
@@ -119,7 +111,6 @@ config SUN8I_A33_CCU
config SUN8I_A83T_CCU
bool "Support for the Allwinner A83T CCU"
select SUNXI_CCU_DIV
- select SUNXI_CCU_GATE
select SUNXI_CCU_NKMP
select SUNXI_CCU_NM
select SUNXI_CCU_MP
@@ -154,7 +145,6 @@ config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
select SUNXI_CCU_DIV
select SUNXI_CCU_MULT
- select SUNXI_CCU_GATE
select SUNXI_CCU_NKMP
select SUNXI_CCU_NM
select SUNXI_CCU_MP
@@ -165,7 +155,6 @@ config SUN9I_A80_CCU
config SUN8I_R_CCU
bool "Support for Allwinner SoCs' PRCM CCUs"
select SUNXI_CCU_DIV
- select SUNXI_CCU_GATE
default MACH_SUN8I || (ARCH_SUNXI && ARM64)
endif
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 78028c8..52aab41 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -1,11 +1,11 @@
# Common objects
obj-$(CONFIG_SUNXI_CCU) += ccu_common.o
obj-$(CONFIG_SUNXI_CCU) += ccu_reset.o
+obj-$(CONFIG_SUNXI_CCU) += ccu_gate.o
# Base clock types
obj-$(CONFIG_SUNXI_CCU_DIV) += ccu_div.o
obj-$(CONFIG_SUNXI_CCU_FRAC) += ccu_frac.o
-obj-$(CONFIG_SUNXI_CCU_GATE) += ccu_gate.o
obj-$(CONFIG_SUNXI_CCU_MUX) += ccu_mux.o
obj-$(CONFIG_SUNXI_CCU_MULT) += ccu_mult.o
obj-$(CONFIG_SUNXI_CCU_PHASE) += ccu_phase.o
--
2.10.2
^ permalink raw reply related
* [PATCH v2] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Sunil Kovvuri @ 2017-04-26 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426113651.GI21744@arm.com>
On Wed, Apr 26, 2017 at 5:06 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Apr 26, 2017 at 04:13:29PM +0530, Sunil Kovvuri wrote:
>> On Wed, Apr 26, 2017 at 3:31 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > Hi Sunil,
>> >
>> > On Tue, Apr 25, 2017 at 03:27:52PM +0530, sunil.kovvuri at gmail.com wrote:
>> >> From: Sunil Goutham <sgoutham@cavium.com>
>> >>
>> >> For software initiated address translation, when domain type is
>> >> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
>> >> i.e return the same IOVA as translated address.
>> >>
>> >> This patch is an extension to Will Deacon's patchset
>> >> "Implement SMMU passthrough using the default domain".
>> >>
>> >> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
>> >> ---
>> >>
>> >> V2
>> >> - As per Will's suggestion applied fix to SMMUv3 driver as well.
>> >
>> > This follows what the AMD driver does, so:
>> >
>> > Acked-by: Will Deacon <will.deacon@arm.com>
>>
>> Thanks,
>>
>> >
>> > but I still think that having drivers/net/ethernet/cavium/thunder/nicvf_queues.c
>> > poke around with the physical address to get at the struct pages underlying
>> > a DMA buffer is really dodgy.
>>
>> Driver is not dealing with page structures to be precise, just like
>> for any other NIC device, driver needs to know the virtual address
>> of the packet to where it's DMA'ed, so that SKB if framed and
>> handed over to network stack. Due to reasons mentioned below,
>> in this driver it's not possible to maintain a list of DMA addresses to
>> Virtual address mappings. Hence using IOMMU API, DMA address
>> is translated to physical address and finally to virtual address. I don't
>> see anything dodgy here.
>
> It's dodgy because you're the only NIC driver using iommu_iova_to_phys
> directly and, afaict, the driver could just stash either the struct page
> or the virtual address at the point of allocation.
Well the driver needs to be written based on how HW functions even if
it results in making use of an API which isn't used earlier by others.
>
>> > Is there no way this can be avoided, perhaps by tracking the pages some other way
>>
>> I have explained that in the commit message
>> --
>> Also VNIC doesn't have a seperate receive buffer ring per receive
>> queue, so there is no 1:1 descriptor index matching between CQE_RX
>> and the index in buffer ring from where a buffer has been used for
>> DMA'ing. Unlike other NICs, here it's not possible to maintain dma
>> address to virt address mappings within the driver. This leaves us
>> no other choice but to use IOMMU's IOVA address conversion API to
>> get buffer's virtual address which can be given to network stack
>> for processing.
>> --
>>
>> >(although I don't understand why you're having to mess with the page reference
>> >counts to start with)?
>> Not sure why you say it's a mess, adjusting page reference counts is quite
>> common if you check other NIC drivers. On ARM64 especially when using
>> 64KB pages, if we have only one packet buffer for each page then we
>> will have to set aside a whole lot of memory which sometimes is not possible
>> on embedded platforms. Hence multiple pkt buffers per page, and page reference
>> is set accordingly.
>
> I wasn't saying that was a mess, I was just saying that I didn't understand
> why you mess (verb) with the page reference counts (my ignorance of the
> network layer). The code that I think is a mess is:
>
> phys_addr = nicvf_iova_to_phys(nic, buf_addr);
> [...]
> put_page(virt_to_page(phys_to_virt(phys_addr)));
Even if it's possible to record info info in this driver, still page reference
count needs to be released to free it otherwise the page is gone.
>
> because:
>
> (a) You have the information you need at allocation time, but you've
> failed to record that and are trying to use the IOMMU API to
> reconstruct the CPU virtual address
That's exactly what I have explained in the commit message, i.e why
I cannot record info at the time of allocation. Also, HW gives address of
the buffer (IOVA or physcial) where it has DMA'ed the packet and not an
index into buffer ring. There is one single buffer ring for 8 receive queues,
so there is no way to do a mapping btw DMA address at receive queue to
recorded info in buffer ring.
All you said is possible and that is exactly what I would have done if HW
gives me an index into buffer ring instead of DMA'ed address and I wouldn't
have been hit so hard with all the bottlenecks in ARM IOMMU infrastructure.
Thanks,
Sunil.
>
> (b) When there isn't an IOMMU present, you assume that bus addresses ==
> physical addresses
>
> (c) You assume that the DMA buffer is mapped in the linear mapping
>
> that's probably all true for ThunderX/arm64, but it's generally not portable
> or reliable code. If you could get a handle to the struct page that you
> allocated in the first place, then you could use page_address to get its
> virtual address instead of having to go via the physical address.
>
> Will
^ permalink raw reply
* [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-26 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zif38qu2.fsf@free-electrons.com>
On Wed, Apr 26, 2017 at 11:23 AM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> On lun., avril 24 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> + spin_lock_irqsave(&info->irq_lock, flags);
>>> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
>>> + /* Manage only the interrupt that was enabled */
>>> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
>>> + spin_unlock_irqrestore(&info->irq_lock, flags);
>>> + while (status) {
>>> + u32 hwirq = ffs(status) - 1;
>>> + u32 virq = irq_find_mapping(d, hwirq +
>>> + i * GPIO_PER_REG);
>>> +
>>> + generic_handle_irq(virq);
>>> + status &= ~BIT(hwirq);
>>> + }
>>
>> You hae a problem here is a new IRQ appears while you are inside
>> of this loop. You need to re-read the status register for each iteration
>> (and &= with the IRQ_EN I guess).
>
> If a new IRQ appears during the loop, then the irq handler will be
> called again because the cause of this new IRQ won't have been acked
> yet. So I think we're fine here.
That *might* be true. It is true if the CPU gets a level IRQ from the
GPIO controller. But hardware dealing with edge IRQs can be very
quirky here, and just send a pulse on the line to the CPU if the
CPU-bound IRQ is also just edge triggered. And then that
pulse would potentially be missed while dealing with the current
IRQ in this handler. (And exactly this happened to us on other
hardware.)
But anyway: why let the irq handler be called again if you can avoid it?
You would avoid a double context switch by just checking it again
in the loop before exiting the handler. And that can be really nice
for latency-sensitive stuff.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 01/22] KVM: arm/arm64: Add ITS save/restore API documentation
From: Christoffer Dall @ 2017-04-26 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492164934-988-2-git-send-email-eric.auger@redhat.com>
On Fri, Apr 14, 2017 at 12:15:13PM +0200, Eric Auger wrote:
> Add description for how to access ITS registers and how to save/restore
> ITS tables into/from memory.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
> v4 -> v5:
> - take into account Christoffer's comments
> - pending table save on GICV3 side now
>
> v3 -> v4:
> - take into account Peter's comments:
> - typos
> - KVM_DEV_ARM_VGIC_GRP_ITS_TABLES kvm_device_attr = 0
> - add a validity bit in DTE
> - document all fields in CTE and ITE
> - document ABI revision
> - take into account Andre's comments:
> - document restrictions about GITS_CREADR writing and GITS_IIDR
> - document -EBUSY error if one or more VCPUS are runnning
> - document 64b registers only can be accessed with 64b access
> - itt_addr field matches bits [51:8] of the itt_addr
>
> v1 -> v2:
> - DTE and ITE now are 8 bytes
> - DTE and ITE now indexed by deviceid/eventid
> - use ITE name instead of ITTE
> - mentions ITT_addr matches bits [51:8] of the actual address
> - mentions LE layout
> ---
> Documentation/virtual/kvm/devices/arm-vgic-its.txt | 99 ++++++++++++++++++++++
> 1 file changed, 99 insertions(+)
>
> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> index 6081a5b..b5f010d 100644
> --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
> @@ -32,7 +32,106 @@ Groups:
> KVM_DEV_ARM_VGIC_CTRL_INIT
> request the initialization of the ITS, no additional parameter in
> kvm_device_attr.addr.
> +
> + KVM_DEV_ARM_ITS_SAVE_TABLES
> + save the ITS table data into guest RAM, at the location provisioned
> + by the guest in corresponding registers/table entries.
> +
> + The layout of the tables in guest memory defines an ABI. The entries
> + are laid out in little endian format as described in the last paragraph.
> +
> + KVM_DEV_ARM_ITS_RESTORE_TABLES
> + restore the ITS tables from guest RAM to ITS internal structures.
> +
> + The GICV3 must be restored before the ITS and all ITS registers but
> + the GITS_CTLR must be restored before restoring the ITS tables.
> +
> + The GITS_IIDR read-only register must also be restored before
> + the table restore as the IIDR revision field encodes the ABI revision.
> +
what is the expected sequence of operations. For example, to restore
the ITS, do I call KVM_DEV_ARM_VGIC_CTRL_INIT first, then restore all
the memory and registers, and finally call KVM_DEV_ARM_ITS_RESTORE_TABLES?
Is there any interaction between when you call KVM_DEV_ARM_ITS_RESTORE_TABLES
and restore GITS_CTLR (which enables the ITS)?
> Errors:
> -ENXIO: ITS not properly configured as required prior to setting
> this attribute
> -ENOMEM: Memory shortage when allocating ITS internal data
> + -EINVAL: Inconsistent restored data
> + -EFAULT: Invalid guest ram access
> + -EBUSY: One or more VCPUS are running
> +
> + KVM_DEV_ARM_VGIC_GRP_ITS_REGS
> + Attributes:
> + The attr field of kvm_device_attr encodes the offset of the
> + ITS register, relative to the ITS control frame base address
> + (ITS_base).
> +
> + kvm_device_attr.addr points to a __u64 value whatever the width
> + of the addressed register (32/64 bits). 64 bit registers can only
> + be accessed with full length.
> +
> + Writes to read-only registers are ignored by the kernel except for:
> + - GITS_READR. It needs to be restored otherwise commands in the queue
> + will be re-executed after restoring CWRITER. GITS_READR must be restored
> + before restoring the GITS_CTLR which is likely to enable the ITS.
> + Also it needs to be restored after GITS_CBASER since a write to
> + GITS_CBASER resets GITS_CREADR.
> + - GITS_IIDR. Its Revision field encodes the table layout ABI revision.
> + In the future we might implement direct injection of virtual LPIS.
> + This will require an upgrade of the table layout and an evolution of
> + the ABI. GITS_IIDR must be restored before the table restoration.
> +
> + For other registers, getting or setting a register has the same
> + effect as reading/writing the register on real hardware.
> + Errors:
> + -ENXIO: Offset does not correspond to any supported register
> + -EFAULT: Invalid user pointer for attr->addr
> + -EINVAL: Offset is not 64-bit aligned
> + -EBUSY: one or more VCPUS are running
It may be helpful to state the ordering requirements somewhere:
Restoring the ITS:
------------------
Restoring the ITS requires certain things to happen in order.
Specifically:
1. Initialize the ITS (KVM_DEV_ARM_VGIC_CTRL_INIT)
2. Restore GITS_IIDR
3. Restore GITS_CBASER
4. Restore GITS_READR
5. Restore remainin registers except GITS_CTLR
6. Make sure all guest memory is restored
7. Load the ITS table data (KVM_DEV_ARM_ITS_RESTORE_TABLES)
> +
> + ITS Table ABI REV0:
> + -------------------
> +
> + Revision 0 of the ABI only supports physical LPIs.
> +
> + The device table and ITT are indexed by the deviceid and eventid,
> + respectively. The collection table is not indexed by collectionid:
> + CTE are written in the table in the order of collection creation. All
> + entries are 8 bytes.
> +
> + Device Table Entry (DTE):
> +
> + bits: | 63| 62 ... 49 | 48 ... 5 | 4 ... 0 |
> + values: | V | next | ITT_addr | Size |
> +
> + where;
> + - V indicates whether the entry is valid. If not, other fields
> + are not meaningful.
> + - next: equals to 0 if this entry is the last one; otherwise it
> + corresponds to the deviceid offset to the next DTE, capped by
> + 2^14 -1.
> + - ITT_addr matches bits [51:8] of the ITT address (256B aligned).
I assume the B here is bytes. Where does this requirement come from?
> + - Size specifies the supported number of bits for the deviceid,
> + minus one
deviceid or eventid?
> +
> + Collection Table Entry (CTE):
> +
> + bits: | 63| 62 .. 52 | 51 ... 16 | 15 ... 0 |
> + values: | V | RES0 | RDBase | ICID |
> +
> + where:
> + - V indicates whether the entry is valid. If not, other fields are
> + not meaningful.
> + - RES0: reserved field with Should-Be-Zero-or-Preserved behavior.
> + - RDBase is the PE number (GICR_TYPER.Processor_Number semantic),
> + - ICID is the collection ID
> +
> + Interrupt Translation Entry (ITE):
> +
> + bits: | 63 ... 48 | 47 ... 16 | 15 ... 0 |
> + values: | next | pINTID | ICID |
> +
> + where:
> + - next: equals to 0 if this entry is the last one; otherwise it corresponds
> + to the eventid offset to the next ITE capped by 2^16 -1.
> + - pINTID is the physical LPI ID; if zero, it means the entry is not valid
> + and other fields are not meaningful.
> + - ICID is the collection ID
> +
> --
> 2.5.5
>
Besides the minor suggestions above:
Reviewed-by: Christoffer Dall <cdall@linaro.org>
^ permalink raw reply
* [PATCH 2/2] dmaengine: Add STM32 MDMA driver
From: Pierre Yves MORDRET @ 2017-04-26 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170406070805.GG4094@localhost>
On 04/06/2017 09:08 AM, Vinod Koul wrote:
> On Mon, Mar 13, 2017 at 04:06:39PM +0100, M'boumba Cedric Madianga wrote:
>> This patch adds the driver for the STM32 MDMA controller.
>
> Again pls do describe the controller
OK. I will add a more detail description with V2
>
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/dmaengine.h>
>> +#include <linux/dma-mapping.h>
>> +#include <linux/dmapool.h>
>> +#include <linux/err.h>
>> +#include <linux/init.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/list.h>
>> +#include <linux/log2.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_dma.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reset.h>
>> +#include <linux/sched.h>
>
> why do you need sched.h, i am sure many of these may not be required, pls
> check
Correct ! not needed. I'll get rid of it in V2
>
>> +static int stm32_mdma_get_width(struct stm32_mdma_chan *chan,
>> + enum dma_slave_buswidth width)
>> +{
>> + switch (width) {
>> + case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> + return STM32_MDMA_BYTE;
>> + case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> + return STM32_MDMA_HALF_WORD;
>> + case DMA_SLAVE_BUSWIDTH_4_BYTES:
>> + return STM32_MDMA_WORD;
>> + case DMA_SLAVE_BUSWIDTH_8_BYTES:
>> + return STM32_MDMA_DOUBLE_WORD;
>
> IIUC we can do this with ffs()
I don't believe we can do that. This function translates DMA_SLAVE enum
into internal register representation.
>
>
>> + default:
>> + dev_err(chan2dev(chan), "Dma bus width not supported\n");
>> + return -EINVAL;
>> + }
>> +}
>> +
>> +static enum dma_slave_buswidth stm32_mdma_get_max_width(u32 buf_len, u32 tlen)
>> +{
>> + enum dma_slave_buswidth max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
>> +
>> + while ((buf_len <= max_width || buf_len % max_width ||
>> + tlen < max_width) && max_width > DMA_SLAVE_BUSWIDTH_1_BYTE)
>> + max_width = max_width >> 1;
>
> 1. this is hard to read
> 2. sound like this can be optimized :)
>
Ok. I will revise the check if improvements can be done
>> +
>> + return max_width;
>> +}
>> +
>> +static u32 stm32_mdma_get_best_burst(u32 buf_len, u32 tlen, u32 max_burst,
>> + enum dma_slave_buswidth width)
>> +{
>> + u32 best_burst = max_burst;
>> + u32 burst_len = best_burst * width;
>> +
>> + if (buf_len % tlen)
>> + return 0;
>> +
>> + while ((tlen < burst_len && best_burst > 1) ||
>> + (burst_len > 0 && tlen % burst_len)) {
>> + best_burst = best_burst >> 1;
>> + burst_len = best_burst * width;
>
> same thing here too
Ok. I will revise the check if improvements can be done
>
>> +
>> + return (best_burst > 1) ? best_burst : 0;
>> +}
>> +
>> +static int stm32_mdma_disable_chan(struct stm32_mdma_chan *chan)
>> +{
>> + struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
>> + u32 ccr, cisr, id, reg;
>> + int ret;
>> +
>> + id = chan->id;
>> + reg = STM32_MDMA_CCR(id);
>> +
>> + /* Disable interrupts */
>> + stm32_mdma_clr_bits(dmadev, reg, STM32_MDMA_CCR_IRQ_MASK);
>> +
>> + ccr = stm32_mdma_read(dmadev, reg);
>> + if (ccr & STM32_MDMA_CCR_EN) {
>> + stm32_mdma_clr_bits(dmadev, reg, STM32_MDMA_CCR_EN);
>> +
>> + /* Ensure that any ongoing transfer has been completed */
>> + ret = readl_relaxed_poll_timeout_atomic(
>
> why not simple readl
When Channel enable(CCR_EN) is reset by SW, it is recommended to wait
for the CTCIF (Channel Transfer Complete interrupt flag) = 1, in order
to ensure that any ongoing buffer transfer has been completed, before
reprogramming the channel.
Moreover since this function might be called under interruption context
(a DMA Client may call dmaengine_terminate_all() for instance) function
cannot allow sleep. Timeout is for cases when IP is stuck and channel
cannot be disabled
>> +static void stm32_mdma_set_dst_bus(struct stm32_mdma_device *dmadev, u32 *ctbr,
>> + u32 dst_addr)
>> +{
>> + u32 mask;
>> + int i;
>> +
>> + /* Check if memory device is on AHB or AXI */
>> + *ctbr &= ~STM32_MDMA_CTBR_DBUS;
>> + mask = dst_addr & 0xF0000000;
>> + for (i = 0; i < dmadev->nr_ahb_addr_masks; i++) {
>> + if (mask == dmadev->ahb_addr_masks[i]) {
>> + *ctbr |= STM32_MDMA_CTBR_DBUS;
>> + break;
>> + }
>> + }
>> +}
>> +
>> +static void stm32_mdma_set_src_bus(struct stm32_mdma_device *dmadev, u32 *ctbr,
>> + u32 src_addr)
>> +{
>> + u32 mask;
>> + int i;
>> +
>> + /* Check if memory device is on AHB or AXI */
>> + *ctbr &= ~STM32_MDMA_CTBR_SBUS;
>> + mask = src_addr & 0xF0000000;
>> + for (i = 0; i < dmadev->nr_ahb_addr_masks; i++) {
>> + if (mask == dmadev->ahb_addr_masks[i]) {
>> + *ctbr |= STM32_MDMA_CTBR_SBUS;
>> + break;
>> + }
>> + }
>
> these too look awfully same..
Ok. I will create a common function then.
>
>> +static int __init stm32_mdma_init(void)
>> +{
>> + return platform_driver_probe(&stm32_mdma_driver, stm32_mdma_probe);
>> +}
>> +
>> +subsys_initcall(stm32_mdma_init);
>
> why subsys?
>
subsys_initcall level is to ensure MDMA is going to be probed before its
clients
>> --
>> 1.9.1
>>
>
^ permalink raw reply
* [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support
From: Yury Norov @ 2017-04-26 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420190530.GA6873@worktop>
On Thu, Apr 20, 2017 at 09:05:30PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 20, 2017 at 09:23:18PM +0300, Yury Norov wrote:
> > Is there some test to reproduce the locking failure for the case.
>
> Possibly sysvsem stress before commit:
>
> 27d7be1801a4 ("ipc/sem.c: avoid using spin_unlock_wait()")
>
> Although a similar scheme is also used in nf_conntrack, see commit:
>
> b316ff783d17 ("locking/spinlock, netfilter: Fix nf_conntrack_lock() barriers")
>
> > I
> > ask because I run loctorture for many hours on my qemu (emulating
> > cortex-a57), and I see no failures in the test reports. And Jan did it
> > on ThunderX, and Adam on QDF2400 without any problems. So even if I
> > rework those functions, how could I check them for correctness?
>
> Running them doesn't prove them correct. Memory ordering bugs have been
> in the kernel for many years without 'ever' triggering. This is stuff
> you have to think about.
>
> > Anyway, regarding the queued_spin_unlock_wait(), is my understanding
> > correct that you assume adding smp_mb() before entering the for(;;)
> > cycle, and using ldaxr/strxr instead of atomic_read()?
>
> You'll have to ask Will, I always forget the arm64 details.
So, below is what I have. For queued_spin_unlock_wait() the generated
code is looking like this:
ffff0000080983a0 <queued_spin_unlock_wait>:
ffff0000080983a0: d5033bbf dmb ish
ffff0000080983a4: b9400007 ldr w7, [x0]
ffff0000080983a8: 350000c7 cbnz w7, ffff0000080983c0 <queued_spin_unlock_wait+0x20>
ffff0000080983ac: 1400000e b ffff0000080983e4 <queued_spin_unlock_wait+0x44>
ffff0000080983b0: d503203f yield
ffff0000080983b4: d5033bbf dmb ish
ffff0000080983b8: b9400007 ldr w7, [x0]
ffff0000080983bc: 34000147 cbz w7, ffff0000080983e4 <queued_spin_unlock_wait+0x44>
ffff0000080983c0: f2401cff tst x7, #0xff
ffff0000080983c4: 54ffff60 b.eq ffff0000080983b0 <queued_spin_unlock_wait+0x10>
ffff0000080983c8: 14000003 b ffff0000080983d4 <queued_spin_unlock_wait+0x34>
ffff0000080983cc: d503201f nop
ffff0000080983d0: d503203f yield
ffff0000080983d4: d5033bbf dmb ish
ffff0000080983d8: b9400007 ldr w7, [x0]
ffff0000080983dc: f2401cff tst x7, #0xff
ffff0000080983e0: 54ffff81 b.ne ffff0000080983d0 <queued_spin_unlock_wait+0x30>
ffff0000080983e4: d50339bf dmb ishld
ffff0000080983e8: d65f03c0 ret
ffff0000080983ec: d503201f nop
If I understand the documentation correctly, it's enough to check the lock
properly. If not - please give me the clue. Will?
Yury
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 22dbde97eefa..2d80161ee367 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -25,6 +25,8 @@ config ARM64
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
select ARCH_WANT_FRAME_POINTERS
select ARCH_HAS_UBSAN_SANITIZE_ALL
+ select ARCH_USE_QUEUED_SPINLOCKS
+ select ARCH_USE_QUEUED_RWLOCKS
select ARM_AMBA
select ARM_ARCH_TIMER
select ARM_GIC
diff --git a/arch/arm64/include/asm/qrwlock.h b/arch/arm64/include/asm/qrwlock.h
new file mode 100644
index 000000000000..626f6ebfb52d
--- /dev/null
+++ b/arch/arm64/include/asm/qrwlock.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_ARM64_QRWLOCK_H
+#define _ASM_ARM64_QRWLOCK_H
+
+#include <asm-generic/qrwlock_types.h>
+#include <asm-generic/qrwlock.h>
+
+#endif /* _ASM_ARM64_QRWLOCK_H */
diff --git a/arch/arm64/include/asm/qspinlock.h b/arch/arm64/include/asm/qspinlock.h
new file mode 100644
index 000000000000..09ef4f13f549
--- /dev/null
+++ b/arch/arm64/include/asm/qspinlock.h
@@ -0,0 +1,42 @@
+#ifndef _ASM_ARM64_QSPINLOCK_H
+#define _ASM_ARM64_QSPINLOCK_H
+
+#include <asm-generic/qspinlock_types.h>
+#include <asm/atomic.h>
+
+extern void queued_spin_unlock_wait(struct qspinlock *lock);
+#define queued_spin_unlock_wait queued_spin_unlock_wait
+
+#define queued_spin_unlock queued_spin_unlock
+/**
+ * queued_spin_unlock - release a queued spinlock
+ * @lock : Pointer to queued spinlock structure
+ *
+ * A smp_store_release() on the least-significant byte.
+ */
+static __always_inline void queued_spin_unlock(struct qspinlock *lock)
+{
+ smp_store_release((u8 *)lock, 0);
+}
+
+#define queued_spin_is_locked queued_spin_is_locked
+/**
+ * queued_spin_is_locked - is the spinlock locked?
+ * @lock: Pointer to queued spinlock structure
+ * Return: 1 if it is locked, 0 otherwise
+ */
+static __always_inline int queued_spin_is_locked(struct qspinlock *lock)
+{
+ /*
+ * See queued_spin_unlock_wait().
+ *
+ * Any !0 state indicates it is locked, even if _Q_LOCKED_VAL
+ * isn't immediately observable.
+ */
+ smp_mb();
+ return atomic_read(&lock->val);
+}
+
+#include <asm-generic/qspinlock.h>
+
+#endif /* _ASM_ARM64_QSPINLOCK_H */
diff --git a/arch/arm64/include/asm/spinlock.h b/arch/arm64/include/asm/spinlock.h
index cae331d553f8..37713397e0c5 100644
--- a/arch/arm64/include/asm/spinlock.h
+++ b/arch/arm64/include/asm/spinlock.h
@@ -20,6 +20,10 @@
#include <asm/spinlock_types.h>
#include <asm/processor.h>
+#ifdef CONFIG_QUEUED_SPINLOCKS
+#include <asm/qspinlock.h>
+#else
+
/*
* Spinlock implementation.
*
@@ -187,6 +191,12 @@ static inline int arch_spin_is_contended(arch_spinlock_t *lock)
}
#define arch_spin_is_contended arch_spin_is_contended
+#endif /* CONFIG_QUEUED_SPINLOCKS */
+
+#ifdef CONFIG_QUEUED_RWLOCKS
+#include <asm/qrwlock.h>
+#else
+
/*
* Write lock implementation.
*
@@ -351,6 +361,8 @@ static inline int arch_read_trylock(arch_rwlock_t *rw)
/* read_can_lock - would read_trylock() succeed? */
#define arch_read_can_lock(x) ((x)->lock < 0x80000000)
+#endif /* CONFIG_QUEUED_RWLOCKS */
+
#define arch_read_lock_flags(lock, flags) arch_read_lock(lock)
#define arch_write_lock_flags(lock, flags) arch_write_lock(lock)
diff --git a/arch/arm64/include/asm/spinlock_types.h b/arch/arm64/include/asm/spinlock_types.h
index 55be59a35e3f..0f0f1561ab6a 100644
--- a/arch/arm64/include/asm/spinlock_types.h
+++ b/arch/arm64/include/asm/spinlock_types.h
@@ -16,9 +16,9 @@
#ifndef __ASM_SPINLOCK_TYPES_H
#define __ASM_SPINLOCK_TYPES_H
-#if !defined(__LINUX_SPINLOCK_TYPES_H) && !defined(__ASM_SPINLOCK_H)
-# error "please don't include this file directly"
-#endif
+#ifdef CONFIG_QUEUED_SPINLOCKS
+#include <asm-generic/qspinlock_types.h>
+#else
#include <linux/types.h>
@@ -36,10 +36,18 @@ typedef struct {
#define __ARCH_SPIN_LOCK_UNLOCKED { 0 , 0 }
+#endif /* CONFIG_QUEUED_SPINLOCKS */
+
+#ifdef CONFIG_QUEUED_RWLOCKS
+#include <asm-generic/qrwlock_types.h>
+#else
+
typedef struct {
volatile unsigned int lock;
} arch_rwlock_t;
#define __ARCH_RW_LOCK_UNLOCKED { 0 }
+#endif /* CONFIG_QUEUED_RWLOCKS */
+
#endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 9d56467dc223..f48f6256e893 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -56,6 +56,7 @@ arm64-obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o \
arm64-obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
arm64-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
+arm64-obj-$(CONFIG_QUEUED_SPINLOCKS) += qspinlock.o
obj-y += $(arm64-obj-y) vdso/ probes/
obj-$(CONFIG_ARM64_ILP32) += vdso-ilp32/
diff --git a/arch/arm64/kernel/qspinlock.c b/arch/arm64/kernel/qspinlock.c
new file mode 100644
index 000000000000..924f19953adb
--- /dev/null
+++ b/arch/arm64/kernel/qspinlock.c
@@ -0,0 +1,34 @@
+#include <asm/qspinlock.h>
+#include <asm/processor.h>
+
+void queued_spin_unlock_wait(struct qspinlock *lock)
+{
+ u32 val;
+
+ for (;;) {
+ smp_mb();
+ val = atomic_read(&lock->val);
+
+ if (!val) /* not locked, we're done */
+ goto done;
+
+ if (val & _Q_LOCKED_MASK) /* locked, go wait for unlock */
+ break;
+
+ /* not locked, but pending, wait until we observe the lock */
+ cpu_relax();
+ }
+
+ for (;;) {
+ smp_mb();
+ val = atomic_read(&lock->val);
+ if (!(val & _Q_LOCKED_MASK)) /* any unlock is good */
+ break;
+
+ cpu_relax();
+ }
+
+done:
+ smp_acquire__after_ctrl_dep();
+}
+EXPORT_SYMBOL(queued_spin_unlock_wait);
--
2.11.0
^ permalink raw reply related
* [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation
From: Christoffer Dall @ 2017-04-26 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4dc866a0-582c-af69-916f-eb435988b5ec@redhat.com>
On Wed, Apr 26, 2017 at 11:57:16AM +0200, Auger Eric wrote:
> Hi Peter, Dave,
>
> On 26/04/2017 10:48, Dr. David Alan Gilbert wrote:
> > * Peter Maydell (peter.maydell at linaro.org) wrote:
> >> On 26 April 2017 at 09:26, Auger Eric <eric.auger@redhat.com> wrote:
> >>> On 25/04/2017 12:43, Peter Maydell wrote:
> >>>> When does the -EFAULT return happen? (if the guest points GITS_BASER<n>
> >>>> etc at invalid memory, presumably?)
> >>>
> >>> Yes that's correct, when GICR_PENDBASER contains a bad GPA.
> >>>
> >>>> How does the QEMU migration code
> >>>> handle this case? Failing migration because the guest has done something
> >>>> silly doesn't seem too palatable, but trying to avoid that could be
> >>>> more effort than an obscure corner case really merits.
> >>>
> >>> The kvm_device_access will cause an abort() as for other errors returned
> >>> by kvm_device_ioctl().
> >>
> >> That's pretty nasty. Guests shouldn't be able to provoke QEMU
> >> into abort()ing, ideally. We don't necessarily have to produce
> >> a successful migration, but we should at least fail it cleanly.
> >
> > Yes, no abort()'s during migration due to guest behaviour.
> > They always end up coming back around to being filed as migration
> > bugs and people worry why they've got cores.
> >
> > Ideally log a message into stderr to say that the guest state
> > is inconsistent so that when someone comes to debug it then they
> > can see it's obvious.
>
> OK I agree. I will respin the QEMU part accordingly and in that
> situation I won't abort and will print a message.
>
Alternatively we should mark a pending error notification to the guest
in KVM, so that when the guest boots it gets something like an SError
instead, given that presumably the guest wrote the weird value. Except
of course if the problem is caused by QEMU fudging with the register
value for the PENDBASER.
Just a thought.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation
From: Peter Maydell @ 2017-04-26 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426130020.GM4104@cbox>
On 26 April 2017 at 14:00, Christoffer Dall <cdall@linaro.org> wrote:
> Alternatively we should mark a pending error notification to the guest
> in KVM, so that when the guest boots it gets something like an SError
> instead, given that presumably the guest wrote the weird value. Except
> of course if the problem is caused by QEMU fudging with the register
> value for the PENDBASER.
If we have scope for complaining at the guest we should do it at
the point where the guest sets PENDBASER in the first place...
thanks
-- PMM
^ permalink raw reply
* [PATCH v5 00/22] vITS save/restore
From: Christoffer Dall @ 2017-04-26 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACJhumdaHDX2oAuJ2PQCqhmJV0u7Eu9SF7a8xsga6sAwJHyrCQ@mail.gmail.com>
Hi Prakash,
On Wed, Apr 26, 2017 at 05:08:07PM +0530, Prakash B wrote:
> Verified on Cavium ThunderX platform
> Continousily migrated Guest more than 500 times b/w different hosts.
> Please feel free to add Tested-by: Prakash, Brahmajyosyula
> <Brahmajyosyula.Prakash@cavium.com>
I appreciate you looking at these patches and testing them (reviews
would have been even more helpful), but in the future you don't need to
reply to each individual patch that you've tested it, but can just give
your tested-by as a single reply to the cover letter.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Gregory CLEMENT @ 2017-04-26 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYYRe4A+Zj+fDpC9SA1pgaVSgewYGB_vCNoWNRXWTtTGQ@mail.gmail.com>
Hi Linus,
On mer., avril 26 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Apr 26, 2017 at 11:23 AM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>> On lun., avril 24 2017, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>>>> + spin_lock_irqsave(&info->irq_lock, flags);
>>>> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
>>>> + /* Manage only the interrupt that was enabled */
>>>> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
>>>> + spin_unlock_irqrestore(&info->irq_lock, flags);
>>>> + while (status) {
>>>> + u32 hwirq = ffs(status) - 1;
>>>> + u32 virq = irq_find_mapping(d, hwirq +
>>>> + i * GPIO_PER_REG);
>>>> +
>>>> + generic_handle_irq(virq);
>>>> + status &= ~BIT(hwirq);
>>>> + }
>>>
>>> You hae a problem here is a new IRQ appears while you are inside
>>> of this loop. You need to re-read the status register for each iteration
>>> (and &= with the IRQ_EN I guess).
>>
>> If a new IRQ appears during the loop, then the irq handler will be
>> called again because the cause of this new IRQ won't have been acked
>> yet. So I think we're fine here.
>
> That *might* be true. It is true if the CPU gets a level IRQ from the
> GPIO controller. But hardware dealing with edge IRQs can be very
> quirky here, and just send a pulse on the line to the CPU if the
> CPU-bound IRQ is also just edge triggered. And then that
> pulse would potentially be missed while dealing with the current
> IRQ in this handler. (And exactly this happened to us on other
> hardware.)
OK thanks for sharing your experience, you convinced me, I am going to
send a new version of the patch with this fix.
>
> But anyway: why let the irq handler be called again if you can avoid
> it?
> You would avoid a double context switch by just checking it again
> in the loop before exiting the handler. And that can be really nice
> for latency-sensitive stuff.
I wanted to avoid an uncached access in each loop if it was not
necessary. But as we finally need it, I will do it.
Gregory
>
> Yours,
> Linus Walleij
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation
From: Christoffer Dall @ 2017-04-26 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA8t0Y-UBu_Fx_YTsmnw8zvd4fctTfobdb-akjdx_81PWA@mail.gmail.com>
On Wed, Apr 26, 2017 at 02:01:55PM +0100, Peter Maydell wrote:
> On 26 April 2017 at 14:00, Christoffer Dall <cdall@linaro.org> wrote:
> > Alternatively we should mark a pending error notification to the guest
> > in KVM, so that when the guest boots it gets something like an SError
> > instead, given that presumably the guest wrote the weird value. Except
> > of course if the problem is caused by QEMU fudging with the register
> > value for the PENDBASER.
>
> If we have scope for complaining at the guest we should do it at
> the point where the guest sets PENDBASER in the first place...
>
Is that what the hardware would have done?
Also, userspace could restore a bogus value in the PENDBASER (even
though the guest wrote something sane), so maybe we should just keep
this as is and handle it nicely in QEMU?
Thanks,
-Christoffer
> thanks
> -- PMM
^ permalink raw reply
* [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)
From: Pavel Machek @ 2017-04-26 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426081330.6ca10e42@vento.lan>
Hi!
> > > I don't see why it would be hard to open files or have threads inside
> > > a library. There are several libraries that do that already, specially
> > > the ones designed to be used on multimidia apps.
> >
> > Well, This is what the libv4l2 says:
> >
> > This file implements libv4l2, which offers v4l2_ prefixed versions
> > of
> > open/close/etc. The API is 100% the same as directly opening
> > /dev/videoX
> > using regular open/close/etc, the big difference is that format
> > conversion
> >
> > but if I open additional files in v4l2_open(), API is no longer the
> > same, as unix open() is defined to open just one file descriptor.
> >
> > Now. There is autogain support in libv4lconvert, but it expects to use
> > same fd for camera and for the gain... which does not work with
> > subdevs.
> >
> > Of course, opening subdevs by name like this is not really
> > acceptable. But can you suggest a method that is?
>
> There are two separate things here:
>
> 1) Autofoucs for a device that doesn't use subdev API
> 2) libv4l2 support for devices that require MC and subdev API
Actually there are three: 0) autogain. Unfortunately, I need autogain
first before autofocus has a chance...
And that means... bayer10 support for autogain.
Plus, I changed avg_lum to long long. Quick calculation tells me int
could overflow with few megapixel sensor.
Oh, btw http://ytse.tricolour.net/docs/LowLightOptimization.html no
longer works.
Regards,
Pavel
diff --git a/lib/libv4lconvert/processing/autogain.c b/lib/libv4lconvert/processing/autogain.c
index c6866d6..0b52d0f 100644
--- a/lib/libv4lconvert/processing/autogain.c
+++ b/lib/libv4lconvert/processing/autogain.c
@@ -68,6 +71,41 @@ static void autogain_adjust(struct v4l2_queryctrl *ctrl, int *value,
}
}
+static int get_luminosity_bayer10(uint16_t *buf, const struct v4l2_format *fmt)
+{
+ long long avg_lum = 0;
+ int x, y;
+
+ buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 +
+ fmt->fmt.pix.width / 4;
+
+ for (y = 0; y < fmt->fmt.pix.height / 2; y++) {
+ for (x = 0; x < fmt->fmt.pix.width / 2; x++)
+ avg_lum += *buf++;
+ buf += fmt->fmt.pix.bytesperline - fmt->fmt.pix.width / 2;
+ }
+ avg_lum /= fmt->fmt.pix.height * fmt->fmt.pix.width / 4;
+ avg_lum /= 4;
+ return avg_lum;
+}
+
+static int get_luminosity_bayer8(unsigned char *buf, const struct v4l2_format *fmt)
+{
+ long long avg_lum = 0;
+ int x, y;
+
+ buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 +
+ fmt->fmt.pix.width / 4;
+
+ for (y = 0; y < fmt->fmt.pix.height / 2; y++) {
+ for (x = 0; x < fmt->fmt.pix.width / 2; x++)
+ avg_lum += *buf++;
+ buf += fmt->fmt.pix.bytesperline - fmt->fmt.pix.width / 2;
+ }
+ avg_lum /= fmt->fmt.pix.height * fmt->fmt.pix.width / 4;
+ return avg_lum;
+}
+
/* auto gain and exposure algorithm based on the knee algorithm described here:
http://ytse.tricolour.net/docs/LowLightOptimization.html */
static int autogain_calculate_lookup_tables(
@@ -100,17 +142,16 @@ static int autogain_calculate_lookup_tables(
switch (fmt->fmt.pix.pixelformat) {
+ case V4L2_PIX_FMT_SGBRG10:
+ case V4L2_PIX_FMT_SGRBG10:
+ case V4L2_PIX_FMT_SBGGR10:
+ case V4L2_PIX_FMT_SRGGB10:
+ avg_lum = get_luminosity_bayer10((void *) buf, fmt);
+ break;
+
case V4L2_PIX_FMT_SGBRG8:
case V4L2_PIX_FMT_SGRBG8:
case V4L2_PIX_FMT_SBGGR8:
case V4L2_PIX_FMT_SRGGB8:
- buf += fmt->fmt.pix.height * fmt->fmt.pix.bytesperline / 4 +
- fmt->fmt.pix.width / 4;
-
- for (y = 0; y < fmt->fmt.pix.height / 2; y++) {
- for (x = 0; x < fmt->fmt.pix.width / 2; x++)
- avg_lum += *buf++;
- buf += fmt->fmt.pix.bytesperline - fmt->fmt.pix.width / 2;
- }
- avg_lum /= fmt->fmt.pix.height * fmt->fmt.pix.width / 4;
+ avg_lum = get_luminosity_bayer8(buf, fmt);
break;
case V4L2_PIX_FMT_RGB24:
diff --git a/lib/libv4lconvert/processing/libv4lprocessing.c b/lib/libv4lconvert/processing/libv4lprocessing.c
index b061f50..b98d024 100644
--- a/lib/libv4lconvert/processing/libv4lprocessing.c
+++ b/lib/libv4lconvert/processing/libv4lprocessing.c
@@ -164,6 +165,10 @@ void v4lprocessing_processing(struct v4lprocessing_data *data,
case V4L2_PIX_FMT_SGRBG8:
case V4L2_PIX_FMT_SBGGR8:
case V4L2_PIX_FMT_SRGGB8:
+ case V4L2_PIX_FMT_SGBRG10:
+ case V4L2_PIX_FMT_SGRBG10:
+ case V4L2_PIX_FMT_SBGGR10:
+ case V4L2_PIX_FMT_SRGGB10:
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
break;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170426/7ba6278a/attachment-0001.sig>
^ permalink raw reply related
* [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation
From: Peter Maydell @ 2017-04-26 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426131421.GA50776@lvm>
On 26 April 2017 at 14:14, Christoffer Dall <christoffer.dall@linaro.org> wrote:
> On Wed, Apr 26, 2017 at 02:01:55PM +0100, Peter Maydell wrote:
>> On 26 April 2017 at 14:00, Christoffer Dall <cdall@linaro.org> wrote:
>> > Alternatively we should mark a pending error notification to the guest
>> > in KVM, so that when the guest boots it gets something like an SError
>> > instead, given that presumably the guest wrote the weird value. Except
>> > of course if the problem is caused by QEMU fudging with the register
>> > value for the PENDBASER.
>>
>> If we have scope for complaining at the guest we should do it at
>> the point where the guest sets PENDBASER in the first place...
>>
>
> Is that what the hardware would have done?
I think it's UNPREDICTABLE to enable the GIC with a bogus PENDBASER,
but I can't find the bit in the spec that actually says that.
I don't know what hardware actually does, but I imagine it will
only notice that it's been handed bogus memory at the point where
it tries to use it.
> Also, userspace could restore a bogus value in the PENDBASER (even
> though the guest wrote something sane), so maybe we should just keep
> this as is and handle it nicely in QEMU?
Yeah, I don't have a strong objection to doing it that way round.
thanks
-- PMM
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Jayachandran C @ 2017-04-26 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426101021.GF21744@arm.com>
On Wed, Apr 26, 2017 at 11:10:21AM +0100, Will Deacon wrote:
> On Wed, Apr 26, 2017 at 07:22:46AM +0000, Pinski, Andrew wrote:
> > On 4/25/2017 11:53 PM, Jayachandran C. wrote:
> > > On Tue, Apr 25, 2017 at 10:23 PM, Will Deacon <will.deacon@arm.com> wrote:
> > >> On Tue, Apr 25, 2017 at 09:13:40AM +0530, Ganapatrao Kulkarni wrote:
> > >>> On Mon, Apr 24, 2017 at 9:15 PM, Will Deacon <will.deacon@arm.com> wrote:
> > >>>> On Thu, Apr 20, 2017 at 02:56:50PM +0530, Ganapatrao Kulkarni wrote:
> > >>>>> OK, if you are ok with sysfs part, i can send next version with that
> > >>>>> change only?.
> > >>>> I think the sysfs part is still a little dodgy, since you still expose the
> > >>>> "exclude_hv" file with a value of 0 when not running at EL2, which would
> > >>>> imply that exclude_hv is forced to zero. I don't think that's correct.
> > >>> okay, i can make exclude_hv visible only when kernel booted in EL2.
> > >>> is it ok to have empty directory "attr" when kernel booted to EL1?
> > >>> attr can be place holder for any other miscellaneous attributes, that
> > >>> can be added in future.
> > >> Sounds good to me, although I'll seek comment from the other perf folks
> > >> before merging anything with ABI implications.
> > > Do you really think this is the solution given:
> > > - this is an arm64 specific sysfs interface that is tied to the perf API
>
> That's why I want feedback from others. The intention would be that this can
> be used by other PMUs as well, since it's not uncommon that parts of the
> sizeable perf_event_attr structure are not used by a given PMU.
>
> > > - the perf API documentation has to be updated for this
>
> So? If having to update documentation means we shouldn't change the kernel,
> then we may as well all find new jobs.
>
> > > - All the applications that use the perf API have to be modified to
> > > check this sysfs interface
> > > - If the application fails to do so, a very narrow corner case
> > > (exclude_hv != exclude_kernel and VHE enabled) fails.
>
> See below, but apparently people care about it.
>
> > > Any application that really cares can already do see if exclude_hv !=
> > > exclude_kernel case works by calling perf_open_event() with those
> > > options and checking the return value.
>
> That's a good point: there is *something* userspace can do, although that
> would be arm64-specific and doesn't really help with the state-space
> explosion you get with combinations of invalid/unused perf_event_attr
> fields.
>
> > An example of an application which needs to changed is HHVM. Currently
> > it sets exclude_hv to true but exclude_kernel to false as it does not
> > care about the hypervisor associated perf events associated with the
> > code, only the kernel and userspace associated evnts.
> > Yes we could submit a patch to use the sysfs interface to check but it
> > would look funny and the facebook folks might reject the patch as it is
> > ARM64 specific in generic code. Note this is how all of this discussion
> > started was HHVM's call to perf_open_event was failing.
>
> Hmm, if you're saying that HHVM won't be changed to use the sysfs stuff,
> then why are we bothering?
>
> Not sure where this leaves us.
If my understanding is correct, the sysfs suggestion above is going to
add API complexity without solving the issue. Ignoring the exclude_hv if
it cannot be honored would be a better solution.
If that is not acceptable (which seems to be the case - but I do not
see a reason for that), I think the better option for the application
is to check if the platform supports the mode exclusion it wants by
using the perf_event_open API itself.
Thanks,
JC.
^ permalink raw reply
* [PATCH v7 1/4] syscalls: Restore address limit after a syscall
From: Thomas Garnier @ 2017-04-26 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426081229.6wnugrs7w3at4xry@gmail.com>
On Wed, Apr 26, 2017 at 1:12 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Thomas Garnier <thgarnie@google.com> wrote:
>
>> >> +#ifdef CONFIG_ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE
>> >> +/*
>> >> + * This function is called when an architecture specific implementation detected
>> >> + * an invalid address limit. The generic user-mode state checker will finish on
>> >> + * the appropriate BUG_ON.
>> >> + */
>> >> +asmlinkage void address_limit_check_failed(void)
>> >> +{
>> >> + verify_pre_usermode_state();
>> >> + panic("address_limit_check_failed called with a valid user-mode state");
>> >
>> > It's very unconstructive to unconditionally panic the system, just because some
>> > kernel code leaked the address limit! Do a warn-once printout and kill the current
>> > task (i.e. don't continue execution), but don't crash everything else!
>>
>> The original change did not crash the kernel for this exact reason.
>> Through reviews, there was an overall agreement that the kernel should
>> not continue in this state.
>
> Ok, I guess we can try that - but the panic message is still pretty misleading:
>
> panic("address_limit_check_failed called with a valid user-mode state");
>
> ... so it was called with a _valid_ user-mode state, and we crash due to something
> valid? Huh?
Yes the message is accurate but I agree that it is misleading and I
will improve it. The address_limit_check_failed function is called by
assembly code on different architectures once the state was detected
as invalid. Instead of crashing at different places, we redirect to
the generic handler (verify_pre_usermode_state) that will crash on the
appropriate BUG_ON line. The address_limit_check_failed function is
not supposed to comeback, the panic call is just a safe guard.
>
> ( Also, the style rule applies to kernel messages as well: function names should
> be referred to as "function_name()". )
Will change.
>
> Thanks,
>
> Ingo
--
Thomas
^ permalink raw reply
* Updating kernel.org cross compilers?
From: Andre Przywara @ 2017-04-26 14:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
(Tony: I've seen you redirecting to "Chris" in an older email, but the
web archive doesn't have his email address)
It seems that many people (even outside the Linux kernel community) use
the cross compilers provided at kernel.org/pub/tools/crosstool.
The latest compiler I find there is 4.9.0, which celebrated its third
birthday at the weekend, also has been superseded by 4.9.4 meanwhile.
So I took Segher's buildall scripts from [1] and threw binutils 2.28 and
GCC 6.3.0 at them. After removing --enable-sjlj-exceptions from
build-gcc and adding --disable-multilib (for building x86-64 on a x86-64
box without 32-bit libs) I was able to build (bare-metal) toolchains for
all architectures except arc, m68k, tilegx and tilepro.
Now my understanding is that a baremetal/stage 1 compiler should be
build with "all-gcc" instead of the implicit "all" make target, and
"install-gcc" instead of "install". And indeed adding this to build-gcc
makes all toolchains build now - except arc, which needs an explicit
"--with-cpu=arc700" on the GCC configure command line.
So after those changes, the sequence:
$ ./buildall --toolchain
$ PATH=$PATH:/opt/cross/bin
$ ./buildall --kernel
worked reasonably well for me (binutils 2.28, GCC 6.3.0, Linux 4.11-rc8
on an Intel host with Ubuntu 14.04.5). Just tilegx/pro is still broken
due to toolchain issues.
So I wonder what the process is to get those compilers updated?
And what is a good build setup, so that the binaries run on as many
systems as possible?
Also the web page (https://www.kernel.org/pub/tools/crosstool) seems to
only link outdated builds (4.6.3, mostly), is that on purpose?
Cheers,
Andre.
[1] http://git.infradead.org/users/segher/buildall.git/
^ permalink raw reply
* [PATCH] iommu: Print a message with the default domain type created
From: Robert Richter @ 2017-04-26 14:38 UTC (permalink / raw)
To: linux-arm-kernel
There are several ways the bypass mode can be enabled. With commit
fccb4e3b8ab0 iommu: Allow default domain type to be set on the kernel command line
there is the option to switch into bypass mode. And, depending on
devicetree options, bypass mode can be also enabled. This makes it
hard to determine if direct mapping is enabled. Print message with the
default domain type case.
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
drivers/iommu/iommu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3b67144dead2..ae84899dabd2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -586,7 +586,9 @@ int iommu_group_add_device(struct iommu_group *group, struct device *dev)
trace_add_device_to_group(group->id, dev);
- pr_info("Adding device %s to group %d\n", dev_name(dev), group->id);
+ pr_info("Adding device %s to group %d, default domain type %d\n",
+ dev_name(dev), group->id,
+ group->default_domain ? group->default_domain->type : -1);
return 0;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 08/12] regulator: axp20x-regulator: add support for AXP803
From: Mark Brown @ 2017-04-26 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-9-icenowy@aosc.io>
On Mon, Apr 17, 2017 at 07:57:43PM +0800, Icenowy Zheng wrote:
> AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
> controllable via I2C/RSB bus.
>
> Add support for them.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Mark Brown <broonie@kernel.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170426/7e9f32cf/attachment.sig>
^ permalink raw reply
* [PATCH v5 02/22] KVM: arm/arm64: Add GICV3 pending table save API documentation
From: Auger Eric @ 2017-04-26 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA-3QL-1=RYhZ-xo0rgYTjRvxhWJfBVrT1f2G_j5t8Wj7A@mail.gmail.com>
Hi Peter, Christoffer,
On 26/04/2017 15:26, Peter Maydell wrote:
> On 26 April 2017 at 14:14, Christoffer Dall <christoffer.dall@linaro.org> wrote:
>> On Wed, Apr 26, 2017 at 02:01:55PM +0100, Peter Maydell wrote:
>>> On 26 April 2017 at 14:00, Christoffer Dall <cdall@linaro.org> wrote:
>>>> Alternatively we should mark a pending error notification to the guest
>>>> in KVM, so that when the guest boots it gets something like an SError
>>>> instead, given that presumably the guest wrote the weird value. Except
>>>> of course if the problem is caused by QEMU fudging with the register
>>>> value for the PENDBASER.
>>>
>>> If we have scope for complaining at the guest we should do it at
>>> the point where the guest sets PENDBASER in the first place...
>>>
>>
>> Is that what the hardware would have done?
>
> I think it's UNPREDICTABLE to enable the GIC with a bogus PENDBASER,
> but I can't find the bit in the spec that actually says that.
> I don't know what hardware actually does, but I imagine it will
> only notice that it's been handed bogus memory at the point where
> it tries to use it.
>
>> Also, userspace could restore a bogus value in the PENDBASER (even
>> though the guest wrote something sane), so maybe we should just keep
>> this as is and handle it nicely in QEMU?
>
> Yeah, I don't have a strong objection to doing it that way round.
OK. I will only update the QEMU code then.
For info, without talking about save/restore, the GICR_PENDBASER is
sync'ed on LPI enable. if the vITS gets an error on kvm_read_guest, we
currently abort the sync without reporting any error.
GICR_PROPBASER is read on cmd execution (MAPI, INV, INVALL). No error is
reported at the moment. My understanding is our implementation chose the
3d alternative of GICV3 arch spec (6.3.2), ie. "the data that generated
the error or errors is treated as having a legal value", increment the
read cursor and currently we don't report any system error to the guest.
Thanks
Eric
>
> thanks
> -- PMM
>
^ permalink raw reply
* [PATCH v2] misc: sram-exec: Use aligned fncpy instead of memcpy
From: Tony Lindgren @ 2017-04-26 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170410145247.6023-1-d-gerlach@ti.com>
* Dave Gerlach <d-gerlach@ti.com> [170410 07:55]:
> Currently the sram-exec functionality, which allows allocation of
> executable memory and provides an API to move code to it, is only
> selected in configs for the ARM architecture. Based on commit
> 5756e9dd0de6 ("ARM: 6640/1: Thumb-2: Symbol manipulation macros for
> function body copying") simply copying a C function pointer address
> using memcpy without consideration of alignment and Thumb is unsafe on
> ARM platforms.
>
> The aforementioned patch introduces the fncpy macro which is a safe way
> to copy executable code on ARM platforms, so let's make use of that here
> rather than the unsafe plain memcpy that was previously used by
> sram_exec_copy. Now sram_exec_copy will move the code to "dst" and
> return an address that is guaranteed to be safely callable.
>
> In the future, architectures hoping to make use of the sram-exec
> functionality must define an fncpy macro just as ARM has done to
> guarantee or check for safe copying to executable memory before allowing
> the arch to select CONFIG_SRAM_EXEC.
Looks good to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH] perf evsel: Fix to perf-stat malloc corruption on arm64 platforms
From: Mark Rutland @ 2017-04-26 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493198780-25415-1-git-send-email-ganapatrao.kulkarni@cavium.com>
Hi Ganapatrao,
Thanks for tracking this down.
On Wed, Apr 26, 2017 at 02:56:20PM +0530, Ganapatrao Kulkarni wrote:
> In some cases, ncpus used for perf_evsel__alloc_fd and for
> perf_evsel__close are not the same, this is causing memory
> overwrite/corruption.
It would be good if we could enumerate when this occurs.
>From what I can tell, the problem occurs when opening a thread-bound
event on PMU with a cpus/cpumask in sysfs.
For perf-stat we create events using create_perf_stat_counter(). There
we see !target_has_cpu(), so we call perf_evsel__open_per_thread(). Thus
perf_evsel__open() is passed NULL cpus, and creates an empty cpu_map. As
cpus->nr = 1, we get 1 * nthreads fds allocated, and open events for
each of these.
Later, we try to close events using perf_evlist__close(). This doesn't
take target_has_cpu() into account, but sees evsel->cpus is non-NULL
(since the PMU had a cpus/cpumask file), and tries to close events for
cpus->nr * nthreads, and goes out-of-bounds of the fd array.
>
> Fixing issue by using same ncpus in perf_evsel__alloc_fd.
>
> This bug is more evident on arm64 platforms, which uses
> cpu_map(cpus) for PMU core devices.
>
> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
> ---
> tools/perf/util/evsel.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index ac59710..0dc94d7 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -1489,7 +1489,9 @@ int perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
> nthreads = threads->nr;
>
> if (evsel->fd == NULL &&
> - perf_evsel__alloc_fd(evsel, cpus->nr, nthreads) < 0)
> + perf_evsel__alloc_fd(evsel,
> + evsel->cpus ? evsel->cpus->nr : cpus->nr,
> + nthreads) < 0)
Unfortunately, I don't think this is the right fix.
Looking@the logic I added in commit:
9f21b815be863218 ("perf evlist: Only open events on CPUs an evsel permit").
... in some cases (e.g. when using perf record with cpu-bound events),
evsel->cpus may contain a subset of evlist->cpus, and thus the use of
evsel->cpus->nr here may lower the number of entries allocated, such
that the manipulation of fds will go out-of-bounds.
I think that to properly solve this, we need a more invasive rework,
ensuring that open/manipulation/close always deal with the same set of
cpus and threads for a given evsel.
I'm taking a look into that now.
Thanks,
Mark.
^ permalink raw reply
* [RFC/RFT PATCH 07/18] ARM: PCI: orion5x: Convert PCI scan API to pci_scan_root_bus_bridge()
From: Andrew Lunn @ 2017-04-26 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170426111809.19922-8-lorenzo.pieralisi@arm.com>
On Wed, Apr 26, 2017 at 12:17:58PM +0100, Lorenzo Pieralisi wrote:
> The introduction of pci_scan_root_bus_bridge() provides a PCI core
> API to scan a PCI root bus backed by an already initialized
> struct pci_host_bridge object, which simplifies the bus scan
> interface and makes the PCI scan root bus interface easier to
> generalize as members are added to the struct pci_host_bridge().
>
> Convert ARM orion5x platform code to pci_scan_root_bus_bridge() to
> improve the PCI root bus scanning interface.
Hi Lorenzo
Maybe there is something not right here.
With plain 4.11-rc7 i get:
root at orion5x:~# lspci -v
0000:00:00.0 Memory controller: Marvell Technology Group Ltd. 88f5182 [Orion-NAS] ARM SoC (rev 02)
Subsystem: Marvell Technology Group Ltd. Device 11ab
Flags: bus master, fast devsel, latency 0, IRQ 12
Memory at <ignored> (64-bit, prefetchable)
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [60] Express Root Port (Slot-), MSI 00
0001:01:00.0 Memory controller: Marvell Technology Group Ltd. 88f5182 [Orion-NAS] ARM SoC (rev 02)
Flags: bus master, fast Back2Back, 66MHz, medium devsel, latency 0
BIST result: 00
Memory at <unassigned> (64-bit, prefetchable)
Memory at <ignored> (64-bit, prefetchable)
Memory at <ignored> (64-bit, non-prefetchable)
Expansion ROM at <ignored> [disabled]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [60] PCI-X non-bridge device
Capabilities: [68] CompactPCI hot-swap <?>
However, with your patches applied i get:
0000:00:00.0 Memory controller: Marvell Technology Group Ltd. 88f5182 [Orion-NAS] ARM SoC (rev 02)
Subsystem: Marvell Technology Group Ltd. Device 11ab
Flags: bus master, fast devsel, latency 0
Memory at <ignored> (64-bit, prefetchable)
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [60] Express Root Port (Slot-), MSI 00
0001:01:00.0 Memory controller: Marvell Technology Group Ltd. 88f5182 [Orion-NAS] ARM SoC (rev 02)
Flags: bus master, fast Back2Back, 66MHz, medium devsel, latency 0
BIST result: 00
Memory at <unassigned> (64-bit, prefetchable)
Memory at <ignored> (64-bit, prefetchable)
Memory at <ignored> (64-bit, non-prefetchable)
Expansion ROM at <ignored> [disabled]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [60] PCI-X non-bridge device
Capabilities: [68] CompactPCI hot-swap <?>
Note that IRQ 12 has disappeared from Flags: on 0000:00:00.0.
Since there are no actual PCI devices on this bus, i cannot test if
interrupts are broken.
Andrew
^ permalink raw reply
* [PATCH v5 00/10] AXP803 PMIC support for Pine64
From: Icenowy Zheng @ 2017-04-26 15:20 UTC (permalink / raw)
To: linux-arm-kernel
The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).
This patchset adds support for it and enabled it in Pine64 device tree.
The basical part of AXP803 MFD driver is already applied, according to Lee.
Thus this patchset is now still two parts, but a bit different to older
revisions:
- Part1: from PATCH 1/10 to PATCH 5/10, which focus on enabling AXP803 in
the device tree: the RSB bus, the R_INTC interrupt controller (for the
NMI line, which is connected to AXP803 on Pine64), and finally the basical
AXP803 node.
- Part2: from PATCH 5/10 to PATCH 10/10, which are enabling the regulator
function of the AXP803 PMIC. Finally Wi-Fi function is added
as a usage of regulators function.
PATCH 1 adds RSB device nodes, which is used for the communication between
A64 and AXP803.
PATCH 2 adds device tree binding of A64 R_INTC.
PATCH 3 really adds support for A64 R_INTC in NMI driver.
PATCH 4 adds R_INTC node in A64 device tree.
PATCH 5 adds AXP803 node to the Pine64 device tree by using already
applied drivers/bindings.
PATCH 6 adds support for AXP803 regulators in AXP20x regulatoe driver.
(The binding is already applied)
PATCH 7 enables the AXP803 regulator cell in MFD driver.
PATCH 8 adds a DTSI file for AXP803, like other older AXP PMICs.
PATCH 9 enables AXP803 regulators in Pine64 device tree.
PATCH 10 enables Wi-Fi for Pine64.
Icenowy Zheng (10):
arm64: allwinner: a64: enable RSB on A64
irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
arm64: allwinner: a64: add NMI (R_INTC) controller on A64
arm64: allwinner: a64: add AXP803 node to Pine64 device tree
regulator: axp20x-regulator: add support for AXP803
mfd: axp20x: add axp20x-regulator cell for AXP803
arm64: allwinner: a64: add DTSI file for AXP803 PMIC
arm64: allwinner: a64: enable AXP803 regulators for Pine64
arm64: allwinner: a64: enable Wi-Fi for Pine64
.../interrupt-controller/allwinner,sunxi-nmi.txt | 7 +-
arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 27 ++++
drivers/irqchip/irq-sunxi-nmi.c | 13 ++
drivers/mfd/axp20x.c | 3 +-
drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++---
include/linux/mfd/axp20x.h | 37 +++++
8 files changed, 501 insertions(+), 25 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
--
2.12.2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox