* [PATCH v5 00/14] Add support for MSM's mmio clock/reset controller
From: Joe Perches @ 2014-02-07 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F53642.3030606@gmail.com>
On Fri, 2014-02-07 at 11:38 -0800, Frank Rowand wrote:
> On 2/6/2014 9:11 PM, Joe Perches wrote:
> > For patch 1, what checkpatch bug might that be?
[]
> Sorry, it is patch 2, not patch 1 ("[PATCH v5 02/14] clk: Add set_rate_and_parent() op"):
>
> WARNING: Multiple spaces after return type
> #188: FILE: include/linux/clk-provider.h:154:
> + int (*set_rate_and_parent)(struct clk_hw *hw,
>
> total: 0 errors, 1 warnings, 152 lines checked
Yup, that one might be a bit aggressive.
It's a complaint about function pointer declaration style.
from checkpatch:
------------------------------------------------------
# unnecessary space "type (*funcptr)(args...)"
elsif ($declare =~ /\s{2,}$/) {
WARN("SPACING",
"Multiple spaces after return type\n" . $herecurr);
}
------------------------------------------------------
This is warning about style equivalent to declarations like:
int foo(int bar);
checkpatch doesn't warn about declarations of that style,
so likely checkpatch shouldn't warn about multiple spaces
after a function pointer return type either.
I don't have a strong opinion one way or another about it.
If you think it should be silenced, it could be either
downgraded to a CHK or removed altogether.
^ permalink raw reply
* [PATCH v2 2/2] ARM: sunxi: dt: Convert to the new irq controller compatibles
From: Maxime Ripard @ 2014-02-07 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391806226-27480-1-git-send-email-maxime.ripard@free-electrons.com>
Switch the device tree to the new compatibles introduced in the irqchip drivers
to have a common pattern accross all Allwinner SoCs.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 2 +-
arch/arm/boot/dts/sun5i-a10s.dtsi | 2 +-
arch/arm/boot/dts/sun5i-a13.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 26cf191..f9d902f 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -347,7 +347,7 @@
};
intc: interrupt-controller at 01c20400 {
- compatible = "allwinner,sun4i-ic";
+ compatible = "allwinner,sun4i-a10-ic";
reg = <0x01c20400 0x400>;
interrupt-controller;
#interrupt-cells = <1>;
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index b114be7..e65fbf26 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -308,7 +308,7 @@
};
intc: interrupt-controller at 01c20400 {
- compatible = "allwinner,sun4i-ic";
+ compatible = "allwinner,sun4i-a10-ic";
reg = <0x01c20400 0x400>;
interrupt-controller;
#interrupt-cells = <1>;
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 5c121fc..d209179 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -290,7 +290,7 @@
ranges;
intc: interrupt-controller at 01c20400 {
- compatible = "allwinner,sun4i-ic";
+ compatible = "allwinner,sun4i-a10-ic";
reg = <0x01c20400 0x400>;
interrupt-controller;
#interrupt-cells = <1>;
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 1/2] irqchip: sunxi: Change compatibles
From: Maxime Ripard @ 2014-02-07 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391806226-27480-1-git-send-email-maxime.ripard@free-electrons.com>
The Allwinner A10 compatibles were following a slightly different compatible
patterns than the rest of the SoCs for historical reasons. Change the compatibles
to match the other pattern in the irq controller driver for consistency.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
.../devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt | 4 ++--
drivers/irqchip/irq-sun4i.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
index 32cec4b..b290ca1 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -2,7 +2,7 @@ Allwinner Sunxi Interrupt Controller
Required properties:
-- compatible : should be "allwinner,sun4i-ic"
+- compatible : should be "allwinner,sun4i-a10-ic"
- reg : Specifies base physical address and size of the registers.
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
@@ -11,7 +11,7 @@ Required properties:
Example:
intc: interrupt-controller {
- compatible = "allwinner,sun4i-ic";
+ compatible = "allwinner,sun4i-a10-ic";
reg = <0x01c20400 0x400>;
interrupt-controller;
#interrupt-cells = <1>;
diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index a5438d8..69e4e2d 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -134,7 +134,7 @@ static int __init sun4i_of_init(struct device_node *node,
return 0;
}
-IRQCHIP_DECLARE(allwinner_sun4i_ic, "allwinner,sun4i-ic", sun4i_of_init);
+IRQCHIP_DECLARE(allwinner_sun4i_ic, "allwinner,sun4i-a10-ic", sun4i_of_init);
static asmlinkage void __exception_irq_entry sun4i_handle_irq(struct pt_regs *regs)
{
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 0/2] irqchip: sun4i: Introduce a new compatible
From: Maxime Ripard @ 2014-02-07 20:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is the second version of the A10 irqchip compatible changes.
The only difference with the v1 being that we're now droping the old
compatibles, instead of keeping them, since the DT maintainers said it was
fine.
Thanks,
Maxime
Maxime Ripard (2):
irqchip: sunxi: Change compatibles
ARM: sunxi: dt: Convert to the new irq controller compatibles
.../devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt | 4 ++--
arch/arm/boot/dts/sun4i-a10.dtsi | 2 +-
arch/arm/boot/dts/sun5i-a10s.dtsi | 2 +-
arch/arm/boot/dts/sun5i-a13.dtsi | 2 +-
drivers/irqchip/irq-sun4i.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
--
1.8.4.2
^ permalink raw reply
* [PATCH] sched_clock: Prevent callers from seeing half-updated data
From: Stephen Boyd @ 2014-02-07 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F524A3.3070400@linaro.org>
If two sched_clock sources are registered we may end up in a
situation where a call to sched_clock() may be accessing the
epoch cycle count for the old counter and the cycle count for the
new counter. This can lead to confusing results where
sched_clock() values jump and then are reset to 0 (due to the way
the registration function forces the epoch_ns to be 0). Fix this
by reorganizing the registration function to hold the seqlock for
as short a time as possible while we update the clock_data
structure for a new counter and stop resetting the epoch_ns count
to 0.
Reported-by: Will Deacon <will.deacon@arm.com>
Cc: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
kernel/time/sched_clock.c | 42 +++++++++++++++++++++++++-----------------
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 0abb36464281..36ffce3a4b83 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -116,20 +116,38 @@ static enum hrtimer_restart sched_clock_poll(struct hrtimer *hrt)
void __init sched_clock_register(u64 (*read)(void), int bits,
unsigned long rate)
{
+ u64 res, wrap, new_mask, new_epoch;
+ u32 new_mult, new_shift;
+ ktime_t new_wrap_kt;
unsigned long r;
- u64 res, wrap;
char r_unit;
if (cd.rate > rate)
return;
WARN_ON(!irqs_disabled());
- read_sched_clock = read;
- sched_clock_mask = CLOCKSOURCE_MASK(bits);
- cd.rate = rate;
/* calculate the mult/shift to convert counter ticks to ns. */
- clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 3600);
+ clocks_calc_mult_shift(&new_mult, &new_shift, rate, NSEC_PER_SEC, 3600);
+
+ new_mask = CLOCKSOURCE_MASK(bits);
+
+ /* calculate how many ns until we wrap */
+ wrap = clocks_calc_max_nsecs(new_mult, new_shift, 0, new_mask);
+ new_wrap_kt = ns_to_ktime(wrap - (wrap >> 3));
+
+ /* update epoch for the new counter */
+ new_epoch = read();
+
+ raw_write_seqcount_begin(&cd.seq);
+ read_sched_clock = read;
+ sched_clock_mask = new_mask;
+ cd.rate = rate;
+ cd.wrap_kt = new_wrap_kt;
+ cd.mult = new_mult;
+ cd.shift = new_shift;
+ cd.epoch_cyc = new_epoch;
+ raw_write_seqcount_end(&cd.seq);
r = rate;
if (r >= 4000000) {
@@ -141,22 +159,12 @@ void __init sched_clock_register(u64 (*read)(void), int bits,
} else
r_unit = ' ';
- /* calculate how many ns until we wrap */
- wrap = clocks_calc_max_nsecs(cd.mult, cd.shift, 0, sched_clock_mask);
- cd.wrap_kt = ns_to_ktime(wrap - (wrap >> 3));
-
/* calculate the ns resolution of this counter */
- res = cyc_to_ns(1ULL, cd.mult, cd.shift);
+ res = cyc_to_ns(1ULL, new_mult, new_shift);
+
pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n",
bits, r, r_unit, res, wrap);
- update_sched_clock();
-
- /*
- * Ensure that sched_clock() starts off at 0ns
- */
- cd.epoch_ns = 0;
-
/* Enable IRQ time accounting if we have a fast enough sched_clock */
if (irqtime > 0 || (irqtime == -1 && rate >= 1000000))
enable_sched_clock_irqtime();
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
From: Russell King - ARM Linux @ 2014-02-07 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391793068.git.moinejf@free.fr>
On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> This patch series tries to simplify the code of simple devices in case
> they are part of componentised subsystems, are declared in a DT, and
> are not using the component bin/unbind functions.
Here's my changes to the TDA998x driver to add support for the component
helper. The TDA998x driver retains support for the old way so that
drivers can be transitioned. For any one DRM "card" the transition to
using the component layer must be all-in or all-out - partial transitions
are not permitted with the simple locking implementation currently in
the component helper due to the possibility of deadlock. (Master
binds, holding the component lock, master declares i2c device, i2c
device is bound to tda998x, which tries to register with the component
layer, trying to take the held lock.)
http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/log/?h=unstable/tda998x-devel
It's marked unstable because the two "drivers/base" commits in there are
_not_ the upstream commits. You'll notice that I just sent one of those
to Gregkh in patch form.
Now, the bits which aren't in that branch but which update the Armada
driver is the below, which needs some clean up and removal of some local
differences I have in my cubox tree, but nicely illustrates why /your/
patches to the component stuff is the wrong approach.
Not only does the patch below add support for using the componentised
TDA998x driver in the above link, but it allows that componentised support
to be specified not only via platform data but also via DT. The DT
stuff is untested, but it works exactly the same way as imx-drm does
which has been tested.
And yes, I'm thinking that maybe moving compare_of() into the component
support so that drivers can share this generic function may be a good
idea.
So... as I've been saying, no changes to component.c are required here.
diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
index 6f6554bac93f..1f2b7c60bff9 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -6,7 +6,9 @@
* published by the Free Software Foundation.
*/
#include <linux/clk.h>
+#include <linux/component.h>
#include <linux/module.h>
+#include <linux/platform_data/armada_drm.h>
#include <drm/drmP.h>
#include <drm/drm_crtc_helper.h>
#include "armada_crtc.h"
@@ -53,6 +55,11 @@ static const struct armada_drm_slave_config tda19988_config = {
};
#endif
+static bool is_componentized(struct device *dev)
+{
+ return dev->of_node || dev->platform_data;
+}
+
static void armada_drm_unref_work(struct work_struct *work)
{
struct armada_private *priv =
@@ -171,16 +178,22 @@ static int armada_drm_load(struct drm_device *dev, unsigned long flags)
goto err_kms;
}
+ if (is_componentized(dev->dev)) {
+ ret = component_bind_all(dev->dev, dev);
+ if (ret)
+ goto err_kms;
+ } else {
#ifdef CONFIG_DRM_ARMADA_TDA1998X
- ret = armada_drm_connector_slave_create(dev, &tda19988_config);
- if (ret)
- goto err_kms;
+ ret = armada_drm_connector_slave_create(dev, &tda19988_config);
+ if (ret)
+ goto err_kms;
#endif
#ifdef CONFIG_DRM_ARMADA_TDA1998X_NXP
- ret = armada_drm_tda19988_nxp_create(dev);
- if (ret)
- goto err_kms;
+ ret = armada_drm_tda19988_nxp_create(dev);
+ if (ret)
+ goto err_kms;
#endif
+ }
ret = drm_vblank_init(dev, n);
if (ret)
@@ -204,6 +217,10 @@ static int armada_drm_load(struct drm_device *dev, unsigned long flags)
drm_irq_uninstall(dev);
err_kms:
drm_mode_config_cleanup(dev);
+
+ if (is_componentized(dev->dev))
+ component_unbind_all(dev->dev, dev);
+
drm_mm_takedown(&priv->linear);
flush_work(&priv->fb_unref_work);
@@ -218,6 +235,10 @@ static int armada_drm_unload(struct drm_device *dev)
armada_fbdev_fini(dev);
drm_irq_uninstall(dev);
drm_mode_config_cleanup(dev);
+
+ if (is_componentized(dev->dev))
+ component_unbind_all(dev->dev, dev);
+
drm_mm_takedown(&priv->linear);
flush_work(&priv->fb_unref_work);
dev->dev_private = NULL;
@@ -380,14 +401,82 @@ static struct drm_driver armada_drm_driver = {
.fops = &armada_drm_fops,
};
+static int armada_drm_bind(struct device *dev)
+{
+ return drm_platform_init(&armada_drm_driver, to_platform_device(dev));
+}
+
+static void armada_drm_unbind(struct device *dev)
+{
+ drm_platform_exit(&armada_drm_driver, to_platform_device(dev));
+}
+
+static int compare_of(struct device *dev, void *data)
+{
+ return dev->of_node == data;
+}
+
+static int armada_drm_compare_name(struct device *dev, void *data)
+{
+ const char *name = data;
+ return !strcmp(dev_name(dev), name);
+}
+
+static int armada_drm_add_components(struct device *dev, struct master *master)
+{
+ int i, ret = -ENXIO;
+
+ if (dev->of_node) {
+ struct device_node *np = dev->of_node;
+
+ for (i = 0; ; i++) {
+ struct device_node *node;
+
+ node = of_parse_phandle(np, "connectors", i);
+ if (!node)
+ break;
+
+ ret = component_master_add_child(master, compare_of,
+ node);
+ of_node_put(node);
+ if (ret)
+ break;
+ }
+ } else if (dev->platform_data) {
+ struct armada_drm_platform_data *data = dev->platform_data;
+
+ for (i = 0; i < data->num_devices; i++) {
+ ret = component_master_add_child(master,
+ armada_drm_compare_name,
+ (void *)data->devices[i]);
+ if (ret)
+ break;
+ }
+ }
+
+ return ret;
+}
+
+static const struct component_master_ops armada_master_ops = {
+ .add_components = armada_drm_add_components,
+ .bind = armada_drm_bind,
+ .unbind = armada_drm_unbind,
+};
+
static int armada_drm_probe(struct platform_device *pdev)
{
- return drm_platform_init(&armada_drm_driver, pdev);
+ if (is_componentized(&pdev->dev))
+ return component_master_add(&pdev->dev, &armada_master_ops);
+ else
+ return drm_platform_init(&armada_drm_driver, pdev);
}
static int armada_drm_remove(struct platform_device *pdev)
{
- drm_platform_exit(&armada_drm_driver, pdev);
+ if (is_componentized(&pdev->dev))
+ component_master_del(&pdev->dev, &armada_master_ops);
+ else
+ drm_platform_exit(&armada_drm_driver, pdev);
return 0;
}
--
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 related
* [PATCH] drivers/base: fix devres handling for master device
From: Russell King @ 2014-02-07 20:09 UTC (permalink / raw)
To: linux-arm-kernel
We weren't handling the devres issues for the master device failing a
bind, or being unbound properly. Add a devres group to contain these,
and release the resources at the appropriate points.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
Greg, if you'd be kind enough to queue this for an -rc release, it'd
help plug a hole I discovered earlier this week in the component
helper. Thanks.
drivers/base/component.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index c53efe6c6d8e..c4778995cd72 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -133,9 +133,16 @@ static int try_to_bring_up_master(struct master *master,
goto out;
}
+ if (!devres_open_group(master->dev, NULL, GFP_KERNEL)) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
/* Found all components */
ret = master->ops->bind(master->dev);
if (ret < 0) {
+ devres_release_group(master->dev, NULL);
+ dev_info(master->dev, "master bind failed: %d\n", ret);
master_remove_components(master);
goto out;
}
@@ -166,6 +173,7 @@ static void take_down_master(struct master *master)
{
if (master->bound) {
master->ops->unbind(master->dev);
+ devres_release_group(master->dev, NULL);
master->bound = false;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Nishanth Menon @ 2014-02-07 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F51FCD.5000009@arm.com>
On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 17:37, Nishanth Menon wrote:
>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> [...]
>
>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>> frequencies and the boost parameters are exposed through sysfs)
>>
>> That will be a different problem -> as currently every single
>> frequency in the cpufreq list has ability to be marked as boost
>> frequency - if userspace does not maintain that, then, IMHO, fix the
>> userspace :D
>>
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
> the list of frequencies based on the state of the boost feature at anytime.
>
> Intuitively the list without boost shouldn't have any frequency above the range
> when it's enabled :), that's what I was referring to. So I am not talking about
> any issue with user-space maintenance.
Fair enough - but i still think it has nothing to do with dt binding
itself -> and i think the discussion we've had should be good for the
binding provided in this patch.. I hope.. if documentation needs a bit
of better explanation to prevent a repeat of the same discussion at a
later point of time, now might be a good time to add it in.
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v5 00/14] Add support for MSM's mmio clock/reset controller
From: Frank Rowand @ 2014-02-07 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391749891.15777.31.camel@joe-AO722>
On 2/6/2014 9:11 PM, Joe Perches wrote:
> On Thu, 2014-02-06 at 20:15 -0800, Frank Rowand wrote:
>> On 1/15/2014 10:47 AM, Stephen Boyd wrote:
>>> The first breaks a reset-controller include ordering requirement. It got
>>> an ack so I think we're ok for it to go through the clock tree.
>>>
>>
>> < snip >
>>
>> checkpatch is whining about patches
>>
>> 4
>> 5
>> 6
>> 7
>> 8
>>
>> (Just for completeness if someone thinks I did not check all the patches,
>> it also whines about patch 11, but I think the whining should be ignored,
>> and it whines about patch 1 but I think that might be a checkpatch bug.)
>
> Hi Frank.
>
> For patch 1, what checkpatch bug might that be?
see below
>
> I think all the checkpatch whinges in patch 11 are correct.
Agreed on patch 11, judgement call on whether to ignore the warnings.
>
> I didn't check any of 4-8.
Hi Joe,
Thanks for jumping in. I did not want to bother you until I dug a little
deeper into the warning to see if I was just misunderstanding something.
Sorry, it is patch 2, not patch 1 ("[PATCH v5 02/14] clk: Add set_rate_and_parent() op"):
WARNING: Multiple spaces after return type
#188: FILE: include/linux/clk-provider.h:154:
+ int (*set_rate_and_parent)(struct clk_hw *hw,
total: 0 errors, 1 warnings, 152 lines checked
-Frank
^ permalink raw reply
* Weird sched_clock behaviour during boot with -rc1
From: Stephen Boyd @ 2014-02-07 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F524A3.3070400@linaro.org>
On 02/07, John Stultz wrote:
> On 02/04/2014 02:00 PM, Stephen Boyd wrote:
> >>
> > That would work, but why can't we just hold the write seqlock
> > during the registration? We would need to make a lockeless
> > version of update_sched_clock() but that doesn't look too hard.
> > It might actually turn out nicer because we call
> > update_sched_clock() here just to set the epoch_cyc but we have
> > to reset the epoch_ns back to 0 to start the count off right.
> >
> > How about this? The only concern is calling read_sched_clock()
> > inside the seqlock, but I don't think that's a concern and if it
> > is we can call it outside the lock at the beginning of this
> > function.
>
> So whats the story here? Are we waiting on an ack from Will or would you
> rather go with Josh's approach?
An acked-by/tested-by from Will would be good. I'll cook up a
patch right now to do everything that has been mentioned in this
thread.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v4 1/5] clk: sunxi: Add support for USB clock-register reset bits
From: Maxime Ripard @ 2014-02-07 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391786513-20780-2-git-send-email-hdegoede@redhat.com>
On Fri, Feb 07, 2014 at 04:21:49PM +0100, Hans de Goede wrote:
> The usb-clk register is special in that it not only contains clk gate bits,
> but also has a few reset bits. This commit adds support for this by allowing
> gates type sunxi clks to also register a reset controller.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140207/eb93acaa/attachment-0001.sig>
^ permalink raw reply
* [PATCH v4 2/5] clk: sunxi: Add USB clock register defintions
From: Maxime Ripard @ 2014-02-07 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391786513-20780-3-git-send-email-hdegoede@redhat.com>
On Fri, Feb 07, 2014 at 04:21:50PM +0100, Hans de Goede wrote:
> From: Roman Byshko <rbyshko@gmail.com>
>
> Add register definitions for the usb-clk register found on sun4i, sun5i and
> sun7i SoCs.
>
> Signed-off-by: Roman Byshko <rbyshko@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140207/727ba076/attachment.sig>
^ permalink raw reply
* [PATCH v4 0/5] Add Allwinner A31 SPI controller support
From: Maxime Ripard @ 2014-02-07 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391605507-30981-1-git-send-email-maxime.ripard@free-electrons.com>
On Wed, Feb 05, 2014 at 02:05:02PM +0100, Maxime Ripard wrote:
> Hi everyone,
>
> This patchset brings support for the SPI controller found in the
> Allwinner A31 SoC.
>
> Even though the controller supports DMA, the driver only supports PIO
> mode for now. This driver will be used to bring up and test DMA on the
> SoC, so support for the DMA will come eventually.
>
> It doesn't support transfer larger than the FIFO size (128 bytes) for
> now, I expect it to be fixed in the future.
>
> Thanks!
> Maxime
>
> Changes from v3:
> - Rebased on top of 3.14-rc1
> - Removed the dependency on devm_spi_alloc_master
> - Modified the pm_runtime code according to reviews
>
> Changes from v2:
> - Removed the select on runtime_pm
> - Fixed the clock error messages
> - Trigger the CS manually, and honour the enable bit in set_cs
> - Convert to devm_* functions
> - Remove useless clk_disable_unprepare in probe
>
> Changes from v1:
> - Switched to using the transfer_one and set_cs callbacks
> - Switched to using runtime_pm
> - Report an error when we try to do a transfer larger than the FIFO
> size, instead of silently timeouting.
> - Added a Kconfig symbol
> - Move the clock ratio change at transfer time
> - Fixed the PLL6 cell size in the DTSI
> - A few fixes here and there: typos, etc.
>
> Maxime Ripard (5):
> clk: sunxi: Add support for PLL6 on the A31
> ARM: sun6i: dt: Add PLL6 and SPI module clocks
> spi: sunxi: Add Allwinner A31 SPI controller driver
> ARM: sun6i: dt: Add SPI controllers to the A31 DTSI
> ARM: sunxi: Enable A31 SPI and SID in the defconfig
Applied patch 2 and 4 to sunxi/dt-for-3.15, and patch 5 to sunxi/defconfig-for-3.15
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140207/b2250536/attachment.sig>
^ permalink raw reply
* [PATCH] dma-buf: avoid using IS_ERR_OR_NULL
From: Greg Kroah-Hartman @ 2014-02-07 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMbhsRQXUZH_n13X78HEvXuF58T-ubAXnEXXPa7Za9L-KEduMQ@mail.gmail.com>
On Fri, Feb 07, 2014 at 09:22:37AM -0800, Colin Cross wrote:
> On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
> >> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross <ccross@android.com> wrote:
> >> > dma_buf_map_attachment and dma_buf_vmap can return NULL or
> >> > ERR_PTR on a error. This encourages a common buggy pattern in
> >> > callers:
> >> > sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> >> > if (IS_ERR_OR_NULL(sgt))
> >> > return PTR_ERR(sgt);
> >> >
> >> > This causes the caller to return 0 on an error. IS_ERR_OR_NULL
> >> > is almost always a sign of poorly-defined error handling.
> >> >
> >> > This patch converts dma_buf_map_attachment to always return
> >> > ERR_PTR, and fixes the callers that incorrectly handled NULL.
> >> > There are a few more callers that were not checking for NULL
> >> > at all, which would have dereferenced a NULL pointer later.
> >> > There are also a few more callers that correctly handled NULL
> >> > and ERR_PTR differently, I left those alone but they could also
> >> > be modified to delete the NULL check.
> >> >
> >> > This patch also converts dma_buf_vmap to always return NULL.
> >> > All the callers to dma_buf_vmap only check for NULL, and would
> >> > have dereferenced an ERR_PTR and panic'd if one was ever
> >> > returned. This is not consistent with the rest of the dma buf
> >> > APIs, but matches the expectations of all of the callers.
> >> >
> >> > Signed-off-by: Colin Cross <ccross@android.com>
> >> > ---
> >> > drivers/base/dma-buf.c | 18 +++++++++++-------
> >> > drivers/gpu/drm/drm_prime.c | 2 +-
> >> > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 2 +-
> >> > drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
> >> > 4 files changed, 14 insertions(+), 10 deletions(-)
> >> >
> >> > diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> >> > index 1e16cbd61da2..cfe1d8bc7bb8 100644
> >> > --- a/drivers/base/dma-buf.c
> >> > +++ b/drivers/base/dma-buf.c
> >> > @@ -251,9 +251,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> >> > * @dmabuf: [in] buffer to attach device to.
> >> > * @dev: [in] device to be attached.
> >> > *
> >> > - * Returns struct dma_buf_attachment * for this attachment; may return negative
> >> > - * error codes.
> >> > - *
> >> > + * Returns struct dma_buf_attachment * for this attachment; returns ERR_PTR on
> >> > + * error.
> >> > */
> >> > struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> >> > struct device *dev)
> >> > @@ -319,9 +318,8 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
> >> > * @attach: [in] attachment whose scatterlist is to be returned
> >> > * @direction: [in] direction of DMA transfer
> >> > *
> >> > - * Returns sg_table containing the scatterlist to be returned; may return NULL
> >> > - * or ERR_PTR.
> >> > - *
> >> > + * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
> >> > + * on error.
> >> > */
> >> > struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
> >> > enum dma_data_direction direction)
> >> > @@ -334,6 +332,8 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
> >> > return ERR_PTR(-EINVAL);
> >> >
> >> > sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> >> > + if (!sg_table)
> >> > + sg_table = ERR_PTR(-ENOMEM);
> >> >
> >> > return sg_table;
> >> > }
> >> > @@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
> >> > * These calls are optional in drivers. The intended use for them
> >> > * is for mapping objects linear in kernel space for high use objects.
> >> > * Please attempt to use kmap/kunmap before thinking about these interfaces.
> >> > + *
> >> > + * Returns NULL on error.
> >> > */
> >> > void *dma_buf_vmap(struct dma_buf *dmabuf)
> >> > {
> >> > @@ -566,7 +568,9 @@ void *dma_buf_vmap(struct dma_buf *dmabuf)
> >> > BUG_ON(dmabuf->vmap_ptr);
> >> >
> >> > ptr = dmabuf->ops->vmap(dmabuf);
> >> > - if (IS_ERR_OR_NULL(ptr))
> >> > + if (WARN_ON_ONCE(IS_ERR(ptr)))
> >>
> >> since vmap is optional, the WARN_ON might be a bit strong.. although
> >> it would be a bit strange for an exporter to supply a vmap fxn which
> >> always returned NULL, not sure about that. Just thought I'd mention
> >> it in case anyone else had an opinion about that.
> >
> > Yeah, I don't like this, it could cause unnecessary reports of problems.
>
> The WARN_ON_ONCE is only if the vmap op returns ERR_PTR, not if it
> returns NULL. This is designed to catch vmap ops that don't follow
> the spec, so I would call them necessary reports, but I can take it
> out if you still disagree.
Ah, ok, that makes more sense. I'll queue this up.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v4 0/8] ARM: sunxi: rename DT clock node names to clk@N
From: Maxime Ripard @ 2014-02-07 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391392304-4660-1-git-send-email-wens@csie.org>
On Mon, Feb 03, 2014 at 09:51:36AM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
>
> This is v4 of the clock node renaming patch series, which renames
> the clock nodes in sunxi dts to conform to device tree naming
> conventions, i.e. clk at N. Dummy clocks that will be renamed/removed
> later, or clocks sharing registers are not renamed.
>
> Renamed clock nodes have clock-output-names properties added to
> desginate their names. Support for this is added in the first
> patch.
Applied the last 4 patches to sunxi/dt-for-3.15.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140207/3aba29dd/attachment.sig>
^ permalink raw reply
* [PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache
From: Sudeep Holla @ 2014-02-07 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207182123.GE16263@obsidianresearch.com>
On 07/02/14 18:21, Jason Gunthorpe wrote:
> On Fri, Feb 07, 2014 at 02:48:26PM +0000, Sudeep Holla wrote:
>> On 06/02/14 23:42, Andrew Lunn wrote:
>
>> Looks more like a software configuration for me unless I am missing
>> something.
>
> There is precedence for this, see
> Documentation/devicetree/bindings/arm/l2cc.txt
>
> Though the feorceon name should match 'wt-override'
>
Thanks for pointing out, may be its good to add reference to l2cc binding if its
applicable.
Do we need both wt-override and writethrough ?
>> It should not be here IMO if its pure software construct, may be you
>> can use already existing cachepolicy kernel parameter instead.
>
> cachepolicy is already doing something very different, it would not be
> appropriate to use it for this.
>
Yes I suspected that by a quick inspection at the code using it, but thought of
checking instead.
Regards,
Sudeep
^ permalink raw reply
* [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
From: Russell King - ARM Linux @ 2014-02-07 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207194204.4d4326bd@armhf>
On Fri, Feb 07, 2014 at 07:42:04PM +0100, Jean-Francois Moine wrote:
> On Fri, 7 Feb 2014 17:33:26 +0000
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> > On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> > > This patch series tries to simplify the code of simple devices in case
> > > they are part of componentised subsystems, are declared in a DT, and
> > > are not using the component bin/unbind functions.
> >
> > I wonder - I said earlier today that this works absolutely fine without
> > modification with DT, so why are you messing about with it adding DT
> > support?
> >
> > This is totally the wrong approach. The idea is that this deals with
> > /devices/ and /devices/ only. It groups up /devices/.
> >
> > It's up to the add_component callback to the master device to decide
> > how to deal with that.
> >
> > > Jean-Francois Moine (2):
> > > drivers/base: permit base components to omit the bind/unbind ops
> >
> > And this patch has me wondering if you even understand how to use
> > this... The master bind/unbind callbacks are the ones which establish
> > the "card" based context with the subsystem.
> >
> > Please, before buggering up this nicely designed implementation, please
> > /first/ look at the imx-drm rework which was posted back in early January
> > which illustrates how this is used in a DT context - which is something
> > I've already pointed you at once today already.
>
> As I told in a previous mail, your code works fine in my DT-based
> Cubox. I am rewriting the TDA988x as a normal encoder/connector, and,
> yes, the bind/unbind functions are useful in this case.
So, which bit of "I've already got that" was missed?
> But you opened a door. In a DT context, you know that the probe_defer
> mechanism does not work correctly. Your work permits to solve delicate
> cases: your component_add tells exactly when a device is available, and
> the master bind callback is the green signal for the device waiting for
> its resources. Indeed, your system was not created for such a usage,
> but it works as it is (anyway, the component bind/unbind functions may
> be empty...).
Sorry. Deferred probe does work, it's been tested with imx-drm, not
only from the master component but also the sub-components. There's
no problem here.
And no component bind/unbind function should ever be empty.
Again, I put it to you that you don't understand this layer.
--
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 21/21] ARM: Kirkwood: Remove DT support
From: Jason Cooper @ 2014-02-07 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F51922.6030502@gmail.com>
On Fri, Feb 07, 2014 at 06:34:26PM +0100, Sebastian Hesselbarth wrote:
> On 02/07/2014 12:42 AM, Andrew Lunn wrote:
> >Now that all the device tree support is in mach-mvebu, remove it from
> >mach-kirkwood.
> >
> >Regenerate kirkwood_defconfig, removing all DT support, and a couple
> >of other redundent options have been removed in the process.
> >
> >Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> >---
>
> Hmm, I wonder what Ian thinks of removing this so quickly again...
>
> Maybe let it rot for 1-2 kernel versions?
The easiest answer is to modify kirkwood_defconfig to select both
ARCH_KIRKWOOD and MACH_KIRKWOOD until such time as we have a working dts
file for _every_ board file. Only then should we look at beginning the
deprecation process for non-DT.
thx,
Jason.
^ permalink raw reply
* [PATCH RFC 0/2] drivers/base: simplify simple DT-based components
From: Jean-Francois Moine @ 2014-02-07 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207173326.GD26684@n2100.arm.linux.org.uk>
On Fri, 7 Feb 2014 17:33:26 +0000
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> > This patch series tries to simplify the code of simple devices in case
> > they are part of componentised subsystems, are declared in a DT, and
> > are not using the component bin/unbind functions.
>
> I wonder - I said earlier today that this works absolutely fine without
> modification with DT, so why are you messing about with it adding DT
> support?
>
> This is totally the wrong approach. The idea is that this deals with
> /devices/ and /devices/ only. It groups up /devices/.
>
> It's up to the add_component callback to the master device to decide
> how to deal with that.
>
> > Jean-Francois Moine (2):
> > drivers/base: permit base components to omit the bind/unbind ops
>
> And this patch has me wondering if you even understand how to use
> this... The master bind/unbind callbacks are the ones which establish
> the "card" based context with the subsystem.
>
> Please, before buggering up this nicely designed implementation, please
> /first/ look at the imx-drm rework which was posted back in early January
> which illustrates how this is used in a DT context - which is something
> I've already pointed you at once today already.
As I told in a previous mail, your code works fine in my DT-based
Cubox. I am rewriting the TDA988x as a normal encoder/connector, and,
yes, the bind/unbind functions are useful in this case.
But you opened a door. In a DT context, you know that the probe_defer
mechanism does not work correctly. Your work permits to solve delicate
cases: your component_add tells exactly when a device is available, and
the master bind callback is the green signal for the device waiting for
its resources. Indeed, your system was not created for such a usage,
but it works as it is (anyway, the component bind/unbind functions may
be empty...).
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 19/21] ARM: MVEBU: Simplifiy headers and make local
From: Jason Gunthorpe @ 2014-02-07 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207093104.7197224d@skate>
> > +#define KIRKWOOD_REGS_PHYS_BASE 0xf1000000
> > +#define DDR_PHYS_BASE (KIRKWOOD_REGS_PHYS_BASE + 0x00000)
> > +#define BRIDGE_PHYS_BASE (KIRKWOOD_REGS_PHYS_BASE + 0x20000)
Sorry I missed this earlier, but it would be *super nice* if
KIRKWOOD_REGS_PHYS_BASE could go away. 0xf1000000 is an arbitary
policy choice and with the mbus driver this is the last hold out.
That said, it could be revised after your series. :)
Regards,
Jason
^ permalink raw reply
* Weird sched_clock behaviour during boot with -rc1
From: John Stultz @ 2014-02-07 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204220045.GC20528@codeaurora.org>
On 02/04/2014 02:00 PM, Stephen Boyd wrote:
> On 02/04, John Stultz wrote:
>> On 02/04/2014 10:36 AM, Will Deacon wrote:
>>> Hi guys,
>>>
>>> Booting -rc1 on my TC2 gives the following strange entries in the dmesg:
>>>
>>>
>>> Uncompressing Linux... done, booting the kernel.
>>> [ 0.000000] Booting Linux on physical CPU 0x0
>>>
>>> [...]
>>>
>>> [ 0.000000] HighMem zone: 329728 pages, LIFO batch:31
>>> [ 7.789662] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
>>> [ 0.000129] PERCPU: Embedded 9 pages/cpu @ee7bd000 s12800 r8192 d15872 u36864
>>>
>>> [...]
>>>
>>> [ 0.868297] NR_IRQS:16 nr_irqs:16 16
>>> [ 0.886350] Architected cp15 timer(s) running at 24.00MHz (phys).
>>> [ 2915.164998] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 2863311519744ns
>>> [ 0.000002] Switching to timer-based delay loop
>>> [ 0.014249] Console: colour dummy device 80x30
>>>
>>>
>>> so it looks like something whacky goes on during sched_clock registration.
>>> Sure enough, we're doing a pr_info in-between updating cs.* and calling
>>> update_sched_clock(), so moving the print sorts things out (diff below).
>> Yea... we have to be particularly careful with sched_clock to avoid
>> locks since we don't want to deadlock, but in this case
>> sched_clock_register is a little too relaxed here.
>>
>> Stephen: Would it make sense to set cd.suspended = true at the top of
>> the registration? That should block any sched_clock calls from getting
>> half-updated data, but still allow the sched_clock_update function to work.
>>
> That would work, but why can't we just hold the write seqlock
> during the registration? We would need to make a lockeless
> version of update_sched_clock() but that doesn't look too hard.
> It might actually turn out nicer because we call
> update_sched_clock() here just to set the epoch_cyc but we have
> to reset the epoch_ns back to 0 to start the count off right.
>
> How about this? The only concern is calling read_sched_clock()
> inside the seqlock, but I don't think that's a concern and if it
> is we can call it outside the lock at the beginning of this
> function.
Hey Stephen,
So whats the story here? Are we waiting on an ack from Will or would you
rather go with Josh's approach?
thanks
-john
^ permalink raw reply
* [PATCH 10/21] ARM: MM: Add DT binding for Feroceon L2 cache
From: Jason Gunthorpe @ 2014-02-07 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F4F23A.3030405@arm.com>
On Fri, Feb 07, 2014 at 02:48:26PM +0000, Sudeep Holla wrote:
> On 06/02/14 23:42, Andrew Lunn wrote:
> Looks more like a software configuration for me unless I am missing
> something.
There is precedence for this, see
Documentation/devicetree/bindings/arm/l2cc.txt
Though the feorceon name should match 'wt-override'
> It should not be here IMO if its pure software construct, may be you
> can use already existing cachepolicy kernel parameter instead.
cachepolicy is already doing something very different, it would not be
appropriate to use it for this.
Jason
^ permalink raw reply
* [PATCH] ARM: mm: add imprecise abort non-deadly handler
From: Ben Dooks @ 2014-02-07 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391797214-17142-1-git-send-email-ben.dooks@codethink.co.uk>
Given that imprecise aborts may be delivered after the action that
caused them (or even for non-cpu related activities such as bridge
faults from a bus-master) it is possible that the wrong process is
terminated as a result.
It is not know at this time in an SMP system which cores get notified
of an imprecise external abort, we have yet to find the right details
in the architecture reference manuals. This also means that killing
the process is probably the wrong thing to do on reception of these aborts.
Add a handler to take and print imprecise aborts and allow the process
to continue. This should ensure that the abort is shown but not kill
the process that was running on the cpu core at the time.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
arch/arm/mm/fault.c | 15 +++++++++++++++
arch/arm/mm/fsr-2level.c | 32 ++++++++++++++++----------------
2 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index eb8830a..c1fd5ba 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -512,6 +512,21 @@ do_bad(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
return 1;
}
+/*
+ * On an imprecise external abort it is possible that the currently running
+ * process did not cause it (it could be from an external bus bridge or
+ * another device causing a fault on the bus).
+ *
+ * Always return handled as we do not know how to do it and killing the
+ * current process may not prevent future faults.
+ */
+static int
+do_bad_imprecise(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
+{
+ printk(KERN_INFO "Caught imprecise abort (0x%03x) %08lx", fsr, addr);
+ return 0;
+}
+
struct fsr_info {
int (*fn)(unsigned long addr, unsigned int fsr, struct pt_regs *regs);
int sig;
diff --git a/arch/arm/mm/fsr-2level.c b/arch/arm/mm/fsr-2level.c
index 18ca74c..8f5ef60 100644
--- a/arch/arm/mm/fsr-2level.c
+++ b/arch/arm/mm/fsr-2level.c
@@ -24,22 +24,22 @@ static struct fsr_info fsr_info[] = {
* 10 of the FSR, and may not be recoverable. These are only
* supported if the CPU abort handler supports bit 10.
*/
- { do_bad, SIGBUS, 0, "unknown 16" },
- { do_bad, SIGBUS, 0, "unknown 17" },
- { do_bad, SIGBUS, 0, "unknown 18" },
- { do_bad, SIGBUS, 0, "unknown 19" },
- { do_bad, SIGBUS, 0, "lock abort" }, /* xscale */
- { do_bad, SIGBUS, 0, "unknown 21" },
- { do_bad, SIGBUS, BUS_OBJERR, "imprecise external abort" }, /* xscale */
- { do_bad, SIGBUS, 0, "unknown 23" },
- { do_bad, SIGBUS, 0, "dcache parity error" }, /* xscale */
- { do_bad, SIGBUS, 0, "unknown 25" },
- { do_bad, SIGBUS, 0, "unknown 26" },
- { do_bad, SIGBUS, 0, "unknown 27" },
- { do_bad, SIGBUS, 0, "unknown 28" },
- { do_bad, SIGBUS, 0, "unknown 29" },
- { do_bad, SIGBUS, 0, "unknown 30" },
- { do_bad, SIGBUS, 0, "unknown 31" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 16" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 17" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 18" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 19" },
+ { do_bad_imprecise, SIGBUS, 0, "lock abort" }, /* xscale */
+ { do_bad_imprecise, SIGBUS, 0, "unknown 21" },
+ { do_bad_imprecise, SIGBUS, BUS_OBJERR, "imprecise external abort" }, /* xscale */
+ { do_bad_imprecise, SIGBUS, 0, "unknown 23" },
+ { do_bad_imprecise, SIGBUS, 0, "dcache parity error" }, /* xscale */
+ { do_bad_imprecise, SIGBUS, 0, "unknown 25" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 26" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 27" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 28" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 29" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 30" },
+ { do_bad_imprecise, SIGBUS, 0, "unknown 31" },
};
static struct fsr_info ifsr_info[] = {
--
1.8.5.3
^ permalink raw reply related
* imprecise abort behaviour
From: Ben Dooks @ 2014-02-07 18:20 UTC (permalink / raw)
To: linux-arm-kernel
With the current discussion about enabling the external abort
handling, I would like to get the following patch reviewed to
change the behaviour of imprecise aborts to simply causing the
host to get a warning instead of a fatal signal.
^ permalink raw reply
* [PATCH] clk: respect the clock dependencies in of_clk_init
From: Emilio López @ 2014-02-07 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F52189.5090506@free-electrons.com>
Hi,
El 07/02/14 15:10, Gregory CLEMENT escribi?:
(snip)
>> ---
>> drivers/clk/mvebu/common.c | 13 +++++++------
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
>> index 25ceccf..730625b 100644
>> --- a/drivers/clk/mvebu/common.c
>> +++ b/drivers/clk/mvebu/common.c
>> @@ -119,19 +119,20 @@ void __init mvebu_clk_gating_setup(struct
>> device_node *np,
>> const struct clk_gating_soc_desc *desc)
>> {
>> struct clk_gating_ctrl *ctrl;
>> - struct clk *clk;
>> void __iomem *base;
>> - const char *default_parent = NULL;
>> + struct of_phandle_args clkspec;
>> + const char *default_parent = "tclk";
>> int n;
>>
>> base = of_iomap(np, 0);
>> if (WARN_ON(!base))
>> return;
>>
>> - clk = of_clk_get(np, 0);
>> - if (!IS_ERR(clk)) {
>> - default_parent = __clk_get_name(clk);
>> - clk_put(clk);
>> + if (!of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
>> &clkspec)) {
>> + of_property_read_string_index(clkspec.np, "clock-output-names",
>> + clkspec.args_count ? clkspec.args[0] : 0,
>> + &default_parent);
>> + of_node_put(clkspec.np);
>
> OK here you duplicate the code from of_clk_get_parent_name, I wonder why
> you didn't use the function.But whatever.
I specifically duplicated it because of_clk_get_parent_name returns the
node name if there's no clock-output-names. That wouldn't be useful in
this case.
> Here you will get default_parent = "mvebu-sar" which is the name of the node, you
> can't have "tclk" because this name is not in the device tree, but it will be
> created by the initialization of the core clocks.
No, default_parent would be "tclk" still because clock-output-names
property doesn't exist. If you ever add such a property, it will
override "tclk".
Cheers,
Emilio
^ 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