* [PATCH V2 02/10] clk: reparent orphans after critical clocks enabled
From: Dong Aisheng @ 2017-12-22 2:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222015507.GE7997@codeaurora.org>
On Thu, Dec 21, 2017 at 05:55:07PM -0800, Stephen Boyd wrote:
> On 12/21, Stephen Boyd wrote:
> >
> > Ok. Great. I'm going to apply this patch now into clk-next to
> > look for regressions on other platforms. If this was the only
> > questionable thing about this series then I think I can apply the
> > rest of it without you needing to resend. I'll check today.
> >
>
> I pushed it into clk-imx7ulp and merged that into clk-next. You
> can use that patch in your series.
>
Okay, great.
Thanks
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: Bjorn Helgaas @ 2017-12-22 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513904194.25872.23.camel@mhfsdcap03>
On Fri, Dec 22, 2017 at 08:56:34AM +0800, Honghui Zhang wrote:
> There's an internal control register that control the Vendor ID and
> device ID values, our designer leave the default value un-touched. I
> will set these values in that way for the next version of fix.
Then there's no problem. The mtk_pcie driver is a platform driver
that claims the host controller based on an of_device_id from a device
tree.
Apparently the bridge is also materialized in PCI config space, which
is typical for x86 host bridges, and makes the bridge appear in
"lspci". But drivers generally don't claim bridges that way.
You can just program the Vendor and Device IDs by writing the internal
control registers somewhere in the mtk_pci_probe() path.
Then you can set the class code the same way, using an internal
control register (if that's possible), or using a quirk with the
correct Mediatek Vendor ID (if there is no internal writable
register).
Bjorn
^ permalink raw reply
* [PATCH V2 01/10] clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk support
From: Dong Aisheng @ 2017-12-22 3:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222012401.GB7997@codeaurora.org>
On Thu, Dec 21, 2017 at 05:24:01PM -0800, Stephen Boyd wrote:
> On 12/20, Dong Aisheng wrote:
> > On Thu, Nov 02, 2017 at 12:50:39AM -0700, Stephen Boyd wrote:
> > > On 07/13, Dong Aisheng wrote:
> > > > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > > > index 9bb472c..55f8c41 100644
> > > > --- a/drivers/clk/clk-divider.c
> > > > +++ b/drivers/clk/clk-divider.c
> > > > @@ -123,6 +123,9 @@ unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
> > > > struct clk_divider *divider = to_clk_divider(hw);
> > > > unsigned int div;
> > > >
> > > > + if (flags & CLK_DIVIDER_ZERO_GATE && !val)
> > > > + return 0;
> > > > +
> > > > div = _get_div(table, val, flags, divider->width);
> > > > if (!div) {
> > > > WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO),
> > > > @@ -141,8 +144,13 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
> > > > struct clk_divider *divider = to_clk_divider(hw);
> > > > unsigned int val;
> > > >
> > > > - val = clk_readl(divider->reg) >> divider->shift;
> > > > - val &= div_mask(divider->width);
> > > > + if ((divider->flags & CLK_DIVIDER_ZERO_GATE) &&
> > > > + !clk_hw_is_enabled(hw)) {
> > >
> > > This seems racy. Are we holding the register lock here?
> > >
> >
> > Would you please clarify what type of racy you mean?
>
> I mean a race between clk_enable() and clk_set_rate(). A
> clk_enable() can happen while a rate change is going on, and then
> the clk_hw_is_enabled() check here would be racing, unless this
> driver specifically tries to prevent that from happening by
> holding a spinlock somewhere.
>
Will this race cause real problems as clk_divider_is_enabled is only
a register read?
And seems either clk_hw_is_enable or __clk_is_enabled is allowed
to be called by anywhere currently. So it may be none of calling
in set_rate or recalc_rate issue.
If they may be race with clk_enable/disable function, seems they may
be better protected by the core.
And i did see some clarify in Documentation/clk.txt:
"The enable lock is a spinlock and is held across calls to the .enable,
.disable and .is_enabled operations. Those operations are thus not allowed to
sleep, and calls to the clk_enable(), clk_disable() and clk_is_enabled() API
functions are allowed in atomic context."
Then how about do like below:
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8a1860a..ce5fa96 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -191,6 +191,7 @@ static bool clk_core_is_prepared(struct clk_core *core)
static bool clk_core_is_enabled(struct clk_core *core)
{
+ unsigned long flags;
bool ret = false;
/*
@@ -218,7 +219,10 @@ static bool clk_core_is_enabled(struct clk_core *core)
}
}
+ flags = clk_enable_lock();
ret = core->ops->is_enabled(core->hw);
+ clk_enable_unlock(flags);
+
done:
clk_pm_runtime_put(core);
> >
> > Currently it only protects register write between set_rate and enable/disable,
> > and other register read are not protected.
> > e.g. in recalc_rate and is_enabled.
>
> If you're holding some lock that is used to protect the register
> writes and also the clk from getting enabled/disabled during a
> rate change then it's fine.
>
Yes, all possible register write are protected.
Regards
Dong Aisheng
> >
> > And i did see similar users, e.g.
> > drivers/clk/sunxi-ng/ccu_mult.c
>
> Sure. Those could also be broken. I'm not sure.
>
> >
> > Should we still need protect them here?
> >
> > > > + val = divider->cached_val;
> > > > + } else {
> > > > + val = clk_readl(divider->reg) >> divider->shift;
> > > > + val &= div_mask(divider->width);
> > > > + }
> > > >
> > > > return divider_recalc_rate(hw, parent_rate, val, divider->table,
> > > > divider->flags);
> > > > @@ -392,6 +400,12 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
> > > > value = divider_get_val(rate, parent_rate, divider->table,
> > > > divider->width, divider->flags);
> > > >
> > > > + if ((divider->flags & CLK_DIVIDER_ZERO_GATE) &&
> > > > + !clk_hw_is_enabled(hw)) {
> > >
> > > Same racy comment here.
> > >
> > > > + divider->cached_val = value;
> > > > + return 0;
> > > > + }
> > > > +
> > > > if (divider->lock)
> > > > spin_lock_irqsave(divider->lock, flags);
> > > > else
> > > > @@ -414,10 +428,85 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
> > > > return 0;
> > > > }
> > > >
> > > > +static int clk_divider_enable(struct clk_hw *hw)
> > > > +{
> > > > + struct clk_divider *divider = to_clk_divider(hw);
> > > > + unsigned long flags = 0;
> > > > + u32 val;
> > > > +
> > > > + if (!(divider->flags & CLK_DIVIDER_ZERO_GATE))
> > > > + return 0;
> > >
> > > This is not good. We will always jump to these functions on
> > > enable/disable for a divider although 99.9% of all dividers that
> > > exist won't need to run this code at all.
> > >
> >
> > I absolutely understand this concern.
> >
> > > Can you please move this logic into your own divider
> > > implementation? The flag can be added to the generic layer if
> > > necessary but I'd prefer to see this logic kept in the driver
> > > that uses it. If we get more than one driver doing the cached
> > > divider thing then we can think about moving it to the more
> > > generic place like here, but for now we should be able to keep
> > > this contained away from the basic types and handled by the
> > > quirky driver that needs it.
> > >
> >
> > If only for above issue, how about invent a clk_divider_gate_ops
> > to separate the users of normal divider and zero gate divider:
> >
> > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > index 4ed516c..b51f3f9 100644
> > --- a/drivers/clk/clk-divider.c
> > +++ b/drivers/clk/clk-divider.c
> > @@ -125,6 +125,9 @@ unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
> >
> > div = _get_div(table, val, flags, divider->width);
> > if (!div) {
> > + if (flags & CLK_DIVIDER_ZERO_GATE)
> > + return 0;
> > +
> > WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO),
> > "%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set\n",
> > clk_hw_get_name(hw));
> > @@ -148,6 +151,23 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
> > divider->flags);
> > }
> >
> > +static unsigned long clk_divider_gate_recalc_rate(struct clk_hw *hw,
> > + unsigned long parent_rate)
> > +{
> > + struct clk_divider *divider = to_clk_divider(hw);
> > + unsigned int val;
> > +
> > + if (!clk_hw_is_enabled(hw)) {
> > + val = divider->cached_val;
> > + } else {
> > + val = clk_readl(divider->reg) >> divider->shift;
> > + val &= div_mask(divider->width);
> > + }
> > +
> > + return divider_recalc_rate(hw, parent_rate, val, divider->table,
> > + divider->flags);
> > +}
> > +
> > static bool _is_valid_table_div(const struct clk_div_table *table,
> > unsigned int div)
> > {
> > @@ -416,6 +436,89 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
> > return 0;
> > }
> >
> > +static int clk_divider_gate_set_rate(struct clk_hw *hw, unsigned long rate,
> > + unsigned long parent_rate)
> > +{
> > + struct clk_divider *divider = to_clk_divider(hw);
> > + int value;
> > +
> > + if (!clk_hw_is_enabled(hw)) {
> > + value = divider_get_val(rate, parent_rate, divider->table,
> > + divider->width, divider->flags);
> > + if (value < 0)
> > + return value;
> > +
> > + divider->cached_val = value;
> > +
> > + return 0;
> > + }
> > +
> > + return clk_divider_set_rate(hw, rate, parent_rate);
> > +}
> > +
> > +static int clk_divider_enable(struct clk_hw *hw)
> > +{
> > + struct clk_divider *divider = to_clk_divider(hw);
> > + unsigned long uninitialized_var(flags);
> > + u32 val;
> > +
> > + if (!divider->cached_val) {
> > + pr_err("%s: no valid preset rate\n", clk_hw_get_name(hw));
> > + return -EINVAL;
> > + }
> > +
> > + if (divider->lock)
> > + spin_lock_irqsave(divider->lock, flags);
> > + else
> > + __acquire(divider->lock);
> > +
> > + /* restore div val */
> > + val = clk_readl(divider->reg);
> > + val |= divider->cached_val << divider->shift;
> > + clk_writel(val, divider->reg);
> > +
> > + if (divider->lock)
> > + spin_unlock_irqrestore(divider->lock, flags);
> > + else
> > + __release(divider->lock);
> > +
> > + return 0;
> > +}
> > +
> > +static void clk_divider_disable(struct clk_hw *hw)
> > +{
> > + struct clk_divider *divider = to_clk_divider(hw);
> > + unsigned long uninitialized_var(flags);
> > + u32 val;
> > +
> > + if (divider->lock)
> > + spin_lock_irqsave(divider->lock, flags);
> > + else
> > + __acquire(divider->lock);
> > +
> > + /* store the current div val */
> > + val = clk_readl(divider->reg) >> divider->shift;
> > + val &= div_mask(divider->width);
> > + divider->cached_val = val;
> > + clk_writel(0, divider->reg);
> > +
> > + if (divider->lock)
> > + spin_unlock_irqrestore(divider->lock, flags);
> > + else
> > + __release(divider->lock);
> > +}
> > +
> > +static int clk_divider_is_enabled(struct clk_hw *hw)
> > +{
> > + struct clk_divider *divider = to_clk_divider(hw);
> > + u32 val;
> > +
> > + val = clk_readl(divider->reg) >> divider->shift;
> > + val &= div_mask(divider->width);
> > +
> > + return val ? 1 : 0;
> > +}
> > +
> > const struct clk_ops clk_divider_ops = {
> > .recalc_rate = clk_divider_recalc_rate,
> > .round_rate = clk_divider_round_rate,
> > @@ -423,6 +526,16 @@ const struct clk_ops clk_divider_ops = {
> > };
> > EXPORT_SYMBOL_GPL(clk_divider_ops);
> >
> > +const struct clk_ops clk_divider_gate_ops = {
> > + .recalc_rate = clk_divider_gate_recalc_rate,
> > + .round_rate = clk_divider_round_rate,
> > + .set_rate = clk_divider_gate_set_rate,
> > + .enable = clk_divider_enable,
> > + .disable = clk_divider_disable,
> > + .is_enabled = clk_divider_is_enabled,
> > +};
> > +EXPORT_SYMBOL_GPL(clk_divider_gate_ops);
> > +
> > const struct clk_ops clk_divider_ro_ops = {
> > .recalc_rate = clk_divider_recalc_rate,
> > .round_rate = clk_divider_round_rate,
> > @@ -438,6 +551,7 @@ static struct clk_hw *_register_divider(struct device *dev, const char *name,
> > struct clk_divider *div;
> > struct clk_hw *hw;
> > struct clk_init_data init;
> > + u32 val;
> > int ret;
> >
> > if (clk_divider_flags & CLK_DIVIDER_HIWORD_MASK) {
> > @@ -455,6 +569,8 @@ static struct clk_hw *_register_divider(struct device *dev, const char *name,
> > init.name = name;
> > if (clk_divider_flags & CLK_DIVIDER_READ_ONLY)
> > init.ops = &clk_divider_ro_ops;
> > + else if (clk_divider_flags & CLK_DIVIDER_ZERO_GATE)
> > + init.ops = &clk_divider_gate_ops;
> > else
> > init.ops = &clk_divider_ops;
> > init.flags = flags | CLK_IS_BASIC;
> > @@ -470,6 +586,12 @@ static struct clk_hw *_register_divider(struct device *dev, const char *name,
> > div->hw.init = &init;
> > div->table = table;
> >
> > + if (div->flags & CLK_DIVIDER_ZERO_GATE) {
> > + val = clk_readl(reg) >> shift;
> > + val &= div_mask(width);
> > + div->cached_val = val;
> > + }
> > +
> > /* register the clock */
> > hw = &div->hw;
> > ret = clk_hw_register(dev, hw);
> > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> > index 7c925e6..5f33b73 100644
> > --- a/include/linux/clk-provider.h
> > +++ b/include/linux/clk-provider.h
> > @@ -358,6 +358,7 @@ struct clk_div_table {
> > * @shift: shift to the divider bit field
> > * @width: width of the divider bit field
> > * @table: array of value/divider pairs, last entry should have div = 0
> > + * @cached_val: cached div hw value used for CLK_DIVIDER_ZERO_GATE
> > * @lock: register lock
> > *
> > * Clock with an adjustable divider affecting its output frequency. Implements
> > @@ -386,6 +387,12 @@ struct clk_div_table {
> > * CLK_DIVIDER_MAX_AT_ZERO - For dividers which are like CLK_DIVIDER_ONE_BASED
> > * except when the value read from the register is zero, the divisor is
> > * 2^width of the field.
> > + * CLK_DIVIDER_ZERO_GATE - For dividers which are like CLK_DIVIDER_ONE_BASED
> > + * when the value read from the register is zero, it means the divisor
> > + * is gated. For this case, the cached_val will be used to store the
> > + * intermediate div for the normal rate operation, like set_rate/get_rate/
> > + * recalc_rate. When the divider is ungated, the driver will actually
> > + * program the hardware to have the requested divider value.
> > */
> > struct clk_divider {
> > struct clk_hw hw;
> > @@ -394,6 +401,7 @@ struct clk_divider {
> > u8 width;
> > u8 flags;
> > const struct clk_div_table *table;
> > + u32 cached_val;
> > spinlock_t *lock;
> > };
> >
> > @@ -406,6 +414,7 @@ struct clk_divider {
> > #define CLK_DIVIDER_ROUND_CLOSEST BIT(4)
> > #define CLK_DIVIDER_READ_ONLY BIT(5)
> > #define CLK_DIVIDER_MAX_AT_ZERO BIT(6)
> > +#define CLK_DIVIDER_ZERO_GATE BIT(7)
> >
> > extern const struct clk_ops clk_divider_ops;
> > extern const struct clk_ops clk_divider_ro_ops;
> >
> > Anyway, if you still think it's not proper, i can put it in platform
> > driver as you wish, just in the cost of a few duplicated codes.
>
> Ok. Keeping it in the basic types but split into different ops
> path looks good.
>
> >
> > > > +
> > > > + if (!divider->cached_val) {
> > > > + pr_err("%s: no valid preset rate\n", clk_hw_get_name(hw));
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + if (divider->lock)
> > > > + spin_lock_irqsave(divider->lock, flags);
> > > > + else
> > > > + __acquire(divider->lock);
> > > > +
> > > > + /* restore div val */
> > > > + val = clk_readl(divider->reg);
> > > > + val |= divider->cached_val << divider->shift;
> > > > + clk_writel(val, divider->reg);
> > > > +
> > > > + if (divider->lock)
> > > > + spin_unlock_irqrestore(divider->lock, flags);
> > > > + else
> > > > + __release(divider->lock);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static void clk_divider_disable(struct clk_hw *hw)
> > > > +{
> > > > + struct clk_divider *divider = to_clk_divider(hw);
> > > > + unsigned long flags = 0;
> > > > + u32 val;
> > > > +
> > > > + if (!(divider->flags & CLK_DIVIDER_ZERO_GATE))
> > > > + return;
> > > > +
> > > > + if (divider->lock)
> > > > + spin_lock_irqsave(divider->lock, flags);
> > > > + else
> > > > + __acquire(divider->lock);
> > > > +
> > > > + /* store the current div val */
> > > > + val = clk_readl(divider->reg) >> divider->shift;
> > > > + val &= div_mask(divider->width);
> > > > + divider->cached_val = val;
> > > > + clk_writel(0, divider->reg);
> > > > +
> > > > + if (divider->lock)
> > > > + spin_unlock_irqrestore(divider->lock, flags);
> > > > + else
> > > > + __release(divider->lock);
> > > > +}
> > > > +
> > > > +static int clk_divider_is_enabled(struct clk_hw *hw)
> > > > +{
> > > > + struct clk_divider *divider = to_clk_divider(hw);
> > > > + u32 val;
> > > > +
> > > > + if (!(divider->flags & CLK_DIVIDER_ZERO_GATE))
> > > > + return __clk_get_enable_count(hw->clk);
> > >
> > > The plan was to delete this API once OMAP stopped using it.
> > > clk_hw_is_enabled() doesn't work?
> >
> > No, it did not work before because clk_hw_is_enabled will result
> > in the dead loop by calling .is_enabled() callback again.
> >
> > That's why __clk_get_enable_count is used instead.
> >
> > However, with above new patch method, this issue was gone.
>
> Great!
>
> >
> > >
> > > > +
> > > > + val = clk_readl(divider->reg) >> divider->shift;
> > > > + val &= div_mask(divider->width);
> > > > +
> > > > + return val ? 1 : 0;
> > > > +}
> > > > +
> > > > const struct clk_ops clk_divider_ops = {
> > > > .recalc_rate = clk_divider_recalc_rate,
> > > > .round_rate = clk_divider_round_rate,
> > > > .set_rate = clk_divider_set_rate,
> > > > + .enable = clk_divider_enable,
> > > > + .disable = clk_divider_disable,
> > > > + .is_enabled = clk_divider_is_enabled,
> > > > };
> > > > EXPORT_SYMBOL_GPL(clk_divider_ops);
> > > >
> > > > @@ -436,6 +525,7 @@ static struct clk_hw *_register_divider(struct device *dev, const char *name,
> > > > struct clk_divider *div;
> > > > struct clk_hw *hw;
> > > > struct clk_init_data init;
> > > > + u32 val;
> > > > int ret;
> > > >
> > > > if (clk_divider_flags & CLK_DIVIDER_HIWORD_MASK) {
> > > > @@ -468,6 +558,12 @@ static struct clk_hw *_register_divider(struct device *dev, const char *name,
> > > > div->hw.init = &init;
> > > > div->table = table;
> > > >
> > > > + if (div->flags & CLK_DIVIDER_ZERO_GATE) {
> > > > + val = clk_readl(reg) >> shift;
> > > > + val &= div_mask(width);
> > > > + div->cached_val = val;
> > > > + }
> > >
> > > What if it isn't on? Setting cached_val to 0 is ok?
> > >
> >
> > If it isn't on, then the cache_val should be 0.
> > And recalc_rate will catch this case and return 0 as there's
> > no proper pre-set rate.
> >
>
> Ok.
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply related
* [clk:clk-next 130/133] drivers/clk/mediatek/clk-mtk.h:44:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
From: kbuild test robot @ 2017-12-22 4:42 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
head: 813bf3417374b0f382d4bfbd712c54794d943c57
commit: 74cb0d6dde85fef197aca3b2976487e99934309d [130/133] clk: mediatek: fixup test-building of MediaTek clock drivers
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 74cb0d6dde85fef197aca3b2976487e99934309d
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All warnings (new ones prefixed by >>):
In file included from drivers/clk/mediatek/reset.c:22:0:
>> drivers/clk/mediatek/clk-mtk.h:44:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
int num, struct clk_onecell_data *clk_data);
^~~~~~~~~~~~~~~~
drivers/clk/mediatek/clk-mtk.h:63:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
int num, struct clk_onecell_data *clk_data);
^~~~~~~~~~~~~~~~
drivers/clk/mediatek/clk-mtk.h:145:10: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
struct clk_onecell_data *clk_data);
^~~~~~~~~~~~~~~~
drivers/clk/mediatek/clk-mtk.h:164:11: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
struct clk_onecell_data *clk_data);
^~~~~~~~~~~~~~~~
drivers/clk/mediatek/clk-mtk.h:190:12: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
struct clk_onecell_data *clk_data);
^~~~~~~~~~~~~~~~
vim +44 drivers/clk/mediatek/clk-mtk.h
4fa04380 James Liao 2015-07-10 35
4fa04380 James Liao 2015-07-10 36 #define FIXED_CLK(_id, _name, _parent, _rate) { \
4fa04380 James Liao 2015-07-10 37 .id = _id, \
4fa04380 James Liao 2015-07-10 38 .name = _name, \
4fa04380 James Liao 2015-07-10 39 .parent = _parent, \
4fa04380 James Liao 2015-07-10 40 .rate = _rate, \
4fa04380 James Liao 2015-07-10 41 }
4fa04380 James Liao 2015-07-10 42
4fa04380 James Liao 2015-07-10 43 void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
4fa04380 James Liao 2015-07-10 @44 int num, struct clk_onecell_data *clk_data);
4fa04380 James Liao 2015-07-10 45
:::::: The code at line 44 was first introduced by commit
:::::: 4fa043806a2cdbf86503068276ab9bba91a726f6 clk: mediatek: Add fixed clocks support for Mediatek SoC.
:::::: TO: James Liao <jamesjj.liao@mediatek.com>
:::::: CC: James Liao <jamesjj.liao@mediatek.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 52902 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171222/f74eaa2e/attachment-0001.gz>
^ permalink raw reply
* [PATCH] arm64: defconfig: Select schedutil as default cpufreq governor
From: Viresh Kumar @ 2017-12-22 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1FinyyFr840-JkTcX2mL8QTtcnvYi3hpczs3Yx_ga-ww@mail.gmail.com>
On 21-12-17, 16:32, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 5:29 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > On 15-12-17, 15:50, Catalin Marinas wrote:
> >> On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote:
> >> > Currently performance governor is getting selected by default, which is
> >> > surely not a very good choice as its pretty much power hungry.
> >> >
> >> > Select schedutil instead.
> >>
> >> And why do we care about this in defconfig? People deploying their own
> >> kernels in mobile may opt for this config, others may prefer the default
> >> governor.
> >>
> >> Also it seems it would be the only architecture make this governor the
> >> default, so NAK.
> >
> > This is a bit dangerous configuration IMHO.
> >
> > Other architectures have some *real* governor selected by default, like Ondemand
> > or Conservative. Running your CPUs at max (because of the default performance
> > governor in arm64 config) may end up burning some SoCs accidentally just because
> > their thermal stuff doesn't kick in to cool SoC down properly.
> >
> > So, we should have one of ondemand, conservative and schedutil selected by
> > default for arm64 as well IMO and schedutil is the one which every one is
> > falling back to now a days, even android.
>
> Maybe it's time to change the global 'default
> CPU_FREQ_DEFAULT_GOV_PERFORMANCE' instead to avoid having to
> do this for each architecture separately?
>
> I think the general idea of using schedutil or ondemand instead of performance
> makes sense, but it doesn't feel right to have to do this for every
> single defconfig
> that doesn't select a default.
+Rafael to see what his views are on this.
--
viresh
^ permalink raw reply
* [PATCH V7 11/12] arm64: dts: add syscon for whale2 platform
From: Chunyan Zhang @ 2017-12-22 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221230316.GY7997@codeaurora.org>
On 22 December 2017 at 07:03, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 12/07, Chunyan Zhang wrote:
>> Some clocks on SC9860 are in the same address area with syscon
>> devices, the proper syscon node will be quoted under the
>> definitions of those clocks in DT.
>>
>> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
>> ---
>
> These last two can go via arm-soc?
Thanks Stephen!
Hi Arnd, Olof
Could you please take the patch 11, 12 through arm-soc?
Thanks,
Chunyan
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V7 12/12] arm64: dts: add clocks for SC9860
From: Chunyan Zhang @ 2017-12-22 5:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207125715.16160-13-chunyan.zhang@spreadtrum.com>
+ arm at kernel.org
On 7 December 2017 at 20:57, Chunyan Zhang <chunyan.zhang@spreadtrum.com> wrote:
> Some clocks on SC9860 are in the same address area with syscon devices,
> those are what have a property of 'sprd,syscon' which would refer to
> syscon devices, others would have a reg property indicated their address
> ranges.
>
> Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
> ---
> arch/arm64/boot/dts/sprd/sc9860.dtsi | 115 +++++++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/sprd/whale2.dtsi | 18 +++++-
> 2 files changed, 131 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> index 7b7d8ce..bf03da4 100644
> --- a/arch/arm64/boot/dts/sprd/sc9860.dtsi
> +++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
> @@ -7,6 +7,7 @@
> */
>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/sprd,sc9860-clk.h>
> #include "whale2.dtsi"
>
> / {
> @@ -183,6 +184,120 @@
> };
>
> soc {
> + pmu_gate: pmu-gate {
> + compatible = "sprd,sc9860-pmu-gate";
> + sprd,syscon = <&pmu_regs>; /* 0x402b0000 */
> + clocks = <&ext_26m>;
> + #clock-cells = <1>;
> + };
> +
> + pll: pll {
> + compatible = "sprd,sc9860-pll";
> + sprd,syscon = <&ana_regs>; /* 0x40400000 */
> + clocks = <&pmu_gate 0>;
> + #clock-cells = <1>;
> + };
> +
> + ap_clk: clock-controller at 20000000 {
> + compatible = "sprd,sc9860-ap-clk";
> + reg = <0 0x20000000 0 0x400>;
> + clocks = <&ext_26m>, <&pll 0>,
> + <&pmu_gate 0>;
> + #clock-cells = <1>;
> + };
> +
> + aon_prediv: aon-prediv {
> + compatible = "sprd,sc9860-aon-prediv";
> + reg = <0 0x402d0000 0 0x400>;
> + clocks = <&ext_26m>, <&pll 0>,
> + <&pmu_gate 0>;
> + #clock-cells = <1>;
> + };
> +
> + apahb_gate: apahb-gate {
> + compatible = "sprd,sc9860-apahb-gate";
> + sprd,syscon = <&ap_ahb_regs>; /* 0x20210000 */
> + clocks = <&aon_prediv 0>;
> + #clock-cells = <1>;
> + };
> +
> + aon_gate: aon-gate {
> + compatible = "sprd,sc9860-aon-gate";
> + sprd,syscon = <&aon_regs>; /* 0x402e0000 */
> + clocks = <&aon_prediv 0>;
> + #clock-cells = <1>;
> + };
> +
> + aonsecure_clk: clock-controller at 40880000 {
> + compatible = "sprd,sc9860-aonsecure-clk";
> + reg = <0 0x40880000 0 0x400>;
> + clocks = <&ext_26m>, <&pll 0>;
> + #clock-cells = <1>;
> + };
> +
> + agcp_gate: agcp-gate {
> + compatible = "sprd,sc9860-agcp-gate";
> + sprd,syscon = <&agcp_regs>; /* 0x415e0000 */
> + clocks = <&aon_prediv 0>;
> + #clock-cells = <1>;
> + };
> +
> + gpu_clk: clock-controller at 60200000 {
> + compatible = "sprd,sc9860-gpu-clk";
> + reg = <0 0x60200000 0 0x400>;
> + clocks = <&pll 0>;
> + #clock-cells = <1>;
> + };
> +
> + vsp_clk: clock-controller at 61000000 {
> + compatible = "sprd,sc9860-vsp-clk";
> + reg = <0 0x61000000 0 0x400>;
> + clocks = <&ext_26m>, <&pll 0>;
> + #clock-cells = <1>;
> + };
> +
> + vsp_gate: vsp-gate {
> + compatible = "sprd,sc9860-vsp-gate";
> + sprd,syscon = <&vsp_regs>; /* 0x61100000 */
> + clocks = <&vsp_clk 0>;
> + #clock-cells = <1>;
> + };
> +
> + cam_clk: clock-controller at 62000000 {
> + compatible = "sprd,sc9860-cam-clk";
> + reg = <0 0x62000000 0 0x4000>;
> + clocks = <&ext_26m>, <&pll 0>;
> + #clock-cells = <1>;
> + };
> +
> + cam_gate: cam-gate {
> + compatible = "sprd,sc9860-cam-gate";
> + sprd,syscon = <&cam_regs>; /* 0x62100000 */
> + clocks = <&cam_clk 0>;
> + #clock-cells = <1>;
> + };
> +
> + disp_clk: clock-controller at 63000000 {
> + compatible = "sprd,sc9860-disp-clk";
> + reg = <0 0x63000000 0 0x400>;
> + clocks = <&ext_26m>, <&pll 0>;
> + #clock-cells = <1>;
> + };
> +
> + disp_gate: disp-gate {
> + compatible = "sprd,sc9860-disp-gate";
> + sprd,syscon = <&disp_regs>; /* 0x63100000 */
> + clocks = <&disp_clk 0>;
> + #clock-cells = <1>;
> + };
> +
> + apapb_gate: apapb-gate {
> + compatible = "sprd,sc9860-apapb-gate";
> + sprd,syscon = <&ap_apb_regs>; /* 0x70b00000 */
> + clocks = <&ap_clk 0>;
> + #clock-cells = <1>;
> + };
> +
> funnel at 10001000 { /* SoC Funnel */
> compatible = "arm,coresight-funnel", "arm,primecell";
> reg = <0 0x10001000 0 0x1000>;
> diff --git a/arch/arm64/boot/dts/sprd/whale2.dtsi b/arch/arm64/boot/dts/sprd/whale2.dtsi
> index 6ea3a75..328009c 100644
> --- a/arch/arm64/boot/dts/sprd/whale2.dtsi
> +++ b/arch/arm64/boot/dts/sprd/whale2.dtsi
> @@ -106,10 +106,24 @@
> };
> };
>
> - ext_26m: ext-26m {
> + ext_32k: ext_32k {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + clock-output-names = "ext-32k";
> + };
> +
> + ext_26m: ext_26m {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <26000000>;
> - clock-output-names = "ext_26m";
> + clock-output-names = "ext-26m";
> + };
> +
> + ext_rco_100m: ext_rco_100m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <100000000>;
> + clock-output-names = "ext-rco-100m";
> };
> };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v4 0/2] PCI: mediatek: Fixups for the IRQ handle routine and MT7622's class code
From: honghui.zhang at mediatek.com @ 2017-12-22 5:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Honghui Zhang <honghui.zhang@mediatek.com>
Two fixups for mediatek's host bridge:
The first patch fixup the IRQ handle routine to avoid IRQ reentry which
may exist for both MT2712 and MT7622.
The second patch fixup class type for MT7622.
Change since v3:
- Setup the class type and vendor ID at the beginning of startup instead
of in a quirk.
- Add mediatek's vendor ID, it could be found in:
https://pcisig.com/membership/member-companies?combine=&page=4
Change since v2:
- Move the initialize of the iterate before the loop to fix an
INTx IRQ issue in the first patch
Change since v1:
- Add the second patch.
- Make the first patch's commit message more standard.
Honghui Zhang (2):
PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
PCI: mediatek: Set up class type and vendor ID for MT7622
drivers/pci/host/pcie-mediatek.c | 23 ++++++++++++++++++-----
include/linux/pci_ids.h | 3 +++
2 files changed, 21 insertions(+), 5 deletions(-)
--
2.6.4
^ permalink raw reply
* [PATCH v4 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: honghui.zhang at mediatek.com @ 2017-12-22 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513921178-16148-1-git-send-email-honghui.zhang@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
There maybe a same IRQ reentry scenario after IRQ received in current
IRQ handle flow:
EP device PCIe host driver EP driver
1. issue an IRQ
2. received IRQ
3. clear IRQ status
4. dispatch IRQ
5. clear IRQ source
The IRQ status was not successfully cleared at step 2 since the IRQ
source was not cleared yet. So the PCIe host driver may receive the
same IRQ after step 5. Then there's an IRQ reentry occurred.
Even worse, if the reentry IRQ was not an IRQ that EP driver expected,
it may not handle the IRQ. Then we may run into the infinite loop from
step 2 to step 4.
Clear the IRQ status after IRQ have been dispatched to avoid the IRQ
reentry.
This patch also fix another INTx IRQ issue by initialize the iterate
before the loop. If an INTx IRQ re-occurred while we are dispatching
the INTx IRQ, then iterate may start from PCI_NUM_INTX + INTX_SHIFT
instead of INTX_SHIFT for the second time entering the
for_each_set_bit_from() loop.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index db93efd..fc29a9a 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -601,15 +601,16 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
struct mtk_pcie_port *port = (struct mtk_pcie_port *)data;
unsigned long status;
u32 virq;
- u32 bit = INTX_SHIFT;
+ u32 bit;
while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
+ bit = INTX_SHIFT;
for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
- /* Clear the INTx */
- writel(1 << bit, port->base + PCIE_INT_STATUS);
virq = irq_find_mapping(port->irq_domain,
bit - INTX_SHIFT);
generic_handle_irq(virq);
+ /* Clear the INTx */
+ writel(1 << bit, port->base + PCIE_INT_STATUS);
}
}
@@ -619,10 +620,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
- /* Clear the MSI */
- writel(1 << bit, port->base + PCIE_IMSI_STATUS);
virq = irq_find_mapping(port->msi_domain, bit);
generic_handle_irq(virq);
+ /* Clear the MSI */
+ writel(1 << bit, port->base + PCIE_IMSI_STATUS);
}
}
/* Clear MSI interrupt status */
--
2.6.4
^ permalink raw reply related
* [PATCH v4 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622
From: honghui.zhang at mediatek.com @ 2017-12-22 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513921178-16148-1-git-send-email-honghui.zhang@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
The hardware default value of IDs and class type is not correct,
fix that by setup the correct values before start up.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
include/linux/pci_ids.h | 3 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index fc29a9a..0ef33e4 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -74,6 +74,10 @@
/* PCIe V2 per-port registers */
#define PCIE_MSI_VECTOR 0x0c0
+
+#define PCIE_CONF_ID 0x100
+#define PCIE_CONF_CLASS 0x104
+
#define PCIE_INT_MASK 0x420
#define INTX_MASK GENMASK(19, 16)
#define INTX_SHIFT 16
@@ -393,6 +397,14 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
val |= PCIE_CSR_LTSSM_EN(port->slot) |
PCIE_CSR_ASPM_L1_EN(port->slot);
writel(val, pcie->base + PCIE_SYS_CFG_V2);
+
+ /* Set up vendor ID and device ID for MT7622*/
+ val = PCI_VENDOR_ID_MEDIATEK | (PCI_DEVICE_ID_MT7622 << 16);
+ writel(val, port->base + PCIE_CONF_ID);
+
+ /* Set up class code for MT7622 */
+ val = PCI_CLASS_BRIDGE_PCI << 16;
+ writel(val, port->base + PCIE_CONF_CLASS);
}
/* Assert all reset signals */
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ab20dc5..000c5df 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2113,6 +2113,9 @@
#define PCI_VENDOR_ID_MYRICOM 0x14c1
+#define PCI_VENDOR_ID_MEDIATEK 0x14c3
+#define PCI_DEVICE_ID_MT7622 0x5396
+
#define PCI_VENDOR_ID_TITAN 0x14D2
#define PCI_DEVICE_ID_TITAN_010L 0x8001
#define PCI_DEVICE_ID_TITAN_100L 0x8010
--
2.6.4
^ permalink raw reply related
* [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2
From: sean.wang at mediatek.com @ 2017-12-22 6:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
On bpi-r2 board, totally there're four uarts which we usually called
uart[0-3] helpful to extend slow I/O devices. Among those ones, uart2 has
dedicated pin slot which is used to conolse log. uart[0-1] appear at the
40-pins connector and uart3 has no pinout, but just has test points (TP47
for TX and TP48 for RX, respectively) nearby uart2. Also, some missing
pinctrl is being complemented for those devices.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 7bf5aa2..64bf5db 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -409,6 +409,20 @@
<MT7623_PIN_82_UTXD1_FUNC_UTXD1>;
};
};
+
+ uart2_pins_a: uart at 2 {
+ pins_dat {
+ pinmux = <MT7623_PIN_14_GPIO14_FUNC_URXD2>,
+ <MT7623_PIN_15_GPIO15_FUNC_UTXD2>;
+ };
+ };
+
+ uart3_pins_a: uart at 3 {
+ pins_dat {
+ pinmux = <MT7623_PIN_242_URTS2_FUNC_URTS2>,
+ <MT7623_PIN_243_UCTS2_FUNC_UTXD3>;
+ };
+ };
};
&pwm {
@@ -454,16 +468,24 @@
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
- status = "disabled";
+ status = "okay";
};
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_a>;
- status = "disabled";
+ status = "okay";
};
&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins_a>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins_a>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2] IPI performance benchmark
From: Yury Norov @ 2017-12-22 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANRm+Cx6Lm8r2Oej+-EX=Dz76bvu81rVKD-RU0=LRSNs3dw7mw@mail.gmail.com>
On Wed, Dec 20, 2017 at 02:44:25PM +0800, Wanpeng Li wrote:
> Hi Yury,
> 2017-12-19 16:50 GMT+08:00 Yury Norov <ynorov@caviumnetworks.com>:
> > This benchmark sends many IPIs in different modes and measures
> > time for IPI delivery (first column), and total time, ie including
> > time to acknowledge the receive by sender (second column).
> >
> > The scenarios are:
> > Dry-run: do everything except actually sending IPI. Useful
> > to estimate system overhead.
> > Self-IPI: Send IPI to self CPU.
> > Normal IPI: Send IPI to some other CPU.
> > Broadcast IPI: Send broadcast IPI to all online CPUs.
> > Broadcast lock: Send broadcast IPI to all online CPUs and force them
> > acquire/release spinlock.
> >
> > The raw output looks like this:
> > [ 155.363374] Dry-run: 0, 2999696 ns
> > [ 155.429162] Self-IPI: 30385328, 65589392 ns
> > [ 156.060821] Normal IPI: 566914128, 631453008 ns
> > [ 158.384427] Broadcast IPI: 0, 2323368720 ns
> > [ 160.831850] Broadcast lock: 0, 2447000544 ns
> >
> > For virtualized guests, sending and reveiving IPIs causes guest exit.
> > I used this test to measure performance impact on KVM subsystem of
> > Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
> >
> > Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> > to host dry-run time, broadcast lock results omitted. Smaller - better.
>
> Could you test on a x86 box? I see a lot of calltraces on my haswell
> client host, there is no calltrace in the guest, however, I can still
> observe "Invalid parameters" warning when insmod this module. In
> addition, the x86 box fails to boot when ipi_benchmark is buildin.
EINVAL is returned intentionally to let user run test again without
annoying rmmod.
^ permalink raw reply
* [clk:clk-next 130/133] drivers/clk/mediatek/clk-mtk.h:44:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
From: Sean Wang @ 2017-12-22 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201712221239.y5YaQIlV%fengguang.wu@intel.com>
thanks, i will try to have a fixup
Sean
On Fri, 2017-12-22 at 12:42 +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> head: 813bf3417374b0f382d4bfbd712c54794d943c57
> commit: 74cb0d6dde85fef197aca3b2976487e99934309d [130/133] clk: mediatek: fixup test-building of MediaTek clock drivers
> config: sparc64-allmodconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 74cb0d6dde85fef197aca3b2976487e99934309d
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64
>
> All warnings (new ones prefixed by >>):
>
> In file included from drivers/clk/mediatek/reset.c:22:0:
> >> drivers/clk/mediatek/clk-mtk.h:44:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> int num, struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
> drivers/clk/mediatek/clk-mtk.h:63:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> int num, struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
> drivers/clk/mediatek/clk-mtk.h:145:10: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
> drivers/clk/mediatek/clk-mtk.h:164:11: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
> drivers/clk/mediatek/clk-mtk.h:190:12: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
>
> vim +44 drivers/clk/mediatek/clk-mtk.h
>
> 4fa04380 James Liao 2015-07-10 35
> 4fa04380 James Liao 2015-07-10 36 #define FIXED_CLK(_id, _name, _parent, _rate) { \
> 4fa04380 James Liao 2015-07-10 37 .id = _id, \
> 4fa04380 James Liao 2015-07-10 38 .name = _name, \
> 4fa04380 James Liao 2015-07-10 39 .parent = _parent, \
> 4fa04380 James Liao 2015-07-10 40 .rate = _rate, \
> 4fa04380 James Liao 2015-07-10 41 }
> 4fa04380 James Liao 2015-07-10 42
> 4fa04380 James Liao 2015-07-10 43 void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
> 4fa04380 James Liao 2015-07-10 @44 int num, struct clk_onecell_data *clk_data);
> 4fa04380 James Liao 2015-07-10 45
>
> :::::: The code at line 44 was first introduced by commit
> :::::: 4fa043806a2cdbf86503068276ab9bba91a726f6 clk: mediatek: Add fixed clocks support for Mediatek SoC.
>
> :::::: TO: James Liao <jamesjj.liao@mediatek.com>
> :::::: CC: James Liao <jamesjj.liao@mediatek.com>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2
From: Sean Wang @ 2017-12-22 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b4e84a68da76c1ca538150a730777ff530c1db5a.1513922513.git.sean.wang@mediatek.com>
On Fri, 2017-12-22 at 14:06 +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> On bpi-r2 board, totally there're four uarts which we usually called
> uart[0-3] helpful to extend slow I/O devices. Among those ones, uart2 has
> dedicated pin slot which is used to conolse log. uart[0-1] appear at the
Hi, Matthias
Could you help to fix the misspelling "conolse" with "console" when you
merge the patch ?
Sean
> 40-pins connector and uart3 has no pinout, but just has test points (TP47
> for TX and TP48 for RX, respectively) nearby uart2. Also, some missing
> pinctrl is being complemented for those devices.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index 7bf5aa2..64bf5db 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -409,6 +409,20 @@
> <MT7623_PIN_82_UTXD1_FUNC_UTXD1>;
> };
> };
> +
> + uart2_pins_a: uart at 2 {
> + pins_dat {
> + pinmux = <MT7623_PIN_14_GPIO14_FUNC_URXD2>,
> + <MT7623_PIN_15_GPIO15_FUNC_UTXD2>;
> + };
> + };
> +
> + uart3_pins_a: uart at 3 {
> + pins_dat {
> + pinmux = <MT7623_PIN_242_URTS2_FUNC_URTS2>,
> + <MT7623_PIN_243_UCTS2_FUNC_UTXD3>;
> + };
> + };
> };
>
> &pwm {
> @@ -454,16 +468,24 @@
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pins_a>;
> - status = "disabled";
> + status = "okay";
> };
>
> &uart1 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart1_pins_a>;
> - status = "disabled";
> + status = "okay";
> };
>
> &uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins_a>;
> + status = "okay";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins_a>;
> status = "okay";
> };
>
^ permalink raw reply
* [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
From: Herbert Xu @ 2017-12-22 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129084121.9385-2-clabbe.montjoie@gmail.com>
On Wed, Nov 29, 2017 at 09:41:18AM +0100, Corentin Labbe wrote:
> The crypto engine could actually only enqueue hash and ablkcipher request.
> This patch permit it to enqueue any type of crypto_async_request.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This is going the wrong way. We do not want to expose any of the
base types such as crypto_alg, crypto_async_request to end-users
and that includes drivers. Only core API code should touch these
base types.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Arnd Bergmann @ 2017-12-22 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYhtrVKk36cza_RUysjp_ZYvT5D0nCGdG3K9=SGsdJNLA@mail.gmail.com>
On Thu, Dec 21, 2017 at 11:30 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Dec 21, 2017 at 4:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Dec 20, 2017 at 1:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> Alter the DaVinci GPIO recovery fetch to use descriptors
>>> all the way down into the board files.
>>>
>>> Cc: arm at kernel.org
>>> Cc: Kevin Hilman <khilman@kernel.org>
>>> Cc: Keerthy <j-keerthy@ti.com>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Acked-by: Sekhar Nori <nsekhar@ti.com>
>>> Tested-by: Sekhar Nori <nsekhar@ti.com>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> ChangeLog v1->v2:
>>> - Change gpiochip name from gpio_davinci.0 to gpio_davinci, simply.
>>
>> This seems to clash with "i2c: davinci: Add PM Runtime Support", please
>> rebase on top of v4.15-rc and resend.
>
> Strange, where do you see this problem?
>
> I just applied the patch on top of Wolfram's for-next
> branch and it worked like a charm. It has the PM Runtime patch
> underneath and all.
I looked at v4.15-rc4, but haven't analyzed further.
Arnd
^ permalink raw reply
* [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Arnd Bergmann @ 2017-12-22 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbCWZB1ZkrdGe0s0GfNVWEYY+NThy4ce-+SBtU-s=WNbQ@mail.gmail.com>
On Thu, Dec 21, 2017 at 11:08 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Dec 21, 2017 at 10:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> We get a dtc warning about the CLCD interrupt being invalid:
>>
>> arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd at 10008000
>>
>> According to the datasheet I found and the old board file, this
>> line is not connected, so I'm removing the respective properties here.
>>
>> Link: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0411d/index.html
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> There is some confusion here. There is CLCD "Color LCD"
> which is just a code name for PrimeCell PL111 and there is the actual
> character LCD which is a hardware thin to talk to a character LCD with
> some characters on.
>
>> diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
>
> So this DTS is for the ARM 11 MP core tile which is described in
> DUI0318F. It doesn't even list an IRQ for the character LCD.
>
>> &charlcd {
>> - interrupt-parent = <&intc>;
>> - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
>
> This was probably me thinking to go back and fill in the right
> IRQ and forgetting to actually do it. Sorry :(
>
>> + /* CLCD is not connected here */
>
> Call it character LCD instead to avoid confusion please.
>
>> + /delete-property/interrupt-parent;
>> + /delete-property/interrupts;
>
> I don't understand this delete-property business (first time
> I see it, but the top level
> DTSI (arm-realview-eb.dtsi) does not define any interrupt
> so can't you just delete this whole &charlcd?
>
> I do think the reference design has a character LCD, and I
> do think it has an interrupt, it's just undocumented so
> someone with this board would have to test it manually
> to figure out which line it is. Whoever uses this design
> will get to it if ever.
Sounds good, can you prepare a patch for this?
We are getting very close to zero warnings now with the
latest arm-soc/for-next branch:
arch/arm/boot/dts/arm-realview-eb-11mp.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-11mp-bbrevd.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-a9mp.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-11mp-bbrevd-ctrevb.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-a9mp-bbrevd.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property):
Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property):
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property):
Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property):
Missing interrupt-parent for /soc/ohci at ec300000
Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property):
Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property):
Property 'cs-gpios', cell 6 is not a phandle reference in
/ahb/apb/spi at e0100000
arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Missing
property '#gpio-cells' in node /interrupt-controller at ec801000 or bad
phandle (referred from /ahb/apb/spi at e0100000:cs-gpios[6])
arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Property
'dmas', cell 4 is not a phandle reference in /ahb/apb/serial at b4100000
arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Missing
property '#dma-cells' in node /interrupt-controller at ec801000 or bad
phandle (referred from /ahb/apb/serial at b4100000:dmas[4])
arch/arm/boot/dts/stih407-b2120.dtb: Warning (gpios_property):
hdmi,hpd-gpio property size (8) too small for cell size 2 in
/soc/sti-display-subsystem/sti-hdmi at 8d04000
arch/arm/boot/dts/stih410-b2120.dtb: Warning (gpios_property):
hdmi,hpd-gpio property size (8) too small for cell size 2 in
/soc/sti-display-subsystem/sti-hdmi at 8d04000
arch/arm/boot/dts/stih410-b2260.dtb: Warning (gpios_property):
hdmi,hpd-gpio property size (8) too small for cell size 2 in
/soc/sti-display-subsystem/sti-hdmi at 8d04000
arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property):
power-gpio property size (12) too small for cell size 3 in
/ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property):
reset-gpio property size (12) too small for cell size 3 in
/ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property):
power-gpio property size (12) too small for cell size 3 in
/ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property):
reset-gpio property size (12) too small for cell size 3 in
/ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning
(interrupts_property): Missing interrupt-parent for
/amba/clcd at 10120000
arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning
(interrupts_property): Missing interrupt-parent for
/amba/clcd at 10120000
arch/arm/boot/dts/spear600-evb.dtb: Warning (interrupts_property):
Missing interrupt-parent for /ahb/apb/rtc at fc900000
Can you also look at the nomadik warnings and possibly some of the others
if you have time? Unfortunately I'm heading out for my Christmas vacation
and can't do any others of these any more.
Arnd
^ permalink raw reply
* [PATCH v2 4/6] ARM: dts: imx6: Add support for phxBOARD-Mira i.MX 6 DualLight/Solo RDK
From: Stefan Riedmüller @ 2017-12-22 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220151008.4aa4b5a5@karo-electronics.de>
Hi,
On 20.12.2017 15:10, Lothar Wa?mann wrote:
> Hi,
>
> On Wed, 20 Dec 2017 14:29:25 +0100 Stefan Riedmueller wrote:
>> From: Christian Hemp <c.hemp@phytec.de>
>>
>> Add support for the PHYTEC phyBOARD-Mira Low-Cost Rapid Development Kit
>> with i.MX 6DualLight/Solo with NAND.
>>
> s/phxBOARD/phyBOARD/ in the subject line.
>
>
> Lothar Wa?mann
I'll fix it, thanks.
Stefan
^ permalink raw reply
* [PATCH] crypto: stm32 - Use standard CONFIG name
From: Fabien DESSENNE @ 2017-12-22 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513793972-11173-1-git-send-email-clabbe@baylibre.com>
Hi Corentin
Thank you for the patch.
On 20/12/17 19:19, Corentin Labbe wrote:
> All hardware crypto devices have their CONFIG names using the following
> convention:
> CRYPTO_DEV_name_algo
>
> This patch apply this conventions on STM32 CONFIG names.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
> ---
> drivers/crypto/stm32/Kconfig | 6 +++---
> drivers/crypto/stm32/Makefile | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/stm32/Kconfig b/drivers/crypto/stm32/Kconfig
> index 61ef00b6bf45..63aa78c0b12b 100644
> --- a/drivers/crypto/stm32/Kconfig
> +++ b/drivers/crypto/stm32/Kconfig
> @@ -1,4 +1,4 @@
> -config CRC_DEV_STM32
> +config CRYPTO_DEV_STM32_CRC
> tristate "Support for STM32 crc accelerators"
> depends on ARCH_STM32
> select CRYPTO_HASH
> @@ -6,7 +6,7 @@ config CRC_DEV_STM32
> This enables support for the CRC32 hw accelerator which can be found
> on STMicroelectronics STM32 SOC.
>
> -config HASH_DEV_STM32
> +config CRYPTO_DEV_STM32_HASH
> tristate "Support for STM32 hash accelerators"
> depends on ARCH_STM32
> depends on HAS_DMA
> @@ -19,7 +19,7 @@ config HASH_DEV_STM32
> This enables support for the HASH hw accelerator which can be found
> on STMicroelectronics STM32 SOC.
>
> -config CRYP_DEV_STM32
> +config CRYPTO_DEV_STM32_CRYP
> tristate "Support for STM32 cryp accelerators"
> depends on ARCH_STM32
> select CRYPTO_HASH
> diff --git a/drivers/crypto/stm32/Makefile b/drivers/crypto/stm32/Makefile
> index 2c19fc155bfd..53d1bb94b221 100644
> --- a/drivers/crypto/stm32/Makefile
> +++ b/drivers/crypto/stm32/Makefile
> @@ -1,3 +1,3 @@
> -obj-$(CONFIG_CRC_DEV_STM32) += stm32_crc32.o
> -obj-$(CONFIG_HASH_DEV_STM32) += stm32-hash.o
> -obj-$(CONFIG_CRYP_DEV_STM32) += stm32-cryp.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_CRC) += stm32_crc32.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_HASH) += stm32-hash.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_CRYP) += stm32-cryp.o
^ permalink raw reply
* [PATCH 0/2] arm64: dts: renesas: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39b80de4-84bd-916e-2ff9-580f7db720f2@mentor.com>
On Thu, Dec 21, 2017 at 04:57:58PM +0200, Vladimir Zapolskiy wrote:
> Hi Simon,
>
> On 12/21/2017 01:28 PM, Simon Horman wrote:
> > On Wed, Dec 20, 2017 at 03:22:10PM +0200, Vladimir Zapolskiy wrote:
> >> The present change is a bug fix for AVB link iteratively up/down.
> >
> > If this is a bug please consider including Fixes tags in the patches.
> >
>
> would you prefer to get v2 with the Fixes tags added or short replies
> to v1 with the requested information?
Either way would be fine. I see you have gone ahead and posted v2,
lets roll with that.
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513869539-18803-2-git-send-email-vladimir_zapolskiy@mentor.com>
On Thu, Dec 21, 2017 at 05:18:58PM +0200, Vladimir Zapolskiy wrote:
> From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
>
> The present change is a bug fix for AVB link iteratively up/down.
>
> Steps to reproduce:
> - start AVB TX stream (Using aplay via MSE),
> - disconnect+reconnect the eth cable,
> - after a reconnection the eth connection goes iteratively up/down
> without user interaction,
> - this may heal after some seconds or even stay for minutes.
>
> As the documentation specifies, the "renesas,no-ether-link" option
> should be used when a board does not provide a proper AVB_LINK signal.
> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
>
> Choosing to keep or remove the "renesas,no-ether-link" option will
> have impact on the code flow in the following ways:
> - keeping this option enabled may lead to unexpected behavior since
> the RX & TX are enabled/disabled directly from adjust_link function
> without any HW interrogation,
> - removing this option, the RX & TX will only be enabled/disabled after
> HW interrogation. The HW check is made through the LMON pin in PSR
> register which specifies AVB_LINK signal value (0 - at low level;
> 1 - at high level).
>
> In conclusion, the present change is also a safety improvement because
> it removes the "renesas,no-ether-link" option leading to a proper way
> of detecting the link state based on HW interrogation and not on
> software heuristic.
>
> Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
The above shuffles the code around but does not introduce the problem
as far as I can see. Instead I think we should use:
Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
> Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index 4e800e933944..c3095bd575d7 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -255,7 +255,6 @@
> &avb {
> pinctrl-0 = <&avb_pins>;
> pinctrl-names = "default";
> - renesas,no-ether-link;
> phy-handle = <&phy0>;
> status = "okay";
>
> --
> 2.8.1
>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513869539-18803-3-git-send-email-vladimir_zapolskiy@mentor.com>
On Thu, Dec 21, 2017 at 05:18:59PM +0200, Vladimir Zapolskiy wrote:
> From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
>
> The present change is a bug fix for AVB link iteratively up/down.
>
> Steps to reproduce:
> - start AVB TX stream (Using aplay via MSE),
> - disconnect+reconnect the eth cable,
> - after a reconnection the eth connection goes iteratively up/down
> without user interaction,
> - this may heal after some seconds or even stay for minutes.
>
> As the documentation specifies, the "renesas,no-ether-link" option
> should be used when a board does not provide a proper AVB_LINK signal.
> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
>
> Choosing to keep or remove the "renesas,no-ether-link" option will
> have impact on the code flow in the following ways:
> - keeping this option enabled may lead to unexpected behavior since
> the RX & TX are enabled/disabled directly from adjust_link function
> without any HW interrogation,
> - removing this option, the RX & TX will only be enabled/disabled after
> HW interrogation. The HW check is made through the LMON pin in PSR
> register which specifies AVB_LINK signal value (0 - at low level;
> 1 - at high level).
>
> In conclusion, the present change is also a safety improvement because
> it removes the "renesas,no-ether-link" option leading to a proper way
> of detecting the link state based on HW interrogation and not on
> software heuristic.
>
> Fixes: 253ed045a34d ("arm64: dts: renesas: Extract common ULCB board support")
The above shuffles the code around but does not introduce the problem
as far as I can see. Instead I think we should use:
Fixes: 144bf6ccb13f ("arm64: dts: h3ulcb: enable EthernetAVB")
Fixes: 883fae315a6a ("arm64: dts: m3ulcb: enable EthernetAVB")
> Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi b/arch/arm64/boot/dts/renesas/ulcb.dtsi
> index be91016e0b48..3e7a6b94e9f8 100644
> --- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
> @@ -145,7 +145,6 @@
> &avb {
> pinctrl-0 = <&avb_pins>;
> pinctrl-names = "default";
> - renesas,no-ether-link;
> phy-handle = <&phy0>;
> status = "okay";
>
> --
> 2.8.1
>
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-22 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpMUnUKxiALAHW9_PE2RYC8GNWLPGpdJ5ca53g=v3rNkfg@mail.gmail.com>
On Thu, Dec 21, 2017 at 05:36:30PM +0530, Bhupesh Sharma wrote:
> Hello Akashi,
>
> On Thu, Dec 21, 2017 at 4:04 PM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > Bhupesh,
> >
> > Can you test the patch attached below, please?
> >
> > It is intended to retain already-reserved regions (ACPI reclaim memory
> > in this case) in system ram (i.e. memblock.memory) without explicitly
> > exporting them via usable-memory-range.
> > (I still have to figure out what the side-effect of this patch is.)
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > On Thu, Dec 21, 2017 at 01:30:43AM +0530, Bhupesh Sharma wrote:
> >> On Tue, Dec 19, 2017 at 6:39 PM, Ard Biesheuvel
> >> <ard.biesheuvel@linaro.org> wrote:
> >> > On 19 December 2017 at 07:09, AKASHI Takahiro
> >> > <takahiro.akashi@linaro.org> wrote:
> >> >> On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
> >> >>> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
> >> >>> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> >> >>> > > On 13 December 2017 at 12:16, AKASHI Takahiro
> >> >>> > > <takahiro.akashi@linaro.org> wrote:
> >> >>> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> >> >>> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
> >> >>> > > >> <takahiro.akashi@linaro.org> wrote:
> >> >>> > > >> > Bhupesh, Ard,
> >> >>> > > >> >
> >> >>> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> >> >>> > > >> >> Hi Ard, Akashi
> >> >>> > > >> >>
> >> >>> > > >> > (snip)
> >> >>> > > >> >
> >> >>> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> >> >>> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> >> >>> > > >> >> identify its own usable memory and exclude, at its boot time, any
> >> >>> > > >> >> other memory areas that are part of the panicked kernel's memory.
> >> >>> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> >> >>> > > >> >> , for details)
> >> >>> > > >> >
> >> >>> > > >> > Right.
> >> >>> > > >> >
> >> >>> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> >> >>> > > >> >> with the crashkernel memory range:
> >> >>> > > >> >>
> >> >>> > > >> >> /* add linux,usable-memory-range */
> >> >>> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> >> >>> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> >> >>> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> >> >>> > > >> >> address_cells, size_cells);
> >> >>> > > >> >>
> >> >>> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> >> >>> > > >> >> , for details)
> >> >>> > > >> >>
> >> >>> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> >> >>> > > >> >> they are marked as System RAM or as RESERVED. As,
> >> >>> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
> >> >>> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> >> >>> > > >> >>
> >> >>> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
> >> >>> > > >> >> ACPI memory and crashes while trying to access the same:
> >> >>> > > >> >>
> >> >>> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> >> >>> > > >> >> -r`.img --reuse-cmdline -d
> >> >>> > > >> >>
> >> >>> > > >> >> [snip..]
> >> >>> > > >> >>
> >> >>> > > >> >> Reserved memory range
> >> >>> > > >> >> 000000000e800000-000000002e7fffff (0)
> >> >>> > > >> >>
> >> >>> > > >> >> Coredump memory ranges
> >> >>> > > >> >> 0000000000000000-000000000e7fffff (0)
> >> >>> > > >> >> 000000002e800000-000000003961ffff (0)
> >> >>> > > >> >> 0000000039d40000-000000003ed2ffff (0)
> >> >>> > > >> >> 000000003ed60000-000000003fbfffff (0)
> >> >>> > > >> >> 0000001040000000-0000001ffbffffff (0)
> >> >>> > > >> >> 0000002000000000-0000002ffbffffff (0)
> >> >>> > > >> >> 0000009000000000-0000009ffbffffff (0)
> >> >>> > > >> >> 000000a000000000-000000affbffffff (0)
> >> >>> > > >> >>
> >> >>> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> >> >>> > > >> >> memory cap'ing passed to the crash kernel inside
> >> >>> > > >> >> 'arch/arm64/mm/init.c' (see below):
> >> >>> > > >> >>
> >> >>> > > >> >> static void __init fdt_enforce_memory_region(void)
> >> >>> > > >> >> {
> >> >>> > > >> >> struct memblock_region reg = {
> >> >>> > > >> >> .size = 0,
> >> >>> > > >> >> };
> >> >>> > > >> >>
> >> >>> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> >>> > > >> >>
> >> >>> > > >> >> if (reg.size)
> >> >>> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> >> >>> > > >> >> comment this out */
> >> >>> > > >> >> }
> >> >>> > > >> >
> >> >>> > > >> > Please just don't do that. It can cause a fatal damage on
> >> >>> > > >> > memory contents of the *crashed* kernel.
> >> >>> > > >> >
> >> >>> > > >> >> 5). Both the above temporary solutions fix the problem.
> >> >>> > > >> >>
> >> >>> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
> >> >>> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> >> >>> > > >> >> fail.
> >> >>> > > >> >>
> >> >>> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> >> >>> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> >> >>> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> >> >>> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> >> >>> > > >> >> dt node 'linux,usable-memory-range'
> >> >>> > > >> >
> >> >>> > > >> > I still don't understand why we need to carry over the information
> >> >>> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> >> >>> > > >> > such regions are free to be reused by the kernel after some point of
> >> >>> > > >> > initialization. Why does crash dump kernel need to know about them?
> >> >>> > > >> >
> >> >>> > > >>
> >> >>> > > >> Not really. According to the UEFI spec, they can be reclaimed after
> >> >>> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> >> >>> > > >> no longer needs them. Of course, in order to be able to boot a kexec
> >> >>> > > >> kernel, those regions needs to be preserved, which is why they are
> >> >>> > > >> memblock_reserve()'d now.
> >> >>> > > >
> >> >>> > > > For my better understandings, who is actually accessing such regions
> >> >>> > > > during boot time, uefi itself or efistub?
> >> >>> > > >
> >> >>> > >
> >> >>> > > No, only the kernel. This is where the ACPI tables are stored. For
> >> >>> > > instance, on QEMU we have
> >> >>> > >
> >> >>> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> >> >>> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> >> >>> > > 01000013)
> >> >>> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > >
> >> >>> > > covered by
> >> >>> > >
> >> >>> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> >> >>> > > ...
> >> >>> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >> >>> >
> >> >>> > OK. I mistakenly understood those regions could be freed after exiting
> >> >>> > UEFI boot services.
> >> >>> >
> >> >>> > >
> >> >>> > > >> So it seems that kexec does not honour the memblock_reserve() table
> >> >>> > > >> when booting the next kernel.
> >> >>> > > >
> >> >>> > > > not really.
> >> >>> > > >
> >> >>> > > >> > (In other words, can or should we skip some part of ACPI-related init code
> >> >>> > > >> > on crash dump kernel?)
> >> >>> > > >> >
> >> >>> > > >>
> >> >>> > > >> I don't think so. And the change to the handling of ACPI reclaim
> >> >>> > > >> regions only revealed the bug, not created it (given that other
> >> >>> > > >> memblock_reserve regions may be affected as well)
> >> >>> > > >
> >> >>> > > > As whether we should honor such reserved regions over kexec'ing
> >> >>> > > > depends on each one's specific nature, we will have to take care one-by-one.
> >> >>> > > > As a matter of fact, no information about "reserved" memblocks is
> >> >>> > > > exposed to user space (via proc/iomem).
> >> >>> > > >
> >> >>> > >
> >> >>> > > That is why I suggested (somewhere in this thread?) to not expose them
> >> >>> > > as 'System RAM'. Do you think that could solve this?
> >> >>> >
> >> >>> > Memblock-reserv'ing them is necessary to prevent their corruption and
> >> >>> > marking them under another name in /proc/iomem would also be good in order
> >> >>> > not to allocate them as part of crash kernel's memory.
> >> >>> >
> >> >>> > But I'm not still convinced that we should export them in useable-
> >> >>> > memory-range to crash dump kernel. They will be accessed through
> >> >>> > acpi_os_map_memory() and so won't be required to be part of system ram
> >> >>> > (or memblocks), I guess.
> >> >>> > -> Bhupesh?
> >> >>>
> >> >>> I forgot how arm64 kernel retrieve the memory ranges and initialize
> >> >>> them. If no "e820" like interfaces shouldn't kernel reinitialize all
> >> >>> the memory according to the efi memmap? For kdump kernel anything other
> >> >>> than usable memory (which is from the dt node instead) should be
> >> >>> reinitialized according to efi passed info, no?
> >> >>
> >> >> All the regions exported in efi memmap will be added to memblock.memory
> >> >> in (u)efi_init() and then trimmed down to the exact range specified as
> >> >> usable-memory-range by fdt_enforce_memory_region().
> >> >>
> >> >> Now I noticed that the current fdt_enforce_memory_region() may not work well
> >> >> with multiple entries in usable-memory-range.
> >> >>
> >> >
> >> > In any case, the root of the problem is that memory regions lose their
> >> > 'memory' annotation due to the way the memory map is mangled before
> >> > being supplied to the kexec kernel.
> >> >
> >> > Would it be possible to classify all memory that we want to hide from
> >> > the kexec kernel as NOMAP instead? That way, it will not be mapped
> >> > implicitly, but will still be mapped cacheable by acpi_os_ioremap(),
> >> > so this seems to be the most appropriate way to deal with the host
> >> > kernel's memory contents.
> >>
> >> Hmm. wouldn't appending the acpi reclaim regions to
> >> 'linux,usable-memory-range' in the dtb being passed to the crashkernel
> >> be better? Because its indirectly achieving a similar objective
> >> (although may be a subset of all System RAM regions on the primary
> >> kernel's memory).
> >>
> >> I am not aware of the background about the current kexec-tools
> >> implementation where we add only the crashkernel range to the dtb
> >> being passed to the crashkernel.
> >>
> >> Probably Akashi can answer better, as to how we arrived at this design
> >> approach and why we didn't want to expose all System RAM regions (i.e.
> >> ! NOMPAP regions) to the crashkernel.
> >>
> >> I am suspecting that some issues were seen/meet when the System RAM (!
> >> NOMAP regions) were exposed to the crashkernel, and that's why we
> >> finalized on this design approach, but this is something which is just
> >> my guess.
> >>
> >> Regards,
> >> Bhupesh
> >>
> >> >>> >
> >> >>> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> >>> > via a kernel command line parameter, "memmap=".
> >> >>>
> >> >>> memmap= is only used in old kexec-tools, now we are passing them via
> >> >>> e820 table.
> >> >>
> >> >> Thanks. I remember that you have explained it before.
> >> >>
> >> >> -Takahiro AKASHI
> >> >>
> >> >>> [snip]
> >> >>>
> >> >>> Thanks
> >> >>> Dave
> >
> > ===8<==
> > From 74e2451fea83d546feae76160ba7de426913fe03 Mon Sep 17 00:00:00 2001
> > From: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Date: Thu, 21 Dec 2017 19:14:23 +0900
> > Subject: [PATCH] arm64: kdump: mark unusable memory as NOMAP
> >
> > ---
> > arch/arm64/mm/init.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 00e7b900ca41..8175db94257b 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -352,11 +352,17 @@ static void __init fdt_enforce_memory_region(void)
> > struct memblock_region reg = {
> > .size = 0,
> > };
> > + u64 idx;
> > + phys_addr_t start, end;
> >
> > of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >
> > - if (reg.size)
> > - memblock_cap_memory_range(reg.base, reg.size);
> > + if (reg.size) {
> > + for_each_free_mem_range(idx, NUMA_NO_NODE, MEMBLOCK_NONE,
> > + &start, &end, NULL)
> > + memblock_mark_nomap(start, end - start);
> > + memblock_clear_nomap(reg.base, reg.size);
> > + }
> > }
> >
> > void __init arm64_memblock_init(void)
> > --
> > 2.15.1
> >
>
> Thanks for the patch. After applying this on top of
> 4.15.0-rc4-next-20171220, there seems to be a improvement and the
> crashkernel boot no longer hangs while trying to access the acpi
> tables.
>
> However I notice a minor issue. Please see the log below for
> reference, the following message keeps spamming the console but I see
> the crashkernel boot proceed further.:
>
> [ 0.000000] ACPI: NUMA: SRAT: PXM 3 -> MPIDR 0x70303 -> Node 3
> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x3fffffff]
> [ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x2000000000-0x2fffffffff]
> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x1000000000-0x1fffffffff]
> [ 0.000000] ACPI: SRAT: Node 3 PXM 3 [mem 0xa000000000-0xafffffffff]
> [ 0.000000] ACPI: SRAT: Node 2 PXM 2 [mem 0x9000000000-0x9fffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffe200-0x1ffbffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffc400-0x1ffbffe1ff]
> [ 0.000000] NUMA: NODE_DATA(1) on node 0
> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffa600-0x1ffbffc3ff]
> [ 0.000000] NUMA: NODE_DATA(2) on node 0
> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbff8800-0x1ffbffa5ff]
> [ 0.000000] NUMA: NODE_DATA(3) on node 0
> [ 0.000000] [ffff7fe008000000-ffff7fe00800ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008010000-ffff7fe00801ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008020000-ffff7fe00802ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008030000-ffff7fe00803ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008040000-ffff7fe00804ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008050000-ffff7fe00805ffff] potential offnode
> page_structs
>
> [snip..]
> [ 0.000000] [ffff7fe0081f0000-ffff7fe0081fffff] potential offnode
> page_structs
These messages shows that some "struct page" data are allocated on remote
(numa) nodes.
Since on your crash dump kernel, all the usable system memory (starting
0x0e800000) belongs to Node#0, we can't avoid such non-local allocations.
In my best guess, you can ingore them except for some performance penality.
This may be one side-effect.
So does your crash dump kernel now boot successfully?
Thanks,
-Takahiro AKASHI
> This WARNING message seems to come from vmemmap_verify() inside
> 'mm/sparse-vmemmap.c'
>
> Regards,
> Bhupesh
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Maxime Ripard @ 2017-12-22 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221190903.56ebae536acf51401c63802c@bidouilliste.com>
On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote:
>
> Hi Maxime,
>
> On Thu, 21 Dec 2017 16:26:30 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
> > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
> > > <maxime.ripard@free-electrons.com> wrote:
> > > > Hi Kyle,
> > > >
> > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> > > >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> > > >> thermal calibration data, add node to describe it.
> > > >>
> > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> > > >> supported in an external driver for FreeBSD.
> > > >>
> > > >> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
> > > >
> > > > The patch looks fine in itself, but we've had a number of issues with
> > > > the register layout (and access patterns) in the past, so I'd rather
> > > > have something that works in Linux too if possible.
> > >
> > > I have a patch that I think should make it work fine on Linux [1], but
> > > I'm afraid I have little to no capability to test it myself and so I
> > > did not add it as well.
> > >
> > > I do know that the rootkey is offset 0x200 into the given space [2],
> > > as is the case with the H3, and that the readout quirk is not needed.
> > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
> > > H3, but I do know that thermal data can be found at 0x34 and 0x38 in
> > > this space.
> >
> > Then maybe we should leave it aside until someone takes some time on
> > the A83t.
>
> Take some time on the Linux driver and do not apply this patch for
> now you mean ?
Yep.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171222/f9c1e545/attachment.sig>
^ permalink raw reply
* [PATCH v5] arm64: dts: ls1088a: Add USB support
From: yinbo.zhu at nxp.com @ 2017-12-22 8:38 UTC (permalink / raw)
To: linux-arm-kernel
From: yinbo.zhu <yinbo.zhu@nxp.com>
Add USB support on ls1088ardb
Signed-off-by: yinbo zhu <yinbo.zhu@nxp.com>
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
Change in v5:
The usb node was sorted alphabetically in label name.
Remove the point in "yinbo.zhu".
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 0f6fcda..4f17601 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -125,3 +125,11 @@
&sata {
status = "okay";
};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index bd80e9a..caf2bdd 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -394,6 +394,26 @@
status = "disabled";
};
+ usb0: usb3 at 3100000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3100000 0x0 0x10000>;
+ interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ status = "disabled";
+ };
+
+ usb1: usb3 at 3110000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3110000 0x0 0x10000>;
+ interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ status = "disabled";
+ };
+
sata: sata at 3200000 {
compatible = "fsl,ls1088a-ahci";
reg = <0x0 0x3200000 0x0 0x10000>,
--
1.7.1
^ permalink raw reply related
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