* [PATCH] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Jintack Lim @ 2016-11-29 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee2dacff-691c-7548-ff71-3a992f399333@arm.com>
On Tue, Nov 29, 2016 at 11:53 AM, Suzuki K Poulose
<suzuki.poulose@arm.com> wrote:
> On 29/11/16 09:36, Marc Zyngier wrote:
>>
>> On 29/11/16 03:28, Jintack Lim wrote:
>>>
>>> On Mon, Nov 28, 2016 at 1:39 PM, Marc Zyngier <marc.zyngier@arm.com>
>>> wrote:
>>>>
>>>> On 28/11/16 17:43, Marc Zyngier wrote:
>>>
>>> This looks much cleaner than my patch.
>>> While we are at it, is it worth to consider that we just need to set
>>> those bits once for VHE case, not for every world switch as an
>>> optimization?
>>
>>
>> Ah! That's a much better idea indeed! And we could stop messing with
>> cntvoff_el2 as well, as it doesn't need to be restored to zero on exit.
>> Could you try and respin something along those lines?
>>
>
> fyi, we have a static_key based cpus_have_const_cap() for Constant cap
> checking (like this case) available in linux-next. May be you could make use
> of that instead of alternatives.
Thanks Suzuki. This looks very useful.
Marc, can I write a patch based on linux-next? The commit which has
cpus_have_const_cap() is not in master and next branch in kvm/arm
repo.
>
>
> Cheers
> Suzuki
>
^ permalink raw reply
* [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Stephen Boyd @ 2016-11-29 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y409cw71.wl%kuninori.morimoto.gx@renesas.com>
On 11/24, Kuninori Morimoto wrote:
>
> Hi Stephen, again
>
> > > I've seen bindings that have the 'clocks' property at the top
> > > level and the appropriate 'clock-names' property to relate the
> > > clocks to a subnode.
> > >
> > > sound_soc {
> > > clocks = <&xxx>, <&xxx>;
> > > clock-names = "cpu", "codec";
> > > ...
> > > cpu {
> > > ...
> > > };
> > > codec {
> > > ...
> > > };
> > > };
> > >
> > > Then the subnodes call clk_get() with the top level device and
> > > the name of their node and things match up. I suppose this
> > > binding is finalized though, so we can't really do that?
> > >
> > > I see that the gpio framework has a similar design called
> > > devm_get_gpiod_from_child(), so how about we add a
> > > devm_get_clk_from_child() API? That would more closely match the
> > > intent here, which is to restrict the clk_get() operation to
> > > child nodes of the device passed as the first argument.
> > >
> > > struct clk *devm_get_clk_from_child(struct device *dev,
> > > const char *con_id,
> > > struct device_node *child);
>
> Thanks, but, my point is that Linux already have "of_clk_get()",
> but we don't have its devm_ version.
> The point is that of_clk_get() can get clock from "device_node".
> Why having devm_ version become so problem ?
The problem is that it encourages the use of of_clk_get() when
clk_get() is more desirable. Ideally of_clk_get() is never used
when a device exists. In this case, it seems like we need to
support it though, hence the suggestion of having a
devm_get_clk_from_child() API, that explicitly reads as "get a
clock from a child node of this device". The distinction is
important, because of_clk_get() should rarely be used.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
From: Christoffer Dall @ 2016-11-29 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6uW5RmjsPPBKB5wLW4TzNmcdc9ZADqp=M2ZJe9Cd+keZg@mail.gmail.com>
On Tue, Nov 29, 2016 at 10:06:27PM +0530, Vijay Kilari wrote:
> On Tue, Nov 29, 2016 at 1:20 AM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Wed, Nov 23, 2016 at 06:31:54PM +0530, vijay.kilari at gmail.com wrote:
> >> 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 | 49 ++++++++++++++++++++++++++++++++++++-
> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 11 +++++++++
> >> virt/kvm/arm/vgic/vgic-mmio.c | 38 ++++++++++++++++++++++++++++
> >> virt/kvm/arm/vgic/vgic-mmio.h | 5 ++++
> >> virt/kvm/arm/vgic/vgic.h | 2 ++
> >> 7 files changed, 117 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..52ed00b 100644
> >> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
> >> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
> >> @@ -510,6 +510,25 @@ 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) {
> >> + if (is_write)
> >> + tmp32 = *reg;
> >> + intid = attr->attr &
> >> + KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK;
> >> + ret = vgic_v3_line_level_info_uaccess(vcpu, is_write,
> >> + intid, &tmp32);
> >> + if (!is_write)
> >> + *reg = tmp32;
> >
> > I had a comment here about not having to use the tmp32 by modifying the
> > line_level_info function, that you seem to have missed.
> >
> > Hint: The level info is not called from an MMIO path so you should be
> > able to just write it in a natural way.
>
> Ok. Changed the prototype of vgic_v3_line_level_info_uaccess() to take
> u64 reg instead of tmp32
>
> >
> >> + } else {
> >> + ret = -EINVAL;
> >> + }
> >> + break;
> >> + }
> >> default:
> >> ret = -EINVAL;
> >> break;
> >> @@ -552,6 +571,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 +617,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 +649,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 2f7b4ed..4d7d93d 100644
> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> >> @@ -808,3 +808,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, u32 *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..d602081 100644
> >> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> >> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> >> @@ -371,6 +371,44 @@ void vgic_mmio_write_config(struct kvm_vcpu *vcpu,
> >> }
> >> }
> >>
> >> +unsigned long vgic_read_irq_line_level_info(struct kvm_vcpu *vcpu, u32 intid)
> >> +{
> >> + int i;
> >> + unsigned long 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 unsigned long 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)) {
> >> + irq->line_level = true;
> >> + vgic_queue_irq_unlock(vcpu->kvm, irq);
> >> + } else {
> >> + irq->line_level = false;
> >> + spin_unlock(&irq->irq_lock);
> >> + }
> >
> > I think you also missed my comment about having to keep the pending
> > state in sync with the level state.
> >
> > Which means you have to set the pending state when the line_level goes
> > up, and lower it when it goes down unless soft_pending is also set,
> > assuming it's configured as a level triggered interrupt.
> >
> > If it's an edge-triggered interrupt, I think you only need to set the
> > pending state on a line being asserted and the rest should be adjusted
> > in case the user restores the configuration state to level triggered
> > later.
>
> Is this ok?
>
> 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)) {
> irq->line_level = true;
> irq->pending = true;
> vgic_queue_irq_unlock(vcpu->kvm, irq);
Actually, I'm not sure what the semantics of the line level ioctl should
be for edge-triggered interrupts? My inclination is that it shouldn't
have any effect at this point, but that would mean that at this point we
should only set the pending variable and try to queue the interrupt if
the config is level. But that also means that when we set the config
later, we need to try to queue the interrupt, which we don't do
currently, because we rely on the guest not fiddling with the config of
an enabled interrupt.
Could it be considered an error if user space tries to set the level for
an edge-triggered interrupt and therefore something we can just ignore
and assume that the corresponing interrupt will be configured as a
level-triggered one later?
Marc/Peter, thoughts on this one?
In any case we probably need to clarify the ABI in terms of this
particular KVM_DEV_AR_VGIC_GRP_LEVEL_INFO group and how it relates to
the config of edge vs. level of interrupts and ordering on restore...
Thanks,
-Christoffer
> } 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);
> }
> }
^ permalink raw reply
* [PATCH v2 1/3] clk: uniphier: remove unneeded member name for union
From: Stephen Boyd @ 2016-11-29 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967061-25975-1-git-send-email-yamada.masahiro@socionext.com>
On 11/24, Masahiro Yamada wrote:
> The struct member name of a union is unneeded. This makes the code
> a bit shorter.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 2/3] clk: uniphier: add CPU-gear change (cpufreq) support
From: Stephen Boyd @ 2016-11-29 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967061-25975-2-git-send-email-yamada.masahiro@socionext.com>
On 11/24, Masahiro Yamada wrote:
> Core support code for CPU frequency changes, which will be used by
> the generic cpufreq driver.
>
> The register view is different from the generic clk-mux; it has
> a separate status register, and an update bit to load the register
> setting.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 3/3] clk: uniphier: add cpufreq data for LD11, LD20 SoCs
From: Stephen Boyd @ 2016-11-29 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967061-25975-3-git-send-email-yamada.masahiro@socionext.com>
On 11/24, Masahiro Yamada wrote:
> Add more data to 64bit SoCs for the cpufreq support.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Wolfram Sang @ 2016-11-29 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121133247.29889-2-romain.perier@free-electrons.com>
> + if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
> + i2c->fm_mask = ICR_BUSMODE_FM;
> + i2c->hs_mask = ICR_BUSMODE_HS;
> + } else {
> + i2c->fm_mask = ICR_FM;
> + i2c->hs_mask = ICR_HS;
> + }
>
> *i2c_types = (enum pxa_i2c_types)(of_id->data);
>
> @@ -1181,6 +1194,13 @@ static int i2c_pxa_probe_pdata(struct platform_device *pdev,
> i2c->master_code = 0xe;
> i2c->rate = plat->rate;
> }
> + if (!strcmp(id->name, "armada-3700-i2c")) {
> + i2c->fm_mask = ICR_BUSMODE_FM;
> + i2c->hs_mask = ICR_BUSMODE_HS;
> + } else {
> + i2c->fm_mask = ICR_FM;
> + i2c->hs_mask = ICR_HS;
> + }
Okay, having the same code twice is not nice as well.
Sorry for missing this in the first review and going a step back, but I
think now the best solution is to have again a REGS_A3700 struct, but we
should extend it with new entries for the shifted bits. Then in the init
code, you can do something like:
i2c->fm_mask = pxa_reg_layout[i2c_type].fm_mask ?: ICR_FM;
Makes sense?
Thanks,
Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161129/53f523c7/attachment-0001.sig>
^ permalink raw reply
* [PATCH v4] clkdev: add devm_of_clk_get()
From: Stephen Boyd @ 2016-11-29 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zikjw08i.wl%kuninori.morimoto.gx@renesas.com>
On 11/29, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
> This patch adds it. It is implemeted in clk-devres.c to share
> devm_clk_release().
Please add an explanation of why we want this sort of API. The
example you gave for audio sound card is useful. We're not going
to remember 5 months from now why we did something, so we should
put that here instead of digging through mailing list archives.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
> index 8f57154..2449b25 100644
> --- a/drivers/clk/clk-devres.c
> +++ b/drivers/clk/clk-devres.c
> @@ -53,3 +53,24 @@ void devm_clk_put(struct device *dev, struct clk *clk)
> WARN_ON(ret);
> }
> EXPORT_SYMBOL(devm_clk_put);
> +
> +struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index)
Please call this devm_get_clk_from_child() instead. Also, replace
the index argument with a string called con_id. Then call
of_clk_get_by_name() instead of of_clk_get().
> +{
> + struct clk **ptr, *clk;
> +
> + ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return ERR_PTR(-ENOMEM);
> +
> + clk = of_clk_get(np, index);
> + if (!IS_ERR(clk)) {
> + *ptr = clk;
> + devres_add(dev, ptr);
> + } else {
> + devres_free(ptr);
> + }
> +
> + return clk;
> +}
> +EXPORT_SYMBOL(devm_of_clk_get);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 123c027..7f50c5f 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -17,8 +17,9 @@
> #include <linux/notifier.h>
>
> struct device;
> -
> struct clk;
> +struct device_node;
> +struct of_phandle_args;
>
> /**
> * DOC: clk notifier callback types
> @@ -249,6 +250,21 @@ static inline void clk_unprepare(struct clk *clk)
> struct clk *devm_clk_get(struct device *dev, const char *id);
>
> /**
> + * devm_clk_get - lookup and obtain a managed reference to a clock producer.
That doesn't even match the name of the function.
> + * @dev: device for clock "consumer"
> + * @np: pointer to clock consumer node
> + * @index: clock index
> + *
> + * This function parses the clocks, and uses them to look up the
> + * struct clk from the registered list of clock providers by using
> + * @np and @index.
> + *
> + * The clock will automatically be freed when the device is unbound
> + * from the bus.
> + */
> +struct clk *devm_of_clk_get(struct device *dev, struct device_node *np, int index);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Maxime Ripard @ 2016-11-29 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1480414715.git.moinejf@free.fr>
On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> This patchset series adds HDMI video support to the Allwinner
> sun8i SoCs which include the display engine 2 (DE2).
> The driver contains the code for the A83T and H3 SoCs, and
> some H3 boards, but it could be used/extended for other SoCs
> (A64, H2, H5) and boards (Banana PIs, Orange PIs).
Honestly, I'm getting a bit worried by the fact that you ignore
reviews.
On the important reviews that you got that are to be seen as major
issues that block the inclusion, we have:
- The fact that the HDMI driver is actually just a designware IP,
and while you should use the driver that already exists, you just
duplicated all that code.
- The fact that you ignored Rob (v6) and I (v5) comment on using OF
graph to model the connection between the display engine and the
TCON. Something that Laurent also pointed out in this version.
- The fact that you ignored that you needed an HDMI connector node
as a child of the HDMI controller. This has been reported by Rob
(v6) and yet again in this version by Laurent.
- 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.
Until those are fixed, I cannot see how this driver can be merged,
unfortunately.
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/20161129/3fff35b9/attachment.sig>
^ permalink raw reply
* [PATCH v2] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-29 21:39 UTC (permalink / raw)
To: linux-arm-kernel
Here's another stab at this writeup. I'd appreciate any comments!
Changes from v1 to v2:
- Consumer/Producer is defined for Extended Address Space descriptors;
should be ignored for QWord/DWord/Word Address Space descriptors
- New arches may use Extended Address Space descriptors in PNP0A03 for
bridge registers, including ECAM (if the arch adds support for this)
- Add more details about MCFG and _CBA (Lv's suggestion)
- Incorporate Rafael's suggestions
---
Bjorn Helgaas (1):
PCI: Add information about describing PCI in ACPI
Documentation/PCI/00-INDEX | 2
Documentation/PCI/acpi-info.txt | 180 +++++++++++++++++++++++++++++++++++++++
2 files changed, 182 insertions(+)
create mode 100644 Documentation/PCI/acpi-info.txt
^ permalink raw reply
* [PATCH v2] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-29 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129212816.15663.28100.stgit@bhelgaas-glaptop.roam.corp.google.com>
Add a writeup about how PCI host bridges should be described in ACPI
using PNP0A03/PNP0A08 devices, PNP0C02 devices, and the MCFG table.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
Documentation/PCI/00-INDEX | 2
Documentation/PCI/acpi-info.txt | 180 +++++++++++++++++++++++++++++++++++++++
2 files changed, 182 insertions(+)
create mode 100644 Documentation/PCI/acpi-info.txt
diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f..0780280 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -1,5 +1,7 @@
00-INDEX
- this file
+acpi-info.txt
+ - info on how PCI host bridges are represented in ACPI
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCIEBUS-HOWTO.txt
diff --git a/Documentation/PCI/acpi-info.txt b/Documentation/PCI/acpi-info.txt
new file mode 100644
index 0000000..06b877f
--- /dev/null
+++ b/Documentation/PCI/acpi-info.txt
@@ -0,0 +1,180 @@
+ ACPI considerations for PCI host bridges
+
+The basic requirement is that the ACPI namespace should describe
+*everything* that consumes address space unless there's another standard
+way for the OS to find it [1, 2]. ?For example, windows that are forwarded
+to PCI by a PCI host bridge should be described via ACPI devices, since the
+OS can't locate the host bridge by itself. ?PCI devices *below* the host
+bridge do not need to be described via ACPI, because the resources they
+consume are inside the host bridge windows, and the OS can discover them
+via the standard PCI enumeration mechanism (using config accesses to read
+and size the BARs).
+
+This ACPI resource description is done via _CRS objects of devices in the
+ACPI namespace [2]. ? The _CRS is like a generalized PCI BAR: the OS can
+read _CRS and figure out what resource is being consumed even if it doesn't
+have a driver for the device [3]. ?That's important because it means an old
+OS can work correctly even on a system with new devices unknown to the OS.
+The new devices won't do anything, but the OS can at least make sure no
+resources conflict with them.
+
+Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
+reserving address space! The static tables are for things the OS needs to
+know early in boot, before it can parse the ACPI namespace. If a new table
+is defined, an old OS needs to operate correctly even though it ignores the
+table. _CRS allows that because it is generic and understood by the old
+OS; a static table does not.
+
+If the OS is expected to manage a non-discoverable device described via
+ACPI, that device will have a specific _HID/_CID that tells the OS what
+driver to bind to it, and the _CRS tells the OS and the driver where the
+device's registers are.
+
+PCI host bridges are PNP0A03 or PNP0A08 devices. ?Their _CRS should
+describe all the address space they consume. ?This includes all the windows
+they forward down to the PCI bus, as well as bridge registers that are not
+forwarded to PCI. ?The bridge registers include things like secondary/
+subordinate bus registers that determine the bus range below the bridge,
+window registers that describe the apertures, etc. ?These are all
+device-specific, non-architected things, so the only way a PNP0A03/PNP0A08
+driver can manage them is via _PRS/_CRS/_SRS, which contain the
+device-specific details. ?The bridge registers also include ECAM space,
+since it is consumed by the bridge.
+
+ACPI defines a Consumer/Producer bit to distinguish the bridge registers
+("Consumer") from the bridge apertures ("Producer") [4, 5], but early
+BIOSes didn't use that bit correctly. The result is that the current ACPI
+spec defines Consumer/Producer only for the relatively new Extended Address
+Space descriptors; the bit should be ignored in the older QWord/DWord/Word
+Address Space descriptors. Consequently, OSes have to assume all
+QWord/DWord/Word descriptors are windows.
+
+Prior to the addition of Extended Address Space descriptors, the failure of
+Consumer/Producer meant there was no way to describe bridge registers in
+the PNP0A03/PNP0A08 device itself. The workaround was to describe the
+bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
+With the exception of ECAM, the bridge register space is device-specific
+anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
+know about it. ?
+
+New architectures should be able to use "Consumer" Extended Address Space
+descriptors in the PNP0A03 device for bridge registers, including ECAM,
+although a strict interpretation of [6] might prohibit this. Old x86 and
+ia64 kernels assume all address space descriptors, including "Consumer"
+Extended Address Space ones, are windows, so it would not be safe to
+describe bridge registers this way on those architectures.
+
+PNP0C02 "motherboard" devices are basically a catch-all. ?There's no
+programming model for them other than "don't use these resources for
+anything else." ?So a PNP0C02 _CRS should claim any address space that is
+(1) not claimed by _CRS under any other device object in the ACPI namespace
+and (2) should not be assigned by the OS to something else.
+
+The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
+unless there's a standard firmware interface for config access, e.g., the
+ia64 SAL interface [7]. A host bridge consumes ECAM memory address space
+and converts memory accesses into PCI configuration accesses. The spec
+defines the ECAM address space layout and functionality; only the base of
+the address space is device-specific. An ACPI OS learns the base address
+from either the static MCFG table or a _CBA method in the PNP0A03 device.
+
+The MCFG table must describe the ECAM space of non-hot pluggable host
+bridges [8]. Since MCFG is a static table and can't be updated by hotplug,
+a _CBA method in the PNP0A03 device describes the ECAM space of a
+hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base
+address always corresponds to bus 0, even if the bus range below the bridge
+(which is reported via _CRS) doesn't start at 0.
+
+
+[1] ACPI 6.0, sec 6.1:
+ For any device that is on a non-enumerable type of bus (for example, an
+ ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
+ system firmware must supply an _HID object ... for each device to
+ enable OSPM to do that.
+
+[2] ACPI 6.0, sec 3.7:
+ The OS enumerates motherboard devices simply by reading through the
+ ACPI Namespace looking for devices with hardware IDs.
+
+ Each device enumerated by ACPI includes ACPI-defined objects in the
+ ACPI Namespace that report the hardware resources the device could
+ occupy [_PRS], an object that reports the resources that are currently
+ used by the device [_CRS], and objects for configuring those resources
+ [_SRS]. The information is used by the Plug and Play OS (OSPM) to
+ configure the devices.
+
+[3] ACPI 6.0, sec 6.2:
+ OSPM uses device configuration objects to configure hardware resources
+ for devices enumerated via ACPI. Device configuration objects provide
+ information about current and possible resource requirements, the
+ relationship between shared resources, and methods for configuring
+ hardware resources.
+
+ When OSPM enumerates a device, it calls _PRS to determine the resource
+ requirements of the device. It may also call _CRS to find the current
+ resource settings for the device. Using this information, the Plug and
+ Play system determines what resources the device should consume and
+ sets those resources by calling the device?s _SRS control method.
+
+ In ACPI, devices can consume resources (for example, legacy keyboards),
+ provide resources (for example, a proprietary PCI bridge), or do both.
+ Unless otherwise specified, resources for a device are assumed to be
+ taken from the nearest matching resource above the device in the device
+ hierarchy.
+
+[4] ACPI 6.0, sec 6.4.3.5.1, 2, 3, 4:
+ QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
+ General Flags: Bit [0] Ignored
+
+ Extended Address Space Descriptor (.4)
+ General Flags: Bit [0] Consumer/Producer:
+ 1?This device consumes this resource
+ 0?This device produces and consumes this resource
+
+[5] ACPI 6.0, sec 19.6.43:
+ ResourceUsage specifies whether the Memory range is consumed by
+ this device (ResourceConsumer) or passed on to child devices
+ (ResourceProducer). If nothing is specified, then
+ ResourceConsumer is assumed.
+
+[6] PCI Firmware 3.0, sec 4.1.2:
+ If the operating system does not natively comprehend reserving the
+ MMCFG region, the MMCFG region must be reserved by firmware. The
+ address range reported in the MCFG table or by _CBA method (see Section
+ 4.1.3) must be reserved by declaring a motherboard resource. For most
+ systems, the motherboard resource would appear at the root of the ACPI
+ namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
+ the resources in this case should not be claimed in the root PCI bus?s
+ _CRS. The resources can optionally be returned in Int15 E820 or
+ EFIGetMemoryMap as reserved memory but must always be reported through
+ ACPI as a motherboard resource.
+
+[7] PCI Express 3.0, sec 7.2.2:
+ For systems that are PC-compatible, or that do not implement a
+ processor-architecture-specific firmware interface standard that allows
+ access to the Configuration Space, the ECAM is required as defined in
+ this section.
+
+[8] PCI Firmware 3.0, sec 4.1.2:
+ The MCFG table is an ACPI table that is used to communicate the base
+ addresses corresponding to the non-hot removable PCI Segment Groups
+ range within a PCI Segment Group available to the operating system at
+ boot. This is required for the PC-compatible systems.
+
+ The MCFG table is only used to communicate the base addresses
+ corresponding to the PCI Segment Groups available to the system at
+ boot.
+
+[9] PCI Firmware 3.0, sec 4.1.3:
+ The _CBA (Memory mapped Configuration Base Address) control method is
+ an optional ACPI object that returns the 64-bit memory mapped
+ configuration base address for the hot plug capable host bridge. The
+ base address returned by _CBA is processor-relative address. The _CBA
+ control method evaluates to an Integer.
+
+ This control method appears under a host bridge object. When the _CBA
+ method appears under an active host bridge object, the operating system
+ evaluates this structure to identify the memory mapped configuration
+ base address corresponding to the PCI Segment Group for the bus number
+ range specified in _CRS method. An ACPI name space object that contains
+ the _CBA method must also contain a corresponding _SEG method.
^ permalink raw reply related
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Maxime Ripard @ 2016-11-29 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66yQ2d=12P_MYyQXTfcZnNAMcb+0i=NEab4sNcJZUyL-w@mail.gmail.com>
On Mon, Nov 28, 2016 at 06:24:24PM +0800, Chen-Yu Tsai wrote:
> On Mon, Nov 28, 2016 at 6:19 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
> >
> >
> > 28.11.2016, 18:07, "Chen-Yu Tsai" <wens@csie.org>:
> >> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy@aosc.xyz> wrote:
> >>> As there's currently a fork of U-Boot which provides simplefb support
> >>
> >> Please add it when its finalized...
> >>
> >>> for H3, a simplefb node can be added to the device tree.
> >>>
> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >>> ---
> >>>
> >>> I'm still not sure which pipeline should I use.
> >>
> >> You are supposed to add _all_ the pipelines that are available and
> >> supported by U-boot. U-boot is then supposed to enable and update
> >> the one it set up.
> >
> > I mean the pipeline string ;-)
>
> Looks good to me. There's no separate frontend/backend in DE 2.0.
It looks good to me too.
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/20161129/5cd26f51/attachment.sig>
^ permalink raw reply
* [PATCH V10 4/6] arm: arm64: pmu: Assign platform PMU CPU affinity
From: Jeremy Linton @ 2016-11-29 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129105255.GD30283@arm.com>
Hi,
On 11/29/2016 04:52 AM, Will Deacon wrote:
> On Wed, Nov 09, 2016 at 05:39:51PM -0600, Jeremy Linton wrote:
>> On systems with multiple PMU types the PMU to CPU affinity
>> needs to be detected and set. The CPU to interrupt affinity
>> should also be set.
>>
(trimming)
>> +static int probe_plat_pmu(struct arm_pmu *pmu,
>> + const struct pmu_probe_info *info,
>> + unsigned int pmuid)
>> {
>> - int cpu = get_cpu();
>> - unsigned int cpuid = read_cpuid_id();
>> int ret = -ENODEV;
>> + int cpu;
>> + int aff_ctr = 0;
>> + static int duplicate_pmus;
>> + struct platform_device *pdev = pmu->plat_device;
>> + int irq = platform_get_irq(pdev, 0);
>>
>> - pr_info("probing PMU on CPU %d\n", cpu);
>> + if (irq >= 0 && !irq_is_percpu(irq)) {
>> + pmu->irq_affinity = kcalloc(pdev->num_resources, sizeof(int),
>> + GFP_KERNEL);
>> + if (!pmu->irq_affinity)
>> + return -ENOMEM;
>> + }
>>
>> + for_each_possible_cpu(cpu) {
>> + unsigned int cpuid = read_specific_cpuid(cpu);
>> +
>> + if (cpuid == pmuid) {
>> + cpumask_set_cpu(cpu, &pmu->supported_cpus);
>> + if (pmu->irq_affinity) {
>> + pmu->irq_affinity[aff_ctr] = cpu;
>> + aff_ctr++;
>> + }
>> + }
>> + }
>> +
>> + /* find the type of PMU given the CPU */
>> for (; info->init != NULL; info++) {
>> - if ((cpuid & info->mask) != info->cpuid)
>> + if ((pmuid & info->mask) != info->cpuid)
>> continue;
>> ret = info->init(pmu);
>> + /*
>> + * if this pmu declaration is unspecified and we have
>> + * previously found a PMU on this platform then append
>> + * a PMU number to the pmu name. This avoids changing
>> + * the names of PMUs that are specific to a class of CPUs.
>> + * The assumption is that if we match a specific PMU in the
>> + * provided pmu_probe_info then it's unique, and another PMU
>> + * in the system will match a different entry rather than
>> + * needing the _number to assure its unique.
>> + */
>> + if ((!info->cpuid) && (duplicate_pmus)) {
>
> This is a bit grim: if you had a PMU with a non-zero info->cpuid, then you
> later found a PMU with a zeroed info->cpuid, the latter would get a
> redundant suffix. This doesn't happen in reality, because the ACPI case
> always has info->cpuid == 0, but if somebody extends armv8_pmu_probe_table
> then we'd get this and probably not realise.
Hoisting the duplicate_pmus inside the !info->cpuid fixes that...
>
> I think the duplicate_pmus counter needs to be tied explicitly to the
> "default type" (i.e. when info->cpuid == 0, but see my next comment).
>
>> + pmu->name = kasprintf(GFP_KERNEL, "%s_%d",
>> + pmu->name, duplicate_pmus);
>> + if (!pmu->name) {
>> + kfree(pmu->irq_affinity);
>> + ret = -ENOMEM;
>> + }
>> + }
>
> This code doesn't run for the device-tree probing case, but I think it would
> be useful to do the same numbering trick for e.g. systems with multiple PMUs
> that all end up matching on armv8_pmuv3.
Ok, its pretty straightforward to move the check into
arm_pmu_device_probe() itself and do a string compare against
DEFAULT_V8_PMU define rather than !cpuid.
Ok, I will do that and post v11 as soon as I hear from Russell about
what he wants to do with read_specific_cpuid().
^ permalink raw reply
* [v6,1/2] i2c: qup: add ACPI support
From: Wolfram Sang @ 2016-11-29 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476203277-6893-2-git-send-email-austinwc@codeaurora.org>
On Tue, Oct 11, 2016 at 10:27:56AM -0600, Austin Christ wrote:
> From: Naveen Kaje <nkaje@codeaurora.org>
>
> Add support to get the device parameters from ACPI. Assume
> that the clocks are managed by firmware.
>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> Signed-off-by: Austin Christ <austinwc@codeaurora.org>
> Reviewed-by: Sricharan R <sricharan@codeaurora.org>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161129/d6d08ac8/attachment.sig>
^ permalink raw reply
* [v6,2/2] i2c: qup: support SMBus block read
From: Wolfram Sang @ 2016-11-29 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476203277-6893-3-git-send-email-austinwc@codeaurora.org>
On Tue, Oct 11, 2016 at 10:27:57AM -0600, Austin Christ wrote:
> From: Naveen Kaje <nkaje@codeaurora.org>
>
> I2C QUP driver relies on SMBus emulation support from the framework.
> To handle SMBus block reads, the driver should check I2C_M_RECV_LEN
> flag and should read the first byte received as the message length.
>
> The driver configures the QUP hardware to read one byte. Once the
> message length is known from this byte, the QUP hardware is configured
> to read the rest.
>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> Signed-off-by: Austin Christ <austinwc@codeaurora.org>
> Reviewed-by: Sricharan R <sricharan@codeaurora.org>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161129/03699389/attachment.sig>
^ permalink raw reply
* [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes
From: Maxime Ripard @ 2016-11-29 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125112213.83420594eb435b6bb1a4d164@free.fr>
On Fri, Nov 25, 2016 at 11:22:13AM +0100, Jean-Francois Moine wrote:
> On Fri, 25 Nov 2016 17:41:51 +0800
> Icenowy Zheng <icenowy@aosc.xyz> wrote:
>
> > After removing CLK_PLL_DE's assigned-clock, the kernel passes compilation.
>
> The 'pll-de' and 'de' must have a fixed rate. Otherwise, if you do not
> use the legacy u-boot, I don't know which can be the rate of the DE.
>
> > However, it cannot recognize any HDMI screen...
> >
> > (My board is Orange Pi One, and I manually added status="okay"; to &lcd0, &de, &hdmi)
> >
> > [ 16.507802] sun8i-de2 1000000.de-controller: bound 1c0c000.lcd-controller (ops de2_lcd_ops [sun8i_de2_drm])
> > [ 16.675948] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops de2_hdmi_fini [sun8i_de2_hdmi])
> > [ 16.685120] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > [ 16.695876] [drm] No driver support for vblank timestamp query.
> > [ 16.701862] sun8i-de2 1000000.de-controller: No connectors reported connected with modes
> > [ 16.713061] [drm] Cannot find any crtc or sizes - going 1024x768
> > [ 16.734214] Console: switching to colour frame buffer device 128x48
> > [ 16.751022] sun8i-de2 1000000.de-controller: fb0: frame buffer device
>
> I put a 'pr_warn' message is case the EDID cannot be read.
> Have you this message?
>
> Anyway, there is a problem with the EDID:
> - my Orange Pi 2 (H3) randomly fails to read it. But this succeeds after
> rebooting once or twice.
> - my Banana Pi M2+ (H3) reads it correctly each time.
> - my Banana Pi M3 (A83T) can never read it.
>
> BTW, on first tries, I was forcing a CEA mode thru the kernel command
> line. This was working with the OPi2 and BPiM3, but there was no sound.
> In the last version, I use a EDID in edid_firmware for having sound
> with the BPiM3. This works fine.
> But, forcing a CEA mode is no more possible, so, when the OPi2 cannot
> read the EDID, the system switches to a VGA mode (default 1024x768)
> which is not supported. It seems that this is your case.
>
> So, in brief, if your board cannot read the EDID, put a EDID somewhere
> and its path in /sys/module/drm_kms_helper/parameters/edid_firmware.
> There will be no console, but X11 will work correctly.
This is one of the things that are usually very helpful to put in a
cover letter. This is obviously also a blocker for the merge of the
driver, and should be dealt with.
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/20161129/a265faef/attachment.sig>
^ permalink raw reply
* [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Maxime Ripard @ 2016-11-29 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114218.14d2ed434802a20fa6b62023@free.fr>
On Mon, Nov 28, 2016 at 11:42:18AM +0100, Jean-Francois Moine wrote:
> On Mon, 28 Nov 2016 17:59:00 +0800
> Icenowy Zheng <icenowy@aosc.xyz> wrote:
>
> > As there's currently a fork of U-Boot which provides simplefb support
> > for H3, a simplefb node can be added to the device tree.
> >
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > ---
> >
> > I'm still not sure which pipeline should I use.
> >
> > And, it seems that HDMI Slow Clock is not needed?
> >
> > (seems that it's only for EDID, but simplefb won't use EDID)
>
> So, I don't see how this may work.
> How can the u-boot know the resolutions of the HDMI display device?
>
> In other words: I have a new H3 board with the last u-boot and kernel.
> I plug my (rather old or brand new) HDMI display device.
> After powering on the system, I hope to get something on the screen.
> How?
If it works like the driver for the first display engine in U-Boot, it
will use the preferred mode reported by the EDID, and will fallback to
1024x768 if it cannot access it.
Maybe it would be worth exchanging on the EDID code that has been done
for the u-boot driver too, so that it can be fixed in your driver.
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/20161129/94d75cc0/attachment-0001.sig>
^ permalink raw reply
* Unable to use perf in VM
From: Itaru Kitayama @ 2016-11-29 22:04 UTC (permalink / raw)
To: linux-arm-kernel
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
[ 119.633600] Modules linked in: ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_broute bridge stp
llc ebtable_nat ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_raw ip6table_mangle ip6table_security iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_raw iptable_mangle iptable_security ebtable_filter ebtables
ip6table_filter ip6_tables vfat fat chipreg mtd virtio_net qemu_fw_cfg
nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c virtio_console
virtio_scsi gpio_keys virtio_mmio virtio_ring virtio
[ 119.677249] CPU: 0 PID: 1144 Comm: git Tainted: P 4.8.0 #3
[ 119.682480] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
02/06/2015
[ 119.687660] task: fffffe00ea96cb00 task.stack: fffffe00e6a60000
[ 119.692167] PC is at armv8pmu_read_counter+0x30/0x68
[ 119.695973] LR is at armpmu_event_update+0x34/0x98
[ 119.699615] pc : [<fffffc000808ff30>] lr : [<fffffc00086fe6c4>]
pstate: 800001c5
[ 119.705137] sp : fffffe00e6a63790
[ 119.707663] x29: fffffe00e6a63790 x28: fffffe00f275ca08
[ 119.711875] x27: 0000000000000000 x26: 0000000000000001
[ 119.716097] x25: fffffe00fff22328 x24: 000000001af18c08
[ 119.720345] x23: fffffe00f275ca00 x22: fffffe00ff8d5c00
[ 119.724589] x21: ffffffff87b2b5f5 x20: fffffe00e6a53800
[ 119.728827] x19: fffffe00e6a539c0 x18: 0000000000000000
[ 119.733018] x17: 000003ff8b323c20 x16: 0000000000000000
[ 119.737274] x15: ffffffffffffffff x14: 726573752f656369
[ 119.741395] x13: 6c732e726573752f x12: 0000000000000000
[ 119.745596] x11: 0000000000010000 x10: 0000000000000001
[ 119.749800] x9 : 0000000000000000 x8 : 0000000000000001
[ 119.754042] x7 : 0000000000000000 x6 : 000000d2ea7d1b28
[ 119.758232] x5 : 0000000000000002 x4 : 00000200f7220000
[ 119.762446] x3 : 0000000000000000 x2 : 0000000000000000
[ 119.766655] x1 : fffffc000808ff00 x0 : 0000000000000004
[ 119.770757]
[ 119.771947] Process git (pid: 1144, stack limit = 0xfffffe00e6a60020)
[ 119.776829] Stack: (0xfffffe00e6a63790 to 0xfffffe00e6a64000)
[ 119.781234] 3780: fffffe00e6a637c0
fffffc00086fe790
[ 119.787139] 37a0: fffffe00e6a53800 fffffe00e6a53800 fffffe00ff8d5c00
0000000000000001
[ 119.793007] 37c0: fffffe00e6a637e0 fffffc00086fe7e4 fffffe00fff22210
fffffe00e6a53800
[ 119.798999] 37e0: fffffe00e6a63810 fffffc00081cc260 fffffe00e6a53800
fffffe00e6a53800
[ 119.804893] 3800: fffffe00fff22418 fffffe00fff2241c fffffe00e6a63860
fffffc00081cc404
[ 119.810826] 3820: fffffe00f275ca00 fffffe00e6a53800 fffffe00fff22418
fffffe00fff2241c
[ 119.816766] 3840: fffffe00f275ca00 fffffe00e6a53800 fffffe00fff22328
0000000000000007
[ 119.822690] 3860: fffffe00e6a638b0 fffffc00081cc900 fffffe00f275ca00
fffffe00e6a53800
[ 119.828597] 3880: fffffe00fff22328 fffffe00f275ca58 fffffe00f275ca48
fffffe00ea96d3b0
[ 119.834537] 38a0: fffffc0008d7ba00 fffffe00fff22328 fffffe00e6a638f0
fffffc00081cca00
[ 119.840379] 38c0: fffffc0008cf7000 fffffe00ea96d3a0 fffffc0008d7c2a0
fffffe00f275ca00
[ 119.846291] 38e0: fffffe00ea96cb00 fffffc00081ce554 fffffe00e6a63900
fffffc00081ce560
[ 119.852112] 3900: fffffe00e6a63990 fffffc000884655c fffffc0008d7ba00
fffffe00fff1ad80
[ 119.858904] 3920: fffffc0008d74000 fffffe00ea96cb00 fffffc00088469b0
0000000000000000
[ 119.864738] 3940: fffffe00ea96d108 fffffe00fff1ad80 0000000000000054
fffffe00e44b39a8
[ 119.870551] 3960: fffffc0008d7ba00 fffffe00fff1ad80 fffffc0008d74000
fffffe00ea96cb00
[ 119.876396] 3980: fffffc00088469b0 fffffe00fff1ad80 fffffe00e6a63a00
fffffc00088469b0
[ 119.882286] 39a0: fffffe00e6a60000 fffffc0008846208 fffffe00fff1b698
7fffffffffffffff
[ 119.888225] 39c0: fffffe00e6a63b70 fffffe00f296ca80 fffffdff80387c80
fffffe00f27f3f00
[ 119.894004] 39e0: 0000000000000054 fffffc00083c6dec fffffe00ee7e7e00
00000000ffffffff
[ 119.899745] 3a00: fffffe00e6a63a20 fffffc00088499ec 7fffffffffffffff
fffffc00083c6df8
[ 119.905577] 3a20: fffffe00e6a63ac0 fffffc0008846208 fffffe00fff1ad80
0000000000000000
[ 119.911378] 3a40: fffffe00fff1b698 7fffffffffffffff fffffe00e6a63b70
fffffe00f296ca80
[ 119.917247] 3a60: fffffdff80387c80 fffffe00f27f3f00 fffffe00e6a63aa0
fffffc000818ac7c
[ 119.923206] 3a80: fffffe00ebdb4d00 0000000000000000 fffffe00ffff5a50
7fffffffffffffff
[ 119.929031] 3aa0: fffffe00e6a63ac0 fffffc0008846200 0000000000000000
0000000000000040
[ 119.934854] 3ac0: fffffe00e6a63af0 fffffc0008847270 0000000000000082
fffffe00e6a63b88
[ 119.940671] 3ae0: fffffe00ffff5a50 fffffc0008847250 fffffe00e6a63b10
fffffc0008846e54
[ 119.946549] 3b00: 0000000000000082 fffffc0008847250 fffffe00e6a63b50
fffffc00081dd688
[ 119.952327] 3b20: 000000000000008a 003fffe000010001 fffffe00f27f3f00
fffffe00f2754900
[ 119.958198] 3b40: fffffe00e6a63cd0 fffffe00f296ca80 fffffe00e6a63bb0
fffffc00081ddf4c
[ 119.964079] 3b60: 0000000000000054 fffffdff80387c80 fffffdff80387c80
0000000000000000
[ 119.969913] 3b80: 0000000000000000 0000000000000000 fffffe00ea96cb00
fffffc000810ce90
[ 119.975650] 3ba0: fffffe00ffff5a58 fffffe00ffff5a58 fffffe00e6a63be0
fffffc00081de310
[ 119.981448] 3bc0: 0000000000000009 fffffe00e44b3b20 0000000000000004
fffffe00e44b3b20
[ 119.987351] 3be0: fffffe00e6a63c50 fffffc0000909ec4 fffffe00e6a63d68
fffffe00e44b3840
[ 119.993135] 3c00: fffffe00e44b39a8 fffffe00f296ca80 fffffe00e6a63cd0
0000000000000024
[ 119.998861] 3c20: 0000000000000054 fffffe00f296ca80 fffffe00f27f3f60
0000000000020000
[ 120.004540] 3c40: fffffe00e44b39a8 024000c0f296ca80 fffffe00e6a63c90
fffffc0008211a68
[ 120.010243] 3c60: fffffe00e6a63d68 fffffe00e6a63d60 0000000000000000
0000000000000000
[ 120.015886] 3c80: 0000000000000009 0000000000000040 fffffe00e6a63d00
fffffc00082174e0
[ 120.021599] 3ca0: fffffe00f296ca80 fffffe00f296ca80 0000000000000040
0000000000000009
[ 120.027289] 3cc0: fffffe00e6a63d68 fffffdff80387c40 024200ca00000054
0000000000000009
[ 120.032992] 3ce0: 000003ff7b940000 0000000000000000 0000000000000000
000002aaf1820000
[ 120.038714] 3d00: fffffe00e6a63da0 fffffc000884cd70 fffffe00e6a63ec0
0000000092000007
[ 120.044401] 3d20: fffffe00ea96cb00 000003ff7b940e54 fffffe00f27f3f00
0000000000000024
[ 120.050125] 3d40: 0000000000000054 fffffc00081d21d4 fffffe00e6a63d70
fffffc000821a26c
[ 120.055824] 3d60: 000003ff7b940e54 fffffe00f296ca80 000003ff7b940000
0000000000000054
[ 120.061514] 3d80: fffffe00e6a8ffd8 0000000000000000 0000000000000000
0000000000000000
[ 120.067304] 3da0: fffffe00e6a63e10 fffffc0008081344 fffffc00088900c8
0000000092000007
[ 120.073004] 3dc0: 000003ff7b940e54 fffffe00e6a63ec0 0000000020000000
0000000000000024
[ 120.078732] 3de0: 0000000092000007 000003ff7b940e54 0000000000000014
fffffe00e6a60000
[ 120.084436] 3e00: fffffe00e6a63e30 0000000000000007 0000000000000000
fffffc0008083038
[ 120.090209] 3e20: 0000000000000000 000002aaf17d5700 ffffffffffffffff
000002aacbd75a6c
[ 120.095903] 3e40: fffffe00e6a63e60 fffffc0008114c64 00000000000000d6
0000000000000004
[ 120.101618] 3e60: fffffe00e6a63e80 fffffc000821d310 000002aaf1820000
00000000000000d6
[ 120.107317] 3e80: fffffe00e6a63ea0 fffffc0008088644 0000000000000008
fffffe00e6a63ec0
[ 120.113005] 3ea0: 0000000000000000 fffffc00080832dc 0000000000000000
0000000000000069
[ 120.118725] 3ec0: 0000000000000000 000003ff7b940e54 0000000000000001
000003ff7b8b0008
[ 120.124410] 3ee0: 000003ffcd064400 ffffffff00000000 000002aacbe4718c
000002aacbde3aa8
[ 120.130144] 3f00: fefefeff64647173 0000000000000000 000002aaf17c6550
0101010101010101
[ 120.135836] 3f20: 0000000000000020 ffffffffffffffff ffffffff00000000
ffffffffffffffff
[ 120.141532] 3f40: 000002aacbe3f9e0 000003ff8b323c20 0000000000000000
000002aacbe4718c
[ 120.147249] 3f60: 000002aaf17d5700 000003ffcd064400 00000000000073b7
000002aaf17d5700
[ 120.152939] 3f80: 0000000000009a0f 0000000000004d60 000003ff7b8b0408
0000000000000014
[ 120.158650] 3fa0: 000002aacbe47000 000003ffcd0641a0 000002aacbd75e1c
000003ffcd0641a0
[ 120.164353] 3fc0: 000002aacbd75a6c 0000000020000000 0000000000000000
ffffffffffffffff
[ 120.170063] 3fe0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 120.175744] Call trace:
[ 120.177588] Exception stack(0xfffffe00e6a63630 to 0xfffffe00e6a63760)
[ 120.182279] 3620: fffffe00e6a539c0
0000040000000000
[ 120.187964] 3640: fffffe00e6a63790 fffffc000808ff30 00000000800001c5
0000000000000080
[ 120.193657] 3660: 0000000000000004 fffffc000808ff00 0000000000000000
0000000000000000
[ 120.199343] 3680: 00000200f7220000 0000000000000002 000000d2ea7d1b28
0000000000000000
[ 120.205011] 36a0: 0000000000000001 0000000000000000 0000000000000001
0000000000010000
[ 120.210698] 36c0: 0000000000000000 6c732e726573752f 726573752f656369
ffffffffffffffff
[ 120.216366] 36e0: 0000000000000000 000003ff8b323c20 0000000000000000
fffffe00e6a539c0
[ 120.222066] 3700: fffffe00e6a53800 ffffffff87b2b5f5 fffffe00ff8d5c00
fffffe00f275ca00
[ 120.227747] 3720: 000000001af18c08 fffffe00fff22328 0000000000000001
0000000000000000
[ 120.233426] 3740: fffffe00f275ca08 fffffe00e6a63790 fffffc00086fe6c4
fffffe00e6a63790
[ 120.239117] [<fffffc000808ff30>] armv8pmu_read_counter+0x30/0x68
[ 120.243497] [<fffffc00086fe790>] armpmu_stop+0x38/0x50
[ 120.247263] [<fffffc00086fe7e4>] armpmu_del+0x3c/0x78
[ 120.250957] [<fffffc00081cc260>] event_sched_out.isra.49+0x140/0x2a0
[ 120.255610] [<fffffc00081cc404>] group_sched_out+0x44/0xc0
[ 120.259622] [<fffffc00081cc900>] ctx_sched_out+0x100/0x1d8
[ 120.263629] [<fffffc00081cca00>] task_ctx_sched_out+0x28/0x58
[ 120.267822] [<fffffc00081ce560>] __perf_event_task_sched_out+0x128/0x368
[ 120.272704] [<fffffc000884655c>] __schedule+0x2ec/0x708
[ 120.276527] [<fffffc00088469b0>] schedule+0x38/0x98
[ 120.280114] [<fffffc00088499ec>] schedule_timeout+0x29c/0x3c0
[ 120.284479] [<fffffc0008846208>] io_schedule_timeout+0xa0/0x108
[ 120.288822] [<fffffc0008847270>] bit_wait_io+0x20/0x70
[ 120.292584] [<fffffc0008846e54>] __wait_on_bit+0xac/0xe8
[ 120.296448] [<fffffc00081dd688>] wait_on_page_bit_killable+0xe0/0xf0
[ 120.301084] [<fffffc00081ddf4c>] __lock_page_or_retry+0xcc/0xf8
[ 120.305416] [<fffffc00081de310>] filemap_fault+0x398/0x548
[ 120.309680] [<fffffc0000909ec4>] xfs_filemap_fault+0x64/0x140 [xfs]
[ 120.314278] [<fffffc0008211a68>] __do_fault+0x78/0x150
[ 120.318045] [<fffffc00082174e0>] handle_mm_fault+0x5d0/0x9c0
[ 120.322171] [<fffffc000884cd70>] do_page_fault+0x2f8/0x3b0
[ 120.326178] [<fffffc0008081344>] do_mem_abort+0x54/0xb0
[ 120.329987] Exception stack(0xfffffe00e6a63e20 to 0xfffffe00e6a63f50)
[ 120.334670] 3e20: 0000000000000000 000002aaf17d5700 ffffffffffffffff
000002aacbd75a6c
[ 120.340351] 3e40: fffffe00e6a63e60 fffffc0008114c64 00000000000000d6
0000000000000004
[ 120.346050] 3e60: fffffe00e6a63e80 fffffc000821d310 000002aaf1820000
00000000000000d6
[ 120.351720] 3e80: fffffe00e6a63ea0 fffffc0008088644 0000000000000008
fffffe00e6a63ec0
[ 120.357387] 3ea0: 0000000000000000 fffffc00080832dc 0000000000000000
0000000000000069
[ 120.363089] 3ec0: 0000000000000000 000003ff7b940e54 0000000000000001
000003ff7b8b0008
[ 120.368760] 3ee0: 000003ffcd064400 ffffffff00000000 000002aacbe4718c
000002aacbde3aa8
[ 120.374561] 3f00: fefefeff64647173 0000000000000000 000002aaf17c6550
0101010101010101
[ 120.380260] 3f20: 0000000000000020 ffffffffffffffff ffffffff00000000
ffffffffffffffff
[ 120.385981] 3f40: 000002aacbe3f9e0 000003ff8b323c20
[ 120.389526] [<fffffc0008083038>] el0_da+0x18/0x1c
[ 120.392978] Code: 51000442 92401042 d51b9ca2 d5033fdf (d53b9d40)
^ permalink raw reply
* [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eric Anholt @ 2016-11-29 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129013436.GA3080@localhost.localdomain>
Eduardo Valentin <edubezval@gmail.com> writes:
> Hello Eric, Martin,
>
> On Mon, Nov 28, 2016 at 12:30:38PM -0800, Eric Anholt wrote:
>> Either the device was initialized by the firmware before handing off to
>> ARM (today's firmware) or it never will be (potential future firmware).
>
> And do you have a way to check if the firmware has the initialization
> code or not? By firmware version, for example. Or even, chip version,
> maybe?
We would know if it's not present because the register would be in its
power-on reset state, which is what the code is checking for.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161129/63bdda2f/attachment.sig>
^ permalink raw reply
* [PATCH RESEND 2/2] gpio: axp209: add pinctrl support
From: Quentin Schulz @ 2016-11-29 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb8cej=AMs2kO1Vks-WYeae+CtAW2YOCc+Pz3E49mcrDQ@mail.gmail.com>
Hi Linus,
On 24/11/2016 15:17, Linus Walleij wrote:
> On Wed, Nov 23, 2016 at 3:11 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>
>> The GPIOs present in the AXP209 PMIC have multiple functions. They
>> typically allow a pin to be used as GPIO input or output and can also be
>> used as ADC or regulator for example.[1]
>>
>> This adds the possibility to use all functions of the GPIOs present in
>> the AXP209 PMIC thanks to pinctrl subsystem.
>>
>> [1] see registers 90H, 92H and 93H at
>> http://dl.linux-sunxi.org/AXP/AXP209_Datasheet_v1.0en.pdf
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>
> I need Maxime's review on this patch.
>
>> .../devicetree/bindings/gpio/gpio-axp209.txt | 28 +-
>
> Also move the bindings to pinctrl/pinctrl-axp209.txt
>
>> drivers/gpio/gpio-axp209.c | 551 ++++++++++++++++++---
>
> Combined drivers should be in drivers/pinctrl/*.
>
> Make a separate patch moving the driver to
> drivers/pinctrl/pinctrl-axp209.c (remember -M to git format-patch)
> augment Kconfig and Makefile in both subsystems and make
> these patches on top of that.
>
So basically:
- first patch for adding pinctrl to the existing driver
- second patch for moving the driver and binding from gpio to pinctrl
subsystem
- third patch for both removing Kconfig entry and Makefile rule from
gpio subsystem, and adding a Kconfig entry and a Makefile rule in
pinctrl subsystem
Is that what you want?
Thanks,
Quentin
> I will deal with cross-merging the result between the GPIO
> and pin control trees.
>
> Yours,
> Linus Walleij
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-29 22:15 UTC (permalink / raw)
To: linux-arm-kernel
The irq_set_affinity_hint() will always fail when !SMP and
Networking will fail on Keystone 2 devices in this case.
Hence, fix by ignoring IRQ affinity settings when !SMP.
Cc: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/soc/ti/knav_qmss_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index b73e353..3aa0470 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1228,7 +1228,7 @@ static int knav_setup_queue_range(struct knav_device *kdev,
range->num_irqs++;
- if (oirq.args_count == 3)
+ if (IS_ENABLED(SMP) && oirq.args_count == 3)
range->irqs[i].cpu_map =
(oirq.args[2] & 0x0000ff00) >> 8;
}
--
2.10.1
^ permalink raw reply related
* [PATCHv4 06/10] xen: Switch to using __pa_symbol
From: Boris Ostrovsky @ 2016-11-29 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-7-git-send-email-labbott@redhat.com>
On 11/29/2016 01:55 PM, Laura Abbott wrote:
> __pa_symbol is the correct macro to use on kernel
> symbols. Switch to this from __pa.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> Found during a sweep of the kernel. Untested.
> ---
> drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
> drivers/xen/xenfs/xenstored.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
> index 4a41ac9..31ca2bf 100644
> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -99,7 +99,7 @@ static int xenbus_backend_mmap(struct file *file, struct vm_area_struct *vma)
> return -EINVAL;
>
> if (remap_pfn_range(vma, vma->vm_start,
> - virt_to_pfn(xen_store_interface),
> + PHYS_PFN(__pa_symbol(xen_store_interface)),
> size, vma->vm_page_prot))
> return -EAGAIN;
>
> diff --git a/drivers/xen/xenfs/xenstored.c b/drivers/xen/xenfs/xenstored.c
> index fef20db..21009ea 100644
> --- a/drivers/xen/xenfs/xenstored.c
> +++ b/drivers/xen/xenfs/xenstored.c
> @@ -38,7 +38,7 @@ static int xsd_kva_mmap(struct file *file, struct vm_area_struct *vma)
> return -EINVAL;
>
> if (remap_pfn_range(vma, vma->vm_start,
> - virt_to_pfn(xen_store_interface),
> + PHYS_PFN(__pa_symbol(xen_store_interface)),
> size, vma->vm_page_prot))
> return -EAGAIN;
>
I suspect this won't work --- xen_store_interface doesn't point to a
kernel symbol.
-boris
^ permalink raw reply
* [PATCHv4 06/10] xen: Switch to using __pa_symbol
From: Laura Abbott @ 2016-11-29 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <935fefbf-97dc-83fc-b7c3-ba3f19f2087f@oracle.com>
On 11/29/2016 02:26 PM, Boris Ostrovsky wrote:
> On 11/29/2016 01:55 PM, Laura Abbott wrote:
>> __pa_symbol is the correct macro to use on kernel
>> symbols. Switch to this from __pa.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> Found during a sweep of the kernel. Untested.
>> ---
>> drivers/xen/xenbus/xenbus_dev_backend.c | 2 +-
>> drivers/xen/xenfs/xenstored.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
>> index 4a41ac9..31ca2bf 100644
>> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
>> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
>> @@ -99,7 +99,7 @@ static int xenbus_backend_mmap(struct file *file, struct vm_area_struct *vma)
>> return -EINVAL;
>>
>> if (remap_pfn_range(vma, vma->vm_start,
>> - virt_to_pfn(xen_store_interface),
>> + PHYS_PFN(__pa_symbol(xen_store_interface)),
>> size, vma->vm_page_prot))
>> return -EAGAIN;
>>
>> diff --git a/drivers/xen/xenfs/xenstored.c b/drivers/xen/xenfs/xenstored.c
>> index fef20db..21009ea 100644
>> --- a/drivers/xen/xenfs/xenstored.c
>> +++ b/drivers/xen/xenfs/xenstored.c
>> @@ -38,7 +38,7 @@ static int xsd_kva_mmap(struct file *file, struct vm_area_struct *vma)
>> return -EINVAL;
>>
>> if (remap_pfn_range(vma, vma->vm_start,
>> - virt_to_pfn(xen_store_interface),
>> + PHYS_PFN(__pa_symbol(xen_store_interface)),
>> size, vma->vm_page_prot))
>> return -EAGAIN;
>>
>
>
> I suspect this won't work --- xen_store_interface doesn't point to a
> kernel symbol.
>
> -boris
>
I reviewed this again and yes you are right. I missed that this
was a pointer and not just a symbol so I think this patch can
just be dropped.
Thanks,
Laura
^ permalink raw reply
* [PATCH] arm: add stat support to fiq
From: Oussama Ghorbel @ 2016-11-29 22:48 UTC (permalink / raw)
To: linux-arm-kernel
This patch allows drivers that uses fiq to have a stat on the
execution number of the fiq handler.
For that three APIs has been defined:
- fiq_kstat_enable: this function enables fiq stat and allocates required
memory for it
- fiq_kstat_disable: this function disable fiq stat and free its allocated
memory
- fiq_kstat_this_cpu_inc: This function increments the fiq stat counter of
the current CPU running the fiq handler
A driver may call fiq_kstat_enable at its initialization to enable fiq
stat and then call fiq_kstat_this_cpu_inc from the fiq handler
When the fiq stat is enabled by a driver, then /proc/interrupts shows the
fiq entry as the following example:
FIQ: 0 21642080 0 0 usb_fiq
If the fiq stat is not enabled, the content will be similar to the old one
as the following example:
FIQ: usb_fiq
The fiq name will be always written on the first column after the last CPU
column
Signed-off-by: Oussama Ghorbel <ghorbel@gmail.com>
---
arch/arm/include/asm/fiq.h | 10 ++++++++++
arch/arm/kernel/fiq.c | 31 +++++++++++++++++++++++++++----
2 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/fiq.h b/arch/arm/include/asm/fiq.h
index d493d0b..77f819b 100644
--- a/arch/arm/include/asm/fiq.h
+++ b/arch/arm/include/asm/fiq.h
@@ -31,6 +31,8 @@ struct fiq_handler {
/* data for the relinquish/reacquire functions
*/
void *dev_id;
+ /* fiq stats percpu */
+ unsigned int __percpu *fiq_kstat;
};
extern int claim_fiq(struct fiq_handler *f);
@@ -53,4 +55,12 @@ static inline void get_fiq_regs(struct pt_regs *regs)
__get_fiq_regs(®s->ARM_r8);
}
+extern int fiq_kstat_enable(struct fiq_handler *fh);
+extern void fiq_kstat_disable(struct fiq_handler *fh);
+
+static inline void fiq_kstat_this_cpu_inc(struct fiq_handler *fh)
+{
+ __this_cpu_inc(*fh->fiq_kstat);
+}
+
#endif
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index 059c3da..4b606df 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -83,10 +83,19 @@ static struct fiq_handler *current_fiq = &default_owner;
int show_fiq_list(struct seq_file *p, int prec)
{
- if (current_fiq != &default_owner)
- seq_printf(p, "%*s: %s\n", prec, "FIQ",
- current_fiq->name);
-
+ int j;
+
+ if (current_fiq == &default_owner)
+ return 0;
+ seq_printf(p, "%*s: ", prec, "FIQ");
+ for_each_online_cpu(j) {
+ if (current_fiq->fiq_kstat)
+ seq_printf(p, "%10u ",
+ *per_cpu_ptr(current_fiq->fiq_kstat, j));
+ else
+ seq_printf(p, "%10s ", "");
+ }
+ seq_printf(p, " %s\n", current_fiq->name);
return 0;
}
@@ -162,3 +171,17 @@ void __init init_FIQ(int start)
get_fiq_regs(&dfl_fiq_regs);
fiq_start = start;
}
+
+int fiq_kstat_enable(struct fiq_handler *fh)
+{
+ fh->fiq_kstat = alloc_percpu(unsigned int);
+ return fh->fiq_kstat != 0 ? 0 : 1;
+}
+EXPORT_SYMBOL(fiq_kstat_enable);
+
+void fiq_kstat_disable(struct fiq_handler *fh)
+{
+ free_percpu(fh->fiq_kstat);
+ fh->fiq_kstat = NULL;
+}
+EXPORT_SYMBOL(fiq_kstat_disable);
--
2.7.4
^ permalink raw reply related
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Laurent Pinchart @ 2016-11-29 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8398357e-5c5e-4d76-9022-1c668aff5076@googlegroups.com>
Hi Jernej,
(CC'ing Kieran Bingham)
On Tuesday 29 Nov 2016 14:47:20 Jernej Skrabec wrote:
> Dne torek, 29. november 2016 22.37.03 UTC+1 je oseba Maxime Ripard napisala:
> > On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> >> This patchset series adds HDMI video support to the Allwinner
> >> sun8i SoCs which include the display engine 2 (DE2).
> >> The driver contains the code for the A83T and H3 SoCs, and
> >> some H3 boards, but it could be used/extended for other SoCs
> >> (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> >
> > Honestly, I'm getting a bit worried by the fact that you ignore
> > reviews.
> >
> > On the important reviews that you got that are to be seen as major
> >
> > issues that block the inclusion, we have:
> > - The fact that the HDMI driver is actually just a designware IP,
> > and while you should use the driver that already exists, you just
> > duplicated all that code.
>
> That might be hard thing to do. A83T fits perfectly, but H3 and newer SoCs
> do not. They are using completely different HDMI phy. Decoupling controller
> and phy code means rewritting a good portion of the code, unless some tricks
> are applied, like calling phy function pointers, if they are defined.
Same HDMI TX but different HDMI TX PHY ? Kieran is working on decoupling the
PHY configuration code for a Renesas SoC, that might be of interest to you.
> Register addresses also differ, but that can be easily solved by using
> undocumented magic value to restore them.
I love that :-)
> > - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> > graph to model the connection between the display engine and the
> > TCON. Something that Laurent also pointed out in this version.
> >
> > - The fact that you ignored that you needed an HDMI connector node
> > as a child of the HDMI controller. This has been reported by Rob
> > (v6) and yet again in this version by Laurent.
> >
> > - 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.
> >
> > Until those are fixed, I cannot see how this driver can be merged,
> > unfortunately.
--
Regards,
Laurent Pinchart
^ 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