* imx-drm: screen flickering
From: Russell King - ARM Linux @ 2014-01-29 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401291553.15040.marex@denx.de>
On Wed, Jan 29, 2014 at 03:53:14PM +0100, Marek Vasut wrote:
> Isn't it the clock polarity being inverted thing again [1]?
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-
> December/215536.html
>
> The easiest way to check this would be to try sig_cfg.clk_pol = 0
> or = 1 and see if it changes anything.
It seems that the pixel clock polarity on iMX hardware is something of
a mess. Some hardware blocks require one polarity, others require a
different polarity.
I think what would make sense is if the various output connectors/
encoders (in other words, imx-hdmi, imx-ldb, etc supplied their
properties concerning the clock polarity to the IPU layer.
We already have something like this in place already: we have the encoder
prepare functions calling into the ipuv3-crtc layer (via imx-drm-core) to
set the interface format, vsync/hsync pins, and clock flags - all of which
get used in the CRTC's mode_set method. Adding the clock polarity into
that path doesn't sound too difficult.
The only issue is that there's a lack of conflict management here - but
that's not a new problem with this approach - it exists with the existing
data.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 0/2] Qualcomm Universal Peripheral (QUP) I2C controller
From: Bjorn Andersson @ 2014-01-29 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390983246.28998.24.camel@iivanov-dev.int.mm-sol.com>
On Wed, Jan 29, 2014 at 12:14 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote:
>
> Hi Bjorn,
>
> On Fri, 2014-01-17 at 15:03 -0800, Bjorn Andersson wrote:
>> Continuing on Ivans i2c-qup series.
>>
>
> Do you plan to send v4 of this driver? I would like to address
> the remaining errors and suggestions and send a new version.
>
Hi Ivan,
Yes I'm planning to send out a new revision of the patch set.
I've incorporated fixes from the review comments here and my colleague
concluded through some testing that block read did not work, so we've
fixed that as well.
What have been holding me from submitting a new patchset is the 3
functions that does polling of state and status updates;
* qup_i2c_poll_state() reads the state register up to 1000 times,
hoping we reach the expected state, will delay 100uS and then continue
with 1000 more retries.
According to the data sheet a state transition is supposed to take
up to 2 bus cycles. Only time I can see that this would take longer
time are all error states, but the data sheet is not very clear
regarding this.
* qup_i2c_wait_idle() reads the status register up to 1000 times,
hoping the fifo gets drained and the bus go idle, if that fails it
sleeps for the time we expect it to take to drain a full fifo and then
loops another 1000 times. This waits for the fifo to have drained and
the bus to go idle. On a read we get to this state if we issue the
write and then hit the error state, so we would reset the entire
block. On write we will only wait for the buffer not to be full before
returning.
* qup_i2c_wait_clock_ready() waits up to 300 bus-clocks for the i2c
bus to go idle or forced low, I don't know why it retries 300 times.
This is called at the end of a write, possibly to wait for the fifo to
drain.
All three loops are in line with how it's been in codeaurora since the
beginning of time, but I at least need to figure out some good names
for those "magic numbers".
Regards,
Bjorn
^ permalink raw reply
* [PATCH 3/3] clk: divider: Optimize clk_divider_bestdiv loop
From: Maxime COQUELIN @ 2014-01-29 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391012648-12481-1-git-send-email-maxime.coquelin@st.com>
Currently, the for-loop used to try all the different dividers to find the
one that best fit tries all the values from 1 to max_div, incrementing by one.
In case of power-of-two, or table based divider, the loop isn't optimal.
Instead of incrementing by one, this patch provides directly the next divider.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
---
drivers/clk/clk-divider.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 1eaa5d8..4aabf4f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -240,6 +240,18 @@ static bool _is_best_div(struct clk_divider *divider,
return now <= rate && now > best;
}
+static int _next_div(struct clk_divider *divider, int div)
+{
+ div++;
+
+ if (divider->flags & CLK_DIVIDER_POWER_OF_TWO)
+ return __roundup_pow_of_two(div);
+ if (divider->table)
+ return _round_up_table(divider->table, div);
+
+ return div;
+}
+
static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate)
{
@@ -267,7 +279,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
*/
maxdiv = min(ULONG_MAX / rate, maxdiv);
- for (i = 1; i <= maxdiv; i++) {
+ for (i = 1; i <= maxdiv; i = _next_div(divider, i)) {
if (!_is_valid_div(divider, i))
continue;
if (rate * i == parent_rate_saved) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] clk: divider: Add round to closest divider
From: Maxime COQUELIN @ 2014-01-29 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391012648-12481-1-git-send-email-maxime.coquelin@st.com>
In some cases, we want to be able to round the divider to the closest one,
instead than rounding up.
This patch adds a new CLK_DIVIDER_ROUND_CLOSEST flag to specify the divider
has to round to closest div, keeping rounding up as de default behaviour.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
---
drivers/clk/clk-divider.c | 69 ++++++++++++++++++++++++++++++++++++++++--
include/linux/clk-provider.h | 3 ++
2 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 2137d58..1eaa5d8 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -43,6 +43,17 @@ static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
return maxdiv;
}
+static unsigned int _get_table_mindiv(const struct clk_div_table *table)
+{
+ unsigned int mindiv = UINT_MAX;
+ const struct clk_div_table *clkt;
+
+ for (clkt = table; clkt->div; clkt++)
+ if (clkt->div < mindiv)
+ mindiv = clkt->div;
+ return mindiv;
+}
+
static unsigned int _get_maxdiv(struct clk_divider *divider)
{
if (divider->flags & CLK_DIVIDER_ONE_BASED)
@@ -162,6 +173,24 @@ static int _round_up_table(const struct clk_div_table *table, int div)
return up;
}
+static int _round_down_table(const struct clk_div_table *table, int div)
+{
+ const struct clk_div_table *clkt;
+ int down = _get_table_mindiv(table);
+
+ for (clkt = table; clkt->div; clkt++) {
+ if (clkt->div == div)
+ return clkt->div;
+ else if (clkt->div > div)
+ continue;
+
+ if ((div - clkt->div) < (div - down))
+ down = clkt->div;
+ }
+
+ return down;
+}
+
static int _div_round_up(struct clk_divider *divider,
unsigned long parent_rate, unsigned long rate)
{
@@ -175,6 +204,42 @@ static int _div_round_up(struct clk_divider *divider,
return div;
}
+static int _div_round_closest(struct clk_divider *divider,
+ unsigned long parent_rate, unsigned long rate)
+{
+ int up, down, div;
+
+ up = down = div = DIV_ROUND_CLOSEST(parent_rate, rate);
+
+ if (divider->flags & CLK_DIVIDER_POWER_OF_TWO) {
+ up = __roundup_pow_of_two(div);
+ down = __rounddown_pow_of_two(div);
+ } else if (divider->table) {
+ up = _round_up_table(divider->table, div);
+ down = _round_down_table(divider->table, div);
+ }
+
+ return (up - div) <= (div - down) ? up : down;
+}
+
+static int _div_round(struct clk_divider *divider, unsigned long parent_rate,
+ unsigned long rate)
+{
+ if (divider->flags & CLK_DIVIDER_ROUND_CLOSEST)
+ return _div_round_closest(divider, parent_rate, rate);
+
+ return _div_round_up(divider, parent_rate, rate);
+}
+
+static bool _is_best_div(struct clk_divider *divider,
+ int rate, int now, int best)
+{
+ if (divider->flags & CLK_DIVIDER_ROUND_CLOSEST)
+ return abs(rate - now) < abs(rate - best);
+
+ return now <= rate && now > best;
+}
+
static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate)
{
@@ -190,7 +255,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
if (!(__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT)) {
parent_rate = *best_parent_rate;
- bestdiv = _div_round_up(divider, parent_rate, rate);
+ bestdiv = _div_round(divider, parent_rate, rate);
bestdiv = bestdiv == 0 ? 1 : bestdiv;
bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;
return bestdiv;
@@ -217,7 +282,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
MULT_ROUND_UP(rate, i));
now = parent_rate / i;
- if (now <= rate && now > best) {
+ if (_is_best_div(divider, rate, now, best)) {
bestdiv = i;
best = now;
*best_parent_rate = parent_rate;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7e59253..595f0ba 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -275,6 +275,8 @@ struct clk_div_table {
* of this register, and mask of divider bits are in higher 16-bit of this
* register. While setting the divider bits, higher 16-bit should also be
* updated to indicate changing divider bits.
+ * CLK_DIVIDER_ROUND_CLOSEST - Makes the best calculated divider to be rounded
+ * to the closest integer instead of the up one.
*/
struct clk_divider {
struct clk_hw hw;
@@ -290,6 +292,7 @@ struct clk_divider {
#define CLK_DIVIDER_POWER_OF_TWO BIT(1)
#define CLK_DIVIDER_ALLOW_ZERO BIT(2)
#define CLK_DIVIDER_HIWORD_MASK BIT(3)
+#define CLK_DIVIDER_ROUND_CLOSEST BIT(4)
extern const struct clk_ops clk_divider_ops;
struct clk *clk_register_divider(struct device *dev, const char *name,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] clk: divider: Fix best div calculation for power-of-two and table dividers
From: Maxime COQUELIN @ 2014-01-29 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391012648-12481-1-git-send-email-maxime.coquelin@st.com>
The divider returned by clk_divider_bestdiv() is likely to be invalid in case
of power-of-two and table dividers when CLK_SET_RATE_PARENT flag isn't set.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
---
drivers/clk/clk-divider.c | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7d..2137d58 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -144,6 +144,37 @@ static bool _is_valid_div(struct clk_divider *divider, unsigned int div)
return true;
}
+static int _round_up_table(const struct clk_div_table *table, int div)
+{
+ const struct clk_div_table *clkt;
+ int up = _get_table_maxdiv(table);
+
+ for (clkt = table; clkt->div; clkt++) {
+ if (clkt->div == div)
+ return clkt->div;
+ else if (clkt->div < div)
+ continue;
+
+ if ((clkt->div - div) < (up - div))
+ up = clkt->div;
+ }
+
+ return up;
+}
+
+static int _div_round_up(struct clk_divider *divider,
+ unsigned long parent_rate, unsigned long rate)
+{
+ int div = DIV_ROUND_UP(parent_rate, rate);
+
+ if (divider->flags & CLK_DIVIDER_POWER_OF_TWO)
+ div = __roundup_pow_of_two(div);
+ if (divider->table)
+ div = _round_up_table(divider->table, div);
+
+ return div;
+}
+
static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate)
{
@@ -159,7 +190,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
if (!(__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT)) {
parent_rate = *best_parent_rate;
- bestdiv = DIV_ROUND_UP(parent_rate, rate);
+ bestdiv = _div_round_up(divider, parent_rate, rate);
bestdiv = bestdiv == 0 ? 1 : bestdiv;
bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;
return bestdiv;
@@ -219,6 +250,10 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
u32 val;
div = parent_rate / rate;
+
+ if (!_is_valid_div(divider, div))
+ return -EINVAL;
+
value = _get_val(divider, div);
if (value > div_mask(divider))
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/3] CCF clock divider changes
From: Maxime COQUELIN @ 2014-01-29 16:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mike,
First patch fixes round_rate for power-of-two and table-based dividers when
the CLK_SET_RATE_PARENT flag isn't set.
Second patch introduces a new flag to give the possibility to round the
divider to the closest one, instead of rounding up by default.
Third patch optimizes the for-loop when CLK_SET_RATE_PARENT is set for
power-of-two and table-based dividers.
The series applies on top of v3.13 tag.
Maxime Coquelin (3):
clk: divider: Fix best div calculation for power-of-two and table
dividers
clk: divider: Add round to closest divider
clk: divider: Optimize clk_divider_bestdiv loop
drivers/clk/clk-divider.c | 118 ++++++++++++++++++++++++++++++++++++++++--
include/linux/clk-provider.h | 3 ++
2 files changed, 118 insertions(+), 3 deletions(-)
--
1.7.9.5
^ permalink raw reply
* imx6 power consumption
From: Fabio Estevam @ 2014-01-29 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1W8XqE-0000Ml-GE@merlin.infradead.org>
On Wed, Jan 29, 2014 at 2:17 PM, Bj?rn Erik Nilsen <ben@datarespons.no> wrote:
>> I successfully managed to cherry-pick a handful of commits from
>> freescale 3.10 and got down to approximately half the consumption.
>> That's already very good news.
>>
>> Looking forward to see these patches upstream. Will you be able upstream
>> them before 3.14 you think?
>
>
> Any updates on this?
Take a look at http://git.linaro.org/people/shawn.guo/linux-2.6.git/shortlog/refs/heads/for-next
.
There are some patches for low power support from Anson.
Regards,
Fabio Estevam
^ permalink raw reply
* imx6 power consumption
From: Bjørn Erik Nilsen @ 2014-01-29 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387440914.4131.4.camel@bnilsen-HP>
Hi guys,
On Thu, 2013-12-19 at 09:15 +0100, Bj?rn Erik Nilsen wrote:
> Hi Anson,
>
> On Thu, 2013-12-19 at 03:28 +0100, Anson.Huang at freescale.com wrote:
> >
> > Best Regards.
> > Anson huang ???
> >
> > Freescale Semiconductor Shanghai
> > ?????????192?A?2?
> > 201203
> > Tel:021-28937058
> >
> >
> > >-----Original Message-----
> > >From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org]
> > >On Behalf Of Shawn Guo
> > >Sent: Wednesday, December 18, 2013 7:33 PM
> > >To: Bj?rn Erik Nilsen
> > >Cc: linux-arm-kernel at lists.infradead.org
> > >Subject: Re: imx6 power consumption
> > >
> > >On Wed, Dec 18, 2013 at 12:12:05PM +0100, Bj?rn Erik Nilsen wrote:
> > >> As far as I can tell, commit e95dddb34c8 "ARM: imx: enable anatop
> > >> suspend/resume" is the common ancestor for mainline and freescale, and
> > >> from there pm-imx6q.c starts to diverge.
> > >>
> > >> I haven not looked at it in great detail yet, but it seems there are
> > >> not too many patches missing in mainline. Any idea why remaining
> > >> patches haven't been upstreamed?
> > >
> > >Probably because no one cares and would spend time to upstream these patches.
> >
> > This root cause is we did NOT put the DSM code in IRAM and free DDR IO in DSM.
> > We have done this in our internal v3.10 kernel, so I will do the upstream soon,
> > Below is the DSM number of i.MX6Q SabreSD we got on v3.10 release:
> >
> > VDDARM_IN(R27) 0mA at 0.97V
> > VDDSOC_IN(R21) 4.2 at 0.97V
> > DDR(R25) 14.8mA at 1.5V
> > VDDHIGH_IN + SNVS(SH17) 0.35mA at 2.98V, 0.9mA
>
>
> I successfully managed to cherry-pick a handful of commits from
> freescale 3.10 and got down to approximately half the consumption.
> That's already very good news.
>
> Looking forward to see these patches upstream. Will you be able upstream
> them before 3.14 you think?
Any updates on this?
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Suravee Suthikulanit @ 2014-01-29 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117110830.GW3471@alberich>
On 1/17/2014 5:08 AM, Andreas Herrmann wrote:
>
> arm-smmu driver uses of_parse_phandle_with_args when parsing DT
> information to determine stream IDs for a master device.
> Thus the number of stream IDs per master device is bound by
> MAX_PHANDLE_ARGS.
>
> To support Calxeda ECX-2000 hardware arm-smmu driver requires a
> slightly higher value for MAX_PHANDLE_ARGS as this hardware has 10
> stream IDs for one master device.
>
> Increasing it to 16 seems a reasonable choice.
>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree at vger.kernel.org
> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
> ---
> include/linux/of.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 276c546..24e1b28 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -67,7 +67,7 @@ struct device_node {
> #endif
> };
>
> -#define MAX_PHANDLE_ARGS 8
> +#define MAX_PHANDLE_ARGS 16
Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't
this be changed to be able to support 128 StreamIDs as well? Although I
am not sure if this would be too big to have on the stack per Rob's
comment in the previous patch set.
Thank you,
Suravee
^ permalink raw reply
* [PATCH] ARM: imx6: Initialize low-power mode early again
From: Philipp Zabel @ 2014-01-29 16:10 UTC (permalink / raw)
To: linux-arm-kernel
Since commit 9e8147bb5ec5d1dda2141da70f96b98985a306cb
"ARM: imx6q: move low-power code out of clock driver"
the kernel fails to boot on i.MX6Q/D if preemption is
enabled (CONFIG_PREEMPT=y). The kernel just hangs
before the console comes up.
The above commit moved the initalization of the low-power
mode setting (enabling clocked WAIT states), which was
introduced in commit 83ae20981ae924c37d02a42c829155fc3851260c
"ARM: imx: correct low-power mode setting", from
imx6q_clks_init to imx6q_pm_init. Now it is called
much later, after all cores are enabled.
This patch moves the low-power mode initialization back
to imx6q_clks_init again (and to imx6sl_clks_init).
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
arch/arm/mach-imx/clk-imx6q.c | 3 +++
arch/arm/mach-imx/clk-imx6sl.c | 3 +++
arch/arm/mach-imx/pm-imx6q.c | 2 --
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index af2e582..4d677f4 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -482,6 +482,9 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
if (IS_ENABLED(CONFIG_PCI_IMX6))
clk_set_parent(clk[lvds1_sel], clk[sata_ref]);
+ /* Set initial power mode */
+ imx6q_set_lpm(WAIT_CLOCKED);
+
np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-gpt");
base = of_iomap(np, 0);
WARN_ON(!base);
diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
index 78f3bd6..6617ac8 100644
--- a/arch/arm/mach-imx/clk-imx6sl.c
+++ b/arch/arm/mach-imx/clk-imx6sl.c
@@ -299,6 +299,9 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
/* Audio-related clocks configuration */
clk_set_parent(clks[IMX6SL_CLK_SPDIF0_SEL], clks[IMX6SL_CLK_PLL3_PFD3]);
+ /* Set initial power mode */
+ imx6q_set_lpm(WAIT_CLOCKED);
+
np = of_find_compatible_node(NULL, NULL, "fsl,imx6sl-gpt");
base = of_iomap(np, 0);
WARN_ON(!base);
diff --git a/arch/arm/mach-imx/pm-imx6q.c b/arch/arm/mach-imx/pm-imx6q.c
index c8fea8f..a9a187d 100644
--- a/arch/arm/mach-imx/pm-imx6q.c
+++ b/arch/arm/mach-imx/pm-imx6q.c
@@ -532,8 +532,6 @@ static void __init imx6_pm_common_init(const struct imx6_pm_socdata
regmap_update_bits(gpr, IOMUXC_GPR1, IMX6Q_GPR1_GINT,
IMX6Q_GPR1_GINT);
- /* Set initial power mode */
- imx6q_set_lpm(WAIT_CLOCKED);
suspend_set_ops(&imx6q_pm_ops);
}
--
1.8.5.3
^ permalink raw reply related
* PCIe trouble on imx6q
From: Kamel BOUHARA @ 2014-01-29 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo6MnY74S=jEemQ9xKDg0xik616MeNE67vROap3orQohGA@mail.gmail.com>
2014-01-29 Bjorn Helgaas <bhelgaas@google.com>:
> [+cc linux-arm, Richard, Shawn (please keep the cc list)]
>
> On Wed, Jan 29, 2014 at 2:28 AM, Kamel BOUHARA <k.bouhara@gmail.com> wrote:
>> ---------- Forwarded message ----------
>> From: Kamel BOUHARA <k.bouhara@gmail.com>
>> Date: 2014-01-29
>> Subject: Re: PCIe trouble on imx6q
>> To: Bjorn Helgaas <bhelgaas@google.com>
>>
>>
>> 2014-01-28 Bjorn Helgaas <bhelgaas@google.com>:
>>> [+cc Richard, Shawn, linux-arm-kernel (all from MAINTAINERS)]
>>>
>>> On Tue, Jan 28, 2014 at 1:02 AM, Kamel BOUHARA <k.bouhara@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> Im getting trouble with kernel 3.13 at boot time, the pcie link failed
>>>> to get up with the following log:
>>>> ------------[ cut here ]------------
>>>> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:159 gpio_to_desc+0x34/0x48()
>>>> invalid GPIO -2
>>>> Modules linked in:
>>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0+ #4
>>>> Backtrace:
>>>> [<8001217c>] (dump_backtrace) from [<80012460>] (show_stack+0x18/0x1c)
>>>> r6:802b9548 r5:00000000 r4:808d3060 r3:00000000
>>>> [<80012448>] (show_stack) from [<806414fc>] (dump_stack+0x84/0x9c)
>>>> [<80641478>] (dump_stack) from [<800289f8>] (warn_slowpath_common+0x70/0x94)
>>>> r5:00000009 r4:bf05bcb0
>>>> [<80028988>] (warn_slowpath_common) from [<80028a54>]
>>>> (warn_slowpath_fmt+0x38/0x40)
>>>> r8:01f00000 r7:00000000 r6:0011cc11 r5:808b68c0 r4:bf24fa30
>>>> [<80028a20>] (warn_slowpath_fmt) from [<802b9548>] (gpio_to_desc+0x34/0x48)
>>>> r3:fffffffe r2:807d23fc
>>>> [<802b9514>] (gpio_to_desc) from [<802d9de0>] (imx6_pcie_host_init+0x174/0x434)
>>>> [<802d9c6c>] (imx6_pcie_host_init) from [<80886dbc>]
>>>> (dw_pcie_host_init+0x348/0x41c)
>>>> r6:00000000 r5:808d52cc r4:00000020 r3:802d9c6c
>>>> [<80886a74>] (dw_pcie_host_init) from [<808871d4>] (imx6_pcie_probe+0x320/0x3dc)
>>>> r10:00000000 r9:000000c4 r8:808d539c r7:bf7e3384 r6:bf24fa30 r5:bf135810
>>>> r4:bf24fa10
>>>> [<80886eb4>] (imx6_pcie_probe) from [<8034b670>] (platform_drv_probe+0x20/0x50)
>>>> r8:808d539c r7:00000000 r6:00000000 r5:808d539c r4:bf135810
>>>> [<8034b650>] (platform_drv_probe) from [<80349c74>]
>>>> (driver_probe_device+0x118/0x234)
>>>> r5:bf135810 r4:80e526b8
>>>> [<80349b5c>] (driver_probe_device) from [<80349e78>] (__driver_attach+0x9c/0xa0)
>>>> r8:80886e90 r7:00000000 r6:bf135844 r5:808d539c r4:bf135810 r3:00000000
>>>> [<80349ddc>] (__driver_attach) from [<8034806c>] (bus_for_each_dev+0x68/0x9c)
>>>> r6:80349ddc r5:808d539c r4:00000000 r3:00000000
>>>> [<80348004>] (bus_for_each_dev) from [<8034972c>] (driver_attach+0x20/0x28)
>>>> r6:808df6a8 r5:bf1f5e00 r4:808d539c
>>>> [<8034970c>] (driver_attach) from [<803493b0>] (bus_add_driver+0x148/0x1f4)
>>>> [<80349268>] (bus_add_driver) from [<8034a4c8>] (driver_register+0x80/0x100)
>>>> r7:8090e640 r6:8090e640 r5:00000005 r4:808d539c
>>>> [<8034a448>] (driver_register) from [<8034b63c>]
>>>> (__platform_driver_register+0x50/0x64)
>>>> r5:00000005 r4:808d5388
>>>> [<8034b5ec>] (__platform_driver_register) from [<8034b6e0>]
>>>> (platform_driver_probe+0x28/0xac)
>>>> [<8034b6b8>] (platform_driver_probe) from [<80886ea8>]
>>>> (imx6_pcie_init+0x18/0x24)
>>>> r5:00000005 r4:808aa104
>>>> [<80886e90>] (imx6_pcie_init) from [<80008978>] (do_one_initcall+0x100/0x164)
>>>> [<80008878>] (do_one_initcall) from [<8085ecc0>]
>>>> (kernel_init_freeable+0x10c/0x1d0)
>>>> r10:8089e060 r9:000000c4 r8:8089e050 r7:8090e640 r6:8090e640 r5:00000005
>>>> r4:808aa104
>>>> [<8085ebb4>] (kernel_init_freeable) from [<8063b67c>] (kernel_init+0x10/0x120)
>>>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8063b66c
>>>> r4:00000000
>>>> [<8063b66c>] (kernel_init) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
>>>> r4:00000000 r3:ffffffff
>>>> ---[ end trace b5e746dfc2398cd6 ]---
>>>> ------------[ cut here ]------------
>>>> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:159 gpio_to_desc+0x34/0x48()
>>>> invalid GPIO -2
>>>> Modules linked in:
>>>> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.13.0+ #4
>>>> Backtrace:
>>>> [<8001217c>] (dump_backtrace) from [<80012460>] (show_stack+0x18/0x1c)
>>>> r6:802b9548 r5:00000000 r4:808d3060 r3:00000000
>>>> [<80012448>] (show_stack) from [<806414fc>] (dump_stack+0x84/0x9c)
>>>> [<80641478>] (dump_stack) from [<800289f8>] (warn_slowpath_common+0x70/0x94)
>>>> r5:00000009 r4:bf05bcb0
>>>> [<80028988>] (warn_slowpath_common) from [<80028a54>]
>>>> (warn_slowpath_fmt+0x38/0x40)
>>>> r8:01f00000 r7:00000000 r6:0011cc11 r5:808b68c0 r4:bf24fa30
>>>> [<80028a20>] (warn_slowpath_fmt) from [<802b9548>] (gpio_to_desc+0x34/0x48)
>>>> r3:fffffffe r2:807d23fc
>>>> [<802b9514>] (gpio_to_desc) from [<802d9df8>] (imx6_pcie_host_init+0x18c/0x434)
>>>> [<802d9c6c>] (imx6_pcie_host_init) from [<80886dbc>]
>>>> (dw_pcie_host_init+0x348/0x41c)
>>>> r6:00000000 r5:808d52cc r4:00000020 r3:802d9c6c
>>>> [<80886a74>] (dw_pcie_host_init) from [<808871d4>] (imx6_pcie_probe+0x320/0x3dc)
>>>> r10:00000000 r9:000000c4 r8:808d539c r7:bf7e3384 r6:bf24fa30 r5:bf135810
>>>> r4:bf24fa10
>>>> [<80886eb4>] (imx6_pcie_probe) from [<8034b670>] (platform_drv_probe+0x20/0x50)
>>>> r8:808d539c r7:00000000 r6:00000000 r5:808d539c r4:bf135810
>>>> [<8034b650>] (platform_drv_probe) from [<80349c74>]
>>>> (driver_probe_device+0x118/0x234)
>>>> r5:bf135810 r4:80e526b8
>>>> [<80349b5c>] (driver_probe_device) from [<80349e78>] (__driver_attach+0x9c/0xa0)
>>>> r8:80886e90 r7:00000000 r6:bf135844 r5:808d539c r4:bf135810 r3:00000000
>>>> [<80349ddc>] (__driver_attach) from [<8034806c>] (bus_for_each_dev+0x68/0x9c)
>>>> r6:80349ddc r5:808d539c r4:00000000 r3:00000000
>>>> [<80348004>] (bus_for_each_dev) from [<8034972c>] (driver_attach+0x20/0x28)
>>>> r6:808df6a8 r5:bf1f5e00 r4:808d539c
>>>> [<8034970c>] (driver_attach) from [<803493b0>] (bus_add_driver+0x148/0x1f4)
>>>> [<80349268>] (bus_add_driver) from [<8034a4c8>] (driver_register+0x80/0x100)
>>>> r7:8090e640 r6:8090e640 r5:00000005 r4:808d539c
>>>> [<8034a448>] (driver_register) from [<8034b63c>]
>>>> (__platform_driver_register+0x50/0x64)
>>>> r5:00000005 r4:808d5388
>>>> [<8034b5ec>] (__platform_driver_register) from [<8034b6e0>]
>>>> (platform_driver_probe+0x28/0xac)
>>>> [<8034b6b8>] (platform_driver_probe) from [<80886ea8>]
>>>> (imx6_pcie_init+0x18/0x24)
>>>> r5:00000005 r4:808aa104
>>>> [<80886e90>] (imx6_pcie_init) from [<80008978>] (do_one_initcall+0x100/0x164)
>>>> [<80008878>] (do_one_initcall) from [<8085ecc0>]
>>>> (kernel_init_freeable+0x10c/0x1d0)
>>>> r10:8089e060 r9:000000c4 r8:8089e050 r7:8090e640 r6:8090e640 r5:00000005
>>>> r4:808aa104
>>>> [<8085ebb4>] (kernel_init_freeable) from [<8063b67c>] (kernel_init+0x10/0x120)
>>>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8063b66c
>>>> r4:00000000
>>>> [<8063b66c>] (kernel_init) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
>>>> r4:00000000 r3:ffffffff
>>>> ---[ end trace b5e746dfc2398cd7 ]---
>>>> imx6q-pcie 1ffc000.pcie: phy link never came up
>>>> PCI host bridge to bus 0000:00
>>>> pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
>>>> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
>>>> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
>>>
>>> Not related to the GPIO/link problem, but something's wrong here --
>>> the host bridge driver should be telling us what bus numbers are
>>> behind the host bridge. Since it didn't, the PCI core had to guess.
>>>
>>>> PCI: bus0: Fast back to back transfers disabled
>>>> PCI: bus1: Fast back to back transfers enabled
>>>> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
>>>> pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
>>>> pci 0000:00:00.0: PCI bridge to [bus 01]
>>>> pci 0000:00:00.0: PCI bridge to [bus 01]
>>>>
>>>> Please, any help is welcome.
>>>> Regards,
>>>> Kamel.B
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> So I suppose, this is not a hardware issue rather a bad configuration ?
>> Maybe the following log from lspci will be helpful ?
>
> It looks like a configuration issue or an imx6q host bridge issue. In
> either case, it looks like something *before* we get to PCIe, so
> something like your DT description of the host bridge is more likely
> to be useful.
>
>> root at phyFLEX-i:~ lspci -vvv
>> 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>> ParErr+ Stepping- SERR+ FastB2B- DisINTx+
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 64 bytes
>> Region 0: Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>> I/O behind bridge: 0000f000-00000fff
>> Memory behind bridge: fff00000-000fffff
>> Prefetchable memory behind bridge: fff00000-000fffff
>> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
>> <TAbort- <MAbort- <SERR- <PERR-
>> [virtual] Expansion ROM at 01100000 [disabled] [size=64K]
>> BridgeCtl: Parity+ SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>> Capabilities: [40] Power Management version 3
>> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>> PME(D0+,D1+,D2-,D3hot+,D3cold+)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [50] MSI: Mask+ 64bit+ Count=1/1 Enable+
>> Address: 0000000090000000 Data: 0000
>> Masking: 00000000 Pending: 00000000
>> Capabilities: [70] Express (v2) Root Port (Slot-), MSI 00
>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
>> <64ns, L1 <1us
>> ExtTag- RBE+ FLReset-
>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
>> Unsupported+
>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
>> AuxPwr+ TransPend-
>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
>> Latency L0 <1us, L1 <8us
>> ClockPM- Surprise- LLActRep+ BwNot-
>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
>> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
>> PMEIntEna+ CRSVisible-
>> RootCap: CRSVisible-
>> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd-
>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
>> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance-
>> SpeedDis-, Selectable De-emphasis: -6dB
>> Transmit Margin: Normal Operating Range,
>> EnterModifiedCompliance- ComplianceSOS-
>> Compliance De-emphasis: -6dB
>> LnkSta2: Current De-emphasis Level: -3.5dB
>> Capabilities: [100] Advanced Error Reporting
>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
>> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>> Capabilities: [140] Virtual Channel <?>
>> Kernel driver in use: pcieport
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ok, actually I didn't get the host bridge set properly for my board,
here is my DT:
/dts-v1/;
#include "imx6q-phytec-pfla02.dtsi"
/ {
model = "Phytec phyFLEX-i.MX6 Quad Carrier-Board";
compatible = "phytec,imx6q-pbab01", "phytec,imx6q-pfla02", "fsl,imx6q";
};
&fec {
status = "okay";
};
&uart4 {
status = "okay";
};
&usdhc2 {
status = "okay";
};
&usdhc3 {
status = "okay";
};
&pcie {
status = "okay";
};
Can you give me a example of host configuration ?
BR, Kamel.B
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Richard Weinberger @ 2014-01-29 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129154622.GB7278@gmail.com>
Am 29.01.2014 16:46, schrieb Andrew Ruder:
> On Wed, Jan 29, 2014 at 08:30:45AM +0100, Richard Weinberger wrote:
>> BTW: Can you please share your .config?
>
> No problem. FYI, this is for a board that is still in development so
> not all my changes have been submitted for inclusion yet. I would be
> happy to share the changes now if necessary but I've attached the --stat
> to show that as far as mtd/ubifs goes, i'm basically running a stock
> v3.12:
Does the issue also happen if you disable preemption?
i.e. CONFIG_PREEMPT_NONE=y
Maybe it is really a race...
Thanks,
//richard
^ permalink raw reply
* [RFC PATCH 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Christoffer Dall @ 2014-01-29 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAhSdy2ny3qhWGMFZcOE1vP1j-iqB9r1Q82fOhUo=NMP1h=JrA@mail.gmail.com>
On Wed, Jan 29, 2014 at 10:22:47AM +0530, Anup Patel wrote:
> On Wed, Jan 29, 2014 at 2:34 AM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Tue, Jan 21, 2014 at 06:31:40PM +0530, Anup Patel wrote:
[...]
> >
> > Which tree does this patch apply to? It looks like you'll get a
> > conflict with:
> > 478a823 arm: KVM: Don't return PSCI_INVAL if waitqueue is inactive
>
> This patchset applies on v3.13 tag of Torvalds tree.
That would not contain anything in kvm/next or kvm-arm-next.
>
> I generally base my patches on latest stable/rc tag of Torvalds tree
> so that I can provide KVM patches to folks interested in trying KVM
> on X-Gene with latest Linux stable/rc.
If you want to make it slightly easier for me or Marc to apply your
patches in general I would recommend basing them off kvm/next or
kvm-arm-next, but it's no big deal.
In this case all you need to consider is already in linus/master.
>
> I will make sure that revised patchset applies on top of
> 478a823 arm: KVM: Don't return PSCI_INVAL if waitqueue is inactive
>
> >
> >> }
> >>
> >> diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
> >> index 0881bf1..ee044a3 100644
> >> --- a/arch/arm/kvm/psci.c
> >> +++ b/arch/arm/kvm/psci.c
> >> @@ -55,13 +55,13 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
> >> }
> >>
> >> if (!vcpu)
> >> - return KVM_PSCI_RET_INVAL;
> >> + return KVM_PSCI_RET_INVALID_PARAMS;
> >>
> >> target_pc = *vcpu_reg(source_vcpu, 2);
> >>
> >> wq = kvm_arch_vcpu_wq(vcpu);
> >> if (!waitqueue_active(wq))
> >> - return KVM_PSCI_RET_INVAL;
> >> + return KVM_PSCI_RET_INVALID_PARAMS;
> >>
> >> kvm_reset_vcpu(vcpu);
> >>
> >> @@ -84,17 +84,49 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
> >> return KVM_PSCI_RET_SUCCESS;
> >> }
> >>
> >> -/**
> >> - * kvm_psci_call - handle PSCI call if r0 value is in range
> >> - * @vcpu: Pointer to the VCPU struct
> >> - *
> >> - * Handle PSCI calls from guests through traps from HVC instructions.
> >> - * The calling convention is similar to SMC calls to the secure world where
> >> - * the function number is placed in r0 and this function returns true if the
> >> - * function number specified in r0 is withing the PSCI range, and false
> >> - * otherwise.
> >> - */
> >> -bool kvm_psci_call(struct kvm_vcpu *vcpu)
> >> +static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
> >> +{
> >> + unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
> >> + unsigned long val;
> >> +
> >> + switch (psci_fn) {
> >> + case KVM_PSCI_0_2_FN_PSCI_VERSION:
> >> + /*
> >> + * Bits[31:16] = Major Version = 0
> >> + * Bits[15:0] = Minor Version = 2
> >> + */
> >> + val = 2;
> >> + break;
> >> + case KVM_PSCI_0_2_FN_CPU_OFF:
> >> + kvm_psci_vcpu_off(vcpu);
> >> + val = KVM_PSCI_RET_SUCCESS;
> >> + break;
> >> + case KVM_PSCI_0_2_FN_CPU_ON:
> >> + case KVM_PSCI_0_2_FN64_CPU_ON:
> >> + val = kvm_psci_vcpu_on(vcpu);
> >> + break;
> >> + case KVM_PSCI_0_2_FN_CPU_SUSPEND:
> >> + case KVM_PSCI_0_2_FN_AFFINITY_INFO:
> >> + case KVM_PSCI_0_2_FN_MIGRATE:
> >> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
> >> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
> >> + case KVM_PSCI_0_2_FN_SYSTEM_OFF:
> >> + case KVM_PSCI_0_2_FN_SYSTEM_RESET:
> >> + case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
> >> + case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
> >> + case KVM_PSCI_0_2_FN64_MIGRATE:
> >> + case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
> >> + val = KVM_PSCI_RET_NOT_SUPPORTED;
> >> + break;
> >> + default:
> >> + return false;
> >> + }
> >> +
> >> + *vcpu_reg(vcpu, 0) = val;
> >> + return true;
> >> +}
> >> +
> >> +static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
> >> {
> >> unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
> >> unsigned long val;
> >> @@ -109,9 +141,8 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
> >> break;
> >> case KVM_PSCI_FN_CPU_SUSPEND:
> >> case KVM_PSCI_FN_MIGRATE:
> >> - val = KVM_PSCI_RET_NI;
> >> + val = KVM_PSCI_RET_NOT_SUPPORTED;
> >> break;
> >> -
> >> default:
> >> return false;
> >> }
> >> @@ -119,3 +150,21 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
> >> *vcpu_reg(vcpu, 0) = val;
> >> return true;
> >> }
> >> +
> >> +/**
> >> + * kvm_psci_call - handle PSCI call if r0 value is in range
> >> + * @vcpu: Pointer to the VCPU struct
> >> + *
> >> + * Handle PSCI calls from guests through traps from HVC instructions.
> >> + * The calling convention is similar to SMC calls to the secure world where
> >> + * the function number is placed in r0 and this function returns true if the
> >> + * function number specified in r0 is withing the PSCI range, and false
> >> + * otherwise.
> >> + */
> >> +bool kvm_psci_call(struct kvm_vcpu *vcpu)
> >> +{
> >> + if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
> >> + return kvm_psci_0_2_call(vcpu);
> >> +
> >> + return kvm_psci_0_1_call(vcpu);
> >> +}
> >
> > Why don't we just try one after the other? Do they conflict in some
> > way?
>
> Atleast the functions IDs are totally different in v0.2 and v0.1
>
> Also, in v0.2 we have separate function IDs for 32bit and 64bit
> VCPU calling same PSCI function.
>
So we could just do:
{
ret = kvm_psci_0_2_call(vcpu);
if (ret)
return ret;
ret = kvm_psci_0_1_call(vcpu);
if (ret)
return ret;
return false;
}
and be rid of the vcpu feature, or? I thought this was Marc's point in
the last KVM/ARM call?
> >
> > I assume PSCI calls are never going to be in the critical path and calls
> > into PSCI are pretty much expected to be slow as a dog anyhow, so if we
> > could avoid the extra churn in user space code and potential user
> > confusion (providing PSCI 0.2 kernel but too old user space tool for
> > example), I think that would be preferred.
>
> Yes, PSCI calls will not be in critical path except few functions such as
> PSCI CPU_SUSPEND and CPU_ON.
>
> For example,
> On real HW, people are very much interested in time taken to resume a
> HW CPU from suspended state because this affects responsiveness of
> a system.
>
In which case time taken to wake up from suspended state in a VM will
for sure not be dominated by an extra call to a psci function id
checking function.
Thanks,
-Christoffer
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Andrew Ruder @ 2014-01-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E8AE25.8080502@nod.at>
On Wed, Jan 29, 2014 at 08:30:45AM +0100, Richard Weinberger wrote:
> BTW: Can you please share your .config?
No problem. FYI, this is for a board that is still in development so
not all my changes have been submitted for inclusion yet. I would be
happy to share the changes now if necessary but I've attached the --stat
to show that as far as mtd/ubifs goes, i'm basically running a stock
v3.12:
% git diff --stat v3.12..HEAD
Documentation/devicetree/bindings/usb/pxa-usb.txt | 5 +-
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/pxa270-elecsys_z2.dts | 330 ++++++
arch/arm/boot/dts/pxa270-elecsys_z4.dts | 434 +++++++
arch/arm/boot/dts/pxa27x.dtsi | 13 +-
arch/arm/boot/dts/pxa2xx.dtsi | 14 +-
arch/arm/boot/dts/pxa3xx.dtsi | 4 +
arch/arm/configs/elecsys_z2_defconfig | 3089 +++++++++++++++
arch/arm/mach-pxa/Kconfig | 18 +
arch/arm/mach-pxa/Makefile | 3 +-
arch/arm/mach-pxa/generic.c | 3 +-
arch/arm/mach-pxa/include/mach/hardware.h | 2 +-
arch/arm/mach-pxa/irq.c | 8 +-
arch/arm/mach-pxa/{pxa-dt.c => pxa27x-dt.c} | 44 +-
arch/arm/mach-pxa/pxa27x.c | 25 +-
arch/arm/mach-pxa/{pxa-dt.c => pxa3xx-dt.c} | 11 +-
arch/arm/mach-pxa/sleep.S | 2 +-
drivers/irqchip/Kconfig | 8 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-zeus.c | 192 +++
drivers/mmc/host/pxamci.c | 33 +-
drivers/net/ethernet/8390/ne.c | 4 +-
drivers/net/ethernet/davicom/dm9000.c | 68 +-
drivers/tty/serial/pxa.c | 6 +-
24 files changed, 4222 insertions(+), 97 deletions(-)
And the .config I'm using is attached.
Thanks,
Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.gz
Type: application/x-gunzip
Size: 14745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140129/c86abdca/attachment.bin>
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Christoffer Dall @ 2014-01-29 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E8DA5D.9030101@arm.com>
On Wed, Jan 29, 2014 at 10:39:25AM +0000, Marc Zyngier wrote:
> On 28/01/14 21:24, Christoffer Dall wrote:
> > The stage-2 memory attributes are distinct from the Hyp memory
> > attributes and the Stage-1 memory attributes. We were using the stage-1
> > memory attributes for stage-2 mappings causing device mappings to be
> > mapped as normal memory. Add the S2 equivalent defines for memory
> > attributes and fix the comments explaining the defines while at it.
> >
> > Add a prot_pte_s2 field to the mem_type struct and fill out the field
> > for device mappings accordingly.
> >
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
Thanks, Catalin, Russell, any comments?
-Christoffer
^ permalink raw reply
* [BUG] reproducable ubifs reboot assert and corruption
From: Andrew Ruder @ 2014-01-29 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E8AB0F.2090905@nod.at>
On Wed, Jan 29, 2014 at 08:17:35AM +0100, Richard Weinberger wrote:
> So you can trigger this by running fsstress on /mnt and then call
> mount -o remount,ro /mnt?
That's all it takes. I actually run the remount until it succeeds,
obviously with fsstress going in the background there is a pretty narrow
window where it needs to sneak in with a write between the start of the
sync_filesystem and before the remount check for writers (-EBUSY).
> Can you also trigger it on nandsim or mtdram?
Haven't tried, but I can. I just don't really have that great of
a development environment for doing this on a desktop machine.
> I did a quick test on my testbed using mtdram and was unable to trigger it.
> But I fear my box is too fast.
I think there is definitely a speed component of my 416 MHz PXA 270 that
makes this pretty easy to hit. What if you did something like (changing
the ubiattach and mount lines obviously)?
I'll see if I can do this in a qemu, but it might take me a while to get
that setup.
- Andy
^ permalink raw reply
* [PATCH v4 1/1] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Ivan Khoronzhuk @ 2014-01-29 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120184418.GI8919@ld-irv-0074>
Hi Sekhar,
Do you want me to correct it?
On 01/20/2014 08:44 PM, Brian Norris wrote:
> Hi Sekhar,
>
> Sorry, I do have one complaint about this patch.
>
> On Fri, Jan 10, 2014 at 03:06:04PM +0530, Sekhar Nori wrote:
>> --- a/arch/arm/mach-davinci/aemif.c
>> +++ b/arch/arm/mach-davinci/aemif.c
>> @@ -130,4 +136,82 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
>>
>> return 0;
>> }
>> -EXPORT_SYMBOL(davinci_aemif_setup_timing);
>> +
>> +/**
>> + * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
>> + * @pdev - link to platform device to setup settings for
>> + *
>> + * This function does not use any locking while programming the AEMIF
>> + * because it is expected that there is only one user of a given
>> + * chip-select.
>> + *
>> + * Returns 0 on success, else negative errno.
>> + */
>> +int davinci_aemif_setup(struct platform_device *pdev)
>> +{
>> + struct davinci_nand_pdata *pdata = dev_get_platdata(&pdev->dev);
>> + uint32_t val;
>> + unsigned long clkrate;
>> + struct resource *res;
>> + void __iomem *base;
>> + struct clk *clk;
>> + int ret = 0;
>> +
>> + clk = clk_get(&pdev->dev, "aemif");
>> + if (IS_ERR(clk)) {
>> + ret = PTR_ERR(clk);
>> + dev_dbg(&pdev->dev, "unable to get AEMIF clock, err %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = clk_prepare_enable(clk);
>> + if (ret < 0) {
>> + dev_dbg(&pdev->dev, "unable to enable AEMIF clock, err %d\n",
>> + ret);
>> + return ret;
> coccinelle gives a warning for this:
>
> arch/arm/mach-davinci/aemif.c:171:2-8: ERROR: missing clk_put; clk_get on line 160 and execution via conditional on line 168 [coccinelle]
>
> You need a clk_put() on the error path for clk_prepare_enable. For
> instance, you can add a label below and replace this 'return ret' with
> 'goto err_put'.
>
>> + }
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> + if (!res) {
>> + dev_err(&pdev->dev, "cannot get IORESOURCE_MEM\n");
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + base = ioremap(res->start, resource_size(res));
>> + if (!base) {
>> + dev_err(&pdev->dev, "ioremap failed for resource %pR\n", res);
>> + ret = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + /*
>> + * Setup Async configuration register in case we did not boot
>> + * from NAND and so bootloader did not bother to set it up.
>> + */
>> + val = davinci_aemif_readl(base, A1CR_OFFSET + pdev->id * 4);
>> + /*
>> + * Extended Wait is not valid and Select Strobe mode is not
>> + * used
>> + */
>> + val &= ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
>> + if (pdata->options & NAND_BUSWIDTH_16)
>> + val |= 0x1;
>> +
>> + davinci_aemif_writel(base, A1CR_OFFSET + pdev->id * 4, val);
>> +
>> + clkrate = clk_get_rate(clk);
>> +
>> + if (pdata->timing)
>> + ret = davinci_aemif_setup_timing(pdata->timing, base, pdev->id,
>> + clkrate);
>> +
>> + if (ret < 0)
>> + dev_dbg(&pdev->dev, "NAND timing values setup fail\n");
>> +
>> + iounmap(base);
>> +err:
>> + clk_disable_unprepare(clk);
> Then the label could be here:
>
> err_put:
>
>> + clk_put(clk);
>> + return ret;
>> +}
> Brian
^ permalink raw reply
* [PATCH v5 17/23] drm/i2c: tda998x: set the PLL division factor in range 0..3
From: Joe Perches @ 2014-01-29 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4ba259762605793aee726b5e33dcad6a8bd4777.1390986083.git.moinejf@free.fr>
On Sat, 2014-01-25 at 18:14 +0100, Jean-Francois Moine wrote:
> The predivider division factor of the register PLL_SERIAL_2 is in the
> range 0..3, the value 0 being used for a division by 1.
trivia:
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
[]
> @@ -886,6 +886,11 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> }
>
> div = 148500 / mode->clock;
> + if (div != 0) {
> + div--;
> + if (div > 3)
> + div = 3;
> + }
perhaps
clamp(div, 1, 4)
div--;
^ permalink raw reply
* [PATCH V4 5/5] Documentation: power: reset: Add documentation for generic SYSCON reboot driver
From: Arnd Bergmann @ 2014-01-29 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E2F450.2070100@gmail.com>
On Friday 24 January 2014 15:16:32 Marc C wrote:
>
> > What's wrong with having a system clock unit binding, that the kernel
> > can decompose as appropriate?
>
> From what I understand, the arm-soc maintainers want to reduce (and perhaps even
> eliminate) these board-specific constructs, and try to utilize common driver-code that
> resides in the "driver" folder. I can vouch for the syscon/regmap framework as something
> which would enable the effort.
While your statement is true in general, it doesn't seem to counter
what Mark R said above.
Arnd
^ permalink raw reply
* [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
From: Arnd Bergmann @ 2014-01-29 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128121656.GH15937@n2100.arm.linux.org.uk>
On Tuesday 28 January 2014 12:16:56 Russell King - ARM Linux wrote:
> On Tue, Jan 28, 2014 at 01:08:47PM +0100, Arnd Bergmann wrote:
>
> On balance, I think the virtual channel approach makes client drivers
> more elegant and simpler, and makes the DMA engine API easier to use,
> and gives greater flexibility for future improvements. So, I wouldn't
> miss the slave_id being removed.
Ok, good. There are some dmaengine drivers that actually behave
in hardware like the virtual-channel extension, i.e. they have
one physical channel per request line (qcom_bam_dma seems to be
one of them in fact), so they don't really have a choice.
The way that both the DT and ACPI bindings are structured,
the request ID is always known by the time the channel is
allocated to allow this model, and that means supporting both
approaches in the same master or slave driver is a mess.
Arnd
^ permalink raw reply
* [PATCH v3 0/6] efuse driver for Tegra
From: Paul Gortmaker @ 2014-01-29 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390952176-30402-1-git-send-email-pdeschrijver@nvidia.com>
On Tue, Jan 28, 2014 at 6:36 PM, Peter De Schrijver
<pdeschrijver@nvidia.com> wrote:
> This driver allows userspace to read the raw efuse data. Its userspace
> interface is modelled after the sunxi_sid driver which provides similar
> functionality for some Allwinner SoCs. It has been tested on
> Tegra20 (ventana), Tegra30 (beaverboard) and Tegra114 (dalmore).
>
> Changes since v1:
>
> * Add documentation for sysfs interface
> * Cleanup messages
>
> Changes since v2:
>
> * Incorporate early fuse code
> * Remove module support
> * Make driver always build when Tegra platform is selected
Given the above, you should be able to remove #include <linux/module.h>
and MODULE_DEVICE_TABLE, etc.
Paul.
--
> * Add DT binding document
> * Address comments on v2
>
> TODO:
> * test on Tegra124 (venice2)
>
> Peter De Schrijver (6):
> ARM: tegra: export apb dma readl/writel
> ARM: tegra: Add chipid, revision and fuse init
> misc: fuse: Add efuse driver for Tegra
> ARM: tegra: Add efuse bindings
> misc: enable fuse drivers
> ARM: tegra: remove fuse files from mach-tegra
>
> Documentation/ABI/testing/sysfs-driver-tegra-fuse | 8 +
> .../devicetree/bindings/fuse/fuse-tegra.txt | 32 +++
> arch/arm/boot/dts/tegra114.dtsi | 7 +
> arch/arm/boot/dts/tegra124.dtsi | 7 +
> arch/arm/boot/dts/tegra20.dtsi | 7 +
> arch/arm/boot/dts/tegra30.dtsi | 7 +
> arch/arm/mach-tegra/Makefile | 4 -
> arch/arm/mach-tegra/apbio.c | 51 ++--
> arch/arm/mach-tegra/cpuidle.c | 2 +-
> arch/arm/mach-tegra/flowctrl.c | 2 +-
> arch/arm/mach-tegra/fuse.c | 252 -----------------
> arch/arm/mach-tegra/fuse.h | 79 ------
> arch/arm/mach-tegra/hotplug.c | 2 +-
> arch/arm/mach-tegra/platsmp.c | 2 +-
> arch/arm/mach-tegra/pm.c | 2 +-
> arch/arm/mach-tegra/pmc.c | 2 +-
> arch/arm/mach-tegra/powergate.c | 2 +-
> arch/arm/mach-tegra/reset-handler.S | 2 +-
> arch/arm/mach-tegra/reset.c | 2 +-
> arch/arm/mach-tegra/sleep-tegra30.S | 2 +-
> arch/arm/mach-tegra/tegra.c | 2 +-
> arch/arm/mach-tegra/tegra114_speedo.c | 104 -------
> arch/arm/mach-tegra/tegra20_speedo.c | 109 --------
> arch/arm/mach-tegra/tegra2_emc.c | 2 +-
> arch/arm/mach-tegra/tegra30_speedo.c | 292 -------------------
> drivers/misc/Makefile | 1 +
> drivers/misc/fuse/Makefile | 1 +
> drivers/misc/fuse/tegra/Makefile | 7 +
> drivers/misc/fuse/tegra/fuse-tegra.c | 228 +++++++++++++++
> drivers/misc/fuse/tegra/fuse-tegra20.c | 136 +++++++++
> drivers/misc/fuse/tegra/fuse-tegra30.c | 178 ++++++++++++
> drivers/misc/fuse/tegra/fuse.h | 82 ++++++
> drivers/misc/fuse/tegra/tegra114_speedo.c | 110 ++++++++
> drivers/misc/fuse/tegra/tegra124_speedo.c | 164 +++++++++++
> drivers/misc/fuse/tegra/tegra20_speedo.c | 110 ++++++++
> drivers/misc/fuse/tegra/tegra30_speedo.c | 294 ++++++++++++++++++++
> include/linux/tegra-soc.h | 39 +++
> 37 files changed, 1461 insertions(+), 872 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-driver-tegra-fuse
> create mode 100644 Documentation/devicetree/bindings/fuse/fuse-tegra.txt
> delete mode 100644 arch/arm/mach-tegra/fuse.c
> delete mode 100644 arch/arm/mach-tegra/fuse.h
> delete mode 100644 arch/arm/mach-tegra/tegra114_speedo.c
> delete mode 100644 arch/arm/mach-tegra/tegra20_speedo.c
> delete mode 100644 arch/arm/mach-tegra/tegra30_speedo.c
> create mode 100644 drivers/misc/fuse/Makefile
> create mode 100644 drivers/misc/fuse/tegra/Makefile
> create mode 100644 drivers/misc/fuse/tegra/fuse-tegra.c
> create mode 100644 drivers/misc/fuse/tegra/fuse-tegra20.c
> create mode 100644 drivers/misc/fuse/tegra/fuse-tegra30.c
> create mode 100644 drivers/misc/fuse/tegra/fuse.h
> create mode 100644 drivers/misc/fuse/tegra/tegra114_speedo.c
> create mode 100644 drivers/misc/fuse/tegra/tegra124_speedo.c
> create mode 100644 drivers/misc/fuse/tegra/tegra20_speedo.c
> create mode 100644 drivers/misc/fuse/tegra/tegra30_speedo.c
>
> --
> 1.7.7.rc0.72.g4b5ea.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* imx-drm: screen flickering
From: Marek Vasut @ 2014-01-29 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129111557.GI16215@pengutronix.de>
On Wednesday, January 29, 2014 at 12:15:57 PM, Sascha Hauer wrote:
> Hi Christian,
>
> On Tue, Jan 28, 2014 at 09:11:32AM +0100, Christian Gmeiner wrote:
> > Hi all.
> >
> > From time to time it happens that my LVDS display is flickering (look
> > at scroll bar in the video).
> > https://drive.google.com/file/d/0B_fznDimUHVubWtvVFlMTkdBbUU/edit?usp=sha
> > ring
> >
> > I really want to find the root cause of it, but I do not know where to
> > start. I can trigger this
> > sometimes after xscreensever "blanks" the screen and the screensafer
> > gets disabled
> > via user input.
> >
> > Any hints?
>
> Sorry, no idea. Philipp and me watched the video, but we both haven't
> seen something like this before.
Isn't it the clock polarity being inverted thing again [1]?
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-
December/215536.html
The easiest way to check this would be to try sig_cfg.clk_pol = 0 or = 1 and see
if it changes anything.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Heikki Krogerus @ 2014-01-29 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128163036.GD28546@saruman.home>
Hi,
On Tue, Jan 28, 2014 at 10:30:36AM -0600, Felipe Balbi wrote:
> On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote:
> > On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote:
> > For the controller drivers the PHYs are just a resource like any
> > other. The controller drivers can't have any responsibility of
> > them. They should not care if PHY drivers are available for them or
> > not, or even if the PHY framework is available or not.
>
> huh? If memory isn't available you don't continue probing, right ? If
> your IORESOURCE_MEM is missing, you also don't continue probing, if your
> IRQ line is missing, you bail too. Those are also nothing but resources
> to the driver, what you're asking here is to treat PHY as a _different_
> resource; which might be fine, but we need to make sure we don't
> continue probing when a PHY is missing in a platform that certainly
> needs a PHY.
Yes, true. In my head I was comparing the PHY only to resources like
gpios, clocks, dma channels, etc. that are often optional to the
drivers.
> > > > > But I really want to see the argument against using no-op. As far as I
> > > > > could see, everybody needs a PHY driver one way or another, some
> > > > > platforms just haven't sent any PHY driver upstream and have their own
> > > > > hacked up solution to avoid using the PHY layer.
> > > >
> > > > Not true in our case. Platforms using Intel's SoCs and chip sets may
> > > > or may not have controllable USB PHY. Quite often they don't. The
> > > > Baytrails have usually ULPI PHY for USB2, but that does not mean they
> > > > provide any vendor specific functions or any need for a driver in any
> > > > case.
> > >
> > > that's different from what I heard.
> >
> > I don't know where you got that impression, but it's not true. The
> > Baytrail SoCs for example don't have internal USB PHYs, which means
> > the manufacturers using it can select what they want. So we have
> > boards where PHY driver(s) is needed and boards where it isn't.
>
> alright, that explains it ;-) So you have external USB2 and USB3 PHYs ?
> You have an external PIPE3 interface ? That's quite an achievement,
> kudos to your HW designers. Getting timing closure on PIPE3 is a
> difficult task.
No, only the USB2 PHY is external. I'm giving you wrong information,
I'm sorry about that. Need to concentrate on what I'm writing.
<snip>
> > This is really good to get. We have some projects where we are dealing
> > with more embedded environments, like IVI, where the kernel should be
> > stripped of everything useless. Since the PHYs are autonomous, we
> > should be able to disable the PHY libraries/frameworks.
>
> hmmm, in that case it's a lot easier to treat. We can use
> ERR_PTR(-ENXIO) as an indication that the framework is disabled, or
> something like that.
>
> The difficult is really reliably supporting e.g. OMAP5 (which won't work
> without a PHY) and your BayTrail with autonomous PHYs. What can we use
> as an indication ?
OMAP has it's own glue driver, so shouldn't it depend on the PHY
layer?
> I mean, I need to know that a particular platform depends on a PHY
> driver before I decide to return -EPROBE_DEFER or just assume the PHY
> isn't needed ;-)
I don't think dwc3 (core) should care about that. The PHY layer needs
to tell us that. If the PHY driver that the platform depends is not
available yet, the PHY layer returns -EPROBE_DEFER and dwc3 ends up
returning -EPROBE_DEFER.
<snip>
> > I think our goals are the same. I just want to also minimize the need
> > for any platform specific extra work from the upper layers regarding
> > the PHYs.
>
> I'll agree to that, but let's not apply patches until we're 100% sure
> there will be no regressions. Looking at $subject, I don't think it
> satisfies that condition ;-)
Agreed. Let's think this through carefully.
Cheers,
--
heikki
^ permalink raw reply
* [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Andreas Herrmann @ 2014-01-29 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129110537.GG26622@mudshark.cambridge.arm.com>
Hi Will, Marek,
On Wed, Jan 29, 2014 at 06:05:37AM -0500, Will Deacon wrote:
> Hi Marek,
>
> On Wed, Jan 29, 2014 at 10:57:01AM +0000, Marek Szyprowski wrote:
> > On 2014-01-16 13:44, Andreas Herrmann wrote:
> > > Instead of using just one bitmap to keep track of IO virtual addresses
> > > (handed out for IOMMU use) introduce a list of iova_ranges (each
> > > having its own bitmap). This allows us to extend existing mappings
> > > when running out of iova space for a mapping.
> > >
> > > If there is not enough space in the mapping to service an IO virtual
> > > address allocation request, __alloc_iova() tries to extend the mapping
> > > -- by allocating another bitmap -- and makes another allocation
> > > attempt using the freshly allocated bitmap.
> > >
> > > This allows arm iommu drivers to start with a decent initial size when
> > > an dma_iommu_mapping is created and still to avoid running out of IO
> > > virtual addresses for the mapping.
> > >
> > > Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac.
> > > I've used SZ_512K both for initial mapping size and grow_size.
> >
> > Thanks for implementing this feature! I remember it was discussed from
> > early beginning of arm dma iommu support, but I never had enough time
> > to actually implement it. I briefly checked the code and it look fine,
> > however I really wonder if we need separate grow_size parameter?
> > Personally I would simplify it to simply grow the bitmap by initial
> > size until it reaches the maximal size.
>
> That sounds sensible, but I also think it would be worth taking into account
> the page sizes supported by the IOMMU as well, since aligning to those makes
> sense from a TLB utilisation perspective.
Meanwhile I also think that the grow_size parameter is overkill. Only
the initial mapping size and the maximum size really matter. Then we
could try to extend the mapping by initial mapping size and if this
fails (we might not have enough pages to serve such an allocation) we
could/should even fall back to allocate a single page (which should
give us at least a 16MB range).
> > The whole concept of the simplified bitmap (where 1 bit != 1 page) for
> > iova allocation is a specific feature of this code and it has nothing
> > to the hardware. After thinking a bit more on the existing
> > implementation I've already observed that it is sometimes hard to
> > understand the parameters for arm_iommu_create_mapping() function,
> > especially the 'order' argument is ofter misunderstood. With your
> > patch we got two additional parameters. Maybe it will be much better
> > to use only 2 arguments: max_mapping_size and allocation_accuracy.
> > The initial bitmap size can be then calculated to fit it into single
> > memory page (that's quite important to avoid allocations larger that
> > a single memory page). 'allocation_accuracy' will serve the same way
> > as 'order' parameter now (but expressed in bytes rather than being
> > the multiplier for the number of pages). This way the
> > arm_iommu_create_mapping() function should be much easier to
> > understand, while keeping the implementation details hidden from the
> > caller.
>
> Hmm, I wouldn't guess the SI unit of accuracy to be bytes ;)
Have to think about the alignment argument and the last paragraph for
a while.
All I can say now is that starting with a bitmap size that fits into a
single memory page doesn't sound right to me. The initial allocation
is "easy" (not GFP_ATOMIC) and thus I think we should start with a
larger bitmap. Say you have a device for which at runtime 512MB
mapping range are required and you use a 4k page for the bitmaps (each
tracking 16MB IOVA range) you'll have 32 bitmaps to maintain. Whereas
when you start with 128MB initial bitmap size and (successfully)
enhance the mapping by 128MB you just have to maintain 4 bitmaps.
But of course coming up with the right choice for the initial bitmap
size that fits all master devices is a hard thing to do ...
Andreas
^ permalink raw reply
* [RFC] arm: vdso: Convert sigpage to vdso implementation
From: Steve Capper @ 2014-01-29 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E81BB7.7070201@mentor.com>
On Tue, Jan 28, 2014 at 03:05:59PM -0600, Nathan Lynch wrote:
> Hi Steve,
>
> On 01/28/2014 10:25 AM, Steve Capper wrote:
> > ARM has a special sigpage that is used for signal return trampolines.
> > Its implementation is very similar to a VDSO conceptually in that it
> > occupies a special mapping in user address space.
> >
> > One could actually host the trampoline code in a VDSO instead with the
> > added advantage that one could also host specialised routines there.
> > One such routine could be gettimeofday where on ARM we have architected
> > (and some vendor supplied) timers that can be queried entirely in
> > userspace, obviating the need for an expensive syscall.
> >
> > This patch converts the sigpage implementation to a VDSO. It is mostly
> > a direct port from Will Deacon's arm64 implementation with the ARM
> > signal trampoline plumbed in.
> >
> > Signed-off-by: Steve Capper <steve.capper@linaro.org>
> > ---
> > As can be inferred from this RFC, I am interested ultimately in
> > implementing a syscall-less gettimeofday for ARM. Whilst researching
> > possible vectors page or VDSO implementations, I came across the
> > sigpage mechanism which is very similar to a VDSO.
> >
> > The very simple function, __kernel_vdso_doubler, resolved in a test
> > program automatically on my Arndale board (running Fedora 20) without
> > any additional prodding.
> >
> > IPC stress tests from LTP were executed to test the signal trampoline.
> >
> > I would appreciate any comments on this approach of converting the
> > sigpage to a VDSO. If this looks sane to people, I will work on the
> > gettimeofday logic in a later patch.
>
> As it happens, I've been working on a vDSO implementation of
> gettimeofday/clock_gettime which does not mess with the signal page.
> I'll reply with the patch separately in a moment.
Cheers Nathan,
--
Steve
>
>
^ 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