* [PATCH v4 1/4] clk: Add support for runtime PM
From: Marek Szyprowski @ 2016-12-30 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483104816-20885-1-git-send-email-m.szyprowski@samsung.com>
Registers for some clocks might be located in the SOC area, which are under the
power domain. To enable access to those registers respective domain has to be
turned on. Additionally, registers for such clocks will usually loose its
contents when power domain is turned off, so additional saving and restoring of
them might be needed in the clock controller driver.
This patch adds basic infrastructure in the clocks core to allow implementing
driver for such clocks under power domains. Clock provider can supply a
struct device pointer, which is the used by clock core for tracking and managing
clock's controller runtime pm state. Each clk_prepare() operation
will first call pm_runtime_get_sync() on the supplied device, while
clk_unprepare() will do pm_runtime_put() at the end.
Additional calls to pm_runtime_get/put functions are required to ensure that any
register access (like calculating/changing clock rates and unpreparing/disabling
unused clocks on boot) will be done with clock controller in runtime resumend
state.
When one wants to register clock controller, which make use of this feature, he
has to:
1. Provide a struct device to the core when registering the provider.
2. Ensure to enable runtime PM for that device before registering clocks.
3. Make sure that the runtime PM status of the controller device reflects
the HW state.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/clk/clk.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 101 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 0fb39fe217d1..3cf202ccf5a9 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -21,6 +21,7 @@
#include <linux/of.h>
#include <linux/device.h>
#include <linux/init.h>
+#include <linux/pm_runtime.h>
#include <linux/sched.h>
#include <linux/clkdev.h>
@@ -46,6 +47,7 @@ struct clk_core {
const struct clk_ops *ops;
struct clk_hw *hw;
struct module *owner;
+ struct device *dev;
struct clk_core *parent;
const char **parent_names;
struct clk_core **parents;
@@ -87,6 +89,26 @@ struct clk {
struct hlist_node clks_node;
};
+/*** runtime pm ***/
+static int clk_pm_runtime_get(struct clk_core *core)
+{
+ int ret = 0;
+
+ if (!core->dev)
+ return 0;
+
+ ret = pm_runtime_get_sync(core->dev);
+ return ret < 0 ? ret : 0;
+}
+
+static void clk_pm_runtime_put(struct clk_core *core)
+{
+ if (!core->dev)
+ return;
+
+ pm_runtime_put(core->dev);
+}
+
/*** locking ***/
static void clk_prepare_lock(void)
{
@@ -150,6 +172,8 @@ static void clk_enable_unlock(unsigned long flags)
static bool clk_core_is_prepared(struct clk_core *core)
{
+ bool status;
+
/*
* .is_prepared is optional for clocks that can prepare
* fall back to software usage counter if it is missing
@@ -157,11 +181,20 @@ static bool clk_core_is_prepared(struct clk_core *core)
if (!core->ops->is_prepared)
return core->prepare_count;
- return core->ops->is_prepared(core->hw);
+ if (clk_pm_runtime_get(core) == 0) {
+ status = core->ops->is_prepared(core->hw);
+ clk_pm_runtime_put(core);
+ } else {
+ status = false;
+ }
+
+ return status;
}
static bool clk_core_is_enabled(struct clk_core *core)
{
+ bool status;
+
/*
* .is_enabled is only mandatory for clocks that gate
* fall back to software usage counter if .is_enabled is missing
@@ -169,7 +202,30 @@ static bool clk_core_is_enabled(struct clk_core *core)
if (!core->ops->is_enabled)
return core->enable_count;
- return core->ops->is_enabled(core->hw);
+ /*
+ * Check if clock controller's device is runtime active before
+ * calling .is_enabled callback. If not, assume that clock is
+ * disabled, because we might be called from atomic context, from
+ * which pm_runtime_get() is not allowed.
+ * This function is called mainly from clk_disable_unused_subtree,
+ * which ensures proper runtime pm activation of controller before
+ * taking enable spinlock, but the below check is needed if one tries
+ * to call it from other places.
+ */
+ if (core->dev) {
+ pm_runtime_get_noresume(core->dev);
+ if (!pm_runtime_active(core->dev)) {
+ status = false;
+ goto done;
+ }
+ }
+
+ status = core->ops->is_enabled(core->hw);
+done:
+ if (core->dev)
+ pm_runtime_put(core->dev);
+
+ return status;
}
/*** helper functions ***/
@@ -489,6 +545,8 @@ static void clk_core_unprepare(struct clk_core *core)
if (core->ops->unprepare)
core->ops->unprepare(core->hw);
+ clk_pm_runtime_put(core);
+
trace_clk_unprepare_complete(core);
clk_core_unprepare(core->parent);
}
@@ -530,10 +588,14 @@ static int clk_core_prepare(struct clk_core *core)
return 0;
if (core->prepare_count == 0) {
- ret = clk_core_prepare(core->parent);
+ ret = clk_pm_runtime_get(core);
if (ret)
return ret;
+ ret = clk_core_prepare(core->parent);
+ if (ret)
+ goto runtime_put;
+
trace_clk_prepare(core);
if (core->ops->prepare)
@@ -541,15 +603,18 @@ static int clk_core_prepare(struct clk_core *core)
trace_clk_prepare_complete(core);
- if (ret) {
- clk_core_unprepare(core->parent);
- return ret;
- }
+ if (ret)
+ goto unprepare;
}
core->prepare_count++;
return 0;
+unprepare:
+ clk_core_unprepare(core->parent);
+runtime_put:
+ clk_pm_runtime_put(core);
+ return ret;
}
static int clk_core_prepare_lock(struct clk_core *core)
@@ -745,6 +810,9 @@ static void clk_unprepare_unused_subtree(struct clk_core *core)
if (core->flags & CLK_IGNORE_UNUSED)
return;
+ if (clk_pm_runtime_get(core))
+ return;
+
if (clk_core_is_prepared(core)) {
trace_clk_unprepare(core);
if (core->ops->unprepare_unused)
@@ -753,6 +821,8 @@ static void clk_unprepare_unused_subtree(struct clk_core *core)
core->ops->unprepare(core->hw);
trace_clk_unprepare_complete(core);
}
+
+ clk_pm_runtime_put(core);
}
static void clk_disable_unused_subtree(struct clk_core *core)
@@ -768,6 +838,9 @@ static void clk_disable_unused_subtree(struct clk_core *core)
if (core->flags & CLK_OPS_PARENT_ENABLE)
clk_core_prepare_enable(core->parent);
+ if (clk_pm_runtime_get(core))
+ goto unprepare_out;
+
flags = clk_enable_lock();
if (core->enable_count)
@@ -792,6 +865,8 @@ static void clk_disable_unused_subtree(struct clk_core *core)
unlock_out:
clk_enable_unlock(flags);
+ clk_pm_runtime_put(core);
+unprepare_out:
if (core->flags & CLK_OPS_PARENT_ENABLE)
clk_core_disable_unprepare(core->parent);
}
@@ -1563,6 +1638,7 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
{
struct clk_core *top, *fail_clk;
unsigned long rate = req_rate;
+ int ret = 0;
if (!core)
return 0;
@@ -1579,21 +1655,28 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (!top)
return -EINVAL;
+ ret = clk_pm_runtime_get(core);
+ if (ret)
+ return ret;
+
/* notify that we are about to change rates */
fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE);
if (fail_clk) {
pr_debug("%s: failed to set %s rate\n", __func__,
fail_clk->name);
clk_propagate_rate_change(top, ABORT_RATE_CHANGE);
- return -EBUSY;
+ ret = -EBUSY;
+ goto err;
}
/* change the rates */
clk_change_rate(top);
core->req_rate = req_rate;
+err:
+ clk_pm_runtime_put(core);
- return 0;
+ return ret;
}
/**
@@ -1824,12 +1907,16 @@ static int clk_core_set_parent(struct clk_core *core, struct clk_core *parent)
p_rate = parent->rate;
}
+ ret = clk_pm_runtime_get(core);
+ if (ret)
+ goto out;
+
/* propagate PRE_RATE_CHANGE notifications */
ret = __clk_speculate_rates(core, p_rate);
/* abort if a driver objects */
if (ret & NOTIFY_STOP_MASK)
- goto out;
+ goto runtime_put;
/* do the re-parent */
ret = __clk_set_parent(core, parent, p_index);
@@ -1842,6 +1929,8 @@ static int clk_core_set_parent(struct clk_core *core, struct clk_core *parent)
__clk_recalc_accuracies(core);
}
+runtime_put:
+ clk_pm_runtime_put(core);
out:
clk_prepare_unlock();
@@ -2549,6 +2638,8 @@ struct clk *clk_register(struct device *dev, struct clk_hw *hw)
goto fail_name;
}
core->ops = hw->init->ops;
+ if (dev && pm_runtime_enabled(dev))
+ core->dev = dev;
if (dev && dev->driver)
core->owner = dev->driver->owner;
core->hw = hw;
--
1.9.1
^ permalink raw reply related
* [PATCH v4 0/4] Add runtime PM support for clocks (on Exynos SoC example)
From: Marek Szyprowski @ 2016-12-30 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161230133344eucas1p21d107e1cf3096916aad1944f7e002bf9@eucas1p2.samsung.com>
Dear All,
This patchset adds runtime PM support to common clock framework. This is an
attempt to implement support for clock controllers, which belongs to a power
domain. This approach works surprisingly well on Exynos 5433 SoC, what allowed
us to solve various freeze/crash issues related to power management.
The main idea behind this patchset is to keep clock's controller power domain
enabled every time when at least one of its clock is enabled or access to its
registers is being made. Clock controller driver (clock provider) can
supply a struct device pointer, which is the used by clock core for tracking and
managing clock's controller runtime pm state. Each clk_prepare() operation will
first call pm_runtime_get_sync() on the supplied device, while clk_unprepare()
will do pm_runtime_put() at the end.
This runtime PM feature has been tested with Exynos4412 (not included in this
patchset) and Exynos5433 clocks drivers. Both have some clocks, which belongs to
respective power domains and need special handling during power on/off
procedures. Till now it wasn't handled at all, what caused various problems.
Patches for clocks drivers change the way the clock provider is initialized.
Instead of CLK_OF_DECLARE based initialization, a complete platform device driver
infrastructure is being used. This is needed to let driver to use runtime PM
feature and integrate with generic power domains. The side-effect of this change
is a delay in clock provider registeration during system boot, so early
initialized drivers might get EPROBEDEFER error when requesting their clocks.
This is an issue for IOMMU drivers, so this patchset will be fully functional
once the deferred probe for IOMMU will be merged.
Patches are based on vanilla v4.10-rc1 kernel.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v4:
- Removed patch for Exynos4412 clocks from the patchset. DT bindings for power
domain for ISP sub-controller needs more discussion. It will be handled
separately when the runtime PM for clocks feature gets merged.
- Added patch with runtime PM support for Exynos AudioSS clock controller driver
(needed to enable audio power domain on Exynos5 series).
- Fixes in Exynos5433 driver:
1. added missing clock for Audio CMU
2. added support for FSYS CMU
3. improved support for DISP CMU (thanks to Andrzej Hajda for
investigating that).
- Rebased onto v4.10-rc1
- Waiting for a review...
v3: http://www.spinics.net/lists/arm-kernel/msg538122.html
- Removed CLK_RUNTIME_PM flag, core now simply checks if runtime pm is enabled
for the provided device during clock registration as suggested by Ulf
- Simplified code for exynos4412 isp clock driver registration
- Resolved some other minor issues pointed by Ulf clk core code
- Rebased onto v4.9-rc1 and new version of IOMMU deferred probe patchset
v2: https://www.spinics.net/lists/arm-kernel/msg532798.html
- Simplified clk_pm_runtime_get/put functions, removed workaround for devices
with disabled runtime pm. Such workaround is no longer needed since commit
4d23a5e84806b202d9231929c9507ef7cf7a0185 ("PM / Domains: Allow runtime PM
during system PM phases").
- Added CLK_RUNTIME_PM flag to indicate clocks, for which clock core should
call runtime pm functions. This solves problem with clocks, for which struct
device is already registered, but no runtime pm is enabled.
- Extended commit messages according to Ulf suggestions.
- Fixed some style issues pointed by Barlomiej.
v1: http://www.spinics.net/lists/arm-kernel/msg528128.html
- initial version
Marek Szyprowski (4):
clk: Add support for runtime PM
clk: samsung: Add support for runtime PM
clk: samsung: exynos5433: Add runtime PM support
clk: samsung: exynos-audss: Use runtime PM
.../devicetree/bindings/clock/clk-exynos-audss.txt | 6 +
.../devicetree/bindings/clock/exynos5433-clock.txt | 16 +
drivers/clk/clk.c | 111 +++++-
drivers/clk/samsung/clk-exynos-audss.c | 62 +--
drivers/clk/samsung/clk-exynos5433.c | 415 ++++++++++++++++-----
drivers/clk/samsung/clk-pll.c | 2 +-
drivers/clk/samsung/clk.c | 12 +-
drivers/clk/samsung/clk.h | 7 +
8 files changed, 504 insertions(+), 127 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433
From: Linus Walleij @ 2016-12-30 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230041421.24448-4-andi.shyti@samsung.com>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> instead of hardcoded values.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
These look fine, but that this and the other DTS patch through ARM SoC.
If you also need the headerfile patch (patch 2) to go through ARM SoC
that is fine,
I can take it out of pinctrl if you want.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433
From: Linus Walleij @ 2016-12-30 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230041421.24448-3-andi.shyti@samsung.com>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> values used for configuration") has added a header file for defining the
> pinctrl values in order to avoid hardcoded settings in the Exynos
> DTS related files.
>
> Extend samsung.h to the Exynos5433 for drive strength values
> which are strictly related to the particular SoC and may defer
> from others.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Patch applied with Chanwoo's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/4] pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433
From: Linus Walleij @ 2016-12-30 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230041421.24448-2-andi.shyti@samsung.com>
On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> From: Chanwoo Choi <cw00.choi@samsung.com>
>
> This patch fixes the wrong width of PINCFG_TYPE_DRV bitfields for Exynos5433
> because PINCFG_TYPE_DRV of Exynos5433 has 4bit fields in the *_DRV
> registers. Usually, other Exynos have 2bit field for PINCFG_TYPE_DRV.
>
> Fixes: 3c5ecc9ed353 ("pinctrl: exynos: Add support for Exynos5433")
> Cc: stable at vger.kernel.org
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Nominally I think you should sign this off too Andi, as you are in the delivery
path.
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 10/20] gpio: pca953x: Add optional reset gpio control
From: Linus Walleij @ 2016-12-30 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483050455-10683-11-git-send-email-steve_longerbeam@mentor.com>
On Thu, Dec 29, 2016 at 11:27 PM, Steve Longerbeam
<slongerbeam@gmail.com> wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
This seems like a separate patch from the other 19 patches so please send it
separately so I can handle logistics easier in the future.
> @@ -133,6 +134,7 @@ struct pca953x_chip {
> const char *const *names;
> unsigned long driver_data;
> struct regulator *regulator;
> + struct gpio_desc *reset_gpio;
Why do you even keep this around in the device state container?
As you only use it in the probe() function, use a local variable.
The descriptor will be free():ed by the devm infrastructure anyways.
> + /* see if we need to de-assert a reset pin */
> + chip->reset_gpio = devm_gpiod_get_optional(&client->dev,
> + "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(chip->reset_gpio)) {
> + dev_err(&client->dev, "request for reset pin failed\n");
> + return PTR_ERR(chip->reset_gpio);
> + }
Nice.
> + if (chip->reset_gpio) {
> + /* bring chip out of reset */
> + dev_info(&client->dev, "releasing reset\n");
> + gpiod_set_value(chip->reset_gpio, 0);
> + }
Is this really needed given that you set it low in the
devm_gpiod_get_optional()?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V1] pinctrl:pxa:pinctrl-pxa2xx:- No need of devm functions
From: Linus Walleij @ 2016-12-30 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87o9zvw69a.fsf@belgarion.home>
On Thu, Dec 29, 2016 at 8:20 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>
>> On Thu, Dec 8, 2016 at 3:35 PM, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
>>
>>> In functions pxa2xx_build_functions, the memory allocated for
>>> 'functions' is live within the function only. After the
>>> allocation it is immediately freed with devm_kfree. There is
>>> no need to allocate memory for 'functions' with devm function
>>> so replace devm_kcalloc with kcalloc and devm_kfree with kfree.
>>>
>>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>>
>> I want the maintainer Robert Jarzmik to review this before I do anything
>
> Hi Linus,
>
> I did review, on December the 10th. I wasn't very enthusiastic about the patch,
> if you check back my reply.
Sorry I missed it (mail overload as usual).
OK dropping this.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: single: fix spelling mistakes on "Ivalid"
From: Linus Walleij @ 2016-12-30 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161223004714.7491-1-colin.king@canonical.com>
On Fri, Dec 23, 2016 at 1:47 AM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fixe to spelling mistake "Ivalid" to "Invalid" in
> dev_err error message.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied with Tony's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/3] ARM: dts: imx6ul: Add OCOTP node
From: Shawn Guo @ 2016-12-30 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480689949-17957-2-git-send-email-d.schultz@phytec.de>
On Fri, Dec 02, 2016 at 03:45:48PM +0100, Daniel Schultz wrote:
> This device node adds OCOTP for the i.MX6UL SoC.
>
> Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Bai Ping (Cc'ed here) from NXP is sending similar patches [1]. DTS
change looks good to me, but I will not apply it until the driver and
bindings get accepted.
Shawn
[1] https://www.spinics.net/lists/arm-kernel/msg540900.html
> ---
> arch/arm/boot/dts/imx6ul.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
> index c5c05fd..ee53795 100644
> --- a/arch/arm/boot/dts/imx6ul.dtsi
> +++ b/arch/arm/boot/dts/imx6ul.dtsi
> @@ -849,6 +849,12 @@
> reg = <0x021b0000 0x4000>;
> };
>
> + ocotp: ocotp at 021bc000 {
> + compatible = "fsl,imx6ul-ocotp";
> + reg = <0x021bc000 0x4000>;
> + clocks = <&clks IMX6UL_CLK_OCOTP>;
> + };
> +
> lcdif: lcdif at 021c8000 {
> compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
> reg = <0x021c8000 0x4000>;
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC
From: Linus Walleij @ 2016-12-30 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1280f095-ab03-93f8-14d2-99d13ba1ce55@arm.com>
On Mon, Dec 26, 2016 at 3:33 PM, Andr? Przywara <andre.przywara@arm.com> wrote:
> So while this patch technically looks correct, I was wondering if we
> should really explore the possibility of making the whole of sunxi
> pinctrl DT controlled.
> I brought this up a while ago, but people weren't overly enthusiastic
> about it, though their argument weren't really convincing to me[1].
>
> So:
> As this "driver" here is basically a table linking GPIO bit settings
> (the actual mux value) to names and every pin we care about needs to be
> enumerated in the DT anyway, why not just add something like:
> allwinner,pinmux = <4>;
> to each pin(group) in the DT and get rid of this "driver" file here
> entirely?
I'm open to that if you can use pinctrl-single which is in the kernel
for this purpose only, and is used with both OMAPs and HiSilicon.
It recently was improved and will be improved more in this cycle,
see for example:
commit 42124bc598f64f84b3335d5a058304207695b84f
pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args
> (...) Also I guess the common sunxi
> pinctrl driver code needs some significant rework.
I would guess is just needs replacing with pinctrl-single in that case.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/2] Use macros to describe gpios on rockchip platform
From: Heiko Stuebner @ 2016-12-30 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477140706-6886-1-git-send-email-andy.yan@rock-chips.com>
Am Samstag, 22. Oktober 2016, 20:51:46 CET schrieb Andy Yan:
> As patch 150696e2e3a4("Add GPIO pin index definition for rockchip pinctrl")
> has been applied, now we can use these macros to describe the corresponding
> gpio ranther than hard code numbers, this will make the dts easier to read
> and write.
>
> Some ideas from Krzysztof's patch on EXYNOS[0].
>
> [0]https://lkml.org/lkml/2016/9/4/71
>
>
>
> Andy Yan (2):
> ARM: dts: rockchip: use pin constants to describe gpios
> ARM64: dts: rockchip: use pin constants to describe gpios
applied to dts branches for 4.11
I've also adapted the gpio interrupts accordingly inside the patches.
Thanks
Heiko
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Bas van Tiel @ 2016-12-30 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230151323.583b7ac5@xhacker>
>> Hi,
>>
>> when using a signal handler as a way to context switch between
>> different usercontexts a reproducible exception occurs on my rpi3 in
>> 64-bit mode. (https://gist.github.com/DanGe42/7148946)
>>
>> Running the context_demo program as a 32-bit ARM executable on a
>> 64-bit kernel is OK, running as a 32 || 64 bit executable on an x86
>> kernel is OK.
>>
>> In the first exception the PC doesn?t look correct, and the *pmd is 0.
>> The 2nd exception happens after running the program again, the PC is 0x0.
>>
>> A successful function trace was not possible -> complete kernel hangup
>> when enabling.
>>
>> Is there another way to gather more information about what is happening?
>
> I can reproduce Segmentation fault with your program on Marvell berlin SoCs
> my kernel version is 4.1, I didn't tested 4.9, 4.10-rc1 etc..
>
> Then I increased the STACKSIZE from 4096 to 8192 in context_demo.c,
> everything works fine now. Maybe arm64 need a bit larger signalstack?
>
yes, increased STACKSIZE to 8192 helps on 4.9/4,10-rc1 but after a
while the exception still occurs, although the message is different.
The *pmd is not 0 in this case.
to trigger this scenario:
- INTERVAL set to 500 [ns]
- kernel with maxcpus=0
- start a 'find /' command in the shell in parallel of the program
- stdout, stderr > redirected to file.
[ 850.581983] a.out[173]: unhandled level 3 permission fault (11) at
0x004391f0, esr 0x8200000f
[ 850.591833] pgd = ffffffc039311000
[ 850.596725] [004391f0] *pgd=0000000039340003
[ 850.602145] , *pud=0000000039340003
[ 850.608352] , *pmd=000000003922c003
[ 850.611963] , *pte=00e80000359c0f53
[ 850.618111]
[ 850.621102]
[ 850.624032] CPU: 0 PID: 173 Comm: a.out Not tainted 4.9.0-v8+ #5
[ 850.631314] Hardware name: Raspberry Pi 3 Model B (DT)
[ 850.637925] task: ffffffc039a13100 task.stack: ffffffc039a14000
[ 850.645314] PC is at 0x4391f0
[ 850.649783] LR is at 0x4391f0
[ 850.654035] pc : [<00000000004391f0>] lr : [<00000000004391f0>]
pstate: 60000000
[ 850.662920] sp : 0000000000420da0
[ 850.667516] x29: 00000000004391f0 x28: 0000000000000000
[ 850.677145] x27: 0000000000000000 x26: 0000000000000000
When I taskset the context_demo program to other cores that are
completely isolated (CONFIG_NO_HZ_FULL, isolcpus=1,2,3) it will run
continuously with the modified STACKSIZE.
regards
Bas
^ permalink raw reply
* [BUG] ARM64: amlogic: gxbb: unhandled level 2 translation fault (11)
From: Heinrich Schuchardt @ 2016-12-30 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c91b83af-0eb8-c519-3428-12f34b04d725@baylibre.com>
On 12/30/2016 10:44 AM, Neil Armstrong wrote:
> On 12/30/2016 09:51 AM, Neil Armstrong wrote:
>> On 12/29/2016 10:18 PM, Heinrich Schuchardt wrote:
>>> On 12/29/2016 10:07 AM, Neil Armstrong wrote:
>>>> On 12/24/2016 03:00 PM, Heinrich Schuchardt wrote:
>>>>> When trying to run sddm on an Hardkernel Odroid C2 I invariably run into the
>>>>> translation fault below.
>>>>>
>>>>> The following mail thread relates this kind of problem to TLB (translation
>>>>> lookaside buffer) broadcasting.
>>>>>
>>>>> https://lkml.org/lkml/2014/4/15/207
>>>>>
>>>>> [ 3163.014263] sddm[1851]: unhandled level 2 translation fault (11) at 0x00000160, esr 0x82000006
>>>>> [ 3163.017287] pgd = ffff80007bf86000
>>>>> [ 3163.020589] [00000160] *pgd=000000007a8a3003
>>>>> [ 3163.024733] , *pud=000000007be9c003
>>>>> [ 3163.028095] , *pmd=0000000000000000
>>>>>
>>>>>
>>>>> [ 3163.033026] CPU: 1 PID: 1851 Comm: sddm Not tainted 4.9.0-next-20161212-r022-arm64 #1
>>>>> [ 3163.040831] Hardware name: Hardkernel ODROID-C2 (DT)
>>>>> [ 3163.045698] task: ffff80007bc6d780 task.stack: ffff80007c524000
>>>>> [ 3163.051563] PC is at 0x160
>>>>> [ 3163.054231] LR is at 0xffff9a9fbc98
>>>>> [ 3163.057686] pc : [<0000000000000160>] lr : [<0000ffff9a9fbc98>] pstate: 40000000
>>>>> [ 3163.065022] sp : 0000ffffd7180130
>>>>> [ 3163.068281] x29: 0000ffffd7180130 x28: 0000ffffd7180288
>>>>> [ 3163.073538] x27: 0000ffff9aa94000 x26: 0000000000000001
>>>>> [ 3163.078798] x25: 0000000000000000 x24: 0000ffffd7180410
>>>>> [ 3163.084060] x23: 000000000e0c2190 x22: 000000000e0ca5c0
>>>>> [ 3163.089322] x21: 0000ffff9ac35000 x20: 0000000000454fa9
>>>>> [ 3163.094583] x19: 0000000000454fa8 x18: 000000000e0b5938
>>>>> [ 3163.099843] x17: 0000ffff9a3f2988 x16: 0000ffff9ac36aa0
>>>>> [ 3163.105105] x15: 0000000000000000 x14: 0000000000000000
>>>>> [ 3163.110367] x13: 6d00640064007300 x12: 0800000005000000
>>>>> [ 3163.115627] x11: 0000040000000000 x10: 0000a00000000000
>>>>> [ 3163.120889] x9 : 00003fffffffffff x8 : 0000000000000000
>>>>> [ 3163.126150] x7 : 000000000e0cb520 x6 : 0000000000454fc0
>>>>> [ 3163.131412] x5 : 0000ffffd717ffd8 x4 : 000000000e0cb510
>>>>> [ 3163.136680] x3 : 0000000000000004 x2 : f2f9022b551b3900
>>>>> [ 3163.141935] x1 : 0000000000000160 x0 : 000000000e0ca5c0
>>>>>
>>>>> Best regards
>>>>>
>>>>> Heinrich Schuchardt
>>>>
>>>> Hi Heinrich,
>>>>
>>>> I personally never had this issue even while loading huge applications loke LibreOffice and Gnome environment.
>>>>
>>>> I will have a look and try to reproduce this issue, can you provide us your configuration and user-space complete use case ?
>>>>
>>>> Neil
>>>>
>>>
>>> Hello Neil,
>>>
>>> the kernel is build with
>>> https://github.com/xypron/kernel-odroid-c2/tree/f8d565ff755e92fd585f5ae10123ce20abe03968
>>>
>>> Especially look at the patch directory and config/config-next-20161212.
>>>
>>> The userland is Debian Stretch with this package:
>>> https://packages.debian.org/stretch/sddm
>>>
>>> The link
>>> https://www.spinics.net/lists/arm-kernel/msg550204.html
>>> that you mention in a separate mail just links to this very thread due
>>> to linux-arm-kernel at lists.infradead.org being in copy.
>>>
>>> Best regards
>>>
>>> Heinrich Schuchardt
>>>
>>
>> Hi,
>>
>> Thanks for the details, but why do you use the next-20161212 tag ? does it work with 4.10-rc1 or previous next tags ?
>>
>> Neil
>>
>
> Hi Heinrich,
>
> I'm able to reproduce the bug using SDMM from Ubuntu running a 4.10-rc1 patched with memory zones :
> [ 17.988446] sddm-greeter[2366]: unhandled level 2 translation fault (11) at 0x00000000, esr 0x92000006
> [ 17.988451] pgd = ffff80003c3ee000
> [ 17.988472] [00000000] *pgd=00000000398bd003
> [ 17.988474] , *pud=00000000398bf003
> [ 17.990477] , *pmd=0000000000000000
>
>
> [ 17.990485] CPU: 3 PID: 2366 Comm: sddm-greeter Not tainted 4.10.0-rc1-00004-gd3f812382-dirty #488
> [ 17.990487] Hardware name: Amlogic Meson GXBB P200 Development Board (DT)
> [ 17.990489] task: ffff80003c160000 task.stack: ffff80003c314000
> [ 17.990493] PC is at 0xffffb2999994
> [ 17.990495] LR is at 0xffffb299f774
> [ 17.990497] pc : [<0000ffffb2999994>] lr : [<0000ffffb299f774>] pstate: 20000000
> [ 17.990503] sp : 0000ffffd2d1d5b0
> [ 17.990504] x29: 0000ffffd2d1d5b0 x28: 0000ffffad10e010
> [ 17.990508] x27: 0000000009c376d0 x26: 0000000000000001
> [ 17.990511] x25: 0000ffffb2b67000 x24: 0000ffffad10e010
> [ 17.990514] x23: 0000000000000000 x22: 0000000000000000
> [ 17.990517] x21: 0000000009c376d0 x20: 0000ffffb2fcdcb8
> [ 17.990520] x19: 0000ffffb2b2b000 x18: 0000000009c78450
> [ 17.990523] x17: 0000ffffb2b68068 x16: 0000ffffb2022158
> [ 17.990526] x15: 0000ffffb2fcd000 x14: 0000000000000000
> [ 17.990529] x13: aaaaaaaaaaaaaaab x12: 0000000000010000
> [ 17.990532] x11: 0000000000000008 x10: 0000000009c3b980
> [ 17.990535] x9 : 0000000009c38c40 x8 : 0000ffffd2d1d4e0
> [ 17.990538] x7 : 0000000000000000 x6 : 0000000009c3b998
> [ 17.990541] x5 : 0000000009c3b980 x4 : 0000800000000000
> [ 17.990544] x3 : 00000000fffffff0 x2 : 0000ffffad10e010
> [ 17.990547] x1 : 0000000009c379d8 x0 : 0000000000000000
>
> Looking about other occurrence of such error, it seems it may be a issue from sdmm instead.
>
> I'll continue searching,
> Neil
>
>
Hello Neil,
I am seeing a simular error when I try to use x2go
to have a remote desktop on the Odroid C2.
[47912.997112] fuse init (API version 7.26)
[47913.405815] x2goagent[28395]: unhandled level 0 translation fault
(11) at 0x3042415a74614c, esr 0x82000004
[47913.409849] pgd = ffff800079a11000
[47913.413704] [3042415a74614c] *pgd=0000000000000000
[47913.420673] CPU: 1 PID: 28395 Comm: x2goagent Not tainted
4.9.0-next-20161212-r024-arm64 #1
[47913.428992] Hardware name: Hardkernel ODROID-C2 (DT)
[47913.433906] task: ffff80007c670000 task.stack: ffff800079e6c000
[47913.439747] PC is at 0x3042415a74614c
[47913.443400] LR is at 0x323042415a74614c
[47913.447194] pc : [<003042415a74614c>] lr : [<323042415a74614c>]
pstate: 80000000
[47913.454528] sp : 0000ffffd7240140
[47913.457789] x29: 313042414c74614c x28: 000000000000007f
[47913.463016] x27: 000000000000007f x26: 0000000000000001
[47913.468278] x25: 0000000000000000 x24: 0000aaaaee52a7e0
[47913.473540] x23: 0000ffffd7240310 x22: 363042414274614c
[47913.478800] x21: 353042415674614c x20: 343042414374614c
[47913.484061] x19: 333042415874614c x18: 0000000000000000
[47913.489324] x17: 0000ffffb1ce2da0 x16: 0000000000000000
[47913.494589] x15: 0000000000000434 x14: 000000000000001f
[47913.499852] x13: 0000aaaa00703f00 x12: 0000003ff8081fff
[47913.505114] x11: 0000000000000000 x10: 0000000000000002
[47913.510373] x9 : 0000000000000010 x8 : 0000000000000042
[47913.515633] x7 : 011cff0800001fff x6 : 0000022300090101
[47913.520904] x5 : 000000000000088c x4 : 0000000000000007
[47913.526158] x3 : 0000aaaae52c1db0 x2 : 0000aaaae573a5a0
[47913.531417] x1 : 0000000000000000 x0 : 0000000000000000
Best regards
Heinrich Schuchardt
^ permalink raw reply
* [PATCH] drivers: remoteproc: constify rproc_ops structures
From: Bjorn Andersson @ 2016-12-30 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481974176-19912-1-git-send-email-bhumirks@gmail.com>
On Sat 17 Dec 03:29 PST 2016, Bhumika Goyal wrote:
> Declare rproc_ops structures as const as they are only passed as an
> argument to the function rproc_alloc. This argument is of type const, so
> rproc_ops structures having this property can be declared const too.
> Done using Coccinelle:
>
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct rproc_ops i at p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> @@
> rproc_alloc(...,&i at p,...)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i at p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct rproc_ops i;
>
> File sizes before:
> text data bss dec hex filename
> 1258 416 0 1674 68a remoteproc/omap_remoteproc.o
> 2402 240 0 2642 a52 remoteproc/st_remoteproc.o
> 2064 272 0 2336 920 remoteproc/st_slim_rproc.o
> 2160 240 0 2400 960 remoteproc/wkup_m3_rproc.o
>
> File sizes after:
> text data bss dec hex filename
> 1297 368 0 1665 681 remoteproc/omap_remoteproc.o
> 2434 192 0 2626 a42 remoteproc/st_remoteproc.o
> 2112 240 0 2352 930 remoteproc/st_slim_rproc.o
> 2200 192 0 2392 958 remoteproc/wkup_m3_rproc.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Thanks Bhumika, this looks good.
But as Suman already asked. Is there any reason why da8xx_remoteproc.c
did not get updated? It looks like the same change would apply there.
Unless I'm missing something, please update the patch and I'll be happy
to apply it.
Regards,
Bjorn
^ permalink raw reply
* [PATCH 2/2] ARM: imx: Add speed grading check for imx6ul
From: Shawn Guo @ 2016-12-30 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480475098-2037-2-git-send-email-ping.bai@nxp.com>
On Wed, Nov 30, 2016 at 11:04:58AM +0800, Bai Ping wrote:
> On i.MX6UL, it has two type of part, the difference
> is the max ARM frequency that can run at(528MHz/700MHz).
> The part can be identified by part marking for speed grading
> fuse. This patch add speed grading check to disable the unsupported
> OPP dynamically.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
We chose to handle such speed grading thing in IMX platform code with
the assumption that this is a special case for i.MX6Q only. No, I'm not
going to take such code for any other i.MX6 SoCs. Please patch cpufreq
driver to handle the speed grading check.
Shawn
^ permalink raw reply
* [PATCH 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Marek Szyprowski @ 2016-12-30 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227153331.jbh7ei6oh3obmnri@kozik-lap>
Hi Krzysztof,
On 2016-12-27 16:33, Krzysztof Kozlowski wrote:
> On Tue, Dec 27, 2016 at 11:30:57AM +0100, Marek Szyprowski wrote:
>> On 2016-12-25 20:19, Krzysztof Kozlowski wrote:
>>> On Fri, Dec 23, 2016 at 01:24:47PM +0100, Marek Szyprowski wrote:
>>>> Add support for special property "samsung,off-state", which indicates a special
>>>> state suitable for device's "sleep" state. Its pin values/properties should
>>>> match the configuration in power down mode. It indicates that pin controller
>>>> can notify runtime power management subsystem, that it is ready for runtime
>>>> suspend if its all pins are configured for such state. This in turn might
>>>> allow to turn respective power domain off to reduce power consumption.
>>>>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> ---
>>>> Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 8 ++++++++
>>>> drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++++
>>>> drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
>>>> 3 files changed, 13 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> index b7bd2e12a269..354eea0e7798 100644
>>>> --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>>>> @@ -105,6 +105,7 @@ Required Properties:
>>>> - samsung,pin-drv: Drive strength configuration.
>>>> - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
>>>> - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
>>>> + - samsung,off-state: Mark this configuration as suitable for bank power off.
>>>> The values specified by these config properties should be derived from the
>>>> hardware manual and these values are programmed as-is into the pin
>>>> @@ -113,6 +114,13 @@ Required Properties:
>>>> Note: A child should include atleast a pin function selection property or
>>>> pin configuration property (one or more) or both.
>>>> + Note: Special property "samsung,off-state" indicates that this state can
>>>> + be used for device's "sleep" pins state. Its pin values/properties should
>>>> + match the configuration in power down mode.
>>> Why power down values cannot be used for sleep state? Why you need
>>> separate pin control state? If pins values should match power down
>>> configuration, then they could just be added to default state, couldn't
>>> they?
>> Separate sleep state is needed because of the pin control bindings and
>> design.
>>
>> A separate sleep state is required to let pin control client driver (in this
>> case
>> Exynos I2S driver) let to choose when it is okay to switch pads into sleep
>> state and I see no other way to achieve this.
> Maybe the pinctrl API should be extended for this? Doing this in DTS
> just for purpose of passing information between drivers (consumer and
> provider) looks odd.
Well, I don't know if it is odd or not, but that's how it is used now
and I see
no reason to reinvent wheel. Please check it yourself:
$ git grep \"sleep\" arch/arm/boot/dts | wc -l
101
> Anyway, you are proposing a new binding so please Cc devicetree mailing
> list and device tree maintainers.
I'm just using the generic pinctrl bindings, but it might make some sense to
add a note to Exynos i2s driver that a sleep pin control state is needed if
one wants to get power domain to be turned off.
>>> In the patch 2/9, existing configuration:
>>> 716 i2s0_bus: i2s0-bus {
>>> (...)
>>> 719 samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
>>> 720 samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
>>> 721 samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
>>> 722 };
>>>
>>> additional configuration:
>>> + i2s0_bus_slp: i2s0-bus-slp {
>>> + samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
>>> + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
>>> + samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
>>> + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>;
>>> + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
>>> + samsung,off-state;
>>> + };
>> I agree that it would be possible to get rid of "samsung,off-state" property
>> and
>> just detect off state when func/pud pair matches power down func/pud.
>>
>>>> It indicates that pin control
>>>> + can notify runtime power management subsystem, that it is ready for runtime
>>>> + suspend if its all pins are configured for such state. This in turn might
>>>> + allow to turn respective power domain off to reduce power consumption.
>>> What do you mean by "notifying RPM subsystem"? Either this is
>>> description of hardware in certain mode (sleep state) or this is not
>>> device tree property.
>> Maybe I wrote the description with a view too limited to the kernel
>> operation
>> perspective, but if we remove the need to mark state as off, the above
>> description
>> will not be needed.
> But still it wouldn't be describing any hardware property, would it?
Well, it somehow describes the hardware, because the pin state when it
is allowed
to turn off the power domain is board specific. I should move that part
to the
Odroid dts, because there might be a board which require other pin
values in power
down mode.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v2 6/6] ARM: mach-mx27_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit 6b879edf75b316 ("[media] staging/media: remove deprecated
mx2 driver") the mx2 camera driver has been removed, so remove the camera
support from the board file as well.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Also remove CSI pins from IOMUX definition
arch/arm/mach-imx/mach-mx27_3ds.c | 107 --------------------------------------
1 file changed, 107 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
index 7ba651a..45e16bd 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -31,7 +31,6 @@
#include <linux/regulator/machine.h>
#include <linux/spi/l4f00242t03.h>
-#include <media/soc_camera.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -53,8 +52,6 @@
#define SD1_CD IMX_GPIO_NR(2, 26)
#define LCD_RESET IMX_GPIO_NR(1, 3)
#define LCD_ENABLE IMX_GPIO_NR(1, 31)
-#define CSI_PWRDWN IMX_GPIO_NR(4, 19)
-#define CSI_RESET IMX_GPIO_NR(3, 6)
static const int mx27pdk_pins[] __initconst = {
/* UART1 */
@@ -144,21 +141,6 @@ static const int mx27pdk_pins[] __initconst = {
PA30_PF_CONTRAST,
LCD_ENABLE | GPIO_GPIO | GPIO_OUT,
LCD_RESET | GPIO_GPIO | GPIO_OUT,
- /* CSI */
- PB10_PF_CSI_D0,
- PB11_PF_CSI_D1,
- PB12_PF_CSI_D2,
- PB13_PF_CSI_D3,
- PB14_PF_CSI_D4,
- PB15_PF_CSI_MCLK,
- PB16_PF_CSI_PIXCLK,
- PB17_PF_CSI_D5,
- PB18_PF_CSI_D6,
- PB19_PF_CSI_D7,
- PB20_PF_CSI_VSYNC,
- PB21_PF_CSI_HSYNC,
- CSI_PWRDWN | GPIO_GPIO | GPIO_OUT,
- CSI_RESET | GPIO_GPIO | GPIO_OUT,
/* SSI4 */
PC16_PF_SSI4_FS,
PC17_PF_SSI4_RXD,
@@ -166,11 +148,6 @@ static const int mx27pdk_pins[] __initconst = {
PC19_PF_SSI4_CLK,
};
-static struct gpio mx27_3ds_camera_gpios[] = {
- { CSI_PWRDWN, GPIOF_OUT_INIT_HIGH, "camera-power" },
- { CSI_RESET, GPIOF_OUT_INIT_HIGH, "camera-reset" },
-};
-
static const struct imxuart_platform_data uart_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
@@ -270,7 +247,6 @@ static struct regulator_init_data gpo_init = {
static struct regulator_consumer_supply vmmc1_consumers[] = {
REGULATOR_SUPPLY("vcore", "spi0.0"),
- REGULATOR_SUPPLY("cmos_2v8", "soc-camera-pdrv.0"),
};
static struct regulator_init_data vmmc1_init = {
@@ -299,22 +275,6 @@ static struct regulator_init_data vgen_init = {
.consumer_supplies = vgen_consumers,
};
-static struct regulator_consumer_supply vvib_consumers[] = {
- REGULATOR_SUPPLY("cmos_vcore", "soc-camera-pdrv.0"),
-};
-
-static struct regulator_init_data vvib_init = {
- .constraints = {
- .min_uV = 1300000,
- .max_uV = 1300000,
- .apply_uV = 1,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE |
- REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(vvib_consumers),
- .consumer_supplies = vvib_consumers,
-};
-
static struct mc13xxx_regulator_init_data mx27_3ds_regulators[] = {
{
.id = MC13783_REG_VMMC1,
@@ -328,9 +288,6 @@ static struct mc13xxx_regulator_init_data mx27_3ds_regulators[] = {
}, {
.id = MC13783_REG_GPO3, /* Turn on 3.3V */
.init_data = &gpo_init,
- }, {
- .id = MC13783_REG_VVIB, /* Power OV2640 */
- .init_data = &vvib_init,
},
};
@@ -370,51 +327,6 @@ static const struct spi_imx_master spi2_pdata __initconst = {
.num_chipselect = ARRAY_SIZE(spi2_chipselect),
};
-static int mx27_3ds_camera_power(struct device *dev, int on)
-{
- /* enable or disable the camera */
- pr_debug("%s: %s the camera\n", __func__, on ? "ENABLE" : "DISABLE");
- gpio_set_value(CSI_PWRDWN, on ? 0 : 1);
-
- if (!on)
- goto out;
-
- /* If enabled, give a reset impulse */
- gpio_set_value(CSI_RESET, 0);
- msleep(20);
- gpio_set_value(CSI_RESET, 1);
- msleep(100);
-
-out:
- return 0;
-}
-
-static struct i2c_board_info mx27_3ds_i2c_camera = {
- I2C_BOARD_INFO("ov2640", 0x30),
-};
-
-static struct regulator_bulk_data mx27_3ds_camera_regs[] = {
- { .supply = "cmos_vcore" },
- { .supply = "cmos_2v8" },
-};
-
-static struct soc_camera_link iclink_ov2640 = {
- .bus_id = 0,
- .board_info = &mx27_3ds_i2c_camera,
- .i2c_adapter_id = 0,
- .power = mx27_3ds_camera_power,
- .regulators = mx27_3ds_camera_regs,
- .num_regulators = ARRAY_SIZE(mx27_3ds_camera_regs),
-};
-
-static struct platform_device mx27_3ds_ov2640 = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &iclink_ov2640,
- },
-};
-
static struct imx_fb_videomode mx27_3ds_modes[] = {
{ /* 480x640 @ 60 Hz */
.mode = {
@@ -471,14 +383,6 @@ static struct spi_board_info mx27_3ds_spi_devs[] __initdata = {
},
};
-static struct platform_device *devices[] __initdata = {
- &mx27_3ds_ov2640,
-};
-
-static const struct mx2_camera_platform_data mx27_3ds_cam_pdata __initconst = {
- .clk = 26000000,
-};
-
static const struct imxi2c_platform_data mx27_3ds_i2c0_data __initconst = {
.bitrate = 100000,
};
@@ -498,7 +402,6 @@ static void __init mx27pdk_init(void)
imx27_add_spi_imx0(&spi1_pdata);
imx27_add_imx_i2c(0, &mx27_3ds_i2c0_data);
- platform_add_devices(devices, ARRAY_SIZE(devices));
imx27_add_imx_fb(&mx27_3ds_fb_data);
imx27_add_imx_ssi(0, &mx27_3ds_ssi_pdata);
@@ -506,8 +409,6 @@ static void __init mx27pdk_init(void)
static void __init mx27pdk_late_init(void)
{
- int ret;
-
mx27_3ds_sdhc1_enable_level_translator();
imx27_add_mxc_mmc(0, &sdhc1_pdata);
@@ -531,14 +432,6 @@ static void __init mx27pdk_late_init(void)
if (mxc_expio_init(MX27_CS5_BASE_ADDR, IMX_GPIO_NR(3, 28)))
pr_warn("Init of the debugboard failed, all devices on the debugboard are unusable.\n");
- ret = gpio_request_array(mx27_3ds_camera_gpios,
- ARRAY_SIZE(mx27_3ds_camera_gpios));
- if (ret) {
- pr_err("Failed to request camera gpios");
- iclink_ov2640.power = NULL;
- }
-
- imx27_add_mx2_camera(&mx27_3ds_cam_pdata);
imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/6] ARM: mach-pcm037: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
mx3 driver") the mx3 camera driver has been removed, so remove the camera
support from the board file as well.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Also remove CSI pins from IOMUX definition
arch/arm/mach-imx/mach-pcm037.c | 115 ----------------------------------------
1 file changed, 115 deletions(-)
diff --git a/arch/arm/mach-imx/mach-pcm037.c b/arch/arm/mach-imx/mach-pcm037.c
index 9f0f55b..b787ba6 100644
--- a/arch/arm/mach-imx/mach-pcm037.c
+++ b/arch/arm/mach-imx/mach-pcm037.c
@@ -31,17 +31,13 @@
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
#include <linux/gfp.h>
-#include <linux/memblock.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
-#include <media/soc_camera.h>
-
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
#include <asm/mach/map.h>
-#include <asm/memblock.h>
#include "common.h"
#include "devices-imx31.h"
@@ -150,22 +146,6 @@ static unsigned int pcm037_pins[] = {
MX31_PIN_D3_SPL__D3_SPL,
MX31_PIN_D3_CLS__D3_CLS,
MX31_PIN_LCS0__GPIO3_23,
- /* CSI */
- IOMUX_MODE(MX31_PIN_CSI_D5, IOMUX_CONFIG_GPIO),
- MX31_PIN_CSI_D6__CSI_D6,
- MX31_PIN_CSI_D7__CSI_D7,
- MX31_PIN_CSI_D8__CSI_D8,
- MX31_PIN_CSI_D9__CSI_D9,
- MX31_PIN_CSI_D10__CSI_D10,
- MX31_PIN_CSI_D11__CSI_D11,
- MX31_PIN_CSI_D12__CSI_D12,
- MX31_PIN_CSI_D13__CSI_D13,
- MX31_PIN_CSI_D14__CSI_D14,
- MX31_PIN_CSI_D15__CSI_D15,
- MX31_PIN_CSI_HSYNC__CSI_HSYNC,
- MX31_PIN_CSI_MCLK__CSI_MCLK,
- MX31_PIN_CSI_PIXCLK__CSI_PIXCLK,
- MX31_PIN_CSI_VSYNC__CSI_VSYNC,
/* GPIO */
IOMUX_MODE(MX31_PIN_ATA_DMACK, IOMUX_CONFIG_GPIO),
/* OTG */
@@ -289,34 +269,6 @@ static struct at24_platform_data board_eeprom = {
.flags = AT24_FLAG_ADDR16,
};
-static int pcm037_camera_power(struct device *dev, int on)
-{
- /* disable or enable the camera in X7 or X8 PCM970 connector */
- gpio_set_value(IOMUX_TO_GPIO(MX31_PIN_CSI_D5), !on);
- return 0;
-}
-
-static struct i2c_board_info pcm037_i2c_camera[] = {
- {
- I2C_BOARD_INFO("mt9t031", 0x5d),
- }, {
- I2C_BOARD_INFO("mt9v022", 0x48),
- },
-};
-
-static struct soc_camera_link iclink_mt9v022 = {
- .bus_id = 0, /* Must match with the camera ID */
- .board_info = &pcm037_i2c_camera[1],
- .i2c_adapter_id = 2,
-};
-
-static struct soc_camera_link iclink_mt9t031 = {
- .bus_id = 0, /* Must match with the camera ID */
- .power = pcm037_camera_power,
- .board_info = &pcm037_i2c_camera[0],
- .i2c_adapter_id = 2,
-};
-
static struct i2c_board_info pcm037_i2c_devices[] = {
{
I2C_BOARD_INFO("at24", 0x52), /* E0=0, E1=1, E2=0 */
@@ -326,22 +278,6 @@ static struct i2c_board_info pcm037_i2c_devices[] = {
}
};
-static struct platform_device pcm037_mt9t031 = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &iclink_mt9t031,
- },
-};
-
-static struct platform_device pcm037_mt9v022 = {
- .name = "soc-camera-pdrv",
- .id = 1,
- .dev = {
- .platform_data = &iclink_mt9v022,
- },
-};
-
/* Not connected by default */
#ifdef PCM970_SDHC_RW_SWITCH
static int pcm970_sdhc1_get_ro(struct device *dev)
@@ -403,42 +339,9 @@ static const struct imxmmc_platform_data sdhc_pdata __initconst = {
.exit = pcm970_sdhc1_exit,
};
-struct mx3_camera_pdata camera_pdata __initdata = {
- .flags = MX3_CAMERA_DATAWIDTH_8 | MX3_CAMERA_DATAWIDTH_10,
- .mclk_10khz = 2000,
-};
-
-static phys_addr_t mx3_camera_base __initdata;
-#define MX3_CAMERA_BUF_SIZE SZ_4M
-
-static int __init pcm037_init_camera(void)
-{
- int dma, ret = -ENOMEM;
- struct platform_device *pdev = imx31_alloc_mx3_camera(&camera_pdata);
-
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- dma = dma_declare_coherent_memory(&pdev->dev,
- mx3_camera_base, mx3_camera_base,
- MX3_CAMERA_BUF_SIZE,
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
- if (!(dma & DMA_MEMORY_MAP))
- goto err;
-
- ret = platform_device_add(pdev);
- if (ret)
-err:
- platform_device_put(pdev);
-
- return ret;
-}
-
static struct platform_device *devices[] __initdata = {
&pcm037_flash,
&pcm037_sram_device,
- &pcm037_mt9t031,
- &pcm037_mt9v022,
};
static const struct fb_videomode fb_modedb[] = {
@@ -651,13 +554,6 @@ static void __init pcm037_timer_init(void)
mx31_clocks_init(26000000);
}
-static void __init pcm037_reserve(void)
-{
- /* reserve 4 MiB for mx3-camera */
- mx3_camera_base = arm_memblock_steal(MX3_CAMERA_BUF_SIZE,
- MX3_CAMERA_BUF_SIZE);
-}
-
static void __init pcm037_init_late(void)
{
int ret;
@@ -677,16 +573,6 @@ static void __init pcm037_init_late(void)
imx31_add_mxc_mmc(0, &sdhc_pdata);
- /* CSI */
- /* Camera power: default - off */
- ret = gpio_request(IOMUX_TO_GPIO(MX31_PIN_CSI_D5), "mt9t031-power");
- if (!ret)
- gpio_direction_output(IOMUX_TO_GPIO(MX31_PIN_CSI_D5), 1);
- else
- iclink_mt9t031.power = NULL;
-
- pcm037_init_camera();
-
pcm970_sja1000_resources[1].start =
gpio_to_irq(IOMUX_TO_GPIO(IOMUX_PIN(48, 105)));
pcm970_sja1000_resources[1].end =
@@ -699,7 +585,6 @@ static void __init pcm037_init_late(void)
MACHINE_START(PCM037, "Phytec Phycore pcm037")
/* Maintainer: Pengutronix */
.atag_offset = 0x100,
- .reserve = pcm037_reserve,
.map_io = mx31_map_io,
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/6] ARM: mach-mx35_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
mx3 driver") the mx3 camera driver has been removed, so remove the camera
support from the board file as well.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Also remove CSI pins from IOMUX definition
arch/arm/mach-imx/mach-mx35_3ds.c | 103 --------------------------------------
1 file changed, 103 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c b/arch/arm/mach-imx/mach-mx35_3ds.c
index c8c2e09..1c33a6c 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -41,12 +41,9 @@
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
#include <asm/mach/map.h>
-#include <asm/memblock.h>
#include <video/platform_lcd.h>
-#include <media/soc_camera.h>
-
#include "3ds_debugboard.h"
#include "common.h"
#include "devices-imx35.h"
@@ -233,83 +230,10 @@ static const iomux_v3_cfg_t mx35pdk_pads[] __initconst = {
MX35_PAD_D3_VSYNC__IPU_DISPB_D3_VSYNC,
MX35_PAD_D3_REV__IPU_DISPB_D3_REV,
MX35_PAD_D3_CLS__IPU_DISPB_D3_CLS,
- /* CSI */
- MX35_PAD_TX1__IPU_CSI_D_6,
- MX35_PAD_TX0__IPU_CSI_D_7,
- MX35_PAD_CSI_D8__IPU_CSI_D_8,
- MX35_PAD_CSI_D9__IPU_CSI_D_9,
- MX35_PAD_CSI_D10__IPU_CSI_D_10,
- MX35_PAD_CSI_D11__IPU_CSI_D_11,
- MX35_PAD_CSI_D12__IPU_CSI_D_12,
- MX35_PAD_CSI_D13__IPU_CSI_D_13,
- MX35_PAD_CSI_D14__IPU_CSI_D_14,
- MX35_PAD_CSI_D15__IPU_CSI_D_15,
- MX35_PAD_CSI_HSYNC__IPU_CSI_HSYNC,
- MX35_PAD_CSI_MCLK__IPU_CSI_MCLK,
- MX35_PAD_CSI_PIXCLK__IPU_CSI_PIXCLK,
- MX35_PAD_CSI_VSYNC__IPU_CSI_VSYNC,
/*PMIC IRQ*/
MX35_PAD_GPIO2_0__GPIO2_0,
};
-/*
- * Camera support
-*/
-static phys_addr_t mx3_camera_base __initdata;
-#define MX35_3DS_CAMERA_BUF_SIZE SZ_8M
-
-static const struct mx3_camera_pdata mx35_3ds_camera_pdata __initconst = {
- .flags = MX3_CAMERA_DATAWIDTH_8,
- .mclk_10khz = 2000,
-};
-
-static int __init imx35_3ds_init_camera(void)
-{
- int dma, ret = -ENOMEM;
- struct platform_device *pdev =
- imx35_alloc_mx3_camera(&mx35_3ds_camera_pdata);
-
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- if (!mx3_camera_base)
- goto err;
-
- dma = dma_declare_coherent_memory(&pdev->dev,
- mx3_camera_base, mx3_camera_base,
- MX35_3DS_CAMERA_BUF_SIZE,
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
-
- if (!(dma & DMA_MEMORY_MAP))
- goto err;
-
- ret = platform_device_add(pdev);
- if (ret)
-err:
- platform_device_put(pdev);
-
- return ret;
-}
-
-static struct i2c_board_info mx35_3ds_i2c_camera = {
- I2C_BOARD_INFO("ov2640", 0x30),
-};
-
-static struct soc_camera_link iclink_ov2640 = {
- .bus_id = 0,
- .board_info = &mx35_3ds_i2c_camera,
- .i2c_adapter_id = 0,
- .power = NULL,
-};
-
-static struct platform_device mx35_3ds_ov2640 = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &iclink_ov2640,
- },
-};
-
static struct regulator_consumer_supply sw1_consumers[] = {
{
.supply = "cpu_vcc",
@@ -321,10 +245,6 @@ static struct regulator_consumer_supply vcam_consumers[] = {
REGULATOR_SUPPLY("VDDA", "0-000a"),
};
-static struct regulator_consumer_supply vaudio_consumers[] = {
- REGULATOR_SUPPLY("cmos_vio", "soc-camera-pdrv.0"),
-};
-
static struct regulator_init_data sw1_init = {
.constraints = {
.name = "SW1",
@@ -405,18 +325,6 @@ static struct regulator_init_data vvideo_init = {
}
};
-static struct regulator_init_data vaudio_init = {
- .constraints = {
- .name = "VAUDIO",
- .min_uV = 2300000,
- .max_uV = 3000000,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
- .boot_on = 1
- },
- .num_consumer_supplies = ARRAY_SIZE(vaudio_consumers),
- .consumer_supplies = vaudio_consumers,
-};
-
static struct regulator_init_data vcam_init = {
.constraints = {
.name = "VCAM",
@@ -460,7 +368,6 @@ static struct mc13xxx_regulator_init_data mx35_3ds_regulators[] = {
{ .id = MC13892_VDIG, .init_data = &vdig_init },
{ .id = MC13892_VUSB2, .init_data = &vusb2_init },
{ .id = MC13892_VVIDEO, .init_data = &vvideo_init },
- { .id = MC13892_VAUDIO, .init_data = &vaudio_init },
{ .id = MC13892_VCAM, .init_data = &vcam_init },
{ .id = MC13892_VGEN1, .init_data = &vgen1_init },
{ .id = MC13892_VGEN2, .init_data = &vgen2_init },
@@ -583,8 +490,6 @@ static void __init mx35_3ds_init(void)
0, i2c_devices_3ds, ARRAY_SIZE(i2c_devices_3ds));
imx35_add_ipu_core();
- platform_device_register(&mx35_3ds_ov2640);
- imx35_3ds_init_camera();
}
static void __init mx35_3ds_late_init(void)
@@ -607,13 +512,6 @@ static void __init mx35pdk_timer_init(void)
mx35_clocks_init();
}
-static void __init mx35_3ds_reserve(void)
-{
- /* reserve MX35_3DS_CAMERA_BUF_SIZE bytes for mx3-camera */
- mx3_camera_base = arm_memblock_steal(MX35_3DS_CAMERA_BUF_SIZE,
- MX35_3DS_CAMERA_BUF_SIZE);
-}
-
MACHINE_START(MX35_3DS, "Freescale MX35PDK")
/* Maintainer: Freescale Semiconductor, Inc */
.atag_offset = 0x100,
@@ -623,6 +521,5 @@ MACHINE_START(MX35_3DS, "Freescale MX35PDK")
.init_time = mx35pdk_timer_init,
.init_machine = mx35_3ds_init,
.init_late = mx35_3ds_late_init,
- .reserve = mx35_3ds_reserve,
.restart = mxc_restart,
MACHINE_END
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/6] ARM: mx31moboard-smartbot: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
mx3 driver") the mx3 camera driver has been removed, so remove the camera
support from the board file as well.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Also remove CSI pins from IOMUX definition
arch/arm/mach-imx/mx31moboard-smartbot.c | 74 --------------------------------
1 file changed, 74 deletions(-)
diff --git a/arch/arm/mach-imx/mx31moboard-smartbot.c b/arch/arm/mach-imx/mx31moboard-smartbot.c
index 89fc35a..5cdd7ab 100644
--- a/arch/arm/mach-imx/mx31moboard-smartbot.c
+++ b/arch/arm/mach-imx/mx31moboard-smartbot.c
@@ -23,8 +23,6 @@
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
-#include <media/soc_camera.h>
-
#include "board-mx31moboard.h"
#include "common.h"
#include "devices-imx31.h"
@@ -37,16 +35,6 @@ static unsigned int smartbot_pins[] = {
/* UART1 */
MX31_PIN_CTS2__CTS2, MX31_PIN_RTS2__RTS2,
MX31_PIN_TXD2__TXD2, MX31_PIN_RXD2__RXD2,
- /* CSI */
- MX31_PIN_CSI_D4__CSI_D4, MX31_PIN_CSI_D5__CSI_D5,
- MX31_PIN_CSI_D6__CSI_D6, MX31_PIN_CSI_D7__CSI_D7,
- MX31_PIN_CSI_D8__CSI_D8, MX31_PIN_CSI_D9__CSI_D9,
- MX31_PIN_CSI_D10__CSI_D10, MX31_PIN_CSI_D11__CSI_D11,
- MX31_PIN_CSI_D12__CSI_D12, MX31_PIN_CSI_D13__CSI_D13,
- MX31_PIN_CSI_D14__CSI_D14, MX31_PIN_CSI_D15__CSI_D15,
- MX31_PIN_CSI_HSYNC__CSI_HSYNC, MX31_PIN_CSI_MCLK__CSI_MCLK,
- MX31_PIN_CSI_PIXCLK__CSI_PIXCLK, MX31_PIN_CSI_VSYNC__CSI_VSYNC,
- MX31_PIN_GPIO3_0__GPIO3_0, MX31_PIN_GPIO3_1__GPIO3_1,
/* ENABLES */
MX31_PIN_DTR_DCE1__GPIO2_8, MX31_PIN_DSR_DCE1__GPIO2_9,
MX31_PIN_RI_DCE1__GPIO2_10, MX31_PIN_DCD_DCE1__GPIO2_11,
@@ -56,65 +44,6 @@ static const struct imxuart_platform_data uart_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
-#define CAM_POWER IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)
-#define CAM_RST_B IOMUX_TO_GPIO(MX31_PIN_GPIO3_0)
-
-static int smartbot_cam_power(struct device *dev, int on)
-{
- gpio_set_value(CAM_POWER, !on);
- return 0;
-}
-
-static int smartbot_cam_reset(struct device *dev)
-{
- gpio_set_value(CAM_RST_B, 0);
- udelay(100);
- gpio_set_value(CAM_RST_B, 1);
- return 0;
-}
-
-static struct i2c_board_info smartbot_i2c_devices[] = {
- {
- I2C_BOARD_INFO("mt9t031", 0x5d),
- },
-};
-
-static struct soc_camera_link base_iclink = {
- .bus_id = 0, /* Must match with the camera ID */
- .power = smartbot_cam_power,
- .reset = smartbot_cam_reset,
- .board_info = &smartbot_i2c_devices[0],
- .i2c_adapter_id = 0,
-};
-
-static struct platform_device smartbot_camera[] = {
- {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &base_iclink,
- },
- },
-};
-
-static struct platform_device *smartbot_cameras[] __initdata = {
- &smartbot_camera[0],
-};
-
-static int __init smartbot_cam_init(void)
-{
- int ret = gpio_request(CAM_RST_B, "cam-reset");
- if (ret)
- return ret;
- gpio_direction_output(CAM_RST_B, 1);
- ret = gpio_request(CAM_POWER, "cam-standby");
- if (ret)
- return ret;
- gpio_direction_output(CAM_POWER, 0);
-
- return 0;
-}
-
static const struct fsl_usb2_platform_data usb_pdata __initconst = {
.operating_mode = FSL_USB2_DR_DEVICE,
.phy_mode = FSL_USB2_PHY_ULPI,
@@ -201,7 +130,4 @@ void __init mx31moboard_smartbot_init(int board)
}
smartbot_resets_init();
-
- smartbot_cam_init();
- platform_add_devices(smartbot_cameras, ARRAY_SIZE(smartbot_cameras));
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/6] ARM: mx31moboard-marxbot: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
mx3 driver") the mx3 camera driver has been removed, so remove the camera
support from the board file as well.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Also remove CSI pins from IOMUX definition
arch/arm/mach-imx/mx31moboard-marxbot.c | 92 ---------------------------------
1 file changed, 92 deletions(-)
diff --git a/arch/arm/mach-imx/mx31moboard-marxbot.c b/arch/arm/mach-imx/mx31moboard-marxbot.c
index 2e895a8..922d491 100644
--- a/arch/arm/mach-imx/mx31moboard-marxbot.c
+++ b/arch/arm/mach-imx/mx31moboard-marxbot.c
@@ -24,8 +24,6 @@
#include <linux/usb/otg.h>
-#include <media/soc_camera.h>
-
#include "common.h"
#include "devices-imx31.h"
#include "ehci.h"
@@ -39,17 +37,6 @@ static unsigned int marxbot_pins[] = {
MX31_PIN_PC_READY__SD2_DATA1, MX31_PIN_PC_WAIT_B__SD2_DATA0,
MX31_PIN_PC_CD2_B__SD2_CLK, MX31_PIN_PC_CD1_B__SD2_CMD,
MX31_PIN_ATA_DIOR__GPIO3_28, MX31_PIN_ATA_DIOW__GPIO3_29,
- /* CSI */
- MX31_PIN_CSI_D6__CSI_D6, MX31_PIN_CSI_D7__CSI_D7,
- MX31_PIN_CSI_D8__CSI_D8, MX31_PIN_CSI_D9__CSI_D9,
- MX31_PIN_CSI_D10__CSI_D10, MX31_PIN_CSI_D11__CSI_D11,
- MX31_PIN_CSI_D12__CSI_D12, MX31_PIN_CSI_D13__CSI_D13,
- MX31_PIN_CSI_D14__CSI_D14, MX31_PIN_CSI_D15__CSI_D15,
- MX31_PIN_CSI_HSYNC__CSI_HSYNC, MX31_PIN_CSI_MCLK__CSI_MCLK,
- MX31_PIN_CSI_PIXCLK__CSI_PIXCLK, MX31_PIN_CSI_VSYNC__CSI_VSYNC,
- MX31_PIN_CSI_D4__GPIO3_4, MX31_PIN_CSI_D5__GPIO3_5,
- MX31_PIN_GPIO3_0__GPIO3_0, MX31_PIN_GPIO3_1__GPIO3_1,
- MX31_PIN_TXD2__GPIO1_28,
/* dsPIC resets */
MX31_PIN_STXD5__GPIO1_21, MX31_PIN_SRXD5__GPIO1_22,
/*battery detection */
@@ -143,82 +130,6 @@ static struct spi_board_info marxbot_spi_board_info[] __initdata = {
},
};
-#define TURRETCAM_POWER IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)
-#define BASECAM_POWER IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
-#define TURRETCAM_RST_B IOMUX_TO_GPIO(MX31_PIN_GPIO3_0)
-#define BASECAM_RST_B IOMUX_TO_GPIO(MX31_PIN_CSI_D4)
-#define CAM_CHOICE IOMUX_TO_GPIO(MX31_PIN_TXD2)
-
-static int marxbot_basecam_power(struct device *dev, int on)
-{
- gpio_set_value(BASECAM_POWER, !on);
- return 0;
-}
-
-static int marxbot_basecam_reset(struct device *dev)
-{
- gpio_set_value(BASECAM_RST_B, 0);
- udelay(100);
- gpio_set_value(BASECAM_RST_B, 1);
- return 0;
-}
-
-static struct i2c_board_info marxbot_i2c_devices[] = {
- {
- I2C_BOARD_INFO("mt9t031", 0x5d),
- },
-};
-
-static struct soc_camera_link base_iclink = {
- .bus_id = 0, /* Must match with the camera ID */
- .power = marxbot_basecam_power,
- .reset = marxbot_basecam_reset,
- .board_info = &marxbot_i2c_devices[0],
- .i2c_adapter_id = 0,
-};
-
-static struct platform_device marxbot_camera[] = {
- {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &base_iclink,
- },
- },
-};
-
-static struct platform_device *marxbot_cameras[] __initdata = {
- &marxbot_camera[0],
-};
-
-static int __init marxbot_cam_init(void)
-{
- int ret = gpio_request(CAM_CHOICE, "cam-choice");
- if (ret)
- return ret;
- gpio_direction_output(CAM_CHOICE, 0);
-
- ret = gpio_request(BASECAM_RST_B, "basecam-reset");
- if (ret)
- return ret;
- gpio_direction_output(BASECAM_RST_B, 1);
- ret = gpio_request(BASECAM_POWER, "basecam-standby");
- if (ret)
- return ret;
- gpio_direction_output(BASECAM_POWER, 0);
-
- ret = gpio_request(TURRETCAM_RST_B, "turretcam-reset");
- if (ret)
- return ret;
- gpio_direction_output(TURRETCAM_RST_B, 1);
- ret = gpio_request(TURRETCAM_POWER, "turretcam-standby");
- if (ret)
- return ret;
- gpio_direction_output(TURRETCAM_POWER, 0);
-
- return 0;
-}
-
#define SEL0 IOMUX_TO_GPIO(MX31_PIN_DTR_DCE1)
#define SEL1 IOMUX_TO_GPIO(MX31_PIN_DSR_DCE1)
#define SEL2 IOMUX_TO_GPIO(MX31_PIN_RI_DCE1)
@@ -356,9 +267,6 @@ void __init mx31moboard_marxbot_init(void)
spi_register_board_info(marxbot_spi_board_info,
ARRAY_SIZE(marxbot_spi_board_info));
- marxbot_cam_init();
- platform_add_devices(marxbot_cameras, ARRAY_SIZE(marxbot_cameras));
-
/* battery present pin */
gpio_request(IOMUX_TO_GPIO(MX31_PIN_LCS0), "bat-present");
gpio_direction_input(IOMUX_TO_GPIO(MX31_PIN_LCS0));
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
mx3 driver") the mx3 camera driver has been removed, so remove the camera
support from the board file as well.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Also remove CSI pins from IOMUX definition
arch/arm/mach-imx/mach-mx31_3ds.c | 160 --------------------------------------
1 file changed, 160 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
index 12b8a52..558e5f8 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -26,16 +26,12 @@
#include <linux/regulator/machine.h>
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
-#include <linux/memblock.h>
-
-#include <media/soc_camera.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
#include <asm/memory.h>
#include <asm/mach/map.h>
-#include <asm/memblock.h>
#include "3ds_debugboard.h"
#include "common.h"
@@ -137,23 +133,6 @@ static int mx31_3ds_pins[] = {
MX31_PIN_HSYNC__HSYNC,
MX31_PIN_FPSHIFT__FPSHIFT,
MX31_PIN_CONTRAST__CONTRAST,
- /* CSI */
- MX31_PIN_CSI_D6__CSI_D6,
- MX31_PIN_CSI_D7__CSI_D7,
- MX31_PIN_CSI_D8__CSI_D8,
- MX31_PIN_CSI_D9__CSI_D9,
- MX31_PIN_CSI_D10__CSI_D10,
- MX31_PIN_CSI_D11__CSI_D11,
- MX31_PIN_CSI_D12__CSI_D12,
- MX31_PIN_CSI_D13__CSI_D13,
- MX31_PIN_CSI_D14__CSI_D14,
- MX31_PIN_CSI_D15__CSI_D15,
- MX31_PIN_CSI_HSYNC__CSI_HSYNC,
- MX31_PIN_CSI_MCLK__CSI_MCLK,
- MX31_PIN_CSI_PIXCLK__CSI_PIXCLK,
- MX31_PIN_CSI_VSYNC__CSI_VSYNC,
- MX31_PIN_CSI_D5__GPIO3_5, /* CMOS PWDN */
- IOMUX_MODE(MX31_PIN_RI_DTE1, IOMUX_CONFIG_GPIO), /* CMOS reset */
/* SSI */
MX31_PIN_STXD4__STXD4,
MX31_PIN_SRXD4__SRXD4,
@@ -162,98 +141,6 @@ static int mx31_3ds_pins[] = {
};
/*
- * Camera support
- */
-static phys_addr_t mx3_camera_base __initdata;
-#define MX31_3DS_CAMERA_BUF_SIZE SZ_8M
-
-#define MX31_3DS_GPIO_CAMERA_PW IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
-#define MX31_3DS_GPIO_CAMERA_RST IOMUX_TO_GPIO(MX31_PIN_RI_DTE1)
-
-static struct gpio mx31_3ds_camera_gpios[] = {
- { MX31_3DS_GPIO_CAMERA_PW, GPIOF_OUT_INIT_HIGH, "camera-power" },
- { MX31_3DS_GPIO_CAMERA_RST, GPIOF_OUT_INIT_HIGH, "camera-reset" },
-};
-
-static const struct mx3_camera_pdata mx31_3ds_camera_pdata __initconst = {
- .flags = MX3_CAMERA_DATAWIDTH_10,
- .mclk_10khz = 2600,
-};
-
-static int __init mx31_3ds_init_camera(void)
-{
- int dma, ret = -ENOMEM;
- struct platform_device *pdev =
- imx31_alloc_mx3_camera(&mx31_3ds_camera_pdata);
-
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- if (!mx3_camera_base)
- goto err;
-
- dma = dma_declare_coherent_memory(&pdev->dev,
- mx3_camera_base, mx3_camera_base,
- MX31_3DS_CAMERA_BUF_SIZE,
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
-
- if (!(dma & DMA_MEMORY_MAP))
- goto err;
-
- ret = platform_device_add(pdev);
- if (ret)
-err:
- platform_device_put(pdev);
-
- return ret;
-}
-
-static int mx31_3ds_camera_power(struct device *dev, int on)
-{
- /* enable or disable the camera */
- pr_debug("%s: %s the camera\n", __func__, on ? "ENABLE" : "DISABLE");
- gpio_set_value(MX31_3DS_GPIO_CAMERA_PW, on ? 0 : 1);
-
- if (!on)
- goto out;
-
- /* If enabled, give a reset impulse */
- gpio_set_value(MX31_3DS_GPIO_CAMERA_RST, 0);
- msleep(20);
- gpio_set_value(MX31_3DS_GPIO_CAMERA_RST, 1);
- msleep(100);
-
-out:
- return 0;
-}
-
-static struct i2c_board_info mx31_3ds_i2c_camera = {
- I2C_BOARD_INFO("ov2640", 0x30),
-};
-
-static struct regulator_bulk_data mx31_3ds_camera_regs[] = {
- { .supply = "cmos_vcore" },
- { .supply = "cmos_2v8" },
-};
-
-static struct soc_camera_link iclink_ov2640 = {
- .bus_id = 0,
- .board_info = &mx31_3ds_i2c_camera,
- .i2c_adapter_id = 0,
- .power = mx31_3ds_camera_power,
- .regulators = mx31_3ds_camera_regs,
- .num_regulators = ARRAY_SIZE(mx31_3ds_camera_regs),
-};
-
-static struct platform_device mx31_3ds_ov2640 = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &iclink_ov2640,
- },
-};
-
-/*
* FB support
*/
static const struct fb_videomode fb_modedb[] = {
@@ -410,7 +297,6 @@ static struct regulator_init_data vmmc2_init = {
static struct regulator_consumer_supply vmmc1_consumers[] = {
REGULATOR_SUPPLY("vcore", "spi0.0"),
- REGULATOR_SUPPLY("cmos_2v8", "soc-camera-pdrv.0"),
};
static struct regulator_init_data vmmc1_init = {
@@ -441,22 +327,6 @@ static struct regulator_init_data vgen_init = {
.consumer_supplies = vgen_consumers,
};
-static struct regulator_consumer_supply vvib_consumers[] = {
- REGULATOR_SUPPLY("cmos_vcore", "soc-camera-pdrv.0"),
-};
-
-static struct regulator_init_data vvib_init = {
- .constraints = {
- .min_uV = 1300000,
- .max_uV = 1300000,
- .apply_uV = 1,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE |
- REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(vvib_consumers),
- .consumer_supplies = vvib_consumers,
-};
-
static struct mc13xxx_regulator_init_data mx31_3ds_regulators[] = {
{
.id = MC13783_REG_PWGT1SPI, /* Power Gate for ARM core. */
@@ -480,9 +350,6 @@ static struct mc13xxx_regulator_init_data mx31_3ds_regulators[] = {
}, {
.id = MC13783_REG_VGEN, /* Power LCD */
.init_data = &vgen_init,
- }, {
- .id = MC13783_REG_VVIB, /* Power CMOS */
- .init_data = &vvib_init,
},
};
@@ -688,10 +555,6 @@ static const struct imxi2c_platform_data mx31_3ds_i2c0_data __initconst = {
.bitrate = 100000,
};
-static struct platform_device *devices[] __initdata = {
- &mx31_3ds_ov2640,
-};
-
static void __init mx31_3ds_init(void)
{
imx31_soc_init();
@@ -723,14 +586,10 @@ static void __init mx31_3ds_init(void)
static void __init mx31_3ds_late(void)
{
- int ret;
-
mx31_3ds_spi_devs[0].irq = gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_GPIO1_3));
spi_register_board_info(mx31_3ds_spi_devs,
ARRAY_SIZE(mx31_3ds_spi_devs));
- platform_add_devices(devices, ARRAY_SIZE(devices));
-
mx31_3ds_usbotg_init();
if (otg_mode_host) {
otg_pdata.otg = imx_otg_ulpi_create(ULPI_OTG_DRVVBUS |
@@ -751,17 +610,6 @@ static void __init mx31_3ds_late(void)
"devices on the debug board are unusable.\n");
imx31_add_mxc_mmc(0, &sdhc1_pdata);
-
- /* CSI */
- /* Camera power: default - off */
- ret = gpio_request_array(mx31_3ds_camera_gpios,
- ARRAY_SIZE(mx31_3ds_camera_gpios));
- if (ret) {
- pr_err("Failed to request camera gpios");
- iclink_ov2640.power = NULL;
- }
-
- mx31_3ds_init_camera();
}
static void __init mx31_3ds_timer_init(void)
@@ -769,13 +617,6 @@ static void __init mx31_3ds_timer_init(void)
mx31_clocks_init(26000000);
}
-static void __init mx31_3ds_reserve(void)
-{
- /* reserve MX31_3DS_CAMERA_BUF_SIZE bytes for mx3-camera */
- mx3_camera_base = arm_memblock_steal(MX31_3DS_CAMERA_BUF_SIZE,
- MX31_3DS_CAMERA_BUF_SIZE);
-}
-
MACHINE_START(MX31_3DS, "Freescale MX31PDK (3DS)")
/* Maintainer: Freescale Semiconductor, Inc. */
.atag_offset = 0x100,
@@ -785,6 +626,5 @@ MACHINE_START(MX31_3DS, "Freescale MX31PDK (3DS)")
.init_time = mx31_3ds_timer_init,
.init_machine = mx31_3ds_init,
.init_late = mx31_3ds_late,
- .reserve = mx31_3ds_reserve,
.restart = mxc_restart,
MACHINE_END
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3][v2] arm64: freescale: ls2080a: Split devicetree for code resuability
From: Shawn Guo @ 2016-12-30 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480325824-14649-3-git-send-email-abhimanyu.saini@nxp.com>
On Mon, Nov 28, 2016 at 03:07:03PM +0530, Abhimanyu Saini wrote:
> LS2088A and LS2080A are similar SoCs with a few differences like
> ARM cores etc.
>
> Reorganize the LS2080A device tree to move the common nodes to:
> - fsl-ls2080a-ls2088a.dtsi
> - fsl-ls2080a-ls2088a-rdb.dts
> - fsl-ls2080a-ls2088a-qds.dts
I do not quite like the naming of these files. Will the following one
be better?
- fsl-ls208xa.dtsi
- fsl-ls208xa-rdb.dtsi
- fsl-ls208xa-qds.dtsi
Also if a DTS file is only to be included by another one, not to
generate a DTB, we name it .dtsi rather than .dts.
Shawn
>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> ---
> .../boot/dts/freescale/fsl-ls2080a-ls2088a-qds.dts | 196 ++++++
> .../boot/dts/freescale/fsl-ls2080a-ls2088a-rdb.dts | 152 +++++
> .../boot/dts/freescale/fsl-ls2080a-ls2088a.dtsi | 727 +++++++++++++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 154 +----
> arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 110 +---
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 706 +-------------------
> 6 files changed, 1100 insertions(+), 945 deletions(-)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a.dtsi
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2016-12-30 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <586072E9.3060609@huawei.com>
Hi Rafael,
On 2016/12/26 9:31, Hanjun Guo wrote:
[cut]
>
> + if (pdevinfo->pre_add_cb)
> + pdevinfo->pre_add_cb(&pdev->dev);
> +
>>>> -> because it looks like this might be done in acpi_platform_notify()
>>>> for platform devices.
>>> It works and I just simply add the code below:
>>>
>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
>>> index f8d6564..e0cd649 100644
>>> --- a/drivers/acpi/glue.c
>>> +++ b/drivers/acpi/glue.c
>>> @@ -13,6 +13,7 @@
>>> #include <linux/slab.h>
>>> #include <linux/rwsem.h>
>>> #include <linux/acpi.h>
>>> +#include <linux/acpi_iort.h>
>>> #include <linux/dma-mapping.h>
>>>
>>> #include "internal.h"
>>> @@ -315,6 +316,8 @@ static int acpi_platform_notify(struct device *dev)
>>> if (!adev)
>>> goto out;
>>>
>>> + acpi_configure_pmsi_domain(dev);
>>> +
>> But that should apply to platform devices only I suppose?
> Yes, it's only for the platform device.
>
>>> if (type && type->setup)
>>> type->setup(dev);
>>> else if (adev->handler && adev->handler->bind)
>>>
>>> Do you suggesting to configure the msi domain in this way?
>>> or add the function in the type->setup() callback (which needs
>>> to introduce a new acpi bus type)?
>> A type->setup() would be somewhat cleaner I think, but then it's more
>> code. Whichever works better I guess. :-)
> Agree, I will demo the type->setup() way and send out the patch for review,
> also I find one minor issue for the IORT code, will update that also for next
> version.
Just demo the code and find out it's seems to cut the feet to the type->setup() code,
because we need a match function (it's ok) and a find_companion() (we don't need that
and make the code worse because we will call the find_companion callback which it not needed
for platform devices:
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 96983c9..654021d9b 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -138,3 +138,31 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
return pdev;
}
EXPORT_SYMBOL_GPL(acpi_create_platform_device);
+
+static bool platform_acpi_bus_match(struct device *dev)
+{
+ return dev->bus == &platform_bus_type;
+}
+
+static struct acpi_device *platform_acpi_bus_find_companion(struct device *dev)
+{
+ /* demo code, do nothing here */
+ return NULL;
+}
+
+static void platform_acpi_setup(struct device *dev)
+{
+ acpi_configure_pmsi_domain(dev);
+}
+
+static struct acpi_bus_type acpi_platform_bus = {
+ .name = "Platform",
+ .match = platform_acpi_bus_match,
+ .find_companion = platform_acpi_bus_find_companion,
+ .setup = platform_acpi_setup,
+};
+
+int acpi_platform_bus_register(void)
+{
+ return register_acpi_bus_type(&acpi_platform_bus);
+}
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 95855cb..0a0a639 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1199,6 +1199,7 @@ static int __init acpi_init(void)
}
pci_mmcfg_late_init();
+ acpi_platform_bus_register();
acpi_iort_init();
acpi_scan_init();
acpi_ec_init();
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 809b536..1d05f92 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -597,6 +597,8 @@ extern bool acpi_driver_match_device(struct device *dev,
struct platform_device *acpi_create_platform_device(struct acpi_device *,
struct property_entry *);
+int acpi_platform_bus_register(void);
+
#define ACPI_PTR(_ptr) (_ptr)
static inline void acpi_device_set_enumerated(struct acpi_device *adev)
So how about just add the code as below?
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 11e63dd..37a8dfe 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -316,7 +316,8 @@ static int acpi_platform_notify(struct device *dev)
if (!adev)
goto out;
+ if (dev->bus == &platform_bus_type)
+ acpi_configure_pmsi_domain(dev);
if (type && type->setup)
type->setup(dev);
Thanks
Hanjun
^ permalink raw reply related
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2016-12-30 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9aa650ad-a32d-e942-1c6b-b069c8a2b87a@codeaurora.org>
On 2016/12/29 22:44, Sinan Kaya wrote:
> On 12/25/2016 8:31 PM, Hanjun Guo wrote:
>>> A type->setup() would be somewhat cleaner I think, but then it's more
>>> code. Whichever works better I guess. :-)
>> Agree, I will demo the type->setup() way and send out the patch for review,
>> also I find one minor issue for the IORT code, will update that also for next
>> version.
> Can you provide details on what the minor issue is with the IORT code?
It's about the mapping of NC (named component) -> SMMU -> ITS, we can
describe it as two ID mappings:
- NC->SMMU
- NC->ITS
And the code for now can work perfect for such id mappings, but if we
want to support chained mapping NC -> SMMU -> ITS, we need to add
extra code which in my [PATCH v5 10/14] ACPI: ARM64: IORT: rework
iort_node_get_id() for NC->SMMU->ITS case, but I just scanned the first
id mapping for now, I think I need to scan all the id mappings (but seems
single id mappings don't need to do that, I will investigate it more).
Thanks
Hanjun
^ 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