* [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed
From: Marc Zyngier @ 2018-05-25 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <25470133.K8n9sLBzRS@diego>
[Thanks Robin for pointing me to that patch.]
Hi Heiko,
On 24/05/18 23:06, Heiko St?bner wrote:
> From: Sandy Huang <hjc@rock-chips.com>
>
> The vop irq is shared between vop and iommu and irq probing in the
> iommu driver moved to the probe function recently. This can in some
> cases lead to a stall if the irq is triggered while the vop driver
> still has it disabled.
>
> But there is no real need to disable the irq, as the vop can simply
> also track its enabled state and ignore irqs in that case.
>
> So remove the enable/disable handling and add appropriate condition
> to the irq handler.
>
> Signed-off-by: Sandy Huang <hjc@rock-chips.com>
> [added an actual commit message]
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Hi Ezequiel,
>
> this patch came from a discussion I had with Rockchip people over the
> iommu changes and resulting issues back in april, but somehow was
> forgotten and not posted to the lists. Correcting that now.
>
> So removing the enable/disable voodoo on the shared interrupt is
> the preferred way.
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 510cdf0..61493d4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -549,8 +549,6 @@ static int vop_enable(struct drm_crtc *crtc)
>
> spin_unlock(&vop->reg_lock);
>
> - enable_irq(vop->irq);
> -
> drm_crtc_vblank_on(crtc);
>
> return 0;
> @@ -596,8 +594,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
>
> vop_dsp_hold_valid_irq_disable(vop);
>
> - disable_irq(vop->irq);
> -
> vop->is_enabled = false;
>
> /*
> @@ -1168,6 +1164,13 @@ static irqreturn_t vop_isr(int irq, void *data)
> int ret = IRQ_NONE;
>
> /*
> + * since the irq is shared with iommu, iommu irq is enabled before vop
> + * enable, so before vop enable we do nothing.
> + */
> + if (!vop->is_enabled)
> + return IRQ_NONE;
> +
What guarantee do we have that the IOMMU will actually service that
interrupt? Can't we get into a situation where the interrupt gets
ignored by both drivers and subsequently disabled by the core irq code
as being spurious?
>From what I understood of the way things are plugged together on the
rockchip platforms, each individual VOP is behind a single IOMMU, hence
there there is hardly any point in handling IOMMU interrupts if the VOP
is off.
But I'm missing the actual reason behind this patch. Could you enlighten me?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains
From: Jon Hunter @ 2018-05-25 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrTtvhxOhf9BPY1=cJ9VQyx9D=P3O0vCV+WXSVR82FozQ@mail.gmail.com>
On 25/05/18 11:45, Ulf Hansson wrote:
...
>> Right, but this case still seems like an error. My understanding is that
>> only drivers will use this API directly and it will not be used by the
>> device driver core (unlike dev_pm_domain_attach), so if anyone calls this
>> attempting to attach another PM domain when one is already attached, they
>> are doing something wrong.
>
> [...]
>
> You may be right!
>
> What I was thinking of is whether multiple PM domains may be optional
> in some cases, but instead a PM domain have already been attached by
> dev_pm_domain_attach(), prior the driver starts to probe.
>
> Then, assuming we return an error for this case, that means the caller
> then need to check the dev->pm_domain pointer, prior calling
> dev_pm_domain_attach_by_id(). Wouldn't it? Perhaps that is more clear
> though?
IMO the driver should know whether is needs multiple power-domains or
not and if it needs multiple then it should just call
dev_pm_domain_attach_by_id() N times without needing to checking
dev->pm_domain first. If it fails then either the PM domain core did
something wrong or power-domains are missing from DT, but either way
there is an error, so let it fail.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCHv2] ARM64: KVM: use lm_alias() for kvm_ksym_ref()
From: Marc Zyngier @ 2018-05-25 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525105010.qswcppfkybznmzka@lakrids.cambridge.arm.com>
On 25/05/18 11:50, Mark Rutland wrote:
> On Thu, May 10, 2018 at 12:13:47PM +0100, Mark Rutland wrote:
>> For historical reasons, we open-code lm_alias() in kvm_ksym_ref().
>>
>> Let's use lm_alias() to avoid duplication and make things clearer.
>>
>> As we have to pull this from <linux/mm.h> (which is not safe for
>> inclusion in assembly), we may as well move the kvm_ksym_ref()
>> definition into the existing !__ASSEMBLY__ block.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: kvmarm at lists.cs.columbia.edu
>> ---
>> arch/arm64/include/asm/kvm_asm.h | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> Marc, Christoffer, are you happy to pick this up?
I've queued it some time ago (see kvmarm/queue), but failed to mention
it on the list...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCHv2] ARM64: KVM: use lm_alias() for kvm_ksym_ref()
From: Mark Rutland @ 2018-05-25 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1f54d71c-6ae1-732f-3ee0-99e38287a3b0@arm.com>
On Fri, May 25, 2018 at 12:08:28PM +0100, Marc Zyngier wrote:
> On 25/05/18 11:50, Mark Rutland wrote:
> > On Thu, May 10, 2018 at 12:13:47PM +0100, Mark Rutland wrote:
> >> For historical reasons, we open-code lm_alias() in kvm_ksym_ref().
> >>
> >> Let's use lm_alias() to avoid duplication and make things clearer.
> >>
> >> As we have to pull this from <linux/mm.h> (which is not safe for
> >> inclusion in assembly), we may as well move the kvm_ksym_ref()
> >> definition into the existing !__ASSEMBLY__ block.
> >>
> >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Christoffer Dall <christoffer.dall@arm.com>
> >> Cc: Marc Zyngier <marc.zyngier@arm.com>
> >> Cc: kvmarm at lists.cs.columbia.edu
> >> ---
> >> arch/arm64/include/asm/kvm_asm.h | 7 +++++--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > Marc, Christoffer, are you happy to pick this up?
>
> I've queued it some time ago (see kvmarm/queue), but failed to mention
> it on the list...
Ah, cheers!
I'll drop this from my list of things to poke. :)
Thanks,
Mark.
^ permalink raw reply
* [PATCH v10 07/18] arm64: fpsimd: Eliminate task->mm checks
From: Christoffer Dall @ 2018-05-25 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525094515.GA13470@e103592.cambridge.arm.com>
On Fri, May 25, 2018 at 10:45:17AM +0100, Dave Martin wrote:
> On Fri, May 25, 2018 at 11:00:20AM +0200, Christoffer Dall wrote:
> > On Thu, May 24, 2018 at 03:37:15PM +0100, Dave Martin wrote:
> > > On Thu, May 24, 2018 at 12:06:59PM +0200, Christoffer Dall wrote:
> > > > On Thu, May 24, 2018 at 10:50:56AM +0100, Dave Martin wrote:
>
> [...]
>
> > > > I'm not sure what the reader is to make of that. Do you not mean the
> > > > TIF_FOREIGN_FPSTATE is always true for kernel threads?
> > >
> > > Again, this is probably a red herring. TIF_FOREIGN_FPSTATE is always
> > > true for kernel threads prior to the patch, except (randomly) for the
> > > init task.
> >
> > That was really what my initial question was about, and what I thought
> > the commit message should make abundantly clear, because that ties the
> > message together with the code.
> >
> > >
> > > This change is not really about TIF_FOREIGN_FPSTATE at all, rather
> > > that there is nothing to justify handling kernel threads differently,
> > > or even distinguishing kernel threads from user threads at all in this
> > > code.
> >
> > Understood.
>
> And my bad was that I hadn't gone to the effort of understanding my own
> argument -- I'd glad to be called out on that.
>
> > > Part of the confusion (and I had confused myself) comes from the fact
> > > that TIF_FOREIGN_FPSTATE is really a per-cpu property and doesn't make
> > > sense as a per-task property -- i.e., the flag is meaningless for
> > > scheduled-out tasks and we must explicitly "repair" it when scheduling
> > > a task in anyway. I think it's a thread flag primarily so that it's
> > > convenient to check alongside other thread flags in the ret_to_user
> > > work loop. This is somewhat less of a justification now that loop was
> > > ported to C.
> > >
> > > > >
> > > > > The context switch logic is already deliberately optimised to defer
> > > > > reloads of the regs until ret_to_user (or sigreturn as a special
> > > > > case), and save them only if they have been previously loaded.
> > >
> > > Does it help to insert the following here?
> > >
> > > "These paths are the only places where the wrong_task and wrong_cpu
> > > conditions can be made false, by calling fpsimd_bind_task_to_cpu()."
> > >
> >
> > yes it does.
> >
> > > > > Kernel threads by definition never reach these paths. As a result,
> > > >
> > > > I'm struggling with the "As a result," here. Is this because reloads of
> > > > regs in ret_to_user (or sigreturn) are the only places that can make
> > > > wrong_cpu or wrong_task be false?
> > >
> > > See the proposed clarification above. Is that sufficient?
> > >
> >
> > yes.
> >
> > > > (I'm actually wanting to understand this, not just bikeshedding the
> > > > commit message, as new corner cases keep coming up on this logic.)
> > >
> > > That's a good thing, and I would really like to explain it in a
> > > concise manner. See [*] below for the "concise" explanation -- it may
> > > demonstrate why I've been evasive...
> > >
> >
> > I don't think you've been evasive at all, I just think we reason about
> > this in slightly different ways, and I was trying to convince myself why
> > this change is safe and summarize that concisely. I think we've
> > accomplished both :)
>
> OK, good. I reposted speculatively on this basis :)
>
> The commit message is in better shape now, and I very much appreciate
> you kicking the tyres on my reasoning!
>
> [...]
>
> > > As an aside, the big wall of text before the definition of struct
> > > fpsimd_last_state_struct is looking out of date and could use an
> > > update to cover at least some of what is explained in [*] better.
> > >
> > > I'm currently considering that out of scope for this series, but I will
> > > keep it in mind to refresh it in the not too distant future.
> > >
> >
> > Fine with me.
>
> OK, good.
>
> [...]
>
> > > [*] The bigger picture:
> > >
> > > * Consider a relation (C,T) between cpus C and tasks T, such that
>
> [...]
>
> > > but by assuming that the code is already well-optimised, "unnecessary"
> > > save/restore work will not be added. If this were not the case, it
> > > could in any case be fixed independently.
> > >
> > > The observation of this _series_ is that we don't need to do very
> > > much in order to be able to generalise the logic to accept KVM vcpus
> > > in place of T.
> > >
> >
> > Thanks for the explanation.
> > -Christoffer
>
> Was this reasonably understandable? If so I could use it as a basis for
> improving the comment block in fpsimd.c, but I'd want to squash it down
> to the essentials. It's pretty verbose as it stands.
Yes, I think that's a resonable way forward. The thing that I hadn't
fully appreciated before is that you may have a valid relation (C,T)
which you wish to invalidate whilst T may not be running on C at that
particular time.
>
> (What I'd really like to do it take an axe to the logic so that we
> end up with something that doesn't require anything like this amount
> of explanation ... but that's more of an aspiration right now.)
>
I'll be happy to review a potentially simplified design, should you come
up with one at some point in the future.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v2 7/8] iommu: Remove IOMMU_OF_DECLARE
From: Will Deacon @ 2018-05-25 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-8-robh@kernel.org>
On Thu, May 24, 2018 at 12:50:23PM -0500, Rob Herring wrote:
> Now that we use the driver core to stop deferred probe for missing
> drivers, IOMMU_OF_DECLARE can be removed.
>
> This is slightly less optimal than having a list of built-in drivers in
> that we'll now defer probe twice before giving up. This shouldn't have a
> significant impact on boot times as past discussions about deferred
> probe have given no evidence of deferred probe having a substantial
> impact.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: iommu at lists.linux-foundation.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-arm-msm at vger.kernel.org
> Cc: linux-rockchip at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> drivers/iommu/arm-smmu-v3.c | 2 --
> drivers/iommu/arm-smmu.c | 7 -------
> drivers/iommu/exynos-iommu.c | 2 --
> drivers/iommu/ipmmu-vmsa.c | 3 ---
> drivers/iommu/msm_iommu.c | 2 --
> drivers/iommu/of_iommu.c | 19 +------------------
> drivers/iommu/qcom_iommu.c | 2 --
> drivers/iommu/rockchip-iommu.c | 2 --
> include/linux/of_iommu.h | 4 ----
> 9 files changed, 1 insertion(+), 42 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 1d647104bccc..22bdabd3d8e0 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2915,8 +2915,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
> -
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
> MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 69e7c60792a8..9dd7cbaa3b0c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2211,13 +2211,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1");
> -IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2");
> -IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
> -IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
> -IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
> -IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
> -
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
> MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> MODULE_LICENSE("GPL v2");
For the SMMU drivers:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 03/14] ARM: bugs: hook processor bug checking into SMP and suspend paths
From: Russell King - ARM Linux @ 2018-05-25 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525100359.GC17671@n2100.armlinux.org.uk>
On Fri, May 25, 2018 at 11:03:59AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 24, 2018 at 04:30:40PM -0700, Florian Fainelli wrote:
> > On 05/21/2018 04:44 AM, Russell King wrote:
> > > Check for CPU bugs when secondary processors are being brought online,
> > > and also when CPUs are resuming from a low power mode. This gives an
> > > opportunity to check that processor specific bug workarounds are
> > > correctly enabled for all paths that a CPU re-enters the kernel.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> >
> > Something I missed, is that this correctly warns about e.g: missing the
> > IBE bit for secondary cores, but it seems to be missing it for the boot CPU:
>
> Are you sure that the boot CPU has the IBE bit clear?
Here's what I get on TI Keystone 2, which doesn't set the IBE bit for
any CPU:
CPU: Testing write buffer coherency: ok
CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
CPU0: Spectre v2: using ICIALLU workaround
/cpus/cpu at 0 missing clock-frequency property
/cpus/cpu at 1 missing clock-frequency property
/cpus/cpu at 2 missing clock-frequency property
/cpus/cpu at 3 missing clock-frequency property
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x80008300 - 0x80008438
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU1: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
CPU1: Spectre v2: using ICIALLU workaround
CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
CPU2: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
CPU2: Spectre v2: using ICIALLU workaround
CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
CPU3: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
CPU3: Spectre v2: using ICIALLU workaround
It should be noted that, if we implement a "bugs" bit exported to
userspace (as I think someone requested) that booting on a system
where only the boot CPU initially comes up (which has the IBE bit
set) and then bringing the secondary CPUs online after userspace
has started (where those CPUs don't have the IBE bit set) will
result in the system initially not being vulnerable, but then
becoming vulnerable when running on those other CPUs.
If the bugs bit had already been checked by userspace, then it would
think that there's no system level vulnerability. Userspace would
need to check the status each time a CPU comes online.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v4 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Will Deacon @ 2018-05-25 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524170713.GY13470@e103592.cambridge.arm.com>
On Thu, May 24, 2018 at 06:07:13PM +0100, Dave Martin wrote:
> On Thu, May 24, 2018 at 05:50:48PM +0100, Will Deacon wrote:
> > On Thu, May 24, 2018 at 04:55:17PM +0100, Dave Martin wrote:
> > > On Thu, May 24, 2018 at 01:49:21PM +0100, Will Deacon wrote:
> > > > On Wed, May 23, 2018 at 06:46:56PM +0100, Dave Martin wrote:
> > > > > @@ -936,3 +949,28 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
> > > > > thread_flags = READ_ONCE(current_thread_info()->flags);
> > > > > } while (thread_flags & _TIF_WORK_MASK);
> > > > > }
> > > > > +
> > > > > +unsigned long __ro_after_init signal_minsigstksz;
> > > > > +
> > > > > +/*
> > > > > + * Determine the stack space required for guaranteed signal devliery.
> > > > > + * This function is used to populate AT_MINSIGSTKSZ at process startup.
> > > > > + * cpufeatures setup is assumed to be complete.
> > > > > + */
> > > > > +void __init minsigstksz_setup(void)
> > > > > +{
> > > > > + struct rt_sigframe_user_layout user;
> > > > > +
> > > > > + init_user_layout(&user);
> > > > > +
> > > > > + /*
> > > > > + * If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
> > > > > + * be big enough, but it's our best guess:
> > > > > + */
> > > > > + if (WARN_ON(setup_sigframe_layout(&user, true)))
> > > > > + signal_minsigstksz = SIGFRAME_MAXSZ;
> > > >
> > > > Can we not leave signal_minsigstksz as zero in this case?
> > >
> > > I prefer to distinguish the "kernel went wrong" case (where we just omit
> > > AT_MINSIGSTKSZ for backwards compatibilty) from the "sigframe too
> > > large" case.
> >
> > Hmm, so I'm confused as to the distinction here. Wouldn't an allocation
> > failure in setup_sigframe_layout be indicative of "kernel went wrong"?
> >
> > To put it another way, if we could determine the maximum sigframe size
> > at build time, surely we'd fail the build if SIGFRAME_MAXSZ wasn't big
> > enough? In that case, detecting this at runtime is also pretty bad (hence
>
> Yup
Good, I was starting to worry I was missing something!
> > the WARN_ON) and I think we should drop the aux entry rather than provide
> > a value that is known to be incorrect.
>
> Telling userspace the signal frame size is not optional: by omitting
> AT_MINSIGSTKSZ we implicitly tell userspace than MINSIGSTKSZ
> is sufficient. But in this case we not only know that this is false, we
> know that SIGFRAME_MAXSZ is not sufficient either. But we also know
> that SIGFRAME_MAXSZ is a closer estimate to the true requirement, because
> it's the larger value.
>
> This falls under the heading of "being no more wrong than necessary".
I think I just prefer distinguishing between "AT_MINSIGSTKSZ isn't
present, I'll assume MINSIGSTKSZ is sufficient but it might not be" and
"AT_MINSIGSTKSZ is present, I know that it's sufficient".
> Either way, this is trying to paper over a kernel bug, by telling
> userspace something "sensible". This may not be a sensible course
> of action...
>
> So if you feel strongly I'm happy to not distinguish the two cases and
> just WARN() in minsigstksz_setup() as at present.
Yes, please.
Will
^ permalink raw reply
* [PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node
From: Wang, Haiyue @ 2018-05-25 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8Xdhmrwfj6tGZ_o_JeoxdOii_5OD5oz80FJFRasvGd1L9w@mail.gmail.com>
Hi Joel & Andrew
This patch is out of date. ;-)
New: https://patchwork.ozlabs.org/patch/893720/
On 2018-05-25 12:34, Joel Stanley wrote:
> Hello Andrew,
>
> On 16 March 2018 at 11:17, Wang, Haiyue <haiyue.wang@linux.intel.com> wrote:
>> Hi Joel and Andrew,
>>
>> Have time to review this patch ? Hope for your comments. :-)
>>
>> BR,
>> Haiyue
>>
>>
>> On 2018-03-07 13:04, Haiyue Wang wrote:
>>> The IPMI KCS device part of the LPC interface and is used for
>>> communication with the host processor.
>>>
>>> Signed-off-by: Haiyue Wang <haiyue.wang@linux.intel.com>
> Do you have time to take a look at these? The device tree doesn't make
> sense to me.
>
> Cheers,
>
> Joel
>
>>> ---
>>> arch/arm/boot/dts/aspeed-g5.dtsi | 43
>>> +++++++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 42 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi
>>> b/arch/arm/boot/dts/aspeed-g5.dtsi
>>> index 8eac57c..f443169 100644
>>> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
>>> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
>>> @@ -267,8 +267,40 @@
>>> ranges = <0x0 0x1e789000 0x1000>;
>>> lpc_bmc: lpc-bmc at 0 {
>>> - compatible =
>>> "aspeed,ast2500-lpc-bmc";
>>> + compatible =
>>> "aspeed,ast2500-lpc-bmc", "simple-mfd", "syscon";
>>> reg = <0x0 0x80>;
>>> + reg-io-width = <4>;
>>> +
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges = <0x0 0x0 0x80>;
>>> +
>>> + kcs1: kcs1 at 0 {
>>> + compatible =
>>> "aspeed,ast2500-kcs-bmc";
>>> + reg = <0x0 0x80>;
>>> + interrupts = <8>;
>>> + kcs_chan = <1>;
>>> + kcs_addr = <0x0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + kcs2: kcs2 at 0 {
>>> + compatible =
>>> "aspeed,ast2500-kcs-bmc";
>>> + reg = <0x0 0x80>;
>>> + interrupts = <8>;
>>> + kcs_chan = <2>;
>>> + kcs_addr = <0x0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + kcs3: kcs3 at 0 {
>>> + compatible =
>>> "aspeed,ast2500-kcs-bmc";
>>> + reg = <0x0 0x80>;
>>> + interrupts = <8>;
>>> + kcs_chan = <3>;
>>> + kcs_addr = <0x0>;
>>> + status = "disabled";
>>> + };
>>> };
>>> lpc_host: lpc-host at 80 {
>>> @@ -294,6 +326,15 @@
>>> status = "disabled";
>>> };
>>> + kcs4: kcs4 at 0 {
>>> + compatible =
>>> "aspeed,ast2500-kcs-bmc";
>>> + reg = <0x0 0xa0>;
>>> + interrupts = <8>;
>>> + kcs_chan = <4>;
>>> + kcs_addr = <0x0>;
>>> + status = "disabled";
>>> + };
>>> +
>>> lhc: lhc at 20 {
>>> compatible =
>>> "aspeed,ast2500-lhc";
>>> reg = <0x20 0x24 0x48
>>> 0x8>;
>>
^ permalink raw reply
* [PATCH 15/15] arm: dts: imx: Add missing OPP properties for CPUs
From: Lucas Stach @ 2018-05-25 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <264124e14b966a1bbc07c364fbd89fc55aa765e6.1527244201.git.viresh.kumar@linaro.org>
Hi Viresh,
Am Freitag, den 25.05.2018, 16:02 +0530 schrieb Viresh Kumar:
> The OPP properties, like "operating-points", should either be present
> for all the CPUs of a cluster or none. If these are present only for a
> subset of CPUs of a cluster then things will start falling apart as soon
> as the CPUs are brought online in a different order. For example, this
> will happen because the operating system looks for such properties in
> the CPU node it is trying to bring up, so that it can create an OPP
> table.
>
> Add such missing properties.
>
> Fix other missing properties (like clocks, supply, clock latency) as
> well to make it all work.
This is a lot of duplicate information for what is effectively a shared
cluster wide thing. This does absolutely not _feel_ right.
What problem are you solving here? Why do we need all this duplicate
information? Why can't we fix it by falling back to looking at cpu0 if
needed?
Regards,
Lucas
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> ?arch/arm/boot/dts/imx6dl.dtsi??????| 23 ++++++++++
> ?arch/arm/boot/dts/imx6q-cm-fx6.dts | 66 +++++++++++++++++++++++++++++
> ?arch/arm/boot/dts/imx6q.dtsi???????| 87 ++++++++++++++++++++++++++++++++++++--
> ?arch/arm/boot/dts/imx7d.dtsi???????|??5 +++
> ?4 files changed, 178 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index b384913c34dd..cc8ffc42d128 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -50,6 +50,29 @@
> > ? device_type = "cpu";
> > ? reg = <1>;
> > ? next-level-cache = <&L2>;
> > + operating-points = <
> > + /* kHz????uV */
> > + 996000??1250000
> > + 792000??1175000
> > + 396000??1150000
> > + >;
> > + fsl,soc-operating-points = <
> > + /* ARM kHz??SOC-PU uV */
> > > + 996000 1175000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> > + clock-latency = <61036>; /* two CLK32 periods */
> > + clocks = <&clks IMX6QDL_CLK_ARM>,
> > + ?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > + ?<&clks IMX6QDL_CLK_STEP>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SW>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > + clock-names = "arm", "pll2_pfd2_396m", "step",
> > + ??????"pll1_sw", "pll1_sys";
> > + arm-supply = <®_arm>;
> > + pu-supply = <®_pu>;
> > + soc-supply = <®_soc>;
> > ? };
> > ? };
> ?
> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> index 65ef4cacbc71..18ae4f3be6e3 100644
> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> @@ -187,6 +187,72 @@
> > ? >;
> ?};
> ?
> +&cpu1 {
> > + /*
> > + ?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > + ?* the module behaves unstable at this frequency. Hence, remove the
> > + ?* 1.2GHz operation point here.
> > + ?*/
> > + operating-points = <
> > > + /* kHz uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 975000
> > + >;
> > + fsl,soc-operating-points = <
> > > + /* ARM kHz SOC-PU uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> +};
> +
> +&cpu2 {
> > + /*
> > + ?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > + ?* the module behaves unstable at this frequency. Hence, remove the
> > + ?* 1.2GHz operation point here.
> > + ?*/
> > + operating-points = <
> > > + /* kHz uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 975000
> > + >;
> > + fsl,soc-operating-points = <
> > > + /* ARM kHz SOC-PU uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> +};
> +
> +&cpu3 {
> > + /*
> > + ?* Although the imx6q fuse indicates that 1.2GHz operation is possible,
> > + ?* the module behaves unstable at this frequency. Hence, remove the
> > + ?* 1.2GHz operation point here.
> > + ?*/
> > + operating-points = <
> > > + /* kHz uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 975000
> > + >;
> > + fsl,soc-operating-points = <
> > > + /* ARM kHz SOC-PU uV */
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> +};
> +
> ?&ecspi1 {
> > ? cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>, <&gpio3 19 GPIO_ACTIVE_HIGH>;
> > ? pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 70483ce72ba6..78b89bb1bfed 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -50,25 +50,106 @@
> > ? soc-supply = <®_soc>;
> > ? };
> ?
> > - cpu at 1 {
> > > + cpu1: cpu at 1 {
> > ? compatible = "arm,cortex-a9";
> > ? device_type = "cpu";
> > ? reg = <1>;
> > ? next-level-cache = <&L2>;
> > + operating-points = <
> > + /* kHz????uV */
> > + 1200000 1275000
> > + 996000??1250000
> > + 852000??1250000
> > + 792000??1175000
> > + 396000??975000
> > + >;
> > + fsl,soc-operating-points = <
> > + /* ARM kHz??SOC-PU uV */
> > + 1200000 1275000
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> > + clock-latency = <61036>; /* two CLK32 periods */
> > + clocks = <&clks IMX6QDL_CLK_ARM>,
> > + ?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > + ?<&clks IMX6QDL_CLK_STEP>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SW>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > + clock-names = "arm", "pll2_pfd2_396m", "step",
> > + ??????"pll1_sw", "pll1_sys";
> > + arm-supply = <®_arm>;
> > + pu-supply = <®_pu>;
> > + soc-supply = <®_soc>;
> > ? };
> ?
> > - cpu at 2 {
> > > + cpu2: cpu at 2 {
> > ? compatible = "arm,cortex-a9";
> > ? device_type = "cpu";
> > ? reg = <2>;
> > ? next-level-cache = <&L2>;
> > + operating-points = <
> > + /* kHz????uV */
> > + 1200000 1275000
> > + 996000??1250000
> > + 852000??1250000
> > + 792000??1175000
> > + 396000??975000
> > + >;
> > + fsl,soc-operating-points = <
> > + /* ARM kHz??SOC-PU uV */
> > + 1200000 1275000
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> > + clock-latency = <61036>; /* two CLK32 periods */
> > + clocks = <&clks IMX6QDL_CLK_ARM>,
> > + ?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > + ?<&clks IMX6QDL_CLK_STEP>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SW>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > + clock-names = "arm", "pll2_pfd2_396m", "step",
> > + ??????"pll1_sw", "pll1_sys";
> > + arm-supply = <®_arm>;
> > + pu-supply = <®_pu>;
> > + soc-supply = <®_soc>;
> > ? };
> ?
> > - cpu at 3 {
> > > + cpu3: cpu at 3 {
> > ? compatible = "arm,cortex-a9";
> > ? device_type = "cpu";
> > ? reg = <3>;
> > ? next-level-cache = <&L2>;
> > + operating-points = <
> > + /* kHz????uV */
> > + 1200000 1275000
> > + 996000??1250000
> > + 852000??1250000
> > + 792000??1175000
> > + 396000??975000
> > + >;
> > + fsl,soc-operating-points = <
> > + /* ARM kHz??SOC-PU uV */
> > + 1200000 1275000
> > > + 996000 1250000
> > > + 852000 1250000
> > > + 792000 1175000
> > > + 396000 1175000
> > + >;
> > + clock-latency = <61036>; /* two CLK32 periods */
> > + clocks = <&clks IMX6QDL_CLK_ARM>,
> > + ?<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
> > + ?<&clks IMX6QDL_CLK_STEP>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SW>,
> > + ?<&clks IMX6QDL_CLK_PLL1_SYS>;
> > + clock-names = "arm", "pll2_pfd2_396m", "step",
> > + ??????"pll1_sw", "pll1_sys";
> > + arm-supply = <®_arm>;
> > + pu-supply = <®_pu>;
> > + soc-supply = <®_soc>;
> > ? };
> > ? };
> ?
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 4c9877ec29f2..5434a8aa5602 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -21,6 +21,11 @@
> > ? compatible = "arm,cortex-a7";
> > ? device_type = "cpu";
> > ? reg = <1>;
> > + operating-points = <
> > > + /* KHz uV */
> > > + 996000 1075000
> > > + 792000 975000
> > + >;
> > ? clock-frequency = <996000000>;
> > ? };
> > ? };
^ permalink raw reply
* [GIT PULL v2] arm64: dts: hisilicon dts updates for v4.18
From: Olof Johansson @ 2018-05-25 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AFAF15A.20500@hisilicon.com>
On Tue, May 15, 2018 at 03:40:26PM +0100, Wei Xu wrote:
> Hi Olof, Hi Arnd,
>
> Please help to pull the following changes.
> Thanks!
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-for-4.18v2
>
> for you to fetch changes up to bb61c53601b4af0f33f99ec0a8c9315246a0b6d4:
>
> arm64: dts: hi3798cv200: enable emmc support for poplar board (2018-05-15 14:54:03 +0100)
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH v2 1/8] driver core: make deferring probe after init optional
From: Robin Murphy @ 2018-05-25 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524181834.GF4828@sirena.org.uk>
On 24/05/18 19:18, Mark Brown wrote:
> On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote:
>
>> Subsystems or drivers may opt-in to this behavior by calling
>> driver_deferred_probe_check_init_done() instead of just returning
>> -EPROBE_DEFER. They may use additional information from DT or kernel's
>> config to decide whether to continue to defer probe or not.
>
> Should userspace have some involvement in this decision? It knows if
> it's got any intention of loading modules for example. Kernel config
> checks might be good enough, though it's going to be a pain to work out
> if the relevant driver is built as a module for example.
Arguably userspace has some control over that already, as in many cases
it can just unbind and reprobe the consumer driver after loading the
provider driver (in my silly IOMMU-drivers-as-modules PoC a while ago I
was delighted to find that it can really be that simple). It's a bit
harder when the device is the primary console or root filesystem, but I
think that's effectively just another variant of the "defer until a
module is loaded" chicken-and-egg problem.
Robin.
^ permalink raw reply
* [GIT PULL] Amlogic 32-bit DT updates for v4.18
From: Olof Johansson @ 2018-05-25 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hh8n8tuw5.fsf@baylibre.com>
On Tue, May 15, 2018 at 03:29:46PM -0700, Kevin Hilman wrote:
> Hi Arnd, Olof,
>
> This is mostly DT, but contains also contains the mach-meson change to
> build the new DT, which might be more appropriate for the 'soc' branch,
> but I left it here because it's just about enabling the new DT. Let me
> know if you prefer it split out.
>
> Kevin
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt
>
> for you to fetch changes up to 35ee52bea66c74a7c33cebda8692d61b1ed7c6e9:
>
> ARM: dts: meson8m2: add support for the Tronsmart MXIII Plus (2018-05-10 17:03:28 -0700)
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.18
From: Olof Johansson @ 2018-05-25 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hd0xwtuqq.fsf@baylibre.com>
On Tue, May 15, 2018 at 03:33:01PM -0700, Kevin Hilman wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic defconfig updates for v4.18
From: Olof Johansson @ 2018-05-25 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h7eo4tumf.fsf@baylibre.com>
On Tue, May 15, 2018 at 03:35:36PM -0700, Kevin Hilman wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-defconfig
>
> for you to fetch changes up to 1e3e7a9f27dc73c50ad7b0f06e6e519bbaa3fee9:
>
> ARM: multi_v7_defconfig: enable the Meson PWM controller (2018-04-27 12:06:02 -0700)
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: arm for v4.18 (#1)
From: Olof Johansson @ 2018-05-25 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87603m1lq9.fsf@bootlin.com>
On Thu, May 17, 2018 at 02:59:42PM +0200, Gregory CLEMENT wrote:
> Hi,
>
> Here is the first pull request for arm for mvebu for v4.18.
>
> As I feared, there were (trivial) merge issues due to the defconfig
> update in linux-next. The best place to solve them is in your tree, so
> as soon as you will pull this, I will remove from my mvebu/for-next
> branch.
Hmm. Yeah, this is because you took upon yourself to run 'make savedefconfig'
for all platforms on this shared defconfig. This will of course conflict with
everything everywhere, and it doesn't seem like a good idea to do this way.
What you're really doing here is turning on one single option? Just do that.
We can run savedefconfig at the end of a merge window here instead of having
one of the platform maintainers do it.
So, feel free to send just the NAND patch, and I can fix it up when I apply it
if needed.
Thanks!
-Olof
^ permalink raw reply
* [GIT PULL 1/3] DaVinci SoC updates for v4.18
From: Olof Johansson @ 2018-05-25 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-1-nsekhar@ti.com>
On Thu, May 17, 2018 at 06:38:43PM +0530, Sekhar Nori wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/soc
>
> for you to fetch changes up to ccfadbb759bed3cc40336e2c486e619e3bf8590b:
>
> Merge branch 'v4.18/nand-cs-simplification' into v4.18/soc (2018-05-02 15:04:15 +0530)
>
> ----------------------------------------------------------------
> DaVinci SoC support updates for v4.18
>
> Mainly contains patches to move NAND chipselect to platform data
> (currently platform device id is being used). These patches have
> been acked by NAND maintainer and because of the driver dependency
> an immutable branch has been provided to Boris.
>
> The other patch is to remove an unnecessary postcore_initcall() on
> DM644x which is needed for common clock framework conversion.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 2/3] DaVinci device-tree updates for v4.18
From: Olof Johansson @ 2018-05-25 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-2-nsekhar@ti.com>
On Thu, May 17, 2018 at 06:38:44PM +0530, Sekhar Nori wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/dt
>
> for you to fetch changes up to fe9d2a40d995dc1da042a4fcd7813239d063554d:
>
> ARM: dts: da850-evm: add WP and CD to MMC (2018-05-16 16:36:51 +0530)
>
> ----------------------------------------------------------------
> DaVinci device-tree updates for v4.18
>
> * DA850 EVM gains USB support, SD card write-protect, card detect
> and some clean-up
> * Support for gpio-ranges makes using gpios from DT much easier
> * Lego EV3 clean-up
>
> ----------------------------------------------------------------
> Adam Ford (3):
> ARM: dts: da850-evm: Enable usb_phy, usb0 and usb1
> ARM: dts: da850-evm: use phandles to extend nodes
> ARM: dts: da850-evm: add WP and CD to MMC
>
> David Lechner (2):
> ARM: dts: da850: use gpio-ranges
> ARM: dts: da850-lego-ev3: remove unnecessary gpio-keys properties
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 3/3] DaVinci defconfig updates for v4.18
From: Olof Johansson @ 2018-05-25 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-3-nsekhar@ti.com>
On Thu, May 17, 2018 at 06:38:45PM +0530, Sekhar Nori wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.18/defconfig
>
> for you to fetch changes up to e081c754ad4b8665364fcfb07b8bec5289f23dd8:
>
> ARM: davinci_all_defconfig: enable support for remoteproc drivers (2018-04-23 20:24:23 +0530)
>
> ----------------------------------------------------------------
> Enable DA8XX remoteproc driver support in davinci_all_defconfig
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH v2 5/5] MAINTAINERS: Add Actions Semi S900 pinctrl entries
From: Linus Walleij @ 2018-05-25 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <25d1c303-71d7-8c38-880f-7bb0e133a876@suse.de>
On Fri, May 25, 2018 at 6:12 AM, Andreas F?rber <afaerber@suse.de> wrote:
> I fail to understand how splitting the MAINTAINERS section is going to
> help with the pinctrl conflict at hand?
OK let's keep it like it is then, one entry.
>The problem is that instead of
> refactoring my S500 pinctrl driver to his liking, Mani has submitted a
> competing S900 pinctrl driver that you went on to merge. The human
> aspect is that merging his driver took the credit away from me having
> written the earlier pinctrl driver (based on my rtd1295 pinctrl driver).
> The practical aspect is that I can't drop my pinctrl driver from my work
> branch until there is equivalent functionality in the merged driver. I
> am lacking the time to rewrite S500 pin definitions on top of Mani's
> myself at this time, and I haven't seen S500 patches from him yet.
I am sorry if you feel you are being treated unfairly.
I can't help to think about the old IT project motto "always
calculate to throw one version away". We are always going to
have a bit of collateral damage around out sometimes chaotic
and unstructured development process.
I haven't seen this S500 patch posted anywhere on the pin control
official mailing list. As subsystem maintainer I have a vast flow of
information already, actively polling around other subcommunities
is simply not possible for me.
I need to deal with what ends up on the list, I think it would have
been better if you simply posted your S500 driver at the time,
no matter the state. "Release early, release often" and discuss
design on the GPIO mailing list where I can see it, so I have some
idea what is going on here.
> Also I had been investing efforts in explaining the upstreaming process
> to Actions, last in November. I see Thomas Liau and Jeff Chen missing in
> CC and I have not seen any Reviewed-by or Acked-by from anyone at
> Actions on this and the preceding series. There are more chips than the
> one on Linaro's 96board, so I would prefer to assure that the design
> works for all. Thus I am very critical of you applying the patches
> without waiting for review by Actions.
It is not too late to take it out if there is some problem from their
side.
When I merge a driver it doesn't mean "definately approved, will
send to Torvalds", type of "seal of approval" it rather usually it
means "I want to test it in linux-next in due time for the merge
window".
I don't mind taking it out if there are problems, and I do not mind
even reverting it in the -rc phase if there are problems.
I don't mind having to revert patches like this or even rebasing
the tree if required.
However if they do not come back at all within some week or
two that is passivity and then it goes in.
> Other aspects are: The reason I wrote the pinctrl driver is that I
> experienced a UART TX issue on the Sparky board and was hoping a pinctrl
> driver might resolve that, but it didn't. So I still have a mix of
> boards where some are working and some are pretty unusable, without any
> clues on why.
Hm how typical :/
Getting to serial is paramount to getting anywhere with the
hacking. I see this becomes a bit of showstopper for your
development work here.
> That said, I don't object to having a separate MAINTAINERS section for
> the pinctrl driver(s) as long as I still get CC'ed on changes. We have
> wanted to add Mani as R for Actions overall, so that would probably mean
> adding me as R to an Actions pinctrl section, to avoid syncing the paths
> between two sections.
No problem we keep it to one entry.
> I had previously felt that it does not make sense
> to list Mani as co-maintainer (M) for Actions overall since he can't tag
> and submit from my repo. And for the record I have offered him to take
> over which he didn't want to. I still hope to find some more time to
> review and queue his SPS patches, a driver that I have designed and thus
> understand and am much happier about the incremental additions there.
OK nice!
> A further side note is that I had reached out about setting up an
> infradead mailing list linux-actions, but there was no response from
> David or anyone. Having an L on the section(s) would avoid messing with
> R and hand-maintained CC lists. Any help with that appreciated.
We can talk to kernel.org about setting up a list, that probably works
quicker.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL v2] arm64: defconfig: hisilicon config updates for v4.18
From: Olof Johansson @ 2018-05-25 12:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5AFEB1E0.9030200@hisilicon.com>
On Fri, May 18, 2018 at 11:58:40AM +0100, Wei Xu wrote:
> Hi Olof, Hi Arnd,
>
> Please help to pull the following changes.
> Thanks!
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-defconfig-for-4.18v2
>
> for you to fetch changes up to 9ab1c973324566baa314f8dd4e3827e4076a8675:
>
> arm64: defconfig: Enable HISILICON_LPC (2018-05-11 11:39:01 +0100)
>
> ----------------------------------------------------------------
> ARM64: hisilicon: defconfig updates for 4.18
>
> - Sync the arm64 defconfig with savedefconfig
> - Enable the support of ethernet, eMMC, Combo/INNO phy
> and PCIe for Hi3798CV200
> - Enable the LPC for hip06 and hip07
>
> ----------------------------------------------------------------
> John Garry (1):
> arm64: defconfig: Enable HISILICON_LPC
>
> Shawn Guo (2):
> arm64: defconfig: sync it with savedefconfig
Same feedback here as for Gregory on his Marvell pull request -- please don't
run savedefconfig since it messes up and adds a lot of conflicts for everybody.
We'll do it in our tree right around the end of the merge window instead.
It's probably easiest to send the patches as patches so we can fix them up if
needed, so please resend separately and we'll apply. (Or send a new pull
request with just the two new config changes).
Thanks!
-Olof
^ permalink raw reply
* qcom: add firmware file for Venus on SDM845
From: Josh Boyer @ 2018-05-25 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527246209-26685-2-git-send-email-vgarodia@codeaurora.org>
On Fri, May 25, 2018 at 7:03 AM Vikash Garodia <vgarodia@codeaurora.org>
wrote:
> This pull request adds firmware files for Venus h/w codec found on the
Qualcomm SDM845 chipset.
> The following changes since commit
2a9b2cf50fb32e36e4fc1586c2f6f1421913b553:
> Merge branch 'for-upstreaming-v1.7.2' of
https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400)
> are available in the git repository at:
> https://github.com/vgarodia/linux-firmware master
> for you to fetch changes up to d6088b9c9d7f49d3c6c43681190889eca0abdcce:
> qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530)
> ----------------------------------------------------------------
> Vikash Garodia (1):
> qcom: add venus firmware files for v5.2
> WHENCE | 9 +++++++++
> qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes
> qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes
> qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes
> qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes
> qcom/venus-5.2/venus.b04 | 1 +
> qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes
> qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes
> 8 files changed, 10 insertions(+)
> create mode 100644 qcom/venus-5.2/venus.b00
> create mode 100644 qcom/venus-5.2/venus.b01
> create mode 100644 qcom/venus-5.2/venus.b02
> create mode 100644 qcom/venus-5.2/venus.b03
> create mode 100644 qcom/venus-5.2/venus.b04
> create mode 100644 qcom/venus-5.2/venus.mbn
> create mode 100644 qcom/venus-5.2/venus.mdt
The venus.mbn file isn't mentioned in WHENCE:
[jwboyer at vader linux-firmware]$ ./check_whence.py
E: qcom/venus-5.2/venus.mbn not listed in WHENCE
[jwboyer at vader linux-firmware]$
Can you fix that up and let me know when to re-pull?
josh
^ permalink raw reply
* [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.18
From: Olof Johansson @ 2018-05-25 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1526548323.git.horms+renesas@verge.net.au>
On Fri, May 18, 2018 at 01:14:48PM +0200, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM64 based SoC defconfig updates for v4.18.
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-defconfig-for-v4.18
>
> for you to fetch changes up to c1fcd2ec1b1970e0e7b0c40c64bc51cf667b1a75:
>
> arm64: defconfig: enable R8A77990 SoC (2018-05-16 11:08:20 +0200)
>
> ----------------------------------------------------------------
> Renesas ARM64 Based SoC Defconfig Updates for v4.18
>
> * Enable in ARM64 defconfig:
> - Recently mainlined support for R-Car E3 (r8a77990) SoC
>
> - HDMI sound and depdencies.
>
> HDMI sound is used by R-Car Gen 3. These options are enabled as
> modules to avoid unnecesesarily enlarging the kernel image.
Thanks, merged.
-Olof
^ permalink raw reply
* [GIT PULL 1/5] dt-bindings: tegra: Changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518142245.20242-1-thierry.reding@gmail.com>
On Fri, May 18, 2018 at 04:22:41PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-dt-bindings
>
> for you to fetch changes up to eb8f53b6d3125894e3d825976eb7e03150496362:
>
> dt-bindings: Relocate Tegra20 memory controller bindings (2018-04-27 11:15:51 +0200)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> dt-bindings: tegra: Changes for v4.18-rc1
>
> This contains the device tree bindings updates for the memory controller
> hot resets that are implemented by driver patches in a different branch.
>
> ----------------------------------------------------------------
> Dmitry Osipenko (3):
> dt-bindings: arm: tegra: Remove duplicated Tegra30+ MC binding
> dt-bindings: memory: tegra: Document #reset-cells property of the Tegra30 MC
> dt-bindings: arm: tegra: Document #reset-cells property of the Tegra20 MC
>
> Thierry Reding (1):
> dt-bindings: Relocate Tegra20 memory controller bindings
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/5] memory: tegra: Changes for v4.18-rc1
From: Olof Johansson @ 2018-05-25 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518142245.20242-2-thierry.reding@gmail.com>
On Fri, May 18, 2018 at 04:22:42PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.18-memory
>
> for you to fetch changes up to bef89a8d81ca97aca864778746b110cf52847868:
>
> memory: tegra: Remove Tegra114 SATA and AFI reset definitions (2018-05-18 12:33:02 +0200)
>
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> memory: tegra: Changes for v4.18-rc1
>
> This contains some cleanup of the memory controller driver as well as
> unification work to share more code between Tegra20 and later SoC
> generations. Also included are an implementation for the hot resets
> functionality by the memory controller which is required to properly
> reset busy hardware.
>
> ----------------------------------------------------------------
> Dmitry Osipenko (14):
> dt-bindings: memory: tegra: Add hot resets definitions
> memory: tegra: Do not handle spurious interrupts
> memory: tegra: Setup interrupts mask before requesting IRQ
> memory: tegra: Apply interrupts mask per SoC
> memory: tegra: Remove unused headers inclusions
> memory: tegra: Squash tegra20-mc into common tegra-mc driver
> memory: tegra: Introduce memory client hot reset
> memory: tegra: Add Tegra20 memory controller hot resets
> memory: tegra: Add Tegra30 memory controller hot resets
> memory: tegra: Add Tegra114 memory controller hot resets
> memory: tegra: Add Tegra124 memory controller hot resets
> memory: tegra: Register SMMU after MC driver became ready
> dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions
> memory: tegra: Remove Tegra114 SATA and AFI reset definitions
>
> Thierry Reding (1):
> memory: tegra: Add Tegra210 memory controller hot resets
Looks like this is just additional/proper resets, are there any backwards
compatibility concerns with older device trees or new assumptions of properties
that should be handled?
-Olof
^ 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