* Building for MMU-less vexpress targets
From: Russell King - ARM Linux @ 2012-11-07 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211071259.15107.arnd@arndb.de>
On Wed, Nov 07, 2012 at 12:59:14PM +0000, Arnd Bergmann wrote:
> On Tuesday 06 November 2012, Russell King - ARM Linux wrote:
> > Now, we don't _have_ to have the single and multi variants if they aren't
> > appropriate for the platform, but we can cover all the cases: a platform
> > where it's part of the multi-platform kernel when built for MMU, but is
> > incapable of being a multi-platform kernel when built without MMU.
> >
> > And we can do it without _too_ much Kconfig pain, and certainly without
> > having to delve into anything beyond arch/arm/Kconfig.
>
> Sure, that works. My point was just that I think it would be simpler
> to keep vexpress multiplatform-only if there are no reasons that prevent
> us from doing that.
>
> I also hope that we can at some point in the future get all ARMv6 and ARMv7
> platforms to be multiplatform-only, while leaving each ARMv4/ARMv5 to be
> any of single, multi, or mixed.
Except... we have one report where this approach already doesn't work,
where we have what is essentially an ARMv7 platform needing to be built
outside the multiplatform stuff...
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Arnd Bergmann @ 2012-11-07 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061802240.21033@xanadu.home>
On Tuesday 06 November 2012, Nicolas Pitre wrote:
> On Tue, 6 Nov 2012, Arnd Bergmann wrote:
>
> > On Tuesday 06 November 2012, Nicolas Pitre wrote:
> > > I really think that it makes no sense at all to support !MMU kernels in
> > > a multi-platform kernel build, even if the set of included platforms
> > > were all !MMU. The kernel has to be linked for the physical address of
> > > the target and not a common invariant virtual address.
> >
> > There are two separate aspects here: One is to run a kernel on !MMU that is
> > built to support multiple platforms. I agree that this is rather pointless
> > and not interesting.
> >
> > The other point is being able to build such a kernel, and this is what Will
> > seems to be interested in more.
>
> What's the point of building a pointless and uninteresting kernel?
Built-time coverage is the only one I can think of, but I think it's a
good reason. Being able to build an "allyesconfig" with MMU disabled
sounds like a good sniff test to see if something broke and is much faster
than building all the defconfigs.
> > The two options are either to make
> > vexpress be single-platform when building for !MMU, or to allow multiplatform
> > kernels to be built without MMU support in principle. I think the second
> > option is more logical and avoids complex Kconfig constructs.
>
> Well, I'd rather prefer to think that the first option is the most
> logical between those 2 options, regardless of Kconfig complexity
> issues.
>
> I didn't look, but just making MULTIPLATFORM depend on !MMU, and
> VEXPRESS depend on MULTIPLATFORM || MMU should be close to what is
> needed, no?
Fine with me too. I suppose you just made the same logic error that
I had earlier in this thread and meant !MMU where you wrote MMU.
Arnd
^ permalink raw reply
* [PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
From: Bedia, Vaibhav @ 2012-11-07 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r4o68bnl.fsf@deeprootsystems.com>
Hi Kevin,
On Wed, Nov 07, 2012 at 06:36:06, Kevin Hilman wrote:
> "Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes:
>
> > On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
>
> [...]
>
> >>
> >> Also, if there are drivers for these devices, won't this interfere?
> >>
> >
> > Hmm, I can think of the following scenarios
> >
> > 1. Runtime PM adapted drivers are compiled in - We'll have to ensure that
> > in their suspend callbacks they end up doing omap_hwmod_idle() via the
> > runtime PM APIs.
>
> That already happens for all omap_devices.
>
> > In this case the omap_hwmod_enable() followed by omap_hwmod_idle() is
> > not necessary in the PM code.
>
> Correct.
>
> > 2. The drivers are not compiled in - In this case, the hwmod code puts
> > the IPs in standby during bootup so the first suspend-resume iteration
> > will pass. During resuming, the SYSC configuration for forced standby will
> > be lost,
>
> Please clarify how the SYSC is lost in this case.
The register configuration of IPs in the PER domain is lost when we enter
the suspend state. So the forced standby configuration from SYSC is lost
and we need to do this for every successful suspend-resume cycle.
>
> > so in the subsequent iterations these IPs won't go standby and the
> > hwmod code does not touch them since they never got enabled. In this case
> > we do need the sequence that is there currently.
> >
> > 3. For some reason the respective drivers don't idle the IPs during suspend -
> > (no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think
> > we should abort the suspend process since we know that the suspend is not
> > going to work.
>
> Agreed.
>
> > Is there some other scenario that needs to be covered?
>
> You covered the ones I was thinking of.
>
> > How about adding some flag in hwmod code for handling this? Something
> > similar to what was done for MMC [1]. I think the problem that we have
> > is in some ways similar to the one addressed in [1].
>
> Except that in the absence of drivers, no hwmod code is executed on the
> suspend/resume path.
>
We could perhaps add a couple of APIs to check the SYSC values when coming
out of suspend and take appropriate action if the sysc cache does not match?
Regards,
Vaibhav
^ permalink raw reply
* [PATCH] ARM: EXYNOS: origen: Add missing USB regulators
From: Tomasz Figa @ 2012-11-07 13:01 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds missing USB OTG regulators needed for s3c-hsotg driver
to work on Origen board.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/mach-exynos/mach-origen.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c
index d8dc6d7..ddf6358 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -100,6 +100,8 @@ static struct regulator_consumer_supply __initdata ldo3_consumer[] = {
REGULATOR_SUPPLY("vddcore", "s5p-mipi-csis.0"), /* MIPI */
REGULATOR_SUPPLY("vdd", "exynos4-hdmi"), /* HDMI */
REGULATOR_SUPPLY("vdd_pll", "exynos4-hdmi"), /* HDMI */
+ REGULATOR_SUPPLY("vusb_d", "s3c-hsotg"), /* OTG */
+ REGULATOR_SUPPLY("vusb_a", "s3c-hsotg"), /* OTG */
};
static struct regulator_consumer_supply __initdata ldo6_consumer[] = {
REGULATOR_SUPPLY("vddio", "s5p-mipi-csis.0"), /* MIPI */
--
1.8.0
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: Make s3c_device_i2c0 always use id 0
From: Tomasz Figa @ 2012-11-07 13:00 UTC (permalink / raw)
To: linux-arm-kernel
This patch removes compatibility definitions added long time ago when
clock ids were used instead of devnames that were needed for platforms
with only one i2c controller with id -1 (some s3c24xx's).
Because currently devname field is used for matching device instances to
clocks and if no devname is provided (as in clock-s3c2412.c and
common-s3c2443.c for i2c clock, both in arch/arm/mach-s3c24xx) the clock
is being matched only by name, so s3c_device_i2c0 can always have id 0.
This patch solves the issue with i2c0 broken on boards where its the
only i2c controller used, tested on Origen.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
arch/arm/mach-s3c64xx/clock.c | 4 ----
arch/arm/plat-samsung/devs.c | 4 ----
2 files changed, 8 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 28041e8..0fd7417 100644
--- a/arch/arm/mach-s3c64xx/clock.c
+++ b/arch/arm/mach-s3c64xx/clock.c
@@ -138,11 +138,7 @@ static struct clk init_clocks_off[] = {
.ctrlbit = S3C_CLKCON_PCLK_TSADC,
}, {
.name = "i2c",
-#ifdef CONFIG_S3C_DEV_I2C1
.devname = "s3c2440-i2c.0",
-#else
- .devname = "s3c2440-i2c",
-#endif
.parent = &clk_p,
.enable = s3c64xx_pclk_ctrl,
.ctrlbit = S3C_CLKCON_PCLK_IIC,
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 52dfa8f..bc50b20 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -486,11 +486,7 @@ static struct resource s3c_i2c0_resource[] = {
struct platform_device s3c_device_i2c0 = {
.name = "s3c2410-i2c",
-#ifdef CONFIG_S3C_DEV_I2C1
.id = 0,
-#else
- .id = -1,
-#endif
.num_resources = ARRAY_SIZE(s3c_i2c0_resource),
.resource = s3c_i2c0_resource,
};
--
1.8.0
^ permalink raw reply related
* Building for MMU-less vexpress targets
From: Arnd Bergmann @ 2012-11-07 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106221437.GQ28327@n2100.arm.linux.org.uk>
On Tuesday 06 November 2012, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2012 at 09:14:49PM +0000, Arnd Bergmann wrote:
> > The other point is being able to build such a kernel, and this is what Will
> > seems to be interested in more. We have made VEXPRESS depend on
> > MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel,
> > and I think we should fix that. The two options are either to make
> > vexpress be single-platform when building for !MMU, or to allow multiplatform
> > kernels to be built without MMU support in principle. I think the second
> > option is more logical and avoids complex Kconfig constructs.
>
> The other thing here is... why does a platform which _was_ able to be
> built in isolation from every other platform suddenly become incapable
> of being so when they join the multiplatform conglomerate? This just
> sounds totally perverse and wrong.
>
> Surely it should be: platforms _not_ yet converted to multiplatform
> can't be selected with multi-platform support enabled?
>
> So, maybe the _proper_ solution here is:
>
> - change the big choice to be: config SINGLE_xxx
> - these select config MACH_FOO / PLAT_FOO / ARCH_FOO
> eg,
> config SINGLE_FOO
> bool "Support for foo platforms in single kernel"
> select MACH_FOO
> - add a final option: config MULTIPLATFORM
> - then add:
>
> config MULTI_FOO
> bool "Include support for foo platforms"
> select MACH_FOO
> depends on MULTIPLATFORM || !MMU
> ...
>
> config MACH_FOO
> bool
A few platforms are doing this. E.g. the vt8500 platform currently
allows both, and the at91 will only allow multiplatform to be selected
for the DT-aware systems, while the single-platform still allows both
DT and non-DT. In general, I'm fine with either approach (multiplatform
only or mixed) and I'd like to leave that choice to the platform
maintainers.
> Now, we don't _have_ to have the single and multi variants if they aren't
> appropriate for the platform, but we can cover all the cases: a platform
> where it's part of the multi-platform kernel when built for MMU, but is
> incapable of being a multi-platform kernel when built without MMU.
>
> And we can do it without _too_ much Kconfig pain, and certainly without
> having to delve into anything beyond arch/arm/Kconfig.
Sure, that works. My point was just that I think it would be simpler
to keep vexpress multiplatform-only if there are no reasons that prevent
us from doing that.
I also hope that we can at some point in the future get all ARMv6 and ARMv7
platforms to be multiplatform-only, while leaving each ARMv4/ARMv5 to be
any of single, multi, or mixed.
> I'd suggest at that point we separate out this stuff into a separate
> file - arch/arm/Kconfig.mach, which contains all the platform selection
> stuff.
Good idea, I like that.
Arnd
^ permalink raw reply
* [PATCH v7 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
From: Vivek Gautam @ 2012-11-07 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351573057-22249-2-git-send-email-p.paneri@samsung.com>
Hi all,
On Tue, Oct 30, 2012 at 10:27 AM, Praveen Paneri <p.paneri@samsung.com> wrote:
>
> This driver uses usb phy framework to interact with s3c-hsotg. Supports
> phy_init and phy_shutdown functions to enable/disable usb phy. Support
> will be extended to host controllers and more Samsung SoCs.
>
> Signed-off-by: Praveen Paneri <p.paneri@samsung.com>
> Acked-by: Heiko Stuebner <heiko@sntech.de>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
I have tested this patch-series for S3C6410 and S5PV310 for gadget functioning.
Looks good to me.
Tested-by: Vivek Gautam <gautam.vivek@samsung.com>
> ---
> .../devicetree/bindings/usb/samsung-usbphy.txt | 11 +
> drivers/usb/phy/Kconfig | 8 +
> drivers/usb/phy/Makefile | 1 +
> drivers/usb/phy/samsung-usbphy.c | 360 ++++++++++++++++++++
> include/linux/platform_data/samsung-usbphy.h | 27 ++
> 5 files changed, 407 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> create mode 100644 drivers/usb/phy/samsung-usbphy.c
> create mode 100644 include/linux/platform_data/samsung-usbphy.h
>
> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> new file mode 100644
> index 0000000..7b26e2d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> @@ -0,0 +1,11 @@
> +* Samsung's usb phy transceiver
> +
> +The Samsung's phy transceiver is used for controlling usb otg phy for
> +s3c-hsotg usb device controller.
> +TODO: Adding the PHY binding with controller(s) according to the under
> +developement generic PHY driver.
> +
> +Required properties:
> +- compatible : should be "samsung,exynos4210-usbphy"
> +- reg : base physical address of the phy registers and length of memory mapped
> + region.
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 63c339b..313685f 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -32,3 +32,11 @@ config MV_U3D_PHY
> help
> Enable this to support Marvell USB 3.0 phy controller for Marvell
> SoC.
> +
> +config SAMSUNG_USBPHY
> + bool "Samsung USB PHY controller Driver"
> + depends on USB_S3C_HSOTG
> + select USB_OTG_UTILS
> + help
> + Enable this to support Samsung USB phy controller for samsung
> + SoCs.
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index b069f29..55dcfc1 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
> obj-$(CONFIG_USB_ISP1301) += isp1301.o
> obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
> +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
> diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
> new file mode 100644
> index 0000000..3c84aab
> --- /dev/null
> +++ b/drivers/usb/phy/samsung-usbphy.c
> @@ -0,0 +1,360 @@
> +/* linux/drivers/usb/phy/samsung-usbphy.c
> + *
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Author: Praveen Paneri <p.paneri@samsung.com>
> + *
> + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/usb/otg.h>
> +#include <linux/platform_data/samsung-usbphy.h>
> +
> +/* Register definitions */
> +
> +#define SAMSUNG_PHYPWR (0x00)
> +
> +#define PHYPWR_NORMAL_MASK (0x19 << 0)
> +#define PHYPWR_OTG_DISABLE (0x1 << 4)
> +#define PHYPWR_ANALOG_POWERDOWN (0x1 << 3)
> +#define PHYPWR_FORCE_SUSPEND (0x1 << 1)
> +/* For Exynos4 */
> +#define PHYPWR_NORMAL_MASK_PHY0 (0x39 << 0)
> +#define PHYPWR_SLEEP_PHY0 (0x1 << 5)
> +
> +#define SAMSUNG_PHYCLK (0x04)
> +
> +#define PHYCLK_MODE_USB11 (0x1 << 6)
> +#define PHYCLK_EXT_OSC (0x1 << 5)
> +#define PHYCLK_COMMON_ON_N (0x1 << 4)
> +#define PHYCLK_ID_PULL (0x1 << 2)
> +#define PHYCLK_CLKSEL_MASK (0x3 << 0)
> +#define PHYCLK_CLKSEL_48M (0x0 << 0)
> +#define PHYCLK_CLKSEL_12M (0x2 << 0)
> +#define PHYCLK_CLKSEL_24M (0x3 << 0)
> +
> +#define SAMSUNG_RSTCON (0x08)
> +
> +#define RSTCON_PHYLINK_SWRST (0x1 << 2)
> +#define RSTCON_HLINK_SWRST (0x1 << 1)
> +#define RSTCON_SWRST (0x1 << 0)
> +
> +#ifndef MHZ
> +#define MHZ (1000*1000)
> +#endif
> +
> +enum samsung_cpu_type {
> + TYPE_S3C64XX,
> + TYPE_EXYNOS4210,
> +};
> +
> +/*
> + * struct samsung_usbphy - transceiver driver state
> + * @phy: transceiver structure
> + * @plat: platform data
> + * @dev: The parent device supplied to the probe function
> + * @clk: usb phy clock
> + * @regs: usb phy register memory base
> + * @ref_clk_freq: reference clock frequency selection
> + * @cpu_type: machine identifier
> + */
> +struct samsung_usbphy {
> + struct usb_phy phy;
> + struct samsung_usbphy_data *plat;
> + struct device *dev;
> + struct clk *clk;
> + void __iomem *regs;
> + int ref_clk_freq;
> + int cpu_type;
> +};
> +
> +#define phy_to_sphy(x) container_of((x), struct samsung_usbphy, phy)
> +
> +/*
> + * Returns reference clock frequency selection value
> + */
> +static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
> +{
> + struct clk *ref_clk;
> + int refclk_freq = 0;
> +
> + ref_clk = clk_get(sphy->dev, "xusbxti");
> + if (IS_ERR(ref_clk)) {
> + dev_err(sphy->dev, "Failed to get reference clock\n");
> + return PTR_ERR(ref_clk);
> + }
> +
> + switch (clk_get_rate(ref_clk)) {
> + case 12 * MHZ:
> + refclk_freq = PHYCLK_CLKSEL_12M;
> + break;
> + case 24 * MHZ:
> + refclk_freq = PHYCLK_CLKSEL_24M;
> + break;
> + case 48 * MHZ:
> + refclk_freq = PHYCLK_CLKSEL_48M;
> + break;
> + default:
> + if (sphy->cpu_type == TYPE_S3C64XX)
> + refclk_freq = PHYCLK_CLKSEL_48M;
> + else
> + refclk_freq = PHYCLK_CLKSEL_24M;
> + break;
> + }
> + clk_put(ref_clk);
> +
> + return refclk_freq;
> +}
> +
> +static void samsung_usbphy_enable(struct samsung_usbphy *sphy)
> +{
> + void __iomem *regs = sphy->regs;
> + u32 phypwr;
> + u32 phyclk;
> + u32 rstcon;
> +
> + /* set clock frequency for PLL */
> + phyclk = sphy->ref_clk_freq;
> + phypwr = readl(regs + SAMSUNG_PHYPWR);
> + rstcon = readl(regs + SAMSUNG_RSTCON);
> +
> + switch (sphy->cpu_type) {
> + case TYPE_S3C64XX:
> + phyclk &= ~PHYCLK_COMMON_ON_N;
> + phypwr &= ~PHYPWR_NORMAL_MASK;
> + rstcon |= RSTCON_SWRST;
> + break;
> + case TYPE_EXYNOS4210:
> + phypwr &= ~PHYPWR_NORMAL_MASK_PHY0;
> + rstcon |= RSTCON_SWRST;
> + default:
> + break;
> + }
> +
> + writel(phyclk, regs + SAMSUNG_PHYCLK);
> + /* set to normal of PHY0 */
> + writel(phypwr, regs + SAMSUNG_PHYPWR);
> + /* reset all ports of PHY and Link */
> + writel(rstcon, regs + SAMSUNG_RSTCON);
> + udelay(10);
> + rstcon &= ~RSTCON_SWRST;
> + writel(rstcon, regs + SAMSUNG_RSTCON);
> +}
> +
> +static void samsung_usbphy_disable(struct samsung_usbphy *sphy)
> +{
> + void __iomem *regs = sphy->regs;
> + u32 phypwr;
> +
> + phypwr = readl(regs + SAMSUNG_PHYPWR);
> +
> + switch (sphy->cpu_type) {
> + case TYPE_S3C64XX:
> + phypwr |= PHYPWR_NORMAL_MASK;
> + break;
> + case TYPE_EXYNOS4210:
> + phypwr |= PHYPWR_NORMAL_MASK_PHY0;
> + default:
> + break;
> + }
> +
> + /* unset to normal of PHY0 */
> + writel(phypwr, regs + SAMSUNG_PHYPWR);
> +}
> +
> +/*
> + * The function passed to the usb driver for phy initialization
> + */
> +static int samsung_usbphy_init(struct usb_phy *phy)
> +{
> + struct samsung_usbphy *sphy;
> + int ret = 0;
> +
> + sphy = phy_to_sphy(phy);
> +
> + /* Enable the phy clock */
> + ret = clk_prepare_enable(sphy->clk);
> + if (ret) {
> + dev_err(sphy->dev, "%s: clk_prepare_enable failed\n", __func__);
> + return ret;
> + }
> +
> + /* Disable phy isolation */
> + if (sphy->plat && sphy->plat->pmu_isolation)
> + sphy->plat->pmu_isolation(false);
> +
> + /* Initialize usb phy registers */
> + samsung_usbphy_enable(sphy);
> +
> + /* Disable the phy clock */
> + clk_disable_unprepare(sphy->clk);
> + return ret;
> +}
> +
> +/*
> + * The function passed to the usb driver for phy shutdown
> + */
> +static void samsung_usbphy_shutdown(struct usb_phy *phy)
> +{
> + struct samsung_usbphy *sphy;
> +
> + sphy = phy_to_sphy(phy);
> +
> + if (clk_prepare_enable(sphy->clk)) {
> + dev_err(sphy->dev, "%s: clk_prepare_enable failed\n", __func__);
> + return;
> + }
> +
> + /* De-initialize usb phy registers */
> + samsung_usbphy_disable(sphy);
> +
> + /* Enable phy isolation */
> + if (sphy->plat && sphy->plat->pmu_isolation)
> + sphy->plat->pmu_isolation(true);
> +
> + clk_disable_unprepare(sphy->clk);
> +}
> +
> +static const struct of_device_id samsung_usbphy_dt_match[];
> +
> +static inline int samsung_usbphy_get_driver_data(struct platform_device *pdev)
> +{
> + if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
> + int data;
> + const struct of_device_id *match;
> + match = of_match_node(samsung_usbphy_dt_match,
> + pdev->dev.of_node);
> + data = (int) match->data;
> + return data;
> + }
> +
> + return platform_get_device_id(pdev)->driver_data;
> +}
> +
> +static int __devinit samsung_usbphy_probe(struct platform_device *pdev)
> +{
> + struct samsung_usbphy *sphy;
> + struct samsung_usbphy_data *pdata;
> + struct device *dev = &pdev->dev;
> + struct resource *phy_mem;
> + void __iomem *phy_base;
> + struct clk *clk;
> + int ret = 0;
> +
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + dev_err(&pdev->dev, "%s: no platform data defined\n", __func__);
> + return -EINVAL;
> + }
> +
> + phy_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!phy_mem) {
> + dev_err(dev, "%s: missing mem resource\n", __func__);
> + return -ENODEV;
> + }
> +
> + phy_base = devm_request_and_ioremap(dev, phy_mem);
> + if (!phy_base) {
> + dev_err(dev, "%s: register mapping failed\n", __func__);
> + return -ENXIO;
> + }
> +
> + sphy = devm_kzalloc(dev, sizeof(*sphy), GFP_KERNEL);
> + if (!sphy)
> + return -ENOMEM;
> +
> + clk = devm_clk_get(dev, "otg");
> + if (IS_ERR(clk)) {
> + dev_err(dev, "Failed to get otg clock\n");
> + return PTR_ERR(clk);
> + }
> +
> + sphy->dev = &pdev->dev;
> + sphy->plat = pdata;
> + sphy->regs = phy_base;
> + sphy->clk = clk;
> + sphy->phy.dev = sphy->dev;
> + sphy->phy.label = "samsung-usbphy";
> + sphy->phy.init = samsung_usbphy_init;
> + sphy->phy.shutdown = samsung_usbphy_shutdown;
> + sphy->cpu_type = samsung_usbphy_get_driver_data(pdev);
> + sphy->ref_clk_freq = samsung_usbphy_get_refclk_freq(sphy);
> +
> + platform_set_drvdata(pdev, sphy);
> +
> + ret = usb_add_phy(&sphy->phy, USB_PHY_TYPE_USB2);
> + return ret;
> +}
> +
> +static int __exit samsung_usbphy_remove(struct platform_device *pdev)
> +{
> + struct samsung_usbphy *sphy = platform_get_drvdata(pdev);
> +
> + usb_remove_phy(&sphy->phy);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id samsung_usbphy_dt_match[] = {
> + {
> + .compatible = "samsung,s3c64xx-usbphy",
> + .data = (void *)TYPE_S3C64XX,
> + }, {
> + .compatible = "samsung,exynos4210-usbphy",
> + .data = (void *)TYPE_EXYNOS4210,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, samsung_usbphy_dt_match);
> +#else
> +#define samsung_usbphy_dt_match NULL
> +#endif
> +
> +static struct platform_device_id samsung_usbphy_driver_ids[] = {
> + {
> + .name = "s3c64xx-usbphy",
> + .driver_data = TYPE_S3C64XX,
> + }, {
> + .name = "exynos4210-usbphy",
> + .driver_data = TYPE_EXYNOS4210,
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(platform, samsung_usbphy_driver_ids);
> +
> +static struct platform_driver samsung_usbphy_driver = {
> + .probe = samsung_usbphy_probe,
> + .remove = __devexit_p(samsung_usbphy_remove),
> + .id_table = samsung_usbphy_driver_ids,
> + .driver = {
> + .name = "samsung-usbphy",
> + .owner = THIS_MODULE,
> + .of_match_table = samsung_usbphy_dt_match,
> + },
> +};
> +
> +module_platform_driver(samsung_usbphy_driver);
> +
> +MODULE_DESCRIPTION("Samsung USB phy controller");
> +MODULE_AUTHOR("Praveen Paneri <p.paneri@samsung.com>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:samsung-usbphy");
> diff --git a/include/linux/platform_data/samsung-usbphy.h b/include/linux/platform_data/samsung-usbphy.h
> new file mode 100644
> index 0000000..1bd24cb
> --- /dev/null
> +++ b/include/linux/platform_data/samsung-usbphy.h
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright (C) 2012 Samsung Electronics Co.Ltd
> + * http://www.samsung.com/
> + * Author: Praveen Paneri <p.paneri@samsung.com>
> + *
> + * Defines platform data for samsung usb phy driver.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#ifndef __SAMSUNG_USBPHY_PLATFORM_H
> +#define __SAMSUNG_USBPHY_PLATFORM_H
> +
> +/**
> + * samsung_usbphy_data - Platform data for USB PHY driver.
> + * @pmu_isolation: Function to control usb phy isolation in PMU.
> + */
> +struct samsung_usbphy_data {
> + void (*pmu_isolation)(int on);
> +};
> +
> +extern void samsung_usbphy_set_pdata(struct samsung_usbphy_data *pd);
> +
> +#endif /* __SAMSUNG_USBPHY_PLATFORM_H */
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks & Regards
Vivek
^ permalink raw reply
* [PATCH -next] ARM: OMAP2+: remove duplicated include from board-overo.c
From: Wei Yongjun @ 2012-11-07 12:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Remove duplicated include.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
arch/arm/mach-omap2/board-overo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 1cfb037..f5ba43f 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -45,7 +45,6 @@
#include <asm/mach/flash.h>
#include <asm/mach/map.h>
-#include "common.h"
#include <video/omapdss.h>
#include <video/omap-panel-generic-dpi.h>
#include <video/omap-panel-tfp410.h>
^ permalink raw reply related
* [GIT PULL] arm-soc: lpc32xx: platform updates
From: Roland Stigge @ 2012-11-07 12:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
this pull request includes the platform topic branch for lpc32xx.
Thanks in advance,
Roland
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.antcom.de/linux-2.6.git lpc32xx/core
for you to fetch changes up to 91deef8069e7ffafac4467200e1d37af1b2d7c56:
ARM: LPC32xx: Cleanup irq.c (2012-11-07 13:30:50 +0100)
----------------------------------------------------------------
Roland Stigge (3):
ARM: LPC32xx: Remove superfluous irq_alloc_descs()
ARM: LPC32xx: Relocate calls to irq_set_chained_handler()
ARM: LPC32xx: Cleanup irq.c
arch/arm/mach-lpc32xx/irq.c | 23 +++++------------------
1 file changed, 5 insertions(+), 18 deletions(-)
^ permalink raw reply
* [PATCH v3] ARM: zynq: Allow UART1 to be used as DEBUG_LL console.
From: Michal Simek @ 2012-11-07 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105215410.GC1254@beefymiracle.amer.corp.natinst.com>
2012/11/5 Josh Cartwright <josh.cartwright@ni.com>:
> On Mon, Nov 05, 2012 at 04:45:49PM -0500, Nick Bowler wrote:
>> The main UART on the Xilinx ZC702 board is UART1, located at address
>> e0001000. Add a Kconfig option to select this device as the low-level
>> debugging port. This allows the really early boot printouts to reach
>> the USB serial adaptor on this board.
>>
>> For consistency's sake, add a choice entry for UART0 even though it is
>> the the default if UART1 is not selected.
>>
>> Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
>> Tested-by: Josh Cartwright <josh.cartwright@ni.com>
>> ---
>> Sorry all for the phenominal delay in sending this out. Josh, I kept
>> your Tested-By since this version is Obviously Equivalent??? to v2...
>
> I re-tested again just in case and everything is good.
Thanks guys, Applied.
Michal
^ permalink raw reply
* [PATCH] DMAEngine: add dmaengine_prep_interleaved_dma wrapper for interleaved api
From: Barry Song @ 2012-11-07 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352209637-8841-1-git-send-email-21cnbao@gmail.com>
sorry for the mis-operation of missing Vinod.
attached this patch too.
2012/11/6 Barry Song <21cnbao@gmail.com>:
> From: Barry Song <Baohua.Song@csr.com>
>
> commit b14dab792dee(DMAEngine: Define interleaved transfer request api) adds
> interleaved request api, this patch adds the dmaengine_prep_interleaved_dma
> just like we have dmaengine_prep_ for other modes to avoid drivers call:
> xxx_chan->device->device_prep_interleaved_dma().
>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> Cc: Jassi Brar <jaswinder.singh@linaro.org>
> ---
> include/linux/dmaengine.h | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index d3201e4..135bbb5 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -660,6 +660,13 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic(
> period_len, dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor *dmaengine_prep_interleaved_dma(
> + struct dma_chan *chan, struct dma_interleaved_template *xt,
> + unsigned long flags)
> +{
> + return chan->device->device_prep_interleaved_dma(chan, xt, flags);
> +}
> +
> static inline int dmaengine_terminate_all(struct dma_chan *chan)
> {
> return dmaengine_device_control(chan, DMA_TERMINATE_ALL, 0);
> --
> 1.7.1
-barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-DMAEngine-add-dmaengine_prep_interleaved_dma-wrapper.patch
Type: application/octet-stream
Size: 1388 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121107/cae286bf/attachment-0001.obj>
^ permalink raw reply
* [PATCH 3/3] dmaengine: sirf: enable the driver support new SiRFmarco SoC
From: Barry Song @ 2012-11-07 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4y=sccFizQfwO-mx5GcvkgR9nWqksmuwrvSYpL+N5U1wg@mail.gmail.com>
2012/10/25 Barry Song <21cnbao@gmail.com>
>
> 2012/10/25 Vinod Koul <vkoul@infradead.org>:
> > On Wed, 2012-10-24 at 19:59 +0800, Barry Song wrote:
> >> Hi Vinod,
> >> Thanks a lot!
> > Please dont top post.
>
> well. saying hello is an exception :-)
>
> >>
> >> 2012/10/24 Vinod Koul <vkoul@infradead.org>
> >> >
> >> > On Thu, 2012-09-27 at 16:36 +0800, Barry Song wrote:
> >> > > From: Barry Song <Baohua.Song@csr.com>
> >> > >
> >> > > The driver supports old up SiRFprimaII SoCs, this patch makes it
> >> > > support
> >> > > the new SiRFmarco as well.
> >> > > SiRFmarco, as a SMP SoC, adds new DMA_INT_EN_CLR and
> >> > > DMA_CH_LOOP_CTRL_CLR
> >> > > registers, to disable IRQ/Channel, we should write 1 to the
> >> > > corresponding
> >> > > bit in the two CLEAR register.
> >> > >
> >> > > Tested on SiRFmarco using SPI driver:
> >> > > $ /mnt/spidev-sirftest -D /dev/spidev32766.0
> >> > > spi mode: 0
> >> > > bits per word: 8
> >> > > max speed: 500000 Hz (500 KHz)
> >> > >
> >> > > 00 00 00 00 00 00
> >> > > 00 00 00 00 00 00
> >> > > 00 00 00 00 00 00
> >> > > 00 00 00 00 00 00
> >> > > 00 00 00 00 00 00
> >> > > 00 00 00 00 00 00
> >> > > 00 00 00 00
> >> > >
> >> > > $ cat /proc/interrupts
> >> > > CPU0 CPU1
> >> > > 32: 1593 0 GIC sirfsoc_timer0
> >> > > 33: 0 3533 GIC sirfsoc_timer1
> >> > > 44: 0 0 GIC sirfsoc_dma
> >> > > 45: 16 0 GIC sirfsoc_dma
> >> > > 47: 6 0 GIC sirfsoc_spi
> >> > > 50: 5654 0 GIC sirfsoc-uart
> >> > > ...
> >> > >
> >> > > Signed-off-by: Barry Song <Baohua.Song@csr.com>
> >> > > ---
> > I tried applying this and it failed for me. Can you please respin this
> > on my next and send again.
done. at:
http://www.spinics.net/lists/arm-kernel/msg204504.html
> >
> > --
> > Vinod Koul
> > Intel Corp.
>
> -barry
^ permalink raw reply
* [PATCH] ARM: SAMSUNG: Fix typo in definition of VIDCON1_VSTATUS_FRONTPORCH value
From: Tomasz Figa @ 2012-11-07 12:31 UTC (permalink / raw)
To: linux-arm-kernel
The correct value for VIDCON1_VSTATUS_FRONTPORCH is 3, not 0.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
include/video/samsung_fimd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index 7ae6c07..263ed4b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -82,7 +82,7 @@
#define VIDCON1_VSTATUS_VSYNC (0x0 << 13)
#define VIDCON1_VSTATUS_BACKPORCH (0x1 << 13)
#define VIDCON1_VSTATUS_ACTIVE (0x2 << 13)
-#define VIDCON1_VSTATUS_FRONTPORCH (0x0 << 13)
+#define VIDCON1_VSTATUS_FRONTPORCH (0x3 << 13)
#define VIDCON1_VCLK_MASK (0x3 << 9)
#define VIDCON1_VCLK_HOLD (0x0 << 9)
#define VIDCON1_VCLK_RUN (0x1 << 9)
--
1.8.0
^ permalink raw reply related
* [PATCH 02/10] arm: at91: move platfarm_data to include/linux/platform_data/atmel.h
From: Marc Kleine-Budde @ 2012-11-07 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352287374-25176-2-git-send-email-plagnioj@jcrosoft.com>
On 11/07/2012 12:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: linux-ide at vger.kernel.org
> Cc: linux-input at vger.kernel.org
> Cc: linux-mmc at vger.kernel.org
> Cc: linux-can at vger.kernel.org
> Cc: netdev at vger.kernel.org
> Cc: linux-pcmcia at lists.infradead.org
> Cc: rtc-linux at googlegroups.com
> Cc: spi-devel-general at lists.sourceforge.net
> Cc: linux-serial at vger.kernel.org
> Cc: linux-usb at vger.kernel.org
> Cc: linux-fbdev at vger.kernel.org
> ---
> HI all,
>
> If it's ok with everyone this will go via at91
> with the patch serie than clean up the include/mach
Fine with me.
> For preparation to switch to arm multiarch kernel
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> (for the CAN related changes)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121107/46c5f879/attachment.sig>
^ permalink raw reply
* [PATCH v4 1/5] zynq: use GIC device tree bindings
From: Michal Simek @ 2012-11-07 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105183509.GA1254@beefymiracle.amer.corp.natinst.com>
2012/11/5 Josh Cartwright <josh.cartwright@ni.com>:
> On Sat, Oct 27, 2012 at 03:20:59PM +0000, Michal Simek wrote:
>> On Saturday, October 27, 2012 4:43 PM, Josh Cartwright wrote:
>> > On Sat, Oct 27, 2012 at 02:06:45PM +0000, Michal Simek wrote:
>> > [...]
>> > > I am not big fan to use dtsi solution because dts can be simple
>> > > generated directly From Xilinx design tool based on your hw design.
>> > > That's why I can't see any benefit To have dtsi file.
>> >
>> > Can I ask you to reconsider?
>>
>> I am open to all solution which will help others. I am not definitely
>> saying NO for this features I just haven't found a reason to support
>> it.
>>
>> > We, for example, don't make any use of the Xilinx
>> > dev tools to generate our device trees.
>>
>> Ok. How does your working flow looks like? I mean you don't get any
>> information from hardware guys how does your hw design look like?
>
> Our usecase may admittedly be a bit weird, because what logic is in the
> PL is ultimately determined (and even implemented) by the end user and
> is loaded at runtime. There is a lot of machinery to make that happen,
> but the point is that I don't have sufficient knowledge upfront to
> generate appropriate bindings for what's in the PL.
ok. It means that you need to use just the part of DTS without PL logic at all.
Does it mean that PL will be connected with any DTS fragment?
>> > Having a dtsi allows for easy extension of the zynq-7000 platform
>> > for our boards, without having to carry duplicate data.
>>
>> ok. I think that make sense if you send the next your series as RFC to
>> see how exactly you would like to use it.
>
> It seems like you caught a glimpse of this in my COMMON_CLK patchset. :)
Yes. Just need to get some time to analyze it.
>> In my workflow we generate DTS directly from design tool which I
>> expect your hw guys use because it is probably needed to generate
>> boot.bin/fsbl/etc. Then there is one more additional step to setup
>> device-tree bsp to generate DTS which directly fits to your HW design.
>> If you have the same boards with different programmable logic I
>> understand that you would like to share that PS part and then just add
>> it that IPs in PL.
> [..]
>> From my point of view. You have to use design tools at least once to
>> get bitstream and boot.bin with fsbl. Please correct me if I am wrong.
>> In this step you can use device-tree BSP to generate DTS ( I doesn't
>> need to be perfect with all attached devices on i2c,spi, phys, etc but
>> it reflects your hardware). You will get it in some seconds and your
>> dts has correct irq numbers/ip description, compatible strings,
>> addresses, position in the system - if you use bus bridges, etc) and
>> you can just directly use it and kernel will boot. If you need to do
>> changes in dts by hand, you can of course do it.
>
> I wouldn't be as opposed to device tree generation if the device tree
> generator was in tree.
Which tree do you exactly mean? Linux kernel or just any git tree?
Let me give you more information about the generator. It uses TCL in SDK
where it provides all structure from the system. It means device-tree generator
will read all information from design tool and based on that will generate
DTS file. It also means if user will setup specific irq lines in design, special
paramters setting in registers then all these values will be added to DTS.
.
> Device tree bindings change, how would/could an
> out-of-tree generator possibly handle changes in bindings?
What do you mean by that? Any example?
Generator will generate DTS on the current configuration which you have setup
in EDK.
For your case when you generate PL part at runtime you probably will use
just the part of DTS (that hard IPs)
> Would a user
> target the generator at a specific version of the kernel? (An in tree
> generator would also seem to necessitate a more formal specification
> language for DT bindings).
Device tree description in the hardware description which is not changing
across kernel versions. Xilinx device tree generator generates DTS
which reflects all standards.
We can send the generated output to device-tree mainling list and ask
for review.
For clk common patches this features is not implemented yet but it is easy
to add it and all generated DTSes will contains it.
If you think to label generator with specific version then we can use
any tag in the device-tree BSP tree.
> It is odd to me that the use of a generator would be required to create
> what is completely static data. What I'm referring to here is the
> collection of peripherals on the zynq-7000 that are not in the PL. For
> me, this requirement adds an unnecessary dependency on the Xilinx EDK
> that I would like to avoid.
I am not saying that you need to use it. If you want to write your DTS
by hand, you still can
but I expect that the most of zynq users will use generator and
generate it because
it is just easier than to describe it by hand and they can be sure
that all parameters are
correctly generated.
If you are using any non-standard solution where you will load pl
logic at runtime
then you can use just generated DTS for hardblock or write it by hand.
> Would it make sense to limit what the device tree generator produces to
> only what is in the PL? (Forgive my ignorance about this tool, I've
> never used it.)
It is tcl script everything is possible.
Are you interesting to use it just for PL?
> This could just be an extension of what I've started to do with the
> COMMON_CLK patchset. A zynq board would be described using several
> device tree snippets, one for the baked-in zynq-7000 peripheral set, one
> for a generated description of what is in the PL, and one describing any
> board-specific details (phy, etc). Something like below:
>
> zynq-7000.dtsi : description of static zynq-7000 peripherals
>
> / {
> amba : amba at 0 {
> slcr: slcr at f8000000 {
> clocks {
> ps_clk : ps_clk {
> compatible = "fixed-clock";
> };
> ...
> }
> };
> i2c0 : i2c0 at e0004000 {
> compatible = "xlnx,i2cps";
> ...
> };
> eth0 : eth0 at e000b000 {
> compatible = "xlnx,emacps";
> ...
> };
> };
> };
>
> zynq-zc702-pl.dtsi : generated description of what is in the PL
>
> &amba {
> /* PL IP generated descriptions here. */
> };
>
> zynq-zc702.dts : board-specific descriptions (osc freq, i2c, spi, phys, etc)
>
> /include/ "zynq-7000.dtsi"
> /include/ "zynq-zc702-pl.dtsi"
> &ps_clk {
> clock-frequency = <33333330>;
> };
> &i2c0 {
> pca9548 at 74 {
> ...
> reg = <0x74>;
> ...
> };
> };
> ð0 {
> phy at 7 {
> compatible = "marvell,888e1116r";
> ...
> reg = <0x7>;
> };
> };
>
> Thoughts?
The problem which I have with it is that if we accept this solution then
we will have to use 3(4-because of skeleton.dtsi) files where 2 files will fix
the origin model.
I can't see the reason why not to use just one file which will
describe it directly.
If you want to use solution with several dtsi files and compose it as
you describe
then it is completely fine but forcing others to use this structure
and write dts by hand will be big pain for a lot of users.
Also in design tools you can setup if you use qspi,nor,nand flash
memory interface.
memory interface, baudrates, dma, ports to PL logic, connections, etc.
and from my point of view is very complicated to describe it by
There are a lot of combination which you can have on one reference board.
You can't enable all hard IPs at one time and use all of them that's
why you shouldn't
list all of them in the kernel.
>From my point of view make sense to have one DTS file in the kernel
and one defconfig
for the most popular zynq board where will be exactly written that this DTS is
connected to this reference hw design. If you want to get more reference design
go to this page and download it.
Adding all DTSes for zynq boards to the kernel is overkill.
If you want to use your hw design you can use this generator and
generate it or write it by
hand.
Thanks,
Michal
^ permalink raw reply
* [RFC PATCH 1/4] ARM: kernel: add device tree init map function
From: Lorenzo Pieralisi @ 2012-11-07 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107110542.GH23305@mudshark.cambridge.arm.com>
On Wed, Nov 07, 2012 at 11:05:42AM +0000, Will Deacon wrote:
> On Wed, Nov 07, 2012 at 10:23:49AM +0000, Lorenzo Pieralisi wrote:
> > On Tue, Nov 06, 2012 at 09:50:44PM +0000, Will Deacon wrote:
> > > > + while ((dn = of_find_node_by_type(dn, "cpu")) && cpu <= nr_cpu_ids) {
> > > > + const u32 *hwid;
> > > > + int len;
> > > > +
> > > > + pr_debug(" * %s...\n", dn->full_name);
> > > > +
> > > > + hwid = of_get_property(dn, "reg", &len);
> > > > +
> > > > + if (!hwid || len != 4) {
> > > > + pr_err(" * %s missing reg property\n", dn->full_name);
> > > > + continue;
> > > > + }
> > > > + /*
> > > > + * We want to assign the boot CPU logical id 0.
> > > > + * Boot CPU checks its own MPIDR and if matches the current
> > > > + * cpu node "reg" value it sets the logical cpu index to 0
> > > > + * and stores the physical id accordingly.
> > > > + * If MPIDR does not match, assign sequential cpu logical
> > > > + * id (starting from 1) and increments it.
> > > > + */
> > > > + i = (be32_to_cpup(hwid) == (read_cpuid_mpidr() & 0xffffff))
> > > > + ? 0 : cpu++;
> > > > +
> > > > + if (!i)
> > > > + printk(KERN_INFO "Booting Linux on CPU HWID 0x%x\n",
> > > > + be32_to_cpup(hwid));
> > >
> > > I don't think we should bother with this print -- we already print something
> > > in smp_setup_processor_id, which cannot differ for the boot CPU, If you want
> > > the full mpidr, we could change that code to include it as well.
> >
> > Yes, it is duplicate code, I will remove it. Extending the printk in
> > smp_setup_processor_id() to include the entire MPIDR should be done
> > though, otherwise we might have printk aliases on system with multiple
> > clusters.
>
> Feel free to make that change. You could also replace NR_CPUS in
> smp_setup_processor_id with nr_cpu_ids for consistency (they'll be the same
> this early on).
Ok.
> > > We might also want some sanity checking that we do indeed end up with
> > > logical id 0 for the boot CPU. If not, I think we should scream and fall
> > > back on the simple mapping created earlier.
> >
> > Well, this basically means that we have to make sure this function is
> > executed on the boot CPU (and it is as the code stands now), right ?
>
> Yes, smp is not up yet which is why we're allowed to play with the logical
> map.
>
> > Since we are reading the MPIDR of the CPU parsing the tree and assign logical
> > cpu 0 accordingly I think we have this check carried out automatically,
> > unless for any given reason someone calls this function on a CPU that is
> > not the boot one (Why ?).
> >
> > Basically I could add a check like:
> >
> > if (WARN_ON(smp_processor_id())
> > return;
> >
> > to fall back to the previous mapping, but that's overkill IMHO.
>
> No, I was thinking about what happens if the devicetree doesn't contain an
> mpidr property that matches the boot cpu. In this case, we will fail to
> assign logical ID 0, right? If this happens, we should complain about an
> invalid devicetree and try to fall back on the logical_map that was
> generated earlier on.
Good point. What I could do, I can assign the MPIDR of the boot CPU to
the logical index 0 before even starting to parse the DT (that's what it
is done in smp_setup_processor_id(), with a couple of twists). Then, if I
find a node that matches the boot CPU mpidr I just skip over it. This
way the boot CPU MPIDR will always be correct the only difference with
the current approach will be that instead of generating the secondaries
MPIDRs we will read them from DT.
The problem with this approach is that if we need a pointer (phandle) to the
boot CPU DT node through the MPIDR and the boot CPU node is botched or missing
we still behave as if the DT CPU nodes were ok.
I think I'd better stick a warning condition in there if the boot CPU
node is not present or botched (from a MPIDR perspective at least).
Thoughts ?
Lorenzo
^ permalink raw reply
* [PATCH v3 0/3] Add DMA and device tree support to the flash controller FLCTL
From: Bastian Hecht @ 2012-11-07 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350641736-18192-1-git-send-email-hechtb@gmail.com>
Hello Artem,
I hope all aiaiai warnings except the adress space issue are fixed. As
I don't see how to fix the address space conversion I wonder if you
can accept the patchset as it is now.
cheers,
Bastian
2012/10/19 Bastian Hecht <hechtb@googlemail.com>:
> changelog v3: - due to shame on me by letting aiaiai complain, I've added
> a third patch (1/3) that cleans up some parts of the driver
> and added a correct error path to probe() in patch 3 (formerly 2/2).
> I found no way to fix this though:
> +drivers/mtd/nand/sh_flctl.c:181:25: warning: cast removes address space of expression [sparse]
>
> changelog v2: - cosmetic fixes in patch 1
> - added dmas and dma-names field in patch 2
>
> This mini-series consists of 2 separately posted patch-sets that shrunk
> to one patch each. It adds DMA support for the data part (not ECC) as
> well as device tree support to the FLCTL flash controller.
> As the 2nd patch is based on the 1st, I've decided to
> collect them here to avoid any confusion.
>
> The first set contained
> [PATCH 1/2] mtd: sh_flctl: Setup and release DMA channels
> [PATCH 2/2] mtd: sh_flctl: Use DMA for data fifo FLTDFIFO when available
> and was merged after 2 reviews to
> [PATCH] mtd: sh_flctl: Add DMA capabilty (same patch as in here)
>
> The second set contained
> [PATCH 1/3] mtd: sh_flctl: Probe SNAND_E flag from NAND chip
> [PATCH 2/3] mtd: sh_flctl: Add device tree support
> [PATCH 3/3] mtd: sh_flctl: Add sh7372 device tree config
> and is merged here to
> mtd: sh_flctl: Add device tree support
>
> Patch 1 can be omitted as SNAND_E is handled in the FLCTL source anyway
> correctly in set_cmd_regs() and the flag can be removed from existing board
> codes without this patch.
> Patch 2 without patch 3 may be confusing so I merged them too. Documentation
> is added as well.
>
> I've added linux-arm-kernel at lists.infradead.org as recipient for the
> device tree part.
>
> The patchset is based on
> l2-mtd git://git.infradead.org/users/dedekind/l2-mtd.git
> with reverted commit e26c113b4130aefa1d8446602bb5b05cfd646bfe.
>
>
> Bastian Hecht (2):
> mtd: sh_flctl: Add DMA capabilty
> mtd: sh_flctl: Add device tree support
>
> .../devicetree/bindings/mtd/flctl-nand.txt | 37 +++
> drivers/mtd/nand/sh_flctl.c | 266 +++++++++++++++++++-
> include/linux/mtd/sh_flctl.h | 12 +
> 3 files changed, 305 insertions(+), 10 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mtd/flctl-nand.txt
>
> --
> 1.7.5.4
>
^ permalink raw reply
* [PATCH 4/4] devicetree: Add Renesas SH Mobile MSIOF spi controller binding doc
From: Bastian Hecht @ 2012-11-07 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352288407-20594-1-git-send-email-hechtb@gmail.com>
Add binding documentation for Renesas' MSIOF SPI controller.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
Documentation/devicetree/bindings/spi/sh-msiof.txt | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/sh-msiof.txt
diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt
new file mode 100644
index 0000000..b62312e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -0,0 +1,12 @@
+Renesas MSIOF spi controller
+
+Required properties:
+- compatible : "renesas,sh-msiof" for SuperH or
+ "renesas,sh-mobile-msiof" for SH Mobile series
+- reg : Offset and length of the register set for the device
+- interrupts : interrupt line used by MSIOF
+
+Optional properties:
+- chip_select : Chip select, defaults to 0
+- tx_fifo_size : Overrides the default tx fifo size given in words
+- rx_fifo_size : Overrides the default rx fifo size given in words
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/4] spi: sh-msiof: Add device tree parsing to driver
From: Bastian Hecht @ 2012-11-07 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352288407-20594-1-git-send-email-hechtb@gmail.com>
This adds the capability to retrieve setup data from the device tree
node. The usage of platform data is still available.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
drivers/spi/spi-sh-msiof.c | 54 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 96358d0..65cd19c 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -20,6 +20,7 @@
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
@@ -592,6 +593,35 @@ static u32 sh_msiof_spi_txrx_word(struct spi_device *spi, unsigned nsecs,
return 0;
}
+#ifdef CONFIG_OF
+static struct sh_msiof_spi_info *sh_msiof_spi_parse_dt(struct device *dev)
+{
+ struct sh_msiof_spi_info *info;
+ struct device_node *np = dev->of_node;
+ u32 chipselect = 0;
+
+ info = devm_kzalloc(dev, sizeof(struct sh_msiof_spi_info), GFP_KERNEL);
+ if (!info) {
+ dev_err(dev, "failed to allocate setup data\n");
+ return NULL;
+ }
+
+ /* Parse the MSIOF properties */
+ of_property_read_u32(np, "chip-select", &chipselect);
+ of_property_read_u32(np, "tx_fifo_size", &info->tx_fifo_override);
+ of_property_read_u32(np, "rx_fifo_size", &info->rx_fifo_override);
+
+ info->num_chipselect = chipselect;
+
+ return info;
+}
+#else
+static struct sh_msiof_spi_info *sh_msiof_spi_parse_dt(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static int sh_msiof_spi_probe(struct platform_device *pdev)
{
struct resource *r;
@@ -610,7 +640,17 @@ static int sh_msiof_spi_probe(struct platform_device *pdev)
p = spi_master_get_devdata(master);
platform_set_drvdata(pdev, p);
- p->info = pdev->dev.platform_data;
+ if (pdev->dev.of_node)
+ p->info = sh_msiof_spi_parse_dt(&pdev->dev);
+ else
+ p->info = pdev->dev.platform_data;
+
+ if (!p->info) {
+ dev_err(&pdev->dev, "failed to obtain device info\n");
+ ret = -ENXIO;
+ goto err1;
+ }
+
init_completion(&p->done);
p->clk = clk_get(&pdev->dev, NULL);
@@ -715,6 +755,17 @@ static int sh_msiof_spi_runtime_nop(struct device *dev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id sh_msiof_match[] = {
+ { .compatible = "renesas,sh-msiof", },
+ { .compatible = "renesas,sh-mobile-msiof", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sh_msiof_match);
+#else
+#define sh_msiof_match NULL
+#endif
+
static struct dev_pm_ops sh_msiof_spi_dev_pm_ops = {
.runtime_suspend = sh_msiof_spi_runtime_nop,
.runtime_resume = sh_msiof_spi_runtime_nop,
@@ -727,6 +778,7 @@ static struct platform_driver sh_msiof_spi_drv = {
.name = "spi_sh_msiof",
.owner = THIS_MODULE,
.pm = &sh_msiof_spi_dev_pm_ops,
+ .of_match_table = sh_msiof_match,
},
};
module_platform_driver(sh_msiof_spi_drv);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/4] spi: Add SH Mobile series as dependency to MSIOF controller
From: Bastian Hecht @ 2012-11-07 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352288407-20594-1-git-send-email-hechtb@gmail.com>
The MSIOF hardware block is used in the SH Mobile series as well, so we
add it here.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
drivers/spi/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 1acae35..d0c0ae6 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -341,10 +341,10 @@ config SPI_SC18IS602
config SPI_SH_MSIOF
tristate "SuperH MSIOF SPI controller"
- depends on SUPERH && HAVE_CLK
+ depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
select SPI_BITBANG
help
- SPI driver for SuperH MSIOF blocks.
+ SPI driver for SuperH and SH Mobile MSIOF blocks.
config SPI_SH
tristate "SuperH SPI controller"
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/4] spi: sh-msiof: Remove unneeded clock name
From: Bastian Hecht @ 2012-11-07 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352288407-20594-1-git-send-email-hechtb@gmail.com>
clk_get() no longer needs a character string for associating the right
clock as this is done via the device struct now.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
drivers/spi/spi-sh-msiof.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 1f466bc..96358d0 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -597,7 +597,6 @@ static int sh_msiof_spi_probe(struct platform_device *pdev)
struct resource *r;
struct spi_master *master;
struct sh_msiof_spi_priv *p;
- char clk_name[16];
int i;
int ret;
@@ -614,10 +613,9 @@ static int sh_msiof_spi_probe(struct platform_device *pdev)
p->info = pdev->dev.platform_data;
init_completion(&p->done);
- snprintf(clk_name, sizeof(clk_name), "msiof%d", pdev->id);
- p->clk = clk_get(&pdev->dev, clk_name);
+ p->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(p->clk)) {
- dev_err(&pdev->dev, "cannot get clock \"%s\"\n", clk_name);
+ dev_err(&pdev->dev, "cannot get clock\n");
ret = PTR_ERR(p->clk);
goto err1;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH RESEND 0/4] spi: sh-msiof: Add DT support
From: Bastian Hecht @ 2012-11-07 11:40 UTC (permalink / raw)
To: linux-arm-kernel
Patch resend from 21st september, this time cover letter included. Added ARM-ML
and SH-ML as recipients too.
The first patch contains a minor cleanup that becomes possible due to older
changes in the SuperH code.
In the 2nd patch we add the SH-Mobile chips as possible architecture requirement
for the MSIOF driver.
Then we come to the core of the patchset: DeviceTree support for sh-msiof in
patch 3 and patch 4.
There are minimal changes to the first publication to the patchset like changing
a comment string, so I just resend it as v1 again as there are no comments to the
original patchset.
Bastian Hecht (4):
spi: sh-msiof: Remove unneeded clock name
spi: Add SH Mobile series as dependency to MSIOF controller
spi: sh-msiof: Add device tree parsing to driver
devicetree: Add Renesas SH Mobile MSIOF spi controller binding doc
Documentation/devicetree/bindings/spi/sh-msiof.txt | 12 ++++
drivers/spi/Kconfig | 4 +-
drivers/spi/spi-sh-msiof.c | 60 ++++++++++++++++++--
3 files changed, 69 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/sh-msiof.txt
--
1.7.5.4
^ permalink raw reply
* [PATCH 10/10] arm: at91: move at91rm9200 rtc header in drivers/rtc
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-07 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352287374-25176-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: rtc-linux at googlegroups.com
---
drivers/rtc/rtc-at91rm9200.c | 2 +-
.../include/mach/at91_rtc.h => drivers/rtc/rtc-at91rm9200.h | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm/mach-at91/include/mach/at91_rtc.h => drivers/rtc/rtc-at91rm9200.h (100%)
diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index fca9790..b6469e2 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -31,7 +31,7 @@
#include <asm/uaccess.h>
-#include <mach/at91_rtc.h>
+#include "rtc-at91rm9200.h"
#define at91_rtc_read(field) \
__raw_readl(at91_rtc_regs + field)
diff --git a/arch/arm/mach-at91/include/mach/at91_rtc.h b/drivers/rtc/rtc-at91rm9200.h
similarity index 100%
rename from arch/arm/mach-at91/include/mach/at91_rtc.h
rename to drivers/rtc/rtc-at91rm9200.h
--
1.7.10.4
^ permalink raw reply related
* [PATCH 09/10] arm: at91: move reset controller header to arm/arm/mach-at91
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-07 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352287374-25176-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/{include/mach => }/at91_rstc.h | 0
arch/arm/mach-at91/at91sam9260.c | 2 +-
arch/arm/mach-at91/at91sam9261.c | 2 +-
arch/arm/mach-at91/at91sam9263.c | 2 +-
arch/arm/mach-at91/at91sam9_alt_reset.S | 2 +-
arch/arm/mach-at91/at91sam9g45_reset.S | 3 +--
arch/arm/mach-at91/at91sam9rl.c | 2 +-
arch/arm/mach-at91/pm.c | 2 +-
8 files changed, 7 insertions(+), 8 deletions(-)
rename arch/arm/mach-at91/{include/mach => }/at91_rstc.h (100%)
diff --git a/arch/arm/mach-at91/include/mach/at91_rstc.h b/arch/arm/mach-at91/at91_rstc.h
similarity index 100%
rename from arch/arm/mach-at91/include/mach/at91_rstc.h
rename to arch/arm/mach-at91/at91_rstc.h
diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
index bb2e17c..9942984 100644
--- a/arch/arm/mach-at91/at91sam9260.c
+++ b/arch/arm/mach-at91/at91sam9260.c
@@ -21,9 +21,9 @@
#include <mach/at91_dbgu.h>
#include <mach/at91sam9260.h>
#include <mach/at91_pmc.h>
-#include <mach/at91_rstc.h>
#include "at91_aic.h"
+#include "at91_rstc.h"
#include "soc.h"
#include "generic.h"
#include "clock.h"
diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
index 09009d8..c583ba2 100644
--- a/arch/arm/mach-at91/at91sam9261.c
+++ b/arch/arm/mach-at91/at91sam9261.c
@@ -20,9 +20,9 @@
#include <mach/cpu.h>
#include <mach/at91sam9261.h>
#include <mach/at91_pmc.h>
-#include <mach/at91_rstc.h>
#include "at91_aic.h"
+#include "at91_rstc.h"
#include "soc.h"
#include "generic.h"
#include "clock.h"
diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
index 0c86aa8..500ee19 100644
--- a/arch/arm/mach-at91/at91sam9263.c
+++ b/arch/arm/mach-at91/at91sam9263.c
@@ -19,9 +19,9 @@
#include <asm/system_misc.h>
#include <mach/at91sam9263.h>
#include <mach/at91_pmc.h>
-#include <mach/at91_rstc.h>
#include "at91_aic.h"
+#include "at91_rstc.h"
#include "soc.h"
#include "generic.h"
#include "clock.h"
diff --git a/arch/arm/mach-at91/at91sam9_alt_reset.S b/arch/arm/mach-at91/at91sam9_alt_reset.S
index 7af2e10..f039538 100644
--- a/arch/arm/mach-at91/at91sam9_alt_reset.S
+++ b/arch/arm/mach-at91/at91sam9_alt_reset.S
@@ -16,7 +16,7 @@
#include <linux/linkage.h>
#include <mach/hardware.h>
#include <mach/at91_ramc.h>
-#include <mach/at91_rstc.h>
+#include "at91_rstc.h"
.arm
diff --git a/arch/arm/mach-at91/at91sam9g45_reset.S b/arch/arm/mach-at91/at91sam9g45_reset.S
index 9d45718..721a1a3 100644
--- a/arch/arm/mach-at91/at91sam9g45_reset.S
+++ b/arch/arm/mach-at91/at91sam9g45_reset.S
@@ -13,8 +13,7 @@
#include <linux/linkage.h>
#include <mach/hardware.h>
#include <mach/at91_ramc.h>
-#include <mach/at91_rstc.h>
-
+#include "at91_rstc.h"
.arm
.globl at91sam9g45_restart
diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
index 5cd076b..97dd8f1 100644
--- a/arch/arm/mach-at91/at91sam9rl.c
+++ b/arch/arm/mach-at91/at91sam9rl.c
@@ -20,9 +20,9 @@
#include <mach/at91_dbgu.h>
#include <mach/at91sam9rl.h>
#include <mach/at91_pmc.h>
-#include <mach/at91_rstc.h>
#include "at91_aic.h"
+#include "at91_rstc.h"
#include "soc.h"
#include "generic.h"
#include "clock.h"
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 3455740..adb6db8 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -36,7 +36,7 @@
* Show the reason for the previous system reset.
*/
-#include <mach/at91_rstc.h>
+#include "at91_rstc.h"
#include "at91_shdwc.h"
static void __init show_reset_status(void)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 08/10] arm: at91: move pit define to the driver
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-07 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352287374-25176-1-git-send-email-plagnioj@jcrosoft.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/mach-at91/at91sam926x_time.c | 14 ++++++++++--
arch/arm/mach-at91/include/mach/at91_pit.h | 32 ----------------------------
2 files changed, 12 insertions(+), 34 deletions(-)
delete mode 100644 arch/arm/mach-at91/include/mach/at91_pit.h
diff --git a/arch/arm/mach-at91/at91sam926x_time.c b/arch/arm/mach-at91/at91sam926x_time.c
index ffc0957..358412f 100644
--- a/arch/arm/mach-at91/at91sam926x_time.c
+++ b/arch/arm/mach-at91/at91sam926x_time.c
@@ -20,8 +20,18 @@
#include <asm/mach/time.h>
-#include <mach/at91_pit.h>
-
+#define AT91_PIT_MR 0x00 /* Mode Register */
+#define AT91_PIT_PITIEN (1 << 25) /* Timer Interrupt Enable */
+#define AT91_PIT_PITEN (1 << 24) /* Timer Enabled */
+#define AT91_PIT_PIV (0xfffff) /* Periodic Interval Value */
+
+#define AT91_PIT_SR 0x04 /* Status Register */
+#define AT91_PIT_PITS (1 << 0) /* Timer Status */
+
+#define AT91_PIT_PIVR 0x08 /* Periodic Interval Value Register */
+#define AT91_PIT_PIIR 0x0c /* Periodic Interval Image Register */
+#define AT91_PIT_PICNT (0xfff << 20) /* Interval Counter */
+#define AT91_PIT_CPIV (0xfffff) /* Inverval Value */
#define PIT_CPIV(x) ((x) & AT91_PIT_CPIV)
#define PIT_PICNT(x) (((x) & AT91_PIT_PICNT) >> 20)
diff --git a/arch/arm/mach-at91/include/mach/at91_pit.h b/arch/arm/mach-at91/include/mach/at91_pit.h
deleted file mode 100644
index d1f80ad..0000000
--- a/arch/arm/mach-at91/include/mach/at91_pit.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-at91/include/mach/at91_pit.h
- *
- * Copyright (C) 2007 Andrew Victor
- * Copyright (C) 2007 Atmel Corporation.
- *
- * Periodic Interval Timer (PIT) - System peripherals regsters.
- * Based on AT91SAM9261 datasheet revision D.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef AT91_PIT_H
-#define AT91_PIT_H
-
-#define AT91_PIT_MR 0x00 /* Mode Register */
-#define AT91_PIT_PITIEN (1 << 25) /* Timer Interrupt Enable */
-#define AT91_PIT_PITEN (1 << 24) /* Timer Enabled */
-#define AT91_PIT_PIV (0xfffff) /* Periodic Interval Value */
-
-#define AT91_PIT_SR 0x04 /* Status Register */
-#define AT91_PIT_PITS (1 << 0) /* Timer Status */
-
-#define AT91_PIT_PIVR 0x08 /* Periodic Interval Value Register */
-#define AT91_PIT_PIIR 0x0c /* Periodic Interval Image Register */
-#define AT91_PIT_PICNT (0xfff << 20) /* Interval Counter */
-#define AT91_PIT_CPIV (0xfffff) /* Inverval Value */
-
-#endif
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox