* [PATCH v10 7/8] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
From: vijay.kilari at gmail.com @ 2016-12-01 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480576187-5012-1-git-send-email-vijay.kilari@gmail.com>
From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
Userspace requires to store and restore of line_level for
level triggered interrupts using ioctl KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO.
Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
---
arch/arm/include/uapi/asm/kvm.h | 7 ++++++
arch/arm64/include/uapi/asm/kvm.h | 6 +++++
virt/kvm/arm/vgic/vgic-kvm-device.c | 45 +++++++++++++++++++++++++++++++++++-
virt/kvm/arm/vgic/vgic-mmio-v3.c | 11 +++++++++
virt/kvm/arm/vgic/vgic-mmio.c | 46 +++++++++++++++++++++++++++++++++++++
virt/kvm/arm/vgic/vgic-mmio.h | 5 ++++
virt/kvm/arm/vgic/vgic.h | 2 ++
7 files changed, 121 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index 98658d9d..f347779 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -191,6 +191,13 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
+#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO 7
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT 10
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
+ (0x3fffffULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK 0x3ff
+#define VGIC_LEVEL_INFO_LINE_LEVEL 0
+
#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
/* KVM_IRQ_LINE irq field index values */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 91c7137..4100f8c 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -211,6 +211,12 @@ struct kvm_arch_memory_slot {
#define KVM_DEV_ARM_VGIC_GRP_CTRL 4
#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
+#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO 7
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT 10
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
+ (0x3fffffULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
+#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK 0x3ff
+#define VGIC_LEVEL_INFO_LINE_LEVEL 0
#define KVM_DEV_ARM_VGIC_CTRL_INIT 0
diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
index b6266fe..d5f7197 100644
--- a/virt/kvm/arm/vgic/vgic-kvm-device.c
+++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
@@ -510,6 +510,21 @@ static int vgic_v3_attr_regs_access(struct kvm_device *dev,
regid, reg);
break;
}
+ case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
+ unsigned int info, intid;
+
+ info = (attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
+ KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT;
+ if (info == VGIC_LEVEL_INFO_LINE_LEVEL) {
+ intid = attr->attr &
+ KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK;
+ ret = vgic_v3_line_level_info_uaccess(vcpu, is_write,
+ intid, reg);
+ } else {
+ ret = -EINVAL;
+ }
+ break;
+ }
default:
ret = -EINVAL;
break;
@@ -552,6 +567,17 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
return vgic_v3_attr_regs_access(dev, attr, ®, true);
}
+ case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
+ u32 __user *uaddr = (u32 __user *)(long)attr->addr;
+ u64 reg;
+ u32 tmp32;
+
+ if (get_user(tmp32, uaddr))
+ return -EFAULT;
+
+ reg = tmp32;
+ return vgic_v3_attr_regs_access(dev, attr, ®, true);
+ }
}
return -ENXIO;
}
@@ -587,8 +613,18 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
return ret;
return put_user(reg, uaddr);
}
- }
+ case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
+ u32 __user *uaddr = (u32 __user *)(long)attr->addr;
+ u64 reg;
+ u32 tmp32;
+ ret = vgic_v3_attr_regs_access(dev, attr, ®, false);
+ if (ret)
+ return ret;
+ tmp32 = reg;
+ return put_user(tmp32, uaddr);
+ }
+ }
return -ENXIO;
}
@@ -609,6 +645,13 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
return vgic_v3_has_attr_regs(dev, attr);
case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
return 0;
+ case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
+ if (((attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
+ KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT) ==
+ VGIC_LEVEL_INFO_LINE_LEVEL)
+ return 0;
+ break;
+ }
case KVM_DEV_ARM_VGIC_GRP_CTRL:
switch (attr->attr) {
case KVM_DEV_ARM_VGIC_CTRL_INIT:
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
index 51439c9..9491d72 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
@@ -809,3 +809,14 @@ int vgic_v3_redist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
return vgic_uaccess(vcpu, &rd_dev, is_write,
offset, val);
}
+
+int vgic_v3_line_level_info_uaccess(struct kvm_vcpu *vcpu, bool is_write,
+ u32 intid, u64 *val)
+{
+ if (is_write)
+ vgic_write_irq_line_level_info(vcpu, intid, *val);
+ else
+ *val = vgic_read_irq_line_level_info(vcpu, intid);
+
+ return 0;
+}
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index f81e0e5..28fef92b 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -371,6 +371,52 @@ void vgic_mmio_write_config(struct kvm_vcpu *vcpu,
}
}
+u64 vgic_read_irq_line_level_info(struct kvm_vcpu *vcpu, u32 intid)
+{
+ int i;
+ u64 val = 0;
+
+ for (i = 0; i < 32; i++) {
+ struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
+
+ if (irq->line_level)
+ val |= (1U << i);
+
+ vgic_put_irq(vcpu->kvm, irq);
+ }
+
+ return val;
+}
+
+void vgic_write_irq_line_level_info(struct kvm_vcpu *vcpu, u32 intid,
+ const u64 val)
+{
+ int i;
+
+ for (i = 0; i < 32; i++) {
+ struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
+
+ spin_lock(&irq->irq_lock);
+ if (val & (1U << i)) {
+ if (irq->config == VGIC_CONFIG_LEVEL) {
+ irq->line_level = true;
+ irq->pending = true;
+ vgic_queue_irq_unlock(vcpu->kvm, irq);
+ } else {
+ spin_unlock(&irq->irq_lock);
+ }
+ } else {
+ if (irq->config == VGIC_CONFIG_EDGE ||
+ (irq->config == VGIC_CONFIG_LEVEL &&
+ !irq->soft_pending))
+ irq->line_level = false;
+ spin_unlock(&irq->irq_lock);
+ }
+
+ vgic_put_irq(vcpu->kvm, irq);
+ }
+}
+
static int match_region(const void *key, const void *elt)
{
const unsigned int offset = (unsigned long)key;
diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
index 1cc7faf..b9423b4 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.h
+++ b/virt/kvm/arm/vgic/vgic-mmio.h
@@ -181,6 +181,11 @@ int vgic_validate_mmio_region_addr(struct kvm_device *dev,
const struct vgic_register_region *regions,
int nr_regions, gpa_t addr);
+u64 vgic_read_irq_line_level_info(struct kvm_vcpu *vcpu, u32 intid);
+
+void vgic_write_irq_line_level_info(struct kvm_vcpu *vcpu, u32 intid,
+ const u64 val);
+
unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
unsigned int vgic_v3_init_dist_iodev(struct vgic_io_device *dev);
diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
index eac272c..60d4350 100644
--- a/virt/kvm/arm/vgic/vgic.h
+++ b/virt/kvm/arm/vgic/vgic.h
@@ -144,6 +144,8 @@ int vgic_v3_cpu_sysregs_uaccess(struct kvm_vcpu *vcpu, bool is_write,
u64 id, u64 *val);
int vgic_v3_has_cpu_sysregs_attr(struct kvm_vcpu *vcpu, bool is_write, u64 id,
u64 *reg);
+int vgic_v3_line_level_info_uaccess(struct kvm_vcpu *vcpu, bool is_write,
+ u32 intid, u64 *val);
int kvm_register_vgic_device(unsigned long type);
void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr);
void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr);
--
1.9.1
^ permalink raw reply related
* [PATCH v10 8/8] arm/arm64: Documentation: Update arm-vgic-v3.txt
From: vijay.kilari at gmail.com @ 2016-12-01 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480576187-5012-1-git-send-email-vijay.kilari@gmail.com>
From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
Update error code returned for Invalid CPU interface register
value and access in AArch32 mode.
Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
---
Documentation/virtual/kvm/devices/arm-vgic-v3.txt | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
index 9348b3c..0f29850 100644
--- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
+++ b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
@@ -142,10 +142,12 @@ Groups:
KVM_DEV_ARM_VGIC_CPU_SYSREGS accesses the CPU interface registers for the
CPU specified by the mpidr field.
+ CPU interface registers access is not implemented for AArch32 mode.
+ Error -ENXIO is returned when accessed in AArch32 mode.
Errors:
-ENXIO: Getting or setting this register is not yet supported
-EBUSY: VCPU is running
- -EINVAL: Invalid mpidr supplied
+ -EINVAL: Invalid mpidr or register value supplied
KVM_DEV_ARM_VGIC_GRP_NR_IRQS
@@ -193,6 +195,11 @@ Groups:
Bit[n] indicates the status for interrupt vINTID + n.
+ Getting or setting the level info for an edge-triggered interrupt is
+ not guaranteed to work. To restore the complete state of the VGIC, the
+ configuration (edge/level) of interrupts must be restored before
+ restoring the level.
+
SGIs and any interrupt with a higher ID than the number of interrupts
supported, will be RAZ/WI. LPIs are always edge-triggered and are
therefore not supported by this interface.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/7] PWM: add pwm-stm32 DT bindings
From: Benjamin Gaignard @ 2016-12-01 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130212055.b57qkqy66j5gg57q@rob-hp-laptop>
2016-11-30 22:20 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Thu, Nov 24, 2016 at 04:14:19PM +0100, Benjamin Gaignard wrote:
>> Define bindings for pwm-stm32
>>
>> version 2:
>> - use parameters instead of compatible of handle the hardware configuration
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../devicetree/bindings/pwm/pwm-stm32.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> new file mode 100644
>> index 0000000..36263f0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> @@ -0,0 +1,37 @@
>> +STMicroelectronics PWM driver bindings for STM32
>> +
>> +Must be a sub-node of STM32 general purpose timer driver
>> +
>> +Required parameters:
>> +- compatible: Must be "st,stm32-pwm"
>> +- pinctrl-names: Set to "default".
>> +- pinctrl-0: List of phandles pointing to pin configuration nodes
>> + for PWM module.
>> + For Pinctrl properties, please refer to [1].
>> +
>> +Optional parameters:
>> +- st,breakinput: Set if the hardware have break input capabilities
>> +- st,breakinput-polarity: Set break input polarity. Default is 0
>> + The value define the active polarity:
>> + - 0 (active LOW)
>> + - 1 (active HIGH)
>> +- st,pwm-num-chan: Number of available PWM channels. Default is 0.
>> +- st,32bits-counter: Set if the hardware have a 32 bits counter
>> +- st,complementary: Set if the hardware have complementary output channels
>
> What does complementary mean here?
Complementary channels are pwm channels where the signal level is inverted
compare to the original channel.
This parameter indicate that the hardware have this kind of outputs.
If the polarity of the original channel change then polarity of
complementary channel
change too.
>
>> +
>> +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>> +
>> +Example:
>> + gptimer1: gptimer1 at 40010000 {
>
> timer at ...
I would like keep "timer" for timer-trigger sub-node
>
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm1 at 0 {
>
> pwm {
>
> Is there more than one?
Not per hardware block but their is 12 of them in the SoC.
Adding a number (which match with SoC documentation) help to find
the wanted pwm in sysfs either we only have the address.
>
>> + compatible = "st,stm32-pwm";
>> + st,pwm-num-chan = <4>;
>> + st,breakinput;
>> + st,complementary;
>> + };
>> + };
>> --
>> 1.9.1
>>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Maxime Ripard @ 2016-12-01 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1777251480557779@web18m.yandex.ru>
On Thu, Dec 01, 2016 at 10:02:59AM +0800, Icenowy Zheng wrote:
>
>
> 01.12.2016, 04:52, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> > On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej ?krabec wrote:
> >> ?> > > > The only
> >> ?> > > > code left from you is for DE2. HDMI stuff is basically copied from
> >> ?> > > > Rockhip
> >> ?> > > > driver (including EDID reading), TCON code is now reverted to the same
> >> ?> > > > as
> >> ?> > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> >> ?> > > > code
> >> ?> > > > and compare it.
> >> ?> > >
> >> ?> > > So is the TCON of DE 2.0 identical to the original TCON?
> >> ?> > >
> >> ?> > > If so, we should reuse sun4i-tcon ...
> >> ?> >
> >> ?> > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> >> ?> > one for TV. However, register offsets are same as before, so I guess
> >> ?> > driver reusage make sense. I think that there are few additional
> >> ?> > registers, but they can be ignored for simplefb.
> >> ?>
> >> ?> The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> >> ?> clock and I/O area.
> >> ?>
> >>
> >> ?True, H3 user manual can be misleading sometimes. But this doesn't change the
> >> ?fact that TCON0 has same register offsets with same meaning.
> >
> > Then yes, we should definitely share the drivers too. So, in the end,
> > the only thing that is actually new is the display-engine?
>
> And HDMI PHY on H3 ;-)
Yes, and that one :)
> In my opinion, we should just put sun8i-de2-drm related code into
> drivers/gpu/drm/sun4i/ . (Or rename the directory to sunxi)
We should definitely reuse the drivers that are already in there for
the TCON and HDMI parts.
I'd have to look at the exact amount of code that would be needed to
support the new display engine, but I guess if it's big, then a
separate folder makes sense, if it isn't, then putting it in sun4i
makes sense (but I'm reluctant to renaming it to sunxi).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161201/dfa70723/attachment.sig>
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Match Updates for v4.10
From: Simon Horman @ 2016-12-01 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6791283.iMDbrK21lt@wuerfel>
On Wed, Nov 30, 2016 at 04:50:20PM +0100, Arnd Bergmann wrote:
> On Wednesday, November 23, 2016 9:13:31 PM CET Simon Horman wrote:
> > This pull request is based on the pull request "soc_device_match()
> > interface for matching against soc_bus attributes" sent by Geert
> > Uytterhoeven which corresponds to the soc-device-match-tag1 tag in his
> > renesas-driver's tree. It provides infrastructure used by changes in this
> > pull request.
> >
> > This pull request is broken out of an earlier pull request,
> > "Second Round of Renesas ARM Based SoC Drivers Updates for v4.10".
> > The motivation for breaking up the pull request is to provide
> > branches with minimal dependencies.
> >
> > This pull request is targeted at the next/drivers branch of the arm-soc tree.
> >
> > It introduces some minor merge conflicts in drivers/soc/renesas/Makefile.
> > The resolution is to take both sides. A sample merge resolution is
> > provided in the renesas-next-20161123v2-v4.9-rc1 tag of the renesas tree.
> >
>
> Pulled into next/drivers, thanks!
Thanks for pulling this and other outstanding pull requests from Geert and
myself. I don't think we have anything more outstanding at this time.
^ permalink raw reply
* [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Tomasz Nowicki @ 2016-12-01 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201002812.GB9409@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn,
On 01.12.2016 01:28, Bjorn Helgaas wrote:
> Hi Tomasz,
>
> On Tue, Nov 15, 2016 at 10:14:57AM +0100, Tomasz Nowicki wrote:
>> ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
>> compliant with ECAM standard. It uses non-standard configuration space
>> accessors (see pci_thunder_pem_ops) and custom configuration space granulation
>> (see bus_shift = 24). In order to access configuration space and
>> probe PEM as ACPI based PCI host controller we need to add MCFG quirk
>> infrastructure. This involves:
>> 1. thunder_pem_init() ACPI extension so that we can probe PEM-specific
>> register ranges analogously to DT
>> 2. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
>> code.
>> 3. New quirk entries for each PEM segment. Each contains platform IDs,
>> mentioned pci_thunder_pem_ops and CFG resources.
>>
>> Quirk is considered for ThunderX silicon pass2.x only which is identified
>> via MCFG revision 1.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> ---
>> drivers/acpi/pci_mcfg.c | 20 +++++++
>> drivers/pci/host/pci-thunder-pem.c | 107 ++++++++++++++++++++++++++++++++-----
>> include/linux/pci-ecam.h | 4 ++
>> 3 files changed, 117 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index ac21db3..e4e2b9b 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -57,6 +57,26 @@ static struct mcfg_fixup mcfg_quirks[] = {
>> { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },
>> { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },
>> { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },
>> +#ifdef CONFIG_PCI_HOST_THUNDER_PEM
>> +#define THUNDER_MCFG_RES(addr, node) \
>> + DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M)
>> +#define THUNDER_MCFG_QUIRK(rev, node) \
>> + { "CAVIUM", "THUNDERX", rev, 4 + (10 * node), MCFG_BUS_ANY, \
>> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88001f000000UL, node) }, \
>> + { "CAVIUM", "THUNDERX", rev, 5 + (10 * node), MCFG_BUS_ANY, \
>> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x884057000000UL, node) }, \
>> + { "CAVIUM", "THUNDERX", rev, 6 + (10 * node), MCFG_BUS_ANY, \
>> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x88808f000000UL, node) }, \
>> + { "CAVIUM", "THUNDERX", rev, 7 + (10 * node), MCFG_BUS_ANY, \
>> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89001f000000UL, node) }, \
>> + { "CAVIUM", "THUNDERX", rev, 8 + (10 * node), MCFG_BUS_ANY, \
>> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x894057000000UL, node) }, \
>> + { "CAVIUM", "THUNDERX", rev, 9 + (10 * node), MCFG_BUS_ANY, \
>> + &pci_thunder_pem_ops, THUNDER_MCFG_RES(0x89808f000000UL, node) }
>> + /* SoC pass2.x */
>> + THUNDER_MCFG_QUIRK(1, 0UL),
>> + THUNDER_MCFG_QUIRK(1, 1UL),
>> +#endif
>
> I want all these quirks to work without having to enable
> device-specific config options like CONFIG_PCI_HOST_THUNDER_PEM.
>
> I tweaked the preceding MCFG quirk support to wrap it in
> CONFIG_PCI_QUIRKS. I also tweaked the qualcomm and hisi patches to
> move the meat of them to pci/quirks.c. My work-in-progress is on
> pci/ecam, but I can't easily build for arm64, so there are likely some
> issues to be resolved.
Please see compilation fix patch in [1] for your series.
>
> I'm hoping to end up with something like this:
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469
>
> The problem with ThunderX is that the config accessors are much bigger
> and I don't really want to duplicate them in both pci/quirks.c and
> pci-thunder-pem.c.
>
> Actually, that raises a question for qualcomm and hisi: in the DT
> model, we use non-ECAM config accessors in the driver, but in the ACPI
> model, we use ECAM accessors. It seems like the accessors should be
> the same regardless of whether we discover the bridge via DT or ACPI.
>
> Anyway, it's almost like we want to build pci-thunder-pem.o if
> CONFIG_PCI_HOST_THUNDER_PEM || (CONFIG_PCI_QUIRKS && CONFIG_ARM64).
> I don't know how to express that nicely.
>
> I was trying to avoid adding an ecam-quirks.c, but maybe we need to
> add it and collect all the different accessors there and add #ifdefs
> inside.
>
> Sorry, this is only half-baked, but I just wanted to throw this out in
> case you have any ideas.
I agree that pci-thunder-pem.c and pci-thunder-ecam.c are too big to be
duplicated. The same for new ecam-quirks.c container. So treating this
as a necessary evil how about:
config PCI_HOST_THUNDER_PEM
bool "Cavium Thunder PCIe controller to off-chip devices"
- depends on OF && ARM64
+ depends on ARM64
+ depends on OF || (ACPI && PCI_QUIRKS)
select PCI_HOST_COMMON
Moreover, IMO we should select PCI_QUIRKS for ARM64 && ACPI by default.
Then it becomes:
config PCI_HOST_THUNDER_PEM
bool "Cavium Thunder PCIe controller to off-chip devices"
- depends on OF && ARM64
+ depends on ARM64
+ depends on OF || ACPI
select PCI_HOST_COMMON
I put the picture together here (on top of your pci/ecam branch):
[1]
https://github.com/semihalf-nowicki-tomasz/linux/commits/pci-quirks-thunderx-v2
Thanks,
Tomasz
^ permalink raw reply
* [PATCH] PCI:MSI Return -ENOSPC when requested vectors is not enough
From: Christoph Hellwig @ 2016-12-01 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480558504-18691-1-git-send-email-dennis.chen@arm.com>
Hi Dennis,
I've fixed ahci to treat all errors the same in the meantime, please
try latest Linux tree. That being said I don't like the different
error returns from __pci_enable_msi_range (and __pci_enable_msix_range),
but they have been there for a while.
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Maxime Ripard @ 2016-12-01 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1971681480527210@web5g.yandex.ru>
On Thu, Dec 01, 2016 at 01:33:30AM +0800, Icenowy Zheng wrote:
> >> ?????????hdmi-out {
> >> ?????????????????compatible = "hdmi-connector";
> >> ?????????????????type = "a";
> >> ?????????????????/* I2C bus and GPIO references are made up for the example */
> >> ?????????????????ddc-i2c-bus = <&i2c4>;
> >> ?????????????????hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
> >
> > the "hdmi-connector" is a big piece of software. It must handle a lot
> > of more and more exotic connectors.
> > So, I hope that you have written a "simple-hdmi-connector" which does
> > nothing but setting the connector type.
> > Where is it?
>
> I suddenly thought about something...
>
> If a DVI connector instead of a HDMI connector is soldered, how
> should such a device tree be written?
Use a dvi-connector instead :)
> How about solder a HDMI-to-VGA bridge on the board? (Maybe there
> should be "dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge"
> drivers?)
It probably wouldn't be dumb, but yeah, it would definitely be a
bridge instead of the connector.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161201/1f559ca4/attachment.sig>
^ permalink raw reply
* [PATCH v2 4/9] clk: stm32f4: Add lcd-tft clock
From: Gabriel Fernandez @ 2016-12-01 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130205333.tiukcjbspuqmedgw@rob-hp-laptop>
Hi Rob,
Thanks for reviewing
On 11/30/2016 09:53 PM, Rob Herring wrote:
> On Thu, Nov 24, 2016 at 03:45:44PM +0100, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch introduces lcd-tft clock for stm32f4 soc.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> .../devicetree/bindings/clock/st,stm32-rcc.txt | 1 +
>> drivers/clk/clk-stm32f4.c | 118 +++++++++++++++++++++
>> include/dt-bindings/clock/stm32f4-clock.h | 3 +-
>> 3 files changed, 121 insertions(+), 1 deletion(-)
>
>> diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
>> index 56b8e10..1be4a3a 100644
>> --- a/include/dt-bindings/clock/stm32f4-clock.h
>> +++ b/include/dt-bindings/clock/stm32f4-clock.h
>> @@ -27,7 +27,8 @@
>> #define CLK_RTC 5
>> #define PLL_VCO_I2S 6
>> #define PLL_VCO_SAI 7
>> +#define CLK_LCD 8
>>
>> -#define END_PRIMARY_CLK 8
>> +#define END_PRIMARY_CLK 9
> Do you really need this? Having this change could cause compatibility
> problems between dtb and kernel versions.
>
> Please restructure the patch series and put all of the binding changes
> including this header into a single patch. Incrementally add s/w
> features, not h/w.
>
> Rob
Okay
Best Regards
Gabriel
^ permalink raw reply
* [PATCH v3 0/4] drm: Add support for the Amlogic Video Processing Unit
From: Neil Armstrong @ 2016-12-01 9:05 UTC (permalink / raw)
To: linux-arm-kernel
This a repost of the previous version at [3] with fixes, the following patches will
be sent via a PULL Request once the DT maintainers acks the DT bindings.
The Amlogic maintainer will take the arm64 DT patches to avoid merges conflicts.
The Amlogic Meson SoCs embeds a Video Processing Unit able to output at least
a Composite/CVBS Video with embedded VDAC and an HDMI Link with Embedded HDMI
Transceiver.
Thus, the current driver does not support HDMI yet.
The Video Processig Unit is composed of multiple modules like the Video
Input Unit and the Video Post Processing that can be associated to a
CRTC with Planes management.
The last Unit is the Venc that embeds at least 3 Encoders, ENCI for Interlace
Video used by CVBS or HDMI, ENCP for Progressive Video used by the HDMI
Transceiver and ENCL for LCD Display.
The LCD Display is not planned to be supported on the Meson GX Family.
This driver is a DRM/KMS driver using the following DRM components :
- GEM-CMA
- PRIME-CMA
- Atomic Modesetting
- FBDev-CMA
For the following SoCs :
- GXBB Family (S905)
- GXL Family (S905X, S905D)
- GXM Family (S912)
The current driver only supports the CVBS PAL/NTSC output modes, but the
CRTC/Planes management should support bigger modes.
But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
a second time.
The Device Tree bindings makes use of the endpoints video interface definitions
to connect to the optional CVBS and in the future the HDMI Connector nodes.
The driver has been tested with Xorg modesetting driver and Weston DRM backend.
Changes since v1 at [3] :
- Rename and move dt-bindings file
- Clarified VPU node graph outputs
- Removed all of_machine_is_compatible
- Cleaned DTS endpoint and board connectors nodes
- Added Laurent Pinchard's ack and reviewed-bys
Changes since v1 at [2] :
- Simplify bindings to have a "composite-video-connector" to represent the on-board composite connector
- Remove the component_match binding since it's unused for now
- Moved all DRM connector code back in the venc_cvbs file
- Check for port endpoints validity to detech connector existence
- Added Daniel Vetter's ack on non-dt patches commit messages
Changes since RFC at [1] :
- Add maintainers entry
- Move all Plane and CRTC code from backend to corresponding DRM code
- Keep only init and common code in backend source files
- Move the CVBS encoder out of the CVBS DT node, only keep the connector
- Various cleanups using DRM helpers
- Cleanup of copyright headers
- Fixup of bindings documentation
[1] http://lkml.kernel.org/r/1480089791-12517-1-git-send-email-narmstrong at baylibre.com
[2] http://lkml.kernel.org/r/1480416469-9655-1-git-send-email-narmstrong at baylibre.com
[3] http://lkml.kernel.org/r/1480520625-13269-1-git-send-email-narmstrong at baylibre.com
Neil Armstrong (4):
drm: Add support for Amlogic Meson Graphic Controller
ARM64: dts: meson-gx: Add Graphic Controller nodes
dt-bindings: display: add Amlogic Meson DRM Bindings
MAINTAINERS: add entry for Amlogic DRM drivers
.../bindings/display/amlogic,meson-vpu.txt | 112 ++
MAINTAINERS | 9 +
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 16 +
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 16 +
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 16 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 +
.../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 16 +
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 +
.../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 16 +
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/meson/Kconfig | 9 +
drivers/gpu/drm/meson/Makefile | 4 +
drivers/gpu/drm/meson/meson_canvas.c | 68 +
drivers/gpu/drm/meson/meson_canvas.h | 42 +
drivers/gpu/drm/meson/meson_crtc.c | 208 +++
drivers/gpu/drm/meson/meson_crtc.h | 32 +
drivers/gpu/drm/meson/meson_drv.c | 343 +++++
drivers/gpu/drm/meson/meson_drv.h | 59 +
drivers/gpu/drm/meson/meson_plane.c | 230 ++++
drivers/gpu/drm/meson/meson_plane.h | 30 +
drivers/gpu/drm/meson/meson_registers.h | 1395 ++++++++++++++++++++
drivers/gpu/drm/meson/meson_vclk.c | 167 +++
drivers/gpu/drm/meson/meson_vclk.h | 34 +
drivers/gpu/drm/meson/meson_venc.c | 254 ++++
drivers/gpu/drm/meson/meson_venc.h | 72 +
drivers/gpu/drm/meson/meson_venc_cvbs.c | 293 ++++
drivers/gpu/drm/meson/meson_venc_cvbs.h | 41 +
drivers/gpu/drm/meson/meson_viu.c | 331 +++++
drivers/gpu/drm/meson/meson_viu.h | 64 +
drivers/gpu/drm/meson/meson_vpp.c | 162 +++
drivers/gpu/drm/meson/meson_vpp.h | 35 +
33 files changed, 4089 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
create mode 100644 drivers/gpu/drm/meson/Kconfig
create mode 100644 drivers/gpu/drm/meson/Makefile
create mode 100644 drivers/gpu/drm/meson/meson_canvas.c
create mode 100644 drivers/gpu/drm/meson/meson_canvas.h
create mode 100644 drivers/gpu/drm/meson/meson_crtc.c
create mode 100644 drivers/gpu/drm/meson/meson_crtc.h
create mode 100644 drivers/gpu/drm/meson/meson_drv.c
create mode 100644 drivers/gpu/drm/meson/meson_drv.h
create mode 100644 drivers/gpu/drm/meson/meson_plane.c
create mode 100644 drivers/gpu/drm/meson/meson_plane.h
create mode 100644 drivers/gpu/drm/meson/meson_registers.h
create mode 100644 drivers/gpu/drm/meson/meson_vclk.c
create mode 100644 drivers/gpu/drm/meson/meson_vclk.h
create mode 100644 drivers/gpu/drm/meson/meson_venc.c
create mode 100644 drivers/gpu/drm/meson/meson_venc.h
create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.c
create mode 100644 drivers/gpu/drm/meson/meson_venc_cvbs.h
create mode 100644 drivers/gpu/drm/meson/meson_viu.c
create mode 100644 drivers/gpu/drm/meson/meson_viu.h
create mode 100644 drivers/gpu/drm/meson/meson_vpp.c
create mode 100644 drivers/gpu/drm/meson/meson_vpp.h
--
1.9.1
^ permalink raw reply
* [PATCH v3 2/4] ARM64: dts: meson-gx: Add Graphic Controller nodes
From: Neil Armstrong @ 2016-12-01 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480583160-31806-1-git-send-email-narmstrong@baylibre.com>
Add Video Processing Unit and CVBS Output nodes, and enable CVBS on selected
boards.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 4 ++++
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 4 ++++
8 files changed, 92 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..eada0b5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -356,5 +356,21 @@
status = "disabled";
};
};
+
+ vpu: vpu at d0100000 {
+ compatible = "amlogic,meson-gx-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "vpu", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ cvbs_vdac_port: port at 0 {
+ reg = <0>;
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 9696820..4cbd626 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -142,6 +142,16 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -229,3 +239,9 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ remote-endpoint = <&cvbs_connector_in>;
+ };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 203be28..4a96e0f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -125,6 +125,16 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -234,3 +244,9 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ remote-endpoint = <&cvbs_connector_in>;
+ };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index ac5ad3b..5353a20 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -506,3 +506,7 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&vpu {
+ compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index e99101a..cea4a3e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -117,6 +117,16 @@
clocks = <&wifi32k>;
clock-names = "ext_clock";
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
&uart_AO {
@@ -203,3 +213,9 @@
clocks = <&clkc CLKID_FCLK_DIV4>;
clock-names = "clkin0";
};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ remote-endpoint = <&cvbs_connector_in>;
+ };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 9f89b99..5c7a8fa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -299,3 +299,7 @@
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
};
+
+&vpu {
+ compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index d320727..f2d0861 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -90,6 +90,16 @@
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
};
+
+ cvbs-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ cvbs_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+ };
};
/* This UART is brought out to the DB9 connector */
@@ -167,3 +177,9 @@
max-speed = <1000>;
};
};
+
+&cvbs_vdac_port {
+ cvbs_vdac_out: endpoint {
+ remote-endpoint = <&cvbs_connector_in>;
+ };
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index c1974bb..eb2f0c3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -112,3 +112,7 @@
};
};
};
+
+&vpu {
+ compatible = "amlogic,meson-gxm-vpu", "amlogic,meson-gx-vpu";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-12-01 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480583160-31806-1-git-send-email-narmstrong@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/display/amlogic,meson-vpu.txt | 112 +++++++++++++++++++++
1 file changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
new file mode 100644
index 0000000..00f74ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
@@ -0,0 +1,112 @@
+Amlogic Meson Display Controller
+================================
+
+The Amlogic Meson Display controller is composed of several components
+that are going to be documented below:
+
+DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
+ | vd1 _______ _____________ _________________ | |
+D |-------| |----| | | | | HDMI PLL |
+D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
+R |-------| |----| Processing | | | | |
+ | osd2 | | | |---| Enci ----------|----|-----VDAC------|
+R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
+A | osd1 | | | Blenders | | Encl ----------|----|---------------|
+M |-------|______|----|____________| |________________| | |
+___|__________________________________________________________|_______________|
+
+
+VIU: Video Input Unit
+---------------------
+
+The Video Input Unit is in charge of the pixel scanout from the DDR memory.
+It fetches the frames addresses, stride and parameters from the "Canvas" memory.
+This part is also in charge of the CSC (Colorspace Conversion).
+It can handle 2 OSD Planes and 2 Video Planes.
+
+VPP: Video Post Processing
+--------------------------
+
+The Video Post Processing is in charge of the scaling and blending of the
+various planes into a single pixel stream.
+There is a special "pre-blending" used by the video planes with a dedicated
+scaler and a "post-blending" to merge with the OSD Planes.
+The OSD planes also have a dedicated scaler for one of the OSD.
+
+VENC: Video Encoders
+--------------------
+
+The VENC is composed of the multiple pixel encoders :
+ - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
+ - ENCP : Progressive Video Encoder for HDMI
+ - ENCL : LCD LVDS Encoder
+The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
+tree and provides the scanout clock to the VPP and VIU.
+The ENCI is connected to a single VDAC for Composite Output.
+The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
+
+Device Tree Bindings:
+---------------------
+
+VPU: Video Processing Unit
+--------------------------
+
+Required properties:
+- compatible: value should be different for each SoC family as :
+ - GXBB (S905) : "amlogic,meson-gxbb-vpu"
+ - GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
+ - GXM (S912) : "amlogic,meson-gxm-vpu"
+ followed by the common "amlogic,meson-gx-vpu"
+- reg: base address and size of he following memory-mapped regions :
+ - vpu
+ - hhi
+ - dmc
+- reg-names: should contain the names of the previous memory regions
+- interrupts: should contain the VENC Vsync interrupt number
+
+Required nodes:
+
+The connections to the VPU output video ports are modeled using the OF graph
+bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+The following table lists for each supported model the port number
+corresponding to each VPU output.
+
+ Port 0 Port 1
+-----------------------------------------
+ S905 (GXBB) CVBS VDAC HDMI-TX
+ S905X (GXL) CVBS VDAC HDMI-TX
+ S905D (GXL) CVBS VDAC HDMI-TX
+ S912 (GXM) CVBS VDAC HDMI-TX
+
+Example:
+
+tv-connector {
+ compatible = "composite-video-connector";
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = <&cvbs_vdac_out>;
+ };
+ };
+};
+
+vpu: vpu at d0100000 {
+ compatible = "amlogic,meson-gxbb-vpu";
+ reg = <0x0 0xd0100000 0x0 0x100000>,
+ <0x0 0xc883c000 0x0 0x1000>,
+ <0x0 0xc8838000 0x0 0x1000>;
+ reg-names = "vpu", "hhi", "dmc";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* CVBS VDAC output port */
+ port at 0 {
+ reg = <0>;
+
+ cvbs_vdac_out: endpoint {
+ remote-endpoint = <&tv_connector_in>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 4/4] MAINTAINERS: add entry for Amlogic DRM drivers
From: Neil Armstrong @ 2016-12-01 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480583160-31806-1-git-send-email-narmstrong@baylibre.com>
Add myself as maintainer for Amlogic DRM drivers.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..b1ad45b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4078,6 +4078,15 @@ S: Supported
F: drivers/gpu/drm/sun4i/
F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+DRM DRIVERS FOR AMLOGIC SOCS
+M: Neil Armstrong <narmstrong@baylibre.com>
+L: dri-devel at lists.freedesktop.org
+L: linux-amlogic at lists.infradead.org
+W: http://linux-meson.com/
+S: Supported
+F: drivers/gpu/drm/meson/
+F: Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+
DRM DRIVERS FOR EXYNOS
M: Inki Dae <inki.dae@samsung.com>
M: Joonyoung Shim <jy0922.shim@samsung.com>
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: dts: h3ulcb: Provide sd0_uhs node
From: Simon Horman @ 2016-12-01 9:07 UTC (permalink / raw)
To: linux-arm-kernel
Provide separaate sd0 and sd0_uhs nodes rather than duplicate sd0 nodes.
Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Fixes: 93373c309a70 ("arm64: dts: h3ulcb: rename SDHI0 pins")
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 6ffb0517421a..dbea2c3d8f0c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -169,7 +169,7 @@
power-source = <3300>;
};
- sdhi0_pins_uhs: sd0 {
+ sdhi0_pins_uhs: sd0_uhs {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
power-source = <1800>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [GIT PULL] Renesas ARM Based SoC Match Updates for v4.10
From: Arnd Bergmann @ 2016-12-01 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201084758.GC18042@verge.net.au>
On Thursday, December 1, 2016 9:47:58 AM CET Simon Horman wrote:
> Thanks for pulling this and other outstanding pull requests from Geert and
> myself. I don't think we have anything more outstanding at this time.
Ok, thanks for the confirmation!
Arnd
^ permalink raw reply
* [PATCH 2/2] dt-bindings: Add DT bindings info for FlexRM mailbox driver
From: Anup Patel @ 2016-12-01 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130213854.jmjwcis2zid6busv@rob-hp-laptop>
On Thu, Dec 1, 2016 at 3:08 AM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Nov 25, 2016 at 10:05:51AM +0530, Anup Patel wrote:
>> This patch adds device tree bindings document for the FlexRM
>> mailbox driver.
>
> Bindings document h/w, not drivers.
OK, I will rephrase this.
>
>>
>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
>> ---
>> .../bindings/mailbox/brcm,flexrm-mbox.txt | 60 ++++++++++++++++++++++
>> 1 file changed, 60 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
>> new file mode 100644
>> index 0000000..7969b1c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/brcm,flexrm-mbox.txt
>> @@ -0,0 +1,60 @@
>> +Broadcom FlexRM Mailbox Driver
>
> h/w
OK, I will rephrase this.
>
>> +===============================
>> +The Broadcom FlexRM ring manager provides a set of rings which can be
>> +used to submit work to offload engines. An SoC may have multiple FlexRM
>> +hardware blocks. There is one device tree entry per block. The FlexRM
>> +mailbox drivers creates a mailbox instance using FlexRM rings where
>> +each mailbox channel is a separate FlexRM ring.
>> +
>> +Required properties:
>> +--------------------
>> +- compatible: Should be "brcm,flexrm-mbox"
>
> Sounds generic. Add SoC specific compatible strings please.
OK, will do.
>
>> +- reg: Specifies base physical address and size of the FlexRM
>> + ring registers
>> +- msi-parent: Phandles (and potential Device IDs) to MSI controllers
>> + The FlexRM engine will send MSIs (instead of wired
>> + interrupts) to CPU. There is one MSI for each FlexRM ring.
>
> One ring is one h/w block, right? How many instances is not really
> relevant.
No, FlexRM is the HW block. One instance of FlexRM provides a set of
rings (typically 32 or more).
There are lot other registers in FlexRM apart from ring registers. Out of
these, only ring registers are accessible to non-secured world (i.e. Linux)
whereas all other registers are only accessible to secure-world firmware
(typically ATF).
>
>> + Refer devicetree/bindings/interrupt-controller/msi.txt
>> +- #mbox-cells: Specifies the number of cells needed to encode a mailbox
>> + channel. This should be 3.
>> +
>> + The 1st cell is the mailbox channel number.
>> +
>> + The 2nd cell contains MSI completion threshold. This is the
>> + number of completion messages for which FlexRM will inject
>> + one MSI interrupt to CPU.
>> +
>> + The 3nd cell contains MSI timer value representing time for
>> + which FlexRM will wait to accumulate N completion messages
>> + where N is the value specified by 2nd cell above. If FlexRM
>> + does not get required number of completion messages in time
>> + specified by this cell then it will inject one MSI interrupt
>> + to CPU provided atleast one completion message is available.
>> +
>> +Optional properties:
>> +--------------------
>> +- dma-coherent: Present if DMA operations made by the FlexRM engine (such
>> + as DMA descriptor access, access to buffers pointed by DMA
>> + descriptors and read/write pointer updates to DDR) are
>> + cache coherent with the CPU.
>> +
>> +Example:
>> +--------
>> +crypto_mbox: mbox at 67000000 {
>> + compatible = "brcm,flexrm-mbox";
>> + reg = <0x67000000 0x200000>;
>> + msi-parent = <&gic_its 0x7f00>;
>> + #mbox-cells = <3>;
>> +};
>> +
>> +crypto_client {
>
> Is this a h/w block or purely a driver on top of the mailbox? The latter
> doesn't belong in DT.
The FlexRM is one HW block. It provides ring-based programming
interface to various offload engines which are separate HW blocks.
The driver for FlexRM is implemented as mailbox controller driver
while the offload engine drivers will be mailbox clients.
>
>> + ...
>> + mboxes = <&crypto_mbox 0 0x1 0xffff>,
>> + <&crypto_mbox 1 0x1 0xffff>,
>> + <&crypto_mbox 16 0x1 0xffff>,
>> + <&crypto_mbox 17 0x1 0xffff>,
>> + <&crypto_mbox 30 0x1 0xffff>,
>> + <&crypto_mbox 31 0x1 0xffff>;
>> + };
>> + ...
>> +};
Regards,
Anup
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Maxime Ripard @ 2016-12-01 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2039137.LtCOH6bs2I@avalon>
Hi Laurent,
On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> > More, it is not sure that the bridge/DW code would work with Allwinner's
> > SoCs.
>
> If it doesn't work and can't be made to work in a non-invasive way they it
> should certainly not be used :-)
Even if the register layout is completely scrambled, as long as the
bits themselves aren't (and by comparing the two drivers it looks like
they haven't changed), you can easily deal with that using the
regmap_fields, with the two implementations (the original one and the
scrambled one) providing their register map that way, and the driver
code using whatever has been provided.
> > Eventually, I went the same way as omap/hdmi5: different driver.
>
> I might try to fix that for OMAP5 at some point, we'll see.
For complex drivers that have already a driver written and a lot of
testing that already happened, I don't think duplication is a smart
move.
> > > - And finally the fact that we can't have several display engine in
> > > parallel, if needs be. This has happened in the past already on
> > > Allwinner SoCs, so it's definitely something we should consider in
> > > the DT bindings, since we can't break them.
> >
> > IIRC, I proposed my driver before yours, and the DE2 is completely
> > different from the other display engines.
> > What you are telling is "add more code to already complex code and have
> > a big driver for all SoCs in each kernels".
> > I think it should be better to have small modules, each one treating
> > specific hardware, and to let only the needed code in the kernel memory
> > at startup time.
> >
> > > Until those are fixed, I cannot see how this driver can be merged,
> > > unfortunately.
> >
> > No problem. I just wanted to help people by giving the job I did on the
> > boards I have. My boards are working for almost one year, fine enough
> > for I use them as daily desktop computers. I don't want to spend one
> > more year for having my code in the Linux kernel: there are so much
> > other exciting things to do...
>
> And you're certainly welcome to contribute drivers to the kernel, that's
> always appreciated. Of course, to ensure a reasonable level of quality and
> consistency between drivers, the review process often requires changes to be
> made to the code being submitted. When it comes to drivers I mostly pay
> attention to DT bindings, userspace APIs and modification to common code.
> Driver code itself, as long as it's reasonably clean and doesn't impede
> development of other drivers or impact system security in an adverse way, is
> still important but maybe slightly less so. I'll defer to Maxime to come to an
> agreement on the multiple display engines in parallel problem as I'm not
> familiar with it for the Allwinner platforms.
The earlier Allwinner SoCs (with the old display engine), we had some
SoCs with multiple instances of the display engine and TCON (the
display engine roughly implementing the planes, the TCON the
CRTC. Roughly.). However, those were sharing some encoders (HDMI,
DSI) after that.
So we need to have a single DRM device taking care of the multiple
display engines, which essentialy means that we have to decouple the
DRM device from the display engine. This was done in the earlier
designs using an additional node with a list of phandles to the
display engines in the system, and obviously, I'd prefer to have some
consistency and reuse the same thing.
But the current approach doesn't work and will require some DT
modifications if that case happens again, which we can't do because of
the DT ABI.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161201/edd95cf1/attachment.sig>
^ permalink raw reply
* Unable to use perf in VM
From: Marc Zyngier @ 2016-12-01 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56fd35f8-76ba-3d5d-f1e0-7df5ff8d396a@redhat.com>
On 30/11/16 19:17, Wei Huang wrote:
>
>
> On 11/30/2016 07:37 AM, Marc Zyngier wrote:
>> On 30/11/16 11:48, Marc Zyngier wrote:
>>> + Shannon
>>>
>>> On 29/11/16 22:04, Itaru Kitayama wrote:
>>>> Hi,
>>>>
>>>> In a VM (virsh controlled, KVM acceleration enabled) on a recent
>>>> kvmarm kernel host, I find I am unable to use perf to obtain
>>>> performance statistics for a complex task like kernel build.
>>>> (I've verified this is seen with a Fedora 25 VM and host combination
>>>> as well)
>>>> APM folks CC'ed think this might be caused by a bug in the core PMU
>>>> framework code, thus I'd like to have experts opinion on this issue.
>>>>
>>>> [root at localhost linux]# perf stat -B make
>>>> CHK include/config/kernel.release
>>>> [ 119.617684] git[1144]: undefined instruction: pc=fffffc000808ff30
>>>> [ 119.623040] Code: 51000442 92401042 d51b9ca2 d5033fdf (d53b9d40)
>>>> [ 119.627607] Internal error: undefined instruction: 0 [#1] SMP
>>>
>>> [...]
>>>
>>> In a VM running mainline hosted on an AMD Seattle box:
>>>
>>> Performance counter stats for 'make':
>>>
>>> 1526089.499304 task-clock:u (msec) # 0.932 CPUs utilized
>>> 0 context-switches:u # 0.000 K/sec
>>> 0 cpu-migrations:u # 0.000 K/sec
>>> 29527793 page-faults:u # 0.019 M/sec
>>> 2913174122673 cycles:u # 1.909 GHz
>>> 2365040892322 instructions:u # 0.81 insn per cycle
>>> <not supported> branches:u
>>> 32049215378 branch-misses:u # 0.00% of all branches
>>>
>>> 1637.531444837 seconds time elapsed
>>>
>>> Running the same host kernel on a Mustang system, the guest explodes
>>> in the way you reported. The failing instruction always seems to be
>>> an access to pmxevcntr_el0 (I've seen both reads and writes).
>>>
>>> Funnily enough, it dies if you try any HW event other than cycles
>>> ("perf stat -e cycles ls" works, and "perf stat -e instructions ls"
>>> explodes). Which would tend to indicate that we're screwing up
>>> the counter selection, but I have no proof of that (specially that
>>> the Seattle guest is working just as expected).
>>
>> It turns out that we *don't* inject an undef. It seems to be generated
>> locally at EL1.
>>
>> Still digging.
>
> Just FYI: I saw it on Mustang before. My initial thought was HW related,
> but without proof. I am interested to see your findings...
It would have been good to report it earlier. Anyway, I've identified
the root issue, which seems to boil down to how you interpret a small
corner of the PMU architecture. I've raised it with the architecture
team here, and I should have a workaround/fix shortly.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Laurent Pinchart @ 2016-12-01 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201091313.th7nucjmvtuolqza@lukather>
Hi Maxime,
On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
> On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote:
> >> More, it is not sure that the bridge/DW code would work with Allwinner's
> >> SoCs.
> >
> > If it doesn't work and can't be made to work in a non-invasive way they it
> > should certainly not be used :-)
>
> Even if the register layout is completely scrambled, as long as the
> bits themselves aren't (and by comparing the two drivers it looks like
> they haven't changed), you can easily deal with that using the
> regmap_fields, with the two implementations (the original one and the
> scrambled one) providing their register map that way, and the driver
> code using whatever has been provided.
Looking at https://linux-sunxi.org/DWC_HDMI_Controller#DWC_HDMI_Controller it
seems that an address remapping function could be used.
> >> Eventually, I went the same way as omap/hdmi5: different driver.
> >
> > I might try to fix that for OMAP5 at some point, we'll see.
>
> For complex drivers that have already a driver written and a lot of
> testing that already happened, I don't think duplication is a smart
> move.
>
> >>> - And finally the fact that we can't have several display engine in
> >>> parallel, if needs be. This has happened in the past already on
> >>> Allwinner SoCs, so it's definitely something we should consider in
> >>> the DT bindings, since we can't break them.
> >>
> >> IIRC, I proposed my driver before yours, and the DE2 is completely
> >> different from the other display engines.
> >> What you are telling is "add more code to already complex code and have
> >> a big driver for all SoCs in each kernels".
> >> I think it should be better to have small modules, each one treating
> >> specific hardware, and to let only the needed code in the kernel memory
> >> at startup time.
> >>
> >>> Until those are fixed, I cannot see how this driver can be merged,
> >>> unfortunately.
> >>
> >> No problem. I just wanted to help people by giving the job I did on the
> >> boards I have. My boards are working for almost one year, fine enough
> >> for I use them as daily desktop computers. I don't want to spend one
> >> more year for having my code in the Linux kernel: there are so much
> >> other exciting things to do...
> >
> > And you're certainly welcome to contribute drivers to the kernel, that's
> > always appreciated. Of course, to ensure a reasonable level of quality and
> > consistency between drivers, the review process often requires changes to
> > be made to the code being submitted. When it comes to drivers I mostly
> > pay attention to DT bindings, userspace APIs and modification to common
> > code. Driver code itself, as long as it's reasonably clean and doesn't
> > impede development of other drivers or impact system security in an
> > adverse way, is still important but maybe slightly less so. I'll defer to
> > Maxime to come to an agreement on the multiple display engines in
> > parallel problem as I'm not familiar with it for the Allwinner platforms.
>
> The earlier Allwinner SoCs (with the old display engine), we had some
> SoCs with multiple instances of the display engine and TCON (the
> display engine roughly implementing the planes, the TCON the
> CRTC. Roughly.). However, those were sharing some encoders (HDMI,
> DSI) after that.
>
> So we need to have a single DRM device taking care of the multiple
> display engines, which essentialy means that we have to decouple the
> DRM device from the display engine. This was done in the earlier
> designs using an additional node with a list of phandles to the
> display engines in the system, and obviously, I'd prefer to have some
> consistency and reuse the same thing.
>
> But the current approach doesn't work and will require some DT
> modifications if that case happens again, which we can't do because of
> the DT ABI.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Florian Weimer @ 2016-12-01 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130135631.GK1574@e103592.cambridge.arm.com>
On 11/30/2016 02:56 PM, Dave Martin wrote:
> If we do have distinct "set process VL" and "set thread VL" interfaces,
> then my view is that the former should fail if there are already
> multiple threads, rather than just setting the VL of a single thread or
> (worse) asynchronously changing the VL of threads other than the
> caller...
Yes, looks feasible to me.
>>> I'm not familiar with resumable functions/executors -- are these in
>>> the C++ standards yet (not that that would cause me to be familiar
>>> with them... ;) Any implementation of coroutines (i.e.,
>>> cooperative switching) is likely to fall under the "setcontext"
>>> argument above.
>>
>> There are different ways to implement coroutines. Stack switching (like
>> setcontext) is obviously impacted by non-uniform register sizes. But even
>> the most conservative variant, rather similar to switch-based emulation you
>> sometimes see in C coroutine implementations, might have trouble restoring
>> the state if it just cannot restore the saved state due to register size
>> reductions.
>
> Which is not a problem if the variably-sized state is not part of the
> switched context?
The VL value is implicitly thread-local data, and the encoded state may
have an implicit dependency on it, although it does not contain vector
registers as such.
> Because the SVE procedure call standard determines that the SVE
> registers are caller-save,
By the way, how is this implemented? Some of them overlap existing
callee-saved registers.
> they are not live at any external function
> boundary -- so in cooperative switching it is useless to save/restore
> this state unless the coroutine framework is defined to have a special
> procedure call standard.
It can use the standard calling convention, but it may have selected a
particular implementation based on the VL value before suspension.
Florian
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Maxime Ripard @ 2016-12-01 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125220752.c989c85e01ed202be0485c78@bidouilliste.com>
Hi Emmanuel,
On Fri, Nov 25, 2016 at 10:07:52PM +0100, Emmanuel Vadot wrote:
> On Fri, 25 Nov 2016 16:20:47 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > On Thu, Nov 24, 2016 at 09:05:09PM +0100, Emmanuel Vadot wrote:
> > > On Thu, 24 Nov 2016 20:55:17 +0100
> > > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> > >
> > > > On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > > > > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > > > > others three only have 1.
> > > > > Add the num-cs property to each node.
> > > > >
> > > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > > >
> > > > I don't think we have any code that uses it at the moment. What is the
> > > > rationale behind this patch?
> > > >
> > > > Thanks!
> > > > Maxime
> > > >
> > > > --
> > > > Maxime Ripard, Free Electrons
> > > > Embedded Linux and Kernel engineering
> > > > http://free-electrons.com
> > >
> > > Hi Maxime,
> > >
> > > If num-cs isn't present nothing prevent to start a transfer with a
> > > non-valid CS pin, resulting in an error.
> > > num-cs are default property especially made for this and a SPI driver
> > > should try to get the property at probe/attach time.
> >
> > Yes, but as far as I know, our driver doesn't. I'm all in for having
> > support for that in our driver, but without it, that patch is kind of
> > useless.
>
> Yes the Linux driver doesn't use it but my upcoming one for FreeBSD
> uses it. So it is not useless for downstream user of DTS.
Ah, I didn't know this was for FreeBSD. So you started to use our DTs,
or do you have some modifications to it? How does that work?
Anyway, the fact that it isn't used by our driver at the moment and
that it's meant for other OSes should be mentionned in the commit log.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161201/b66af5d5/attachment-0001.sig>
^ permalink raw reply
* [PULL] KVM/ARM updates for 4.9-rc7
From: Marc Zyngier @ 2016-12-01 9:25 UTC (permalink / raw)
To: linux-arm-kernel
Paolo, Radim,
Hopefully, this is the last update for 4.9. This time, a single patch
that prevents bogus acknoledgement of interrupts.
It'd be great if this could make it into v4.9-final
Thanks,
M.
The following changes since commit b112c84a6ff035271d41d548c10215f18443d6a6:
KVM: arm64: Fix the issues when guest PMCCFILTR is configured (2016-11-18 09:06:58 +0000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.9-rc7
for you to fetch changes up to 8ca18eec2b2276b449c1dc86b98bf083c5fe4e09:
KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs (2016-11-24 13:12:07 +0000)
----------------------------------------------------------------
KVM/ARM updates for v4.9-rc7
- Do not call kvm_notify_acked for PPIs
----------------------------------------------------------------
Marc Zyngier (1):
KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
virt/kvm/arm/vgic/vgic-v2.c | 6 ++++--
virt/kvm/arm/vgic/vgic-v3.c | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Marc Zyngier @ 2016-12-01 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480584341-32340-1-git-send-email-marc.zyngier@arm.com>
When we inject a level triggerered interrupt (and unless it
is backed by the physical distributor - timer style), we request
a maintenance interrupt. Part of the processing for that interrupt
is to feed to the rest of KVM (and to the eventfd subsystem) the
information that the interrupt has been EOIed.
But that notification only makes sense for SPIs, and not PPIs
(such as the PMU interrupt). Skip over the notification if
the interrupt is not an SPI.
Cc: stable at vger.kernel.org # 4.7+
Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch backend")
Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch backend")
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/vgic/vgic-v2.c | 6 ++++--
virt/kvm/arm/vgic/vgic-v3.c | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 0a063af..9bab867 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -50,8 +50,10 @@ void vgic_v2_process_maintenance(struct kvm_vcpu *vcpu)
WARN_ON(cpuif->vgic_lr[lr] & GICH_LR_STATE);
- kvm_notify_acked_irq(vcpu->kvm, 0,
- intid - VGIC_NR_PRIVATE_IRQS);
+ /* Only SPIs require notification */
+ if (vgic_valid_spi(vcpu->kvm, intid))
+ kvm_notify_acked_irq(vcpu->kvm, 0,
+ intid - VGIC_NR_PRIVATE_IRQS);
}
}
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index 9f0dae3..5c9f974 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -41,8 +41,10 @@ void vgic_v3_process_maintenance(struct kvm_vcpu *vcpu)
WARN_ON(cpuif->vgic_lr[lr] & ICH_LR_STATE);
- kvm_notify_acked_irq(vcpu->kvm, 0,
- intid - VGIC_NR_PRIVATE_IRQS);
+ /* Only SPIs require notification */
+ if (vgic_valid_spi(vcpu->kvm, intid))
+ kvm_notify_acked_irq(vcpu->kvm, 0,
+ intid - VGIC_NR_PRIVATE_IRQS);
}
/*
--
2.1.4
^ permalink raw reply related
* How should we group related devices in DT ? (was Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support)
From: Laurent Pinchart @ 2016-12-01 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201091313.th7nucjmvtuolqza@lukather>
Hello,
On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote:
[snip]
> The earlier Allwinner SoCs (with the old display engine), we had some
> SoCs with multiple instances of the display engine and TCON (the
> display engine roughly implementing the planes, the TCON the
> CRTC. Roughly.). However, those were sharing some encoders (HDMI,
> DSI) after that.
>
> So we need to have a single DRM device taking care of the multiple
> display engines, which essentialy means that we have to decouple the
> DRM device from the display engine. This was done in the earlier
> designs using an additional node with a list of phandles to the
> display engines in the system, and obviously, I'd prefer to have some
> consistency and reuse the same thing.
I believe this problem isn't limited to sunxi and should be addressed in a
more generic way. How should we describe in the device tree that multiple
instances of a device unrelated from a control point of view are related at
the hardware level ? There are multiple reasons why we need this, and here are
a few.
- As described above, unrelated display controller instances that share
encoders at their output need to be exposed to userspace as a single DRM
device. This is also the case on Renesas platforms (where the display engines
are independent except for the "small" detail that output routing is
controlled through the first display engine).
- On Renesas platforms again a radio-related SPI receiver has multiple
independent channels that each have their own registers, clocks and
interrupts, but share the same physical clock and sync pins. They are used to
receive multiple channels of the same data stream and must be exposed as a
single V4L2 device to userspace. A generic DT binding RFC is available at
http://www.spinics.net/lists/devicetree/msg152414.html.
> But the current approach doesn't work and will require some DT
> modifications if that case happens again, which we can't do because of
> the DT ABI.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-12-01 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cdfd3c65-d473-badb-ea6a-035f7ab79217@arm.com>
On Mon, Nov 28, 2016 at 12:29:07AM +0000, Andr? Przywara wrote:
> > Something more interesting happened.
> >
> > Xunlong made a add-on board for Orange Pi Zero, which exposes the
> > two USB Controllers exported at expansion bus as USB Type-A
> > connectors.
> >
> > Also it exposes a analog A/V jack and a microphone.
> >
> > Should I enable {e,o}hci{2.3} in the device tree?
>
> Actually we should do this regardless of this extension board. The USB
> pins are not multiplexed and are exposed on user accessible pins (just
> not soldered, but that's a detail), so I think they qualify for DT
> enablement. And even if a user can't use them, it doesn't hurt to have
> them (since they are not multiplexed).
My main concern about this is that we'll leave regulators enabled by
default, for a minority of users. And that minority will prevent to do
a proper power management when the times come since we'll have to keep
that behaviour forever.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161201/6200cc6b/attachment.sig>
^ 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