* [PATCH 1/2] clk: uniphier: add CPU-gear change (cpufreq) support
From: Masahiro Yamada @ 2016-11-23 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477503088-26508-1-git-send-email-yamada.masahiro@socionext.com>
Hi Stephen,
Ping.
2016-10-27 2:31 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> 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>
> ---
>
> drivers/clk/uniphier/Makefile | 3 +
> drivers/clk/uniphier/clk-uniphier-core.c | 3 +
> drivers/clk/uniphier/clk-uniphier-cpugear.c | 115 ++++++++++++++++++++++++++++
> drivers/clk/uniphier/clk-uniphier.h | 17 +++-
> 4 files changed, 136 insertions(+), 2 deletions(-)
> create mode 100644 drivers/clk/uniphier/clk-uniphier-cpugear.c
>
> diff --git a/drivers/clk/uniphier/Makefile b/drivers/clk/uniphier/Makefile
> index f27b3603..665d1d6 100644
> --- a/drivers/clk/uniphier/Makefile
> +++ b/drivers/clk/uniphier/Makefile
> @@ -1,8 +1,11 @@
> obj-y += clk-uniphier-core.o
> +
> +obj-y += clk-uniphier-cpugear.o
> obj-y += clk-uniphier-fixed-factor.o
> obj-y += clk-uniphier-fixed-rate.o
> obj-y += clk-uniphier-gate.o
> obj-y += clk-uniphier-mux.o
> +
> obj-y += clk-uniphier-sys.o
> obj-y += clk-uniphier-mio.o
> obj-y += clk-uniphier-peri.o
> diff --git a/drivers/clk/uniphier/clk-uniphier-core.c b/drivers/clk/uniphier/clk-uniphier-core.c
> index 26c53f7..0007218 100644
> --- a/drivers/clk/uniphier/clk-uniphier-core.c
> +++ b/drivers/clk/uniphier/clk-uniphier-core.c
> @@ -27,6 +27,9 @@ static struct clk_hw *uniphier_clk_register(struct device *dev,
> const struct uniphier_clk_data *data)
> {
> switch (data->type) {
> + case UNIPHIER_CLK_TYPE_CPUGEAR:
> + return uniphier_clk_register_cpugear(dev, regmap, data->name,
> + &data->data.cpugear);
> case UNIPHIER_CLK_TYPE_FIXED_FACTOR:
> return uniphier_clk_register_fixed_factor(dev, data->name,
> &data->data.factor);
> diff --git a/drivers/clk/uniphier/clk-uniphier-cpugear.c b/drivers/clk/uniphier/clk-uniphier-cpugear.c
> new file mode 100644
> index 0000000..9bff26e
> --- /dev/null
> +++ b/drivers/clk/uniphier/clk-uniphier-cpugear.c
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright (C) 2016 Socionext Inc.
> + * Author: Masahiro Yamada <yamada.masahiro@socionext.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/regmap.h>
> +
> +#include "clk-uniphier.h"
> +
> +#define UNIPHIER_CLK_CPUGEAR_STAT 0 /* status */
> +#define UNIPHIER_CLK_CPUGEAR_SET 4 /* set */
> +#define UNIPHIER_CLK_CPUGEAR_UPD 8 /* update */
> +#define UNIPHIER_CLK_CPUGEAR_UPD_BIT BIT(0)
> +
> +struct uniphier_clk_cpugear {
> + struct clk_hw hw;
> + struct regmap *regmap;
> + unsigned int regbase;
> + unsigned int mask;
> +};
> +
> +#define to_uniphier_clk_cpugear(_hw) \
> + container_of(_hw, struct uniphier_clk_cpugear, hw)
> +
> +static int uniphier_clk_cpugear_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct uniphier_clk_cpugear *gear = to_uniphier_clk_cpugear(hw);
> + int ret;
> + unsigned int val;
> +
> + ret = regmap_write_bits(gear->regmap,
> + gear->regbase + UNIPHIER_CLK_CPUGEAR_SET,
> + gear->mask, index);
> + if (ret)
> + return ret;
> +
> + ret = regmap_write_bits(gear->regmap,
> + gear->regbase + UNIPHIER_CLK_CPUGEAR_SET,
> + UNIPHIER_CLK_CPUGEAR_UPD_BIT,
> + UNIPHIER_CLK_CPUGEAR_UPD_BIT);
> + if (ret)
> + return ret;
> +
> + return regmap_read_poll_timeout(gear->regmap,
> + gear->regbase + UNIPHIER_CLK_CPUGEAR_UPD,
> + val, !(val & UNIPHIER_CLK_CPUGEAR_UPD_BIT),
> + 0, 1);
> +}
> +
> +static u8 uniphier_clk_cpugear_get_parent(struct clk_hw *hw)
> +{
> + struct uniphier_clk_cpugear *gear = to_uniphier_clk_cpugear(hw);
> + int num_parents = clk_hw_get_num_parents(hw);
> + int ret;
> + unsigned int val;
> +
> + ret = regmap_read(gear->regmap,
> + gear->regbase + UNIPHIER_CLK_CPUGEAR_STAT, &val);
> + if (ret)
> + return ret;
> +
> + val &= gear->mask;
> +
> + return val < num_parents ? val : -EINVAL;
> +}
> +
> +static const struct clk_ops uniphier_clk_cpugear_ops = {
> + .determine_rate = __clk_mux_determine_rate,
> + .set_parent = uniphier_clk_cpugear_set_parent,
> + .get_parent = uniphier_clk_cpugear_get_parent,
> +};
> +
> +struct clk_hw *uniphier_clk_register_cpugear(struct device *dev,
> + struct regmap *regmap,
> + const char *name,
> + const struct uniphier_clk_cpugear_data *data)
> +{
> + struct uniphier_clk_cpugear *gear;
> + struct clk_init_data init;
> + int ret;
> +
> + gear = devm_kzalloc(dev, sizeof(*gear), GFP_KERNEL);
> + if (!gear)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &uniphier_clk_cpugear_ops;
> + init.flags = CLK_SET_RATE_PARENT;
> + init.parent_names = data->parent_names;
> + init.num_parents = data->num_parents,
> +
> + gear->regmap = regmap;
> + gear->regbase = data->regbase;
> + gear->mask = data->mask;
> + gear->hw.init = &init;
> +
> + ret = devm_clk_hw_register(dev, &gear->hw);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + return &gear->hw;
> +}
> diff --git a/drivers/clk/uniphier/clk-uniphier.h b/drivers/clk/uniphier/clk-uniphier.h
> index 0244dba..9707b0f 100644
> --- a/drivers/clk/uniphier/clk-uniphier.h
> +++ b/drivers/clk/uniphier/clk-uniphier.h
> @@ -20,15 +20,24 @@
> struct device;
> struct regmap;
>
> -#define UNIPHIER_CLK_MUX_MAX_PARENTS 8
> +#define UNIPHIER_CLK_CPUGEAR_MAX_PARENTS 16
> +#define UNIPHIER_CLK_MUX_MAX_PARENTS 8
>
> enum uniphier_clk_type {
> + UNIPHIER_CLK_TYPE_CPUGEAR,
> UNIPHIER_CLK_TYPE_FIXED_FACTOR,
> UNIPHIER_CLK_TYPE_FIXED_RATE,
> UNIPHIER_CLK_TYPE_GATE,
> UNIPHIER_CLK_TYPE_MUX,
> };
>
> +struct uniphier_clk_cpugear_data {
> + const char *parent_names[UNIPHIER_CLK_CPUGEAR_MAX_PARENTS];
> + unsigned int num_parents;
> + unsigned int regbase;
> + unsigned int mask;
> +};
> +
> struct uniphier_clk_fixed_factor_data {
> const char *parent_name;
> unsigned int mult;
> @@ -58,6 +67,7 @@ struct uniphier_clk_data {
> enum uniphier_clk_type type;
> int idx;
> union {
> + struct uniphier_clk_cpugear_data cpugear;
> struct uniphier_clk_fixed_factor_data factor;
> struct uniphier_clk_fixed_rate_data rate;
> struct uniphier_clk_gate_data gate;
> @@ -90,7 +100,10 @@ struct uniphier_clk_data {
> }, \
> }
>
> -
> +struct clk_hw *uniphier_clk_register_cpugear(struct device *dev,
> + struct regmap *regmap,
> + const char *name,
> + const struct uniphier_clk_cpugear_data *data);
> struct clk_hw *uniphier_clk_register_fixed_factor(struct device *dev,
> const char *name,
> const struct uniphier_clk_fixed_factor_data *data);
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Nicolas Pitre @ 2016-11-23 1:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123120436.18dc21e7@roar.ozlabs.ibm.com>
On Wed, 23 Nov 2016, Nicholas Piggin wrote:
> On Tue, 22 Nov 2016 11:34:48 -0500 (EST)
> Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>
> > On Tue, 22 Nov 2016, Arnd Bergmann wrote:
> >
> > > This adds an asm/asm-prototypes.h header for ARM to fix the broken symbol
> > > versioning for symbols exported from assembler files.
> > >
> > > I couldn't find the correct prototypes for the compiler builtins,
> > > so I went with the fake 'void f(void)' prototypes that we had
> > > before, restoring the state before they were moved.
> > >
> > > Originally I assumed that the problem was just a harmless warning
> > > in unusual configurations, but as Uwe found, we actually need this
> > > to load most modules when symbol versioning is enabled, as it is
> > > in many distro kernels.
> > >
> > > Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > > Fixes: 4dd1837d7589 ("arm: move exports to definitions")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > Compared to the earlier version, I dropped the changes to the
> > > csumpartial files, which now get handled correctly by Kbuild
> > > even when the export comes from a macro, and I also dropped the
> > > changes to the bitops files, which were already fixed in a
> > > patch from Nico.
> > >
> > > The patch applies cleanly on top of the rmk/fixes tree but has
> > > no effect there, as it also needs 4efca4ed05cb ("kbuild: modversions
> > > for EXPORT_SYMBOL() for asm") and cc6acc11cad1 ("kbuild: be more
> > > careful about matching preprocessed asm ___EXPORT_SYMBOL").
> > >
> > > With the combination of rmk/fixes, torvalds/master and these two
> > > patches, symbol versioning works again on ARM. As it is still
> > > broken on almost all other architectures (powerpc is fixed,
> > > x86 has a patch), I wonder if we should make CONFIG_MODVERSIONS
> > > as broken for everything else.
> >
> > I'm not sure I like this at all.
> >
> > The goal for moving EXPORT_SYMBOL() to assembly code where symbols were
> > defined is to make things close together and avoid those centralized
> > list of symbols that you can easily miss when modifying the actual code.
>
> Right.
>
> >
> > This series is therefore bringing back a centralized list of symbols in
> > a slightly different form, nullifying the advantages from having moved
> > EXPORT_SYMBOL() to asm code. To me this looks like a big step backward.
>
> Exported symbols have C declarations in headers already. For the most
> part, anyway -- these ones Arnd adds are for compiler runtime which is
> why some architectures haven't had the prototypes.
Hmmm. That's right. That makes it much more justifiable.
My main objection is withdrawn.
However there is a bunch of includes added to asm-prototypes.h:
+#include <linux/arm-smccc.h>
+#include <linux/bitops.h>
+#include <linux/ftrace.h>
+#include <linux/io.h>
+#include <linux/platform_data/asoc-imx-ssi.h>
+#include <linux/string.h>
+#include <linux/uaccess.h>
+
+#include <asm/checksum.h>
+#include <asm/div64.h>
+#include <asm/memory.h>
Are those necessary at all?
Nicolas
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-23 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479860851.10840.11@smtp.gmail.com>
On Wed, Nov 23, 2016 at 01:27:31AM +0100, tomas.hlavacek at nic.cz wrote:
> Hi Uwe!
>
> On Tue, Nov 22, 2016 at 10:59 PM, tomas.hlavacek at nic.cz wrote:
> >Anyway I took your patch and tried few things:
> >- add pca9538 interrupt-controller
> >- add IRQ for 88E1514 PHY - and there is a problem:
> ...
>
> I thought it over and if I am not mistaken this is not going to work
> anyway, because pca9538 driver causes the GPIO driver to set
> IRQ_NESTED_THREAD, so we can not simply use one of the GPIO expander
> pins as IRQ source for 88E1514, because request_irq() on it will
> fail ultimately.
Actually, the phylib now does uses threaded IRQs, since i implemented
interrupt support for the mv88e6xxx driver. Its interrupts require
MDIO transactions, so have to be threaded.
However, i don't think using interrupts on the pca9538 are
reliable. Interrupt support is compile time optional for that
driver. It is not clear to me if distributions do compile the driver
with interrupts enabled. So it could be the probe fails with OpenWRT,
Debian, etc...
Andrew
^ permalink raw reply
* [PATCH 0/2] kexec-tools: arm64: Add dcache enabling facility
From: Pratyush Anand @ 2016-11-23 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8415f028-f42e-2980-9b60-e85aae046d02@infradead.org>
Hi Geoff,
On Wednesday 23 November 2016 12:26 AM, Geoff Levand wrote:
> Hi Pratyush,
>
> On 11/21/2016 08:32 PM, Pratyush Anand wrote:
>> It takes more that 2 minutes to verify SHA in purgatory when vmlinuz
>> image
>> is around 13MB and initramfs is around 30MB. It takes more than 20 second
>> even when we have -O2 optimization enabled. However, if dcache is enabled
>> during purgatory execution then, it takes just a second in SHA
>> verification.
>
> As I had mentioned in another thread, I think -O2 optimization is
> sufficient considering the complexity of the code needed to enable
> the dcache. Integrity checking is only needed for crash dump
> support. If the crash reboot takes an extra 20 seconds does it
> matter?
>
Even this 20 second for kdump case is also annoying and this could
increase if the size of initramfs increases.
Moreover, by default d-cache is still disabled, so even if it is complex
and you might see some instability, it will not affect the existing
systems. So, IMHO we should have this in the upstream.
> For the re-boot of a stable system where the new kernel is loaded
> then immediately kexec'ed into integrity checking is not needed.
> For that arm64 support needs to be added to kexec-lite.
I think kexec-lite is a separate project and --lite in kexec-tools was
never acked. So, even for `kexec -l` it will be helpful.
~Pratyush
^ permalink raw reply
* [PATCH 1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
From: Nicholas Piggin @ 2016-11-23 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123004106.GA14217@n2100.armlinux.org.uk>
On Wed, 23 Nov 2016 00:41:07 +0000
Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> On Tue, Nov 22, 2016 at 11:34:48AM -0500, Nicolas Pitre wrote:
> > On Tue, 22 Nov 2016, Arnd Bergmann wrote:
> > > This adds an asm/asm-prototypes.h header for ARM to fix the broken symbol
> > > versioning for symbols exported from assembler files.
> > >
> > > I couldn't find the correct prototypes for the compiler builtins,
> > > so I went with the fake 'void f(void)' prototypes that we had
> > > before, restoring the state before they were moved.
> > >
> > > Originally I assumed that the problem was just a harmless warning
> > > in unusual configurations, but as Uwe found, we actually need this
> > > to load most modules when symbol versioning is enabled, as it is
> > > in many distro kernels.
> > >
> > > Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > > Fixes: 4dd1837d7589 ("arm: move exports to definitions")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > ---
> > > Compared to the earlier version, I dropped the changes to the
> > > csumpartial files, which now get handled correctly by Kbuild
> > > even when the export comes from a macro, and I also dropped the
> > > changes to the bitops files, which were already fixed in a
> > > patch from Nico.
> > >
> > > The patch applies cleanly on top of the rmk/fixes tree but has
> > > no effect there, as it also needs 4efca4ed05cb ("kbuild: modversions
> > > for EXPORT_SYMBOL() for asm") and cc6acc11cad1 ("kbuild: be more
> > > careful about matching preprocessed asm ___EXPORT_SYMBOL").
> > >
> > > With the combination of rmk/fixes, torvalds/master and these two
> > > patches, symbol versioning works again on ARM. As it is still
> > > broken on almost all other architectures (powerpc is fixed,
> > > x86 has a patch), I wonder if we should make CONFIG_MODVERSIONS
> > > as broken for everything else.
> >
> > I'm not sure I like this at all.
> >
> > The goal for moving EXPORT_SYMBOL() to assembly code where symbols were
> > defined is to make things close together and avoid those centralized
> > list of symbols that you can easily miss when modifying the actual code.
> >
> > This series is therefore bringing back a centralized list of symbols in
> > a slightly different form, nullifying the advantages from having moved
> > EXPORT_SYMBOL() to asm code. To me this looks like a big step backward.
> >
> > Why not simply extending the original idea of keeping exports close to
> > the actual code by _also_ having a macro that provides the function
> > prototype alongside the EXPORT_SYMBOL() instance? That could even be
> > expressed with some EXPORT_SYMBOL_PROTO(ret, sym, arg...) macro that
> > does it all.
>
> What you're saying is that you don't like the solution that's taken
> weeks to get merged up to this point, so where do we go from here
> now? This crap has been broken since 4.9-rc1, and is a regression.
>
> I think at this point, we just declare that modversions are broken
> on ARM, and those who created this mess get to explain to people
> why the fsck they broke the kernel.
Let's fix it instead :)
Why not merge Arnd's 2 patches? I think he mostly addressed your concerns
of them. Or...
>
> 4.9 is the next LTS kernel? ROTFL!
>
> I agree with Nicolas - it seems that the whole EXPORT_SYMBOL() crap
> has just been a pointless exercise in churn, resulting only in
> something "different" because it looks "cool" to do it some other
> way. There's no real benefit here at all, only harm.
>
> Just revert the damned patches that created this breakage in the
> first place please. It's now way too late to be trying to fix it
> any other way.
>
4dd1837d7589 diffstat is entirely in arch/arm. I think reverting that
would fix it (I haven't tested it myself so I would advise testing
before committing). So the ball is in your court.
As for process concerns, you have made valid points. Sometimes a mistake
is made or we make an incorrect assumption about how another person works
or what mailing lists they have read, or do not anticipate the fallout
from some change.
Everyone does it sometimes, so it's never a bad time to reflect on how
we work with others and try to do better.
Thanks,
Nick
^ permalink raw reply
* [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory
From: Pratyush Anand @ 2016-11-23 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53ee2a62-7822-5457-e59f-e65e64a57019@infradead.org>
Hi Geoff,
On Wednesday 23 November 2016 12:27 AM, Geoff Levand wrote:
> Hi Pratyush,
>
> On 11/21/2016 08:32 PM, Pratyush Anand wrote:
>> When "enable-dcache" is passed to the kexec() command line, kexec-tools
>> passes this information to purgatory, which in turn enables cache during
>> sha-256 verification.
>
> What's the point of this enable-dcache option? Why not just
> always enable the cache if we can?
As I have written in changelog of patch 1/2
"We are supporting only 4K and 64K page sizes. This code will not work if a
hardware is not supporting at least one of these page sizes. Therefore,
D-cache is disabled by default and enabled only when "enable-dcache" is
passed to the kexec()."
Although this is very unlikely that a hardware will support only 16K
page sizes, however it is possible. Therefore, its better to keep it
disabled by default.
~Pratyush
^ permalink raw reply
* [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Rick Chang @ 2016-11-23 1:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <badf8125-27ed-9c5b-fbc0-75716ffdfb0e@xs4all.nl>
Hi Hans,
On Tue, 2016-11-22 at 13:43 +0100, Hans Verkuil wrote:
> On 22/11/16 04:21, Rick Chang wrote:
> > Hi Hans,
> >
> > On Mon, 2016-11-21 at 15:51 +0100, Hans Verkuil wrote:
> >> On 17/11/16 04:38, Rick Chang wrote:
> >>> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> >>> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> >>> ---
> >>> This patch depends on:
> >>> CCF "Add clock support for Mediatek MT2701"[1]
> >>> iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
> >>>
> >>> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
> >>> [2] https://patchwork.kernel.org/patch/9164013/
> >>
> >> I assume that 1 & 2 will appear in 4.10? So this patch needs to go in
> >> after the
> >> other two are merged in 4.10?
> >>
> >> Regards,
> >>
> >> Hans
> >
> > [1] will appear in 4.10, but [2] will appear latter than 4.10.So this
> > patch needs to go in after [1] & [2] will be merged in 4.11.
>
> So what should I do? Merge the driver for 4.11 and wait with this patch
> until [2] is merged in 4.11? Does that sound reasonable?
>
> Regards,
>
> Hans
What do you think about this? You merge the driver first and I send this
patch again after [1] & [2] is merged.
^ permalink raw reply
* [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory
From: Dave Young @ 2016-11-23 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54cad725-90f0-8dfe-bee6-fe1d3e02175d@redhat.com>
On 11/23/16 at 07:16am, Pratyush Anand wrote:
> Hi Geoff,
>
> On Wednesday 23 November 2016 12:27 AM, Geoff Levand wrote:
> > Hi Pratyush,
> >
> > On 11/21/2016 08:32 PM, Pratyush Anand wrote:
> > > When "enable-dcache" is passed to the kexec() command line, kexec-tools
> > > passes this information to purgatory, which in turn enables cache during
> > > sha-256 verification.
> >
> > What's the point of this enable-dcache option? Why not just
> > always enable the cache if we can?
>
> As I have written in changelog of patch 1/2
>
> "We are supporting only 4K and 64K page sizes. This code will not work if a
> hardware is not supporting at least one of these page sizes. Therefore,
> D-cache is disabled by default and enabled only when "enable-dcache" is
> passed to the kexec()."
>
>
> Although this is very unlikely that a hardware will support only 16K page
> sizes, however it is possible. Therefore, its better to keep it disabled by
> default.
If it is *unlikely* it could be better to make it as default and add a
--disable-dcache instead.
>
> ~Pratyush
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Thanks
Dave
^ permalink raw reply
* [PATCH 2/2] arm64: Pass RAM boundary and enable-dcache flag to purgatory
From: Pratyush Anand @ 2016-11-23 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123020300.GA3481@dhcp-128-65.nay.redhat.com>
On Wednesday 23 November 2016 07:33 AM, Dave Young wrote:
>> Although this is very unlikely that a hardware will support only 16K page
>> > sizes, however it is possible. Therefore, its better to keep it disabled by
>> > default.
> If it is *unlikely* it could be better to make it as default and add a
> --disable-dcache instead.
>
I think, I can do that.
~Pratyush
^ permalink raw reply
* [PATCH V9 1/6] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Chunyan Zhang @ 2016-11-23 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122173950.56585f50@gandalf.local.home>
On 23 November 2016 at 06:39, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 21 Nov 2016 15:57:18 +0800
> Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
>
>> Currently Function traces can be only exported to ring buffer, this
>> patch added trace_export concept which can process traces and export
>> them to a registered destination as an addition to the current only
>> one output of Ftrace - i.e. ring buffer.
>>
>> In this way, if we want Function traces to be sent to other destination
>> rather than ring buffer only, we just need to register a new trace_export
>> and implement its own .write() function for writing traces to storage.
>>
>> With this patch, only Function trace (trace type is TRACE_FN)
>> is supported.
>>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>> ---
>> include/linux/trace.h | 28 +++++++++++
>> kernel/trace/trace.c | 129 +++++++++++++++++++++++++++++++++++++++++++++++++-
>> 2 files changed, 156 insertions(+), 1 deletion(-)
>> create mode 100644 include/linux/trace.h
>>
>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>> new file mode 100644
>> index 0000000..9330a58
>> --- /dev/null
>> +++ b/include/linux/trace.h
>> @@ -0,0 +1,28 @@
>> +#ifndef _LINUX_TRACE_H
>> +#define _LINUX_TRACE_H
>> +
>> +#ifdef CONFIG_TRACING
>> +/*
>> + * The trace export - an export of Ftrace output. The trace_export
>> + * can process traces and export them to a registered destination as
>> + * an addition to the current only output of Ftrace - i.e. ring buffer.
>> + *
>> + * If you want traces to be sent to some other place rather than ring
>> + * buffer only, just need to register a new trace_export and implement
>> + * its own .write() function for writing traces to the storage.
>> + *
>> + * next - pointer to the next trace_export
>> + * write - copy traces which have been delt with ->commit() to
>> + * the destination
>> + */
>> +struct trace_export {
>> + struct trace_export __rcu *next;
>> + void (*write)(const void *, unsigned int);
>> +};
>> +
>> +int register_ftrace_export(struct trace_export *export);
>> +int unregister_ftrace_export(struct trace_export *export);
>> +
>> +#endif /* CONFIG_TRACING */
>> +
>> +#endif /* _LINUX_TRACE_H */
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index 8696ce6..038291d 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -40,6 +40,7 @@
>> #include <linux/poll.h>
>> #include <linux/nmi.h>
>> #include <linux/fs.h>
>> +#include <linux/trace.h>
>> #include <linux/sched/rt.h>
>>
>> #include "trace.h"
>> @@ -2128,6 +2129,129 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
>> ftrace_trace_userstack(buffer, flags, pc);
>> }
>>
>> +static void
>> +trace_process_export(struct trace_export *export,
>> + struct ring_buffer_event *event)
>> +{
>> + struct trace_entry *entry;
>> + unsigned int size = 0;
>> +
>> + entry = ring_buffer_event_data(event);
>> + size = ring_buffer_event_length(event);
>> + export->write(entry, size);
>> +}
>> +
>> +static DEFINE_MUTEX(ftrace_export_lock);
>> +
>> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
>> +
>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>> +
>> +static inline void ftrace_exports_enable(void)
>> +{
>> + static_branch_enable(&ftrace_exports_enabled);
>> +}
>> +
>> +static inline void ftrace_exports_disable(void)
>> +{
>> + static_branch_disable(&ftrace_exports_enabled);
>> +}
>> +
>> +void ftrace_exports(struct ring_buffer_event *event)
>
> I'm currently testing the patches, but is there a reason that
> ftrace_exports() is not static?
At present ftrace_exports() is only used by function trace though,
but I hope it can be used by other traces when it needed.
So I didn't mark it with static, but if you think it should better be
static for the time being, I can revise that.
Thanks,
Chunyan
>
> -- Steve
>
>> +{
>> + struct trace_export *export;
>> +
>> + preempt_disable_notrace();
>> +
>> + export = rcu_dereference_raw_notrace(ftrace_exports_list);
>> + while (export) {
>> + trace_process_export(export, event);
>> + export = rcu_dereference_raw_notrace(export->next);
>> + }
>> +
>> + preempt_enable_notrace();
>> +}
>> +
>> +static inline void
>> +add_trace_export(struct trace_export **list, struct trace_export *export)
>> +{
>> + rcu_assign_pointer(export->next, *list);
>> + /*
>> + * We are entering export into the list but another
>> + * CPU might be walking that list. We need to make sure
>> + * the export->next pointer is valid before another CPU sees
>> + * the export pointer included into the list.
>> + */
>> + rcu_assign_pointer(*list, export);
>> +}
>> +
>> +static inline int
>> +rm_trace_export(struct trace_export **list, struct trace_export *export)
>> +{
>> + struct trace_export **p;
>> +
>> + for (p = list; *p != NULL; p = &(*p)->next)
>> + if (*p == export)
>> + break;
>> +
>> + if (*p != export)
>> + return -1;
>> +
>> + rcu_assign_pointer(*p, (*p)->next);
>> +
>> + return 0;
>> +}
>> +
>> +static inline void
>> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
>> +{
>> + if (*list == NULL)
>> + ftrace_exports_enable();
>> +
>> + add_trace_export(list, export);
>> +}
>> +
>> +static inline int
>> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
>> +{
>> + int ret;
>> +
>> + ret = rm_trace_export(list, export);
>> + if (*list == NULL)
>> + ftrace_exports_disable();
>> +
>> + return ret;
>> +}
>> +
>> +int register_ftrace_export(struct trace_export *export)
>> +{
>> + if (WARN_ON_ONCE(!export->write))
>> + return -1;
>> +
>> + mutex_lock(&ftrace_export_lock);
>> +
>> + add_ftrace_export(&ftrace_exports_list, export);
>> +
>> + mutex_unlock(&ftrace_export_lock);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(register_ftrace_export);
>> +
>> +int unregister_ftrace_export(struct trace_export *export)
>> +{
>> + int ret;
>> +
>> + mutex_lock(&ftrace_export_lock);
>> +
>> + ret = rm_ftrace_export(&ftrace_exports_list, export);
>> +
>> + mutex_unlock(&ftrace_export_lock);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
>> +
>> void
>> trace_function(struct trace_array *tr,
>> unsigned long ip, unsigned long parent_ip, unsigned long flags,
>> @@ -2146,8 +2270,11 @@ trace_function(struct trace_array *tr,
>> entry->ip = ip;
>> entry->parent_ip = parent_ip;
>>
>> - if (!call_filter_check_discard(call, entry, buffer, event))
>> + if (!call_filter_check_discard(call, entry, buffer, event)) {
>> + if (static_branch_unlikely(&ftrace_exports_enabled))
>> + ftrace_exports(event);
>> __buffer_unlock_commit(buffer, event);
>> + }
>> }
>>
>> #ifdef CONFIG_STACKTRACE
>
^ permalink raw reply
* [PATCH 1/2] PCI: iproc: fix 32-bit build
From: Ray Jui @ 2016-11-23 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4393833.rTFctaL9Kd@wuerfel>
On 11/22/2016 1:13 PM, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:42:05 AM CET Ray Jui wrote:
>>
>> Hmmm, somehow we've never seen this link error for the ARM32 based
>> platforms that we build for. Does it behave differently between
>> different versions of compilers?
>>
>> Nevertheless, this is a good change to take, thanks!
>
> I looked at it again, and see now that it only happens with
> a 64-bit RESOURCE_SIZE_T, which is only used on 32-bit
> platforms with more than 4GB of memory addresses. It would
> however show up in a multiplatform distro build for ARMv7VE,
> so the fix is still clearly needed.
>
> Arnd
>
Yes, got it for how it showed up in your environment, :)
This change stands good as it has been.
Thanks,
Ray
^ permalink raw reply
* [PATCH 2/2] PCI: iproc: avoid maybe-uninitialized warning
From: Ray Jui @ 2016-11-23 3:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2504851.C6gOdhdaGF@wuerfel>
On 11/22/2016 1:15 PM, Arnd Bergmann wrote:
> On Tuesday, November 22, 2016 9:45:24 AM CET Ray Jui wrote:
>>> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
>>> index 857ff5198317..0359569c8d78 100644
>>> --- a/drivers/pci/host/pcie-iproc.c
>>> +++ b/drivers/pci/host/pcie-iproc.c
>>> @@ -936,6 +936,7 @@ static int iproc_pcie_setup_ib(struct iproc_pcie *pcie,
>>>
>>> }
>>> }
>>> + ret = -EINVAL;
>>> err_ib:
>>> dev_err(dev, "unable to configure inbound mapping\n");
>>> dev_err(dev, "axi %pap, pci %pap, res size %pap\n",
>>>
>>
>> This change is good, but in my opinion, a further improvement for
>> clarity would be to initialize 'ret' to -EINVAL in the beginning of this
>> function when 'ret' is declared. What do you think?
>>
>
> I never do that, see https://rusty.ozlabs.org/?p=232 for a great
> explanation about why.
>
> Arnd
>
Okay got it. Thanks!
Ray
^ permalink raw reply
* [PATCH v2 0/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Chen-Yu Tsai @ 2016-11-23 3:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lee,
This is v2 of my AXP806 cold boot access fix series.
Changes since v1:
- Added define for value 0x10 written to AXP806_REG_ADDR_EXT
register.
Cover letter from v1:
Recently we've added full SPL support for A80 to mainline U-boot. This
means we no longer depend on Allwinner's bootloader. It also means that
some of system configuration the bootloader set up no longer applies.
The bootloader was correctly configuring the multi-device addressing
support in the AXP806 PMIC. If the PMIC is not correctly addressed, it
just ignores all reads and writes to the other registers. As mainline
U-boot does not support the AXP806, and since we can't always count on
a good bootloader, we should re-configure this in the kernel regardless.
Patch 1 adds the registers for the multi-device addressing scheme to
the AXP806 regmap.
Patch 2 configures the register at probe time, and reinitializes the
regmap cache.
Since support for this PMIC was just added in 4.9-rc1, I hope you can
merge these 2 patches as fixes for 4.9.
Thank you!
Regards
ChenYu
Chen-Yu Tsai (2):
mfd: axp20x: Add address extension registers for AXP806 regmap
mfd: axp20x: Fix AXP806 access errors on cold boot
drivers/mfd/axp20x.c | 41 ++++++++++++++++++++++++++++++++++++++++-
include/linux/mfd/axp20x.h | 2 ++
2 files changed, 42 insertions(+), 1 deletion(-)
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/2] mfd: axp20x: Add address extension registers for AXP806 regmap
From: Chen-Yu Tsai @ 2016-11-23 3:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123031616.10114-1-wens@csie.org>
The AXP806 supports either master/standalone or slave mode.
Slave mode allows sharing the serial bus, even with multiple
AXP806 which all have the same hardware address.
This is done with extra "serial interface address extension",
or AXP806_BUS_ADDR_EXT, and "register address extension", or
AXP806_REG_ADDR_EXT, registers. The former is read-only, with
1 bit customizable at the factory, and 1 bit depending on the
state of an external pin. The latter is writable. Only when
the these device addressing bits (in the upper 4 bits of the
registers) match, will the device respond to operations on
its other registers.
Add these 2 registers to the regmap so we can access them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/mfd/axp20x.c | 3 ++-
include/linux/mfd/axp20x.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index ba130be32e61..cdaeb34a9a38 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -135,6 +135,7 @@ static const struct regmap_range axp806_writeable_ranges[] = {
regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN),
regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
+ regmap_reg_range(AXP806_REG_ADDR_EXT, AXP806_REG_ADDR_EXT),
};
static const struct regmap_range axp806_volatile_ranges[] = {
@@ -305,7 +306,7 @@ static const struct regmap_config axp806_regmap_config = {
.val_bits = 8,
.wr_table = &axp806_writeable_table,
.volatile_table = &axp806_volatile_table,
- .max_register = AXP806_VREF_TEMP_WARN_L,
+ .max_register = AXP806_REG_ADDR_EXT,
.cache_type = REGCACHE_RBTREE,
};
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index fec597fb34cb..7e85ececcedf 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -115,6 +115,8 @@ enum {
#define AXP806_CLDO2_V_CTRL 0x25
#define AXP806_CLDO3_V_CTRL 0x26
#define AXP806_VREF_TEMP_WARN_L 0xf3
+#define AXP806_BUS_ADDR_EXT 0xfe
+#define AXP806_REG_ADDR_EXT 0xff
/* Interrupt */
#define AXP152_IRQ1_EN 0x40
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/2] mfd: axp20x: Fix AXP806 access errors on cold boot
From: Chen-Yu Tsai @ 2016-11-23 3:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123031616.10114-1-wens@csie.org>
The AXP806 supports either master/standalone or slave mode.
Slave mode allows sharing the serial bus, even with multiple
AXP806 which all have the same hardware address.
This is done with extra "serial interface address extension",
or AXP806_BUS_ADDR_EXT, and "register address extension", or
AXP806_REG_ADDR_EXT, registers. The former is read-only, with
1 bit customizable at the factory, and 1 bit depending on the
state of an external pin. The latter is writable. Only when
the these device addressing bits (in the upper 4 bits of the
registers) match, will the device respond to operations on
its other registers.
The AXP806_REG_ADDR_EXT was previously configured by Allwinner's
bootloader. Work on U-boot SPL support now allows us to switch
to mainline U-boot, which doesn't do this for us. There might
be other bare minimum bootloaders out there which don't to this
either. It's best to handle this in the kernel.
This patch sets AXP806_REG_ADDR_EXT to 0x10, which is what we
know to be the proper value for a standard AXP806 in slave mode.
Afterwards it will reinitialize the regmap cache, to purge any
invalid stale values.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/mfd/axp20x.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index cdaeb34a9a38..a0166c667656 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -31,6 +31,8 @@
#define AXP20X_OFF 0x80
+#define AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE BIT(4)
+
static const char * const axp20x_model_names[] = {
"AXP152",
"AXP202",
@@ -829,6 +831,42 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
{
int ret;
+ /*
+ * The AXP806 supports either master/standalone or slave mode.
+ * Slave mode allows sharing the serial bus, even with multiple
+ * AXP806 which all have the same hardware address.
+ *
+ * This is done with extra "serial interface address extension",
+ * or AXP806_BUS_ADDR_EXT, and "register address extension", or
+ * AXP806_REG_ADDR_EXT, registers. The former is read-only, with
+ * 1 bit customizable at the factory, and 1 bit depending on the
+ * state of an external pin. The latter is writable. Only when
+ * the these device addressing bits (in the upper 4 bits of the
+ * registers) match, will the device respond to operations on its
+ * other registers.
+ *
+ * Since we only support an AXP806 chained to an AXP809 in slave
+ * mode, and there isn't any existing hardware which uses AXP806
+ * in master mode, or has 2 AXP806s in the same system, we can
+ * just program the register address extension to the slave mode
+ * address.
+ */
+ if (axp20x->variant == AXP806_ID) {
+ /* Write to the register address extension register */
+ regmap_write(axp20x->regmap, AXP806_REG_ADDR_EXT,
+ AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE);
+
+ /* Make sure the write hits the device */
+ regcache_sync_region(axp20x->regmap, AXP806_REG_ADDR_EXT,
+ AXP806_REG_ADDR_EXT);
+
+ /*
+ * Reinitialize the regmap cache in case the device didn't
+ * properly respond to our reads before.
+ */
+ regmap_reinit_cache(axp20x->regmap, axp20x->regmap_cfg);
+ }
+
ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
IRQF_ONESHOT | IRQF_SHARED, -1,
axp20x->regmap_irq_chip,
--
2.10.2
^ permalink raw reply related
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Zheng, Lv @ 2016-11-23 3:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117175938.17465.45820.stgit@bhelgaas-glaptop.roam.corp.google.com>
Hi, Bjorn
Thanks for the documentation.
It really helps!
However I have a question below.
> From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-owner at vger.kernel.org] On Behalf Of Bjorn
> Helgaas
> Subject: [PATCH] PCI: Add information about describing PCI in ACPI
>
> 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 | 136 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 138 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..ccbcfda
> --- /dev/null
> +++ b/Documentation/PCI/acpi-info.txt
> @@ -0,0 +1,136 @@
> + 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 methods of devices in
> +the ACPI namespace [2]. ? _CRS methods are like generalized PCI BARs:
> +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.
The entire document doesn't talk about the details of _CBA.
There is only one line below mentioned _CBA as an example.
> +
> +If the OS is expected to manage an ACPI device, 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.
> +
> +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 any address space that is (1) not claimed by some
> +other ACPI device and (2) should not be assigned by the OS to
> +something else, should be claimed by a PNP0C02 _CRS method.
> +
> +PCI host bridges are PNP0A03 or PNP0A08 devices. ?Their _CRS should
> +describe all the address space they consume. ?In principle, this would
> +be all the windows they forward down to the PCI bus, as well as the
> +bridge registers themselves. ?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. ?These bridge registers also
> +include ECAM space, since it is consumed by the bridge.
> +
> +ACPI defined a Producer/Consumer bit that was intended to distinguish
> +the bridge apertures from the bridge registers [4, 5]. ?However,
> +BIOSes didn't use that bit correctly, and the result is that OSes have
> +to assume that everything in a PCI host bridge _CRS is a window. ?That
> +leaves no way to describe the bridge registers in the PNP0A03/PNP0A08
> +device itself.
> +
> +The workaround is 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. ?For
> +ECAM, pci_root.c learns about the space from either MCFG or the _CBA
> +method.
Should the relationship of MCFG and _CBA be covered in this document?
Thanks and best regards
Lv
> +
> +Note that the PCIe spec actually does require ECAM unless there's a
> +standard firmware interface for config access, e.g., the ia64 SAL
> +interface [7]. One reason is that we want a generic host bridge
> +driver (pci_root.c), and a generic driver requires a generic way to
> +access config space.
> +
> +
> +[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.4:
> + Extended Address Space Descriptor
> + 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.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/3] TI DA850/OMAP-L138/AM18x pinconf
From: David Lechner @ 2016-11-23 3:29 UTC (permalink / raw)
To: linux-arm-kernel
This series adds a new driver and DT bindings for TI DA850/OMAP-L138/AM18x
pinconf (bias pullup/pulldown).
The motivation for this series is LEGO MINDSTORMS EV3 support. It needs most,
if not all, internal pullup/down resistors disabled in order to work correctly.
David Lechner (3):
devicetree: bindings: pinctrl: Add binding for ti,da850-pupd
pinctrl: New driver for TI DA8XX/OMAP-L138/AM18XX pinconf
ARM: dts: da850: Add node for pullup/pulldown pinconf
.../devicetree/bindings/pinctrl/ti,da850-pupd.txt | 55 ++++++
arch/arm/boot/dts/da850.dtsi | 5 +
drivers/pinctrl/Kconfig | 9 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-da850-pupd.c | 210 +++++++++++++++++++++
5 files changed, 280 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/ti,da850-pupd.txt
create mode 100644 drivers/pinctrl/pinctrl-da850-pupd.c
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] devicetree: bindings: pinctrl: Add binding for ti, da850-pupd
From: David Lechner @ 2016-11-23 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479871767-20160-1-git-send-email-david@lechnology.com>
Device-tree bindings for TI DA8XX/OMAP-L138/AM18XX pullup/pulldown
pinconf controller.
Signed-off-by: David Lechner <david@lechnology.com>
---
.../devicetree/bindings/pinctrl/ti,da850-pupd.txt | 55 ++++++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/ti,da850-pupd.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/ti,da850-pupd.txt b/Documentation/devicetree/bindings/pinctrl/ti,da850-pupd.txt
new file mode 100644
index 0000000..7f29805
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ti,da850-pupd.txt
@@ -0,0 +1,55 @@
+* Pin configuration for TI DA850/OMAP-L138/AM18x
+
+These SoCs have a separate controller for setting bias (internal pullup/down).
+Bias can only be selected for groups rather than individual pins.
+
+Required Properties:
+
+ - compatible: Must be "ti,da850-pupd"
+ - reg: Base address and length of the memory resource used by the pullup/down
+ controller hardware module.
+
+The controller node also acts as a container for pin group configuration nodes.
+The names of these groups are ignored.
+
+Pin Group Node Properties:
+
+- groups: An array of strings, each string containing the name of a pin group.
+ Valid names are "cp0".."cp31".
+
+The pin configuration parameters use the generic pinconf bindings defined in
+pinctrl-bindings.txt in this directory. The supported parameters are
+bias-disable, bias-pull-up, bias-pull-down.
+
+
+Example
+-------
+
+In common dtsi file:
+
+ pinconf: pin-controller at 22c00c {
+ compatible = "ti,da850-pupd";
+ reg = <0x22c00c 0x8>;
+ };
+
+In board-specific file:
+
+ &pinconf {
+ pinctrl-0 = <&pinconf_bias_groups>;
+ pinctrl-names = "default";
+
+ pinconf_bias_groups: bias-groups {
+ pull-up {
+ groups = "cp30", "cp31";
+ bias-pull-up;
+ };
+ pull-down {
+ groups = "cp29", "cp28";
+ bias-pull-down;
+ };
+ disable {
+ groups = "cp27", "cp26";
+ bias-disable;
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] pinctrl: New driver for TI DA8XX/OMAP-L138/AM18XX pinconf
From: David Lechner @ 2016-11-23 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479871767-20160-1-git-send-email-david@lechnology.com>
This adds a new driver for pinconf on TI DA8XX/OMAP-L138/AM18XX. These
SoCs have a separate controller for controlling pullup/pulldown groups.
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/pinctrl/Kconfig | 9 ++
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-da850-pupd.c | 210 +++++++++++++++++++++++++++++++++++
3 files changed, 220 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-da850-pupd.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 5f40ad6..54044a8 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -93,6 +93,15 @@ config PINCTRL_AMD
Requires ACPI/FDT device enumeration code to set up a platform
device.
+config PINCTRL_DA850_PUPD
+ tristate "TI DA850/OMAP-L138/AM18XX pullup/pulldown groups"
+ depends on OF && (ARCH_DAVINCI_DA850 || COMPILE_TEST)
+ select PINCONF
+ select GENERIC_PINCONF
+ help
+ Driver for TI DA850/OMAP-L138/AM18XX pinconf. Used to control
+ pullup/pulldown pin groups.
+
config PINCTRL_DIGICOLOR
bool
depends on OF && (ARCH_DIGICOLOR || COMPILE_TEST)
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 3b8e6f7..25d50a8 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_PINCTRL_BF60x) += pinctrl-adi2-bf60x.o
obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
obj-$(CONFIG_PINCTRL_AT91PIO4) += pinctrl-at91-pio4.o
obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
+obj-$(CONFIG_PINCTRL_DA850_PUPD) += pinctrl-da850-pupd.o
obj-$(CONFIG_PINCTRL_DIGICOLOR) += pinctrl-digicolor.o
obj-$(CONFIG_PINCTRL_FALCON) += pinctrl-falcon.o
obj-$(CONFIG_PINCTRL_MAX77620) += pinctrl-max77620.o
diff --git a/drivers/pinctrl/pinctrl-da850-pupd.c b/drivers/pinctrl/pinctrl-da850-pupd.c
new file mode 100644
index 0000000..0446df7
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-da850-pupd.c
@@ -0,0 +1,210 @@
+/*
+ * Pinconf driver for TI DA850/OMAP-L138/AM18XX pullup/pulldown groups
+ *
+ * Copyright (C) 2016 David Lechner
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/bitops.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/platform_device.h>
+
+#define DA850_PUPD_ENA 0x00
+#define DA850_PUPD_SEL 0x04
+
+struct da850_pupd_data {
+ void __iomem *base;
+ struct pinctrl_desc desc;
+ struct pinctrl_dev *pinctrl;
+};
+
+static const char * const da850_pupd_group_names[] = {
+ "cp0", "cp1", "cp2", "cp3", "cp4", "cp5", "cp6", "cp7",
+ "cp8", "cp9", "cp10", "cp11", "cp12", "cp13", "cp14", "cp15",
+ "cp16", "cp17", "cp18", "cp19", "cp20", "cp21", "cp22", "cp23",
+ "cp24", "cp25", "cp26", "cp27", "cp28", "cp29", "cp30", "cp31",
+};
+
+static int da850_pupd_get_groups_count(struct pinctrl_dev *pctldev)
+{
+ return ARRAY_SIZE(da850_pupd_group_names);
+}
+
+static const char *da850_pupd_get_get_group_name(struct pinctrl_dev *pctldev,
+ unsigned int selector)
+{
+ return da850_pupd_group_names[selector];
+}
+
+static int da850_pupd_get_get_group_pins(struct pinctrl_dev *pctldev,
+ unsigned int selector,
+ const unsigned int **pins,
+ unsigned int *num_pins)
+{
+ *num_pins = 0;
+
+ return 0;
+}
+
+static const struct pinctrl_ops da850_pupd_pctlops = {
+ .get_groups_count = da850_pupd_get_groups_count,
+ .get_group_name = da850_pupd_get_get_group_name,
+ .get_group_pins = da850_pupd_get_get_group_pins,
+ .dt_node_to_map = pinconf_generic_dt_node_to_map_group,
+ .dt_free_map = pinconf_generic_dt_free_map,
+};
+
+static int da850_pupd_pin_config_group_get(struct pinctrl_dev *pctldev,
+ unsigned int selector,
+ unsigned long *config)
+{
+ struct da850_pupd_data *data = pinctrl_dev_get_drvdata(pctldev);
+ enum pin_config_param param = pinconf_to_config_param(*config);
+ u32 val;
+ u16 arg;
+
+ val = readl(data->base + DA850_PUPD_ENA);
+ arg = !!(~val & BIT(selector));
+
+ switch (param) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ break;
+ case PIN_CONFIG_BIAS_PULL_UP:
+ case PIN_CONFIG_BIAS_PULL_DOWN:
+ if (arg) {
+ /* bias is disabled */
+ arg = 0;
+ break;
+ }
+ val = readl(data->base + DA850_PUPD_SEL);
+ if (param == PIN_CONFIG_BIAS_PULL_DOWN)
+ val = ~val;
+ arg = !!(val & BIT(selector));
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ *config = pinconf_to_config_packed(param, arg);
+
+ return 0;
+}
+
+static int da850_pupd_pin_config_group_set(struct pinctrl_dev *pctldev,
+ unsigned int selector,
+ unsigned long *configs,
+ unsigned int num_configs)
+{
+ struct da850_pupd_data *data = pinctrl_dev_get_drvdata(pctldev);
+ u32 ena, sel;
+ enum pin_config_param param;
+ u16 arg;
+ int i;
+
+ ena = readl(data->base + DA850_PUPD_ENA);
+ sel = readl(data->base + DA850_PUPD_SEL);
+
+ for (i = 0; i < num_configs; i++) {
+ param = pinconf_to_config_param(configs[i]);
+ arg = pinconf_to_config_argument(configs[i]);
+
+ switch (param) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ ena &= ~BIT(selector);
+ break;
+ case PIN_CONFIG_BIAS_PULL_UP:
+ ena |= BIT(selector);
+ sel |= BIT(selector);
+ break;
+ case PIN_CONFIG_BIAS_PULL_DOWN:
+ ena |= BIT(selector);
+ sel &= ~BIT(selector);
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+
+ writel(sel, data->base + DA850_PUPD_SEL);
+ writel(ena, data->base + DA850_PUPD_ENA);
+
+ return 0;
+}
+
+static const struct pinconf_ops da850_pupd_confops = {
+ .is_generic = true,
+ .pin_config_group_get = da850_pupd_pin_config_group_get,
+ .pin_config_group_set = da850_pupd_pin_config_group_set,
+};
+
+static int da850_pupd_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct da850_pupd_data *data;
+ struct resource *res;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(data->base)) {
+ dev_err(dev, "Could not map resource\n");
+ return PTR_ERR(data->base);
+ }
+
+ data->desc.name = dev_name(dev);
+ data->desc.pctlops = &da850_pupd_pctlops;
+ data->desc.confops = &da850_pupd_confops;
+ data->desc.owner = THIS_MODULE;
+
+ data->pinctrl = devm_pinctrl_register(dev, &data->desc, data);
+ if (IS_ERR(data->pinctrl)) {
+ dev_err(dev, "Failed to register pinctrl\n");
+ return PTR_ERR(data->pinctrl);
+ }
+
+ platform_set_drvdata(pdev, data);
+
+ return 0;
+}
+
+static int da850_pupd_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static const struct of_device_id da850_pupd_of_match[] = {
+ { .compatible = "ti,da850-pupd" },
+ { }
+};
+
+static struct platform_driver da850_pupd_driver = {
+ .driver = {
+ .name = "ti-da850-pupd",
+ .of_match_table = da850_pupd_of_match,
+ },
+ .probe = da850_pupd_probe,
+ .remove = da850_pupd_remove,
+};
+module_platform_driver(da850_pupd_driver);
+
+MODULE_AUTHOR("David Lechner <david@lechnology.com>");
+MODULE_DESCRIPTION("TI DA850/OMAP-L138/AM18XX pullup/pulldown configuration");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: David Lechner @ 2016-11-23 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479871767-20160-1-git-send-email-david@lechnology.com>
This SoC has a separate pin controller for configuring pullup/pulldown
bias on groups of pins.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 8945815..1c0224c 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -210,6 +210,11 @@
};
};
+ pinconf: pin-controller at 22c00c {
+ compatible = "ti,da850-pupd";
+ reg = <0x22c00c 0x8>;
+ status = "disabled";
+ };
prictrl: priority-controller at 14110 {
compatible = "ti,da850-mstpri";
reg = <0x14110 0x0c>;
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/3] dmaengine: sun6i: share the dma driver with sun50i
From: Vinod Koul @ 2016-11-23 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479638740-20520-4-git-send-email-hao5781286@gmail.com>
On Sun, Nov 20, 2016 at 06:45:40PM +0800, Hao Zhang wrote:
> Changes the limited buswith to 8 bytes,and add
> the test in sun6i_dma_config function
>
> Accroding to sun6i dma driver, i think ,if the client
^^^^^^^^
typo and other grammatical mistakes here..
> doesn't configure the address width with dmaengine_slave_config
> function, it would use the default width. So we can add the test
> in sun6i_dma_config function called by dmaengine_slave_config,
> and test the configuration whether is support for the device.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a235878..f7c90b6 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -250,7 +250,7 @@ static inline s8 convert_burst(u32 maxburst)
> static inline s8 convert_buswidth(enum dma_slave_buswidth addr_width)
> {
> if ((addr_width < DMA_SLAVE_BUSWIDTH_1_BYTE) ||
> - (addr_width > DMA_SLAVE_BUSWIDTH_4_BYTES))
> + (addr_width > DMA_SLAVE_BUSWIDTH_8_BYTES))
> return -EINVAL;
>
> return addr_width >> 1;
> @@ -758,6 +758,18 @@ static int sun6i_dma_config(struct dma_chan *chan,
> {
> struct sun6i_vchan *vchan = to_sun6i_vchan(chan);
>
> + if ((BIT(config->src_addr_width) | chan->device->src_addr_widths) !=
> + chan->device->src_addr_widths) {
First I dont like coding style here
Second, this is not driver specific, should be move to core..
--
~Vinod
^ permalink raw reply
* [PATCH] dmaengine: qcom_hidma: autoload while probing ACPI
From: Vinod Koul @ 2016-11-23 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479583718-2716-1-git-send-email-okaya@codeaurora.org>
On Sat, Nov 19, 2016 at 02:28:37PM -0500, Sinan Kaya wrote:
> MODULE_DEVICE_TABLE is used by the kernel to determine which device driver
> should be loaded for which platform device. MODULE_DEVICE_TABLE has been
> only defined for the device-tree based platforms in the current code.
> Defining it also for ACPI based platforms.
Applied now
--
~Vinod
^ permalink raw reply
* [PATCH V9 1/6] tracing: add a possibility of exporting function trace to other places instead of ring buffer only
From: Chunyan Zhang @ 2016-11-23 5:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG2=9p8AP4A09rnbqBLWr1UPiJ=7GzWB0Ncfzd0sb=yZ9kb56Q@mail.gmail.com>
Hi Steve,
Actually I had been keeping the idea that we would need to export most
kinds of traces rather than function trace only to somewhere else, say
STM, that's also why I made STM_SOURCE_FTRACE depending on TRACING
which was later changed to FUNCTION_TRACER according to you advice.
Thanks,
Chunyan
On 23 November 2016 at 10:27, Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
> On 23 November 2016 at 06:39, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Mon, 21 Nov 2016 15:57:18 +0800
>> Chunyan Zhang <zhang.chunyan@linaro.org> wrote:
>>
>>> Currently Function traces can be only exported to ring buffer, this
>>> patch added trace_export concept which can process traces and export
>>> them to a registered destination as an addition to the current only
>>> one output of Ftrace - i.e. ring buffer.
>>>
>>> In this way, if we want Function traces to be sent to other destination
>>> rather than ring buffer only, we just need to register a new trace_export
>>> and implement its own .write() function for writing traces to storage.
>>>
>>> With this patch, only Function trace (trace type is TRACE_FN)
>>> is supported.
>>>
>>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>>> ---
>>> include/linux/trace.h | 28 +++++++++++
>>> kernel/trace/trace.c | 129 +++++++++++++++++++++++++++++++++++++++++++++++++-
>>> 2 files changed, 156 insertions(+), 1 deletion(-)
>>> create mode 100644 include/linux/trace.h
>>>
>>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>>> new file mode 100644
>>> index 0000000..9330a58
>>> --- /dev/null
>>> +++ b/include/linux/trace.h
>>> @@ -0,0 +1,28 @@
>>> +#ifndef _LINUX_TRACE_H
>>> +#define _LINUX_TRACE_H
>>> +
>>> +#ifdef CONFIG_TRACING
>>> +/*
>>> + * The trace export - an export of Ftrace output. The trace_export
>>> + * can process traces and export them to a registered destination as
>>> + * an addition to the current only output of Ftrace - i.e. ring buffer.
>>> + *
>>> + * If you want traces to be sent to some other place rather than ring
>>> + * buffer only, just need to register a new trace_export and implement
>>> + * its own .write() function for writing traces to the storage.
>>> + *
>>> + * next - pointer to the next trace_export
>>> + * write - copy traces which have been delt with ->commit() to
>>> + * the destination
>>> + */
>>> +struct trace_export {
>>> + struct trace_export __rcu *next;
>>> + void (*write)(const void *, unsigned int);
>>> +};
>>> +
>>> +int register_ftrace_export(struct trace_export *export);
>>> +int unregister_ftrace_export(struct trace_export *export);
>>> +
>>> +#endif /* CONFIG_TRACING */
>>> +
>>> +#endif /* _LINUX_TRACE_H */
>>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>>> index 8696ce6..038291d 100644
>>> --- a/kernel/trace/trace.c
>>> +++ b/kernel/trace/trace.c
>>> @@ -40,6 +40,7 @@
>>> #include <linux/poll.h>
>>> #include <linux/nmi.h>
>>> #include <linux/fs.h>
>>> +#include <linux/trace.h>
>>> #include <linux/sched/rt.h>
>>>
>>> #include "trace.h"
>>> @@ -2128,6 +2129,129 @@ void trace_buffer_unlock_commit_regs(struct trace_array *tr,
>>> ftrace_trace_userstack(buffer, flags, pc);
>>> }
>>>
>>> +static void
>>> +trace_process_export(struct trace_export *export,
>>> + struct ring_buffer_event *event)
>>> +{
>>> + struct trace_entry *entry;
>>> + unsigned int size = 0;
>>> +
>>> + entry = ring_buffer_event_data(event);
>>> + size = ring_buffer_event_length(event);
>>> + export->write(entry, size);
>>> +}
>>> +
>>> +static DEFINE_MUTEX(ftrace_export_lock);
>>> +
>>> +static struct trace_export __rcu *ftrace_exports_list __read_mostly;
>>> +
>>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>>> +
>>> +static inline void ftrace_exports_enable(void)
>>> +{
>>> + static_branch_enable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +static inline void ftrace_exports_disable(void)
>>> +{
>>> + static_branch_disable(&ftrace_exports_enabled);
>>> +}
>>> +
>>> +void ftrace_exports(struct ring_buffer_event *event)
>>
>> I'm currently testing the patches, but is there a reason that
>> ftrace_exports() is not static?
>
> At present ftrace_exports() is only used by function trace though,
> but I hope it can be used by other traces when it needed.
> So I didn't mark it with static, but if you think it should better be
> static for the time being, I can revise that.
>
> Thanks,
> Chunyan
>
>
>>
>> -- Steve
>>
>>> +{
>>> + struct trace_export *export;
>>> +
>>> + preempt_disable_notrace();
>>> +
>>> + export = rcu_dereference_raw_notrace(ftrace_exports_list);
>>> + while (export) {
>>> + trace_process_export(export, event);
>>> + export = rcu_dereference_raw_notrace(export->next);
>>> + }
>>> +
>>> + preempt_enable_notrace();
>>> +}
>>> +
>>> +static inline void
>>> +add_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + rcu_assign_pointer(export->next, *list);
>>> + /*
>>> + * We are entering export into the list but another
>>> + * CPU might be walking that list. We need to make sure
>>> + * the export->next pointer is valid before another CPU sees
>>> + * the export pointer included into the list.
>>> + */
>>> + rcu_assign_pointer(*list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_trace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + struct trace_export **p;
>>> +
>>> + for (p = list; *p != NULL; p = &(*p)->next)
>>> + if (*p == export)
>>> + break;
>>> +
>>> + if (*p != export)
>>> + return -1;
>>> +
>>> + rcu_assign_pointer(*p, (*p)->next);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static inline void
>>> +add_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + if (*list == NULL)
>>> + ftrace_exports_enable();
>>> +
>>> + add_trace_export(list, export);
>>> +}
>>> +
>>> +static inline int
>>> +rm_ftrace_export(struct trace_export **list, struct trace_export *export)
>>> +{
>>> + int ret;
>>> +
>>> + ret = rm_trace_export(list, export);
>>> + if (*list == NULL)
>>> + ftrace_exports_disable();
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +int register_ftrace_export(struct trace_export *export)
>>> +{
>>> + if (WARN_ON_ONCE(!export->write))
>>> + return -1;
>>> +
>>> + mutex_lock(&ftrace_export_lock);
>>> +
>>> + add_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> + mutex_unlock(&ftrace_export_lock);
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(register_ftrace_export);
>>> +
>>> +int unregister_ftrace_export(struct trace_export *export)
>>> +{
>>> + int ret;
>>> +
>>> + mutex_lock(&ftrace_export_lock);
>>> +
>>> + ret = rm_ftrace_export(&ftrace_exports_list, export);
>>> +
>>> + mutex_unlock(&ftrace_export_lock);
>>> +
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(unregister_ftrace_export);
>>> +
>>> void
>>> trace_function(struct trace_array *tr,
>>> unsigned long ip, unsigned long parent_ip, unsigned long flags,
>>> @@ -2146,8 +2270,11 @@ trace_function(struct trace_array *tr,
>>> entry->ip = ip;
>>> entry->parent_ip = parent_ip;
>>>
>>> - if (!call_filter_check_discard(call, entry, buffer, event))
>>> + if (!call_filter_check_discard(call, entry, buffer, event)) {
>>> + if (static_branch_unlikely(&ftrace_exports_enabled))
>>> + ftrace_exports(event);
>>> __buffer_unlock_commit(buffer, event);
>>> + }
>>> }
>>>
>>> #ifdef CONFIG_STACKTRACE
>>
^ permalink raw reply
* [RESEND PATCH 2/3] ARM: davinci: hawk: Remove vbus and over current gpios
From: Sekhar Nori @ 2016-11-23 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKXjFTMLt0j4yfHUww6k6FMu4=Z+mhZJCKi-tqmqdaOUs0fJ9Q@mail.gmail.com>
On Tuesday 22 November 2016 09:11 PM, Axel Haslam wrote:
> Hi Sekhar
>
> On Tue, Nov 22, 2016 at 11:37 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Monday 21 November 2016 10:23 PM, Axel Haslam wrote:
>>> The hawk board VBUS is fixed to a 5v source, and the over
>>> current pin is actually not connected to the SoC.
>>>
>>> Do not reseve these gpios for OHCI as they are not related
>>> to usb.
>>>
>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>>
>> As discussed over the MMC/SD patches, this patch should be based off the
>> hawkboard schematic, not the LCDK schematic.
>>
>
> I looked at the hawkboard schematics and they are the same
> as the lcdk as far as usb i concerned:
>
> The ohci vbus is fixed to 5v, and the over current pins of the
> TPS are not connected. so this patch should be ok for
> both the hawk and the lcdk.
Alright! Thanks for checking.
Regards,
Sekhar
^ permalink raw reply
* [PATCH 1/4] ARM: davinci: da8xx: VPIF: enable DT init
From: Kevin Hilman @ 2016-11-23 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <31948202-333f-b465-07b8-6260cce29b59@lechnology.com>
David Lechner <david@lechnology.com> writes:
> On 11/22/2016 01:45 PM, Kevin Hilman wrote:
>> Add basic support for DT initializaion of VPIF (capture) via DT. Clocks
>> and mux still need to happen in this file until there are real clock and
>> pinctrl drivers, but the video nodes and subdevs can all come from DT.
>>
>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>> ---
>> arch/arm/mach-davinci/da8xx-dt.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
>> index c9f7e9274aa8..7b41611f2665 100644
>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>> @@ -17,6 +17,7 @@
>> #include <mach/common.h>
>> #include "cp_intc.h"
>> #include <mach/da8xx.h>
>> +#include <mach/mux.h>
>>
>> static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>> OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
>> @@ -38,14 +39,30 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
>> NULL),
>> OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
>> OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
>> + OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
>> {}
>> };
>>
>> #ifdef CONFIG_ARCH_DAVINCI_DA850
>>
>> +#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
>> +static __init void da850_vpif_capture_init(void)
>> +{
>> + int ret;
>> +
>> + ret = davinci_cfg_reg_list(da850_vpif_capture_pins);
>
> Why can't we use the existing pinctrl-single node in device tree for
> muxing the pins?
Oops, you're right. They can.
Kevin
^ 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