* OMAP baseline test results for v3.7-rc3
From: Tony Lindgren @ 2012-10-30 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508FE8BA.1080404@ti.com>
* Vaibhav Hiremath <hvaibhav@ti.com> [121030 07:50]:
> >
> > MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> > already submitted to the list recently. So MMC support will come along with
> > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
From: Tony Lindgren @ 2012-10-30 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALLhW=4ukBuRSVcPm2A37PgBhv33yKqk2G=Dz2XTUyswXw=JMg@mail.gmail.com>
* Omar Ramirez Luna <omar.luna@linaro.org> [121030 05:20]:
> Tony,
>
> On 29 October 2012 12:52, Tony Lindgren <tony@atomide.com> wrote:
> >> --- /dev/null
> >> +++ b/include/linux/platform_data/omap_mailbox.h
> >> @@ -0,0 +1,105 @@
> >
> > This file should only contain pure platform data needed
> > by the core omap code to pass to the mailbox driver.
>
> Ok, looking at it closely, this header file is related to the API
> itself, there is nothing that could be actually considered as pure
> platform data, the structures are related with the mailbox framework
> and even if I split this file into two, the additional header would
> end up including the "platform_data" header unless I move
> save/restore_ctx functions and then export them as symbols for the
> API.
>
> So, it might be better for the entire file to sit in
> linux/include/mailbox/ then.
OK to me.
> > The mailbox API header should be somewhere else,
> > like include/linux/mailbox/mailbox-omap.h or similar.
>
> Ok.
>
> > But shouldn't this all now be handled by using the
> > remoteproc framework?
>
> Remoteproc doesn't handle the mailbox hardware directly, it still
> relies in the mailbox framework for the low level communications.
> E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses
> mailbox msg to generate an interrupt to Proc2, Proc2 queries the
> message (virtqueue) based on the mailbox message received.
OK.
Greg, do these patches look OK to you to move to live under
drivers/mailbox?
Regards,
Tony
^ permalink raw reply
* vexpress issues in next-20121029
From: Pawel Moll @ 2012-10-30 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508EE610.9050703@wwwdotorg.org>
Hi Stephen,
On Mon, 2012-10-29 at 20:24 +0000, Stephen Warren wrote:
> 1) At compile-time: v2m_timer_init() and v2m_dt_timer_init() reference
> functions vexpress_clk_init() and vexpress_clk_of_init() respectively,
> which don't appear anywhere in the source tree.
There was a glitch between clk-next and arm-soc - it should be fine
starting with next-20121030.
> 2) With those calls commented out, I find that
> vexpress_sysreg_init_leds() is device_initcall, and so executes even
> when not running on vexpress HW. This crashes on Tegra (which I have
> converted to single-zImage locally).
Uh, how stupid of me! I have to finally get used to the new
multi-platform-kernel reality... Sorry about it - a quick workaround
would be:
8<----------------------------
diff --git a/drivers/mfd/vexpress-sysreg.c
b/drivers/mfd/vexpress-sysreg.c
index 059d6b1..99e89a8 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -474,7 +474,6 @@ static int __init vexpress_sysreg_init(void)
}
core_initcall(vexpress_sysreg_init);
-
#if defined(CONFIG_LEDS_CLASS)
struct vexpress_sysreg_led {
@@ -526,6 +525,9 @@ static int __init vexpress_sysreg_init_leds(void)
struct vexpress_sysreg_led *led;
int i;
+ if (!vexpress_sysreg_base)
+ return 0;
+
/* Clear all user LEDs */
writel(0, vexpress_sysreg_base + SYS_LED);
8<----------------------------
while I'm improving the situation by better means.
Sorry about this and thanks for letting me know!
Pawe?
^ permalink raw reply related
* [PATCH 1/5] ARM: at91: atmel-ssc: add platform device id table
From: Mark Brown @ 2012-10-30 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350901079-18307-1-git-send-email-voice.shen@atmel.com>
On Mon, Oct 22, 2012 at 06:17:55PM +0800, Bo Shen wrote:
> Using platform device id to check whether the Atmel SOC support dma for
> data transfer
>
> If match "at91rm9200_ssc" which does not support DMA transfer
> If match "at91sam9g45_ssc" which support DMA transfer
Any comments on this from that Atmel folks? If I don't see something
I'll probably just apply.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/fa8dc4a7/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] irqchip: Move ARM GIC to drivers/irqchip
From: Rob Herring @ 2012-10-30 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030160129.7e39619b@skate>
On 10/30/2012 10:01 AM, Thomas Petazzoni wrote:
> Rob,
>
> On Tue, 30 Oct 2012 09:54:18 -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> Now that we have drivers/irqchip, move GIC irqchip to drivers/irqchip. This
>> is necessary to share the GIC with arm and arm64.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> ---
>> arch/arm/common/Kconfig | 8 --------
>> arch/arm/common/Makefile | 1 -
>> drivers/irqchip/Kconfig | 8 ++++++++
>> drivers/irqchip/Makefile | 1 +
>> arch/arm/common/gic.c => drivers/irqchip/irq-gic.c | 0
>> drivers/irqchip/irqchip.c | 10 ++++++++++
>> drivers/irqchip/irqchip.h | 1 +
>> 7 files changed, 20 insertions(+), 9 deletions(-)
>
> What about arch/arm/include/asm/hardware/gic.h ?
>
> Contrary to the current version of the bcm2835 IRQ controller driver
> and the armada-370-xp IRQ controller driver, the GIC and VIC drivers
> not only expose a <foo>_of_init() function, but also other functions
> that are directly used by several non-DT capable ARM sub-architectures.
>
> Of course, it works by leaving gic.h where it is now, but it sounds
> strange to have the driver in drivers/irqchip/ and the header file in
> arch/arm/include/asm/hardware/, especially if the goal is to be able to
> use those drivers in arm64.
Right. I'll have to move it. I wasn't really thinking about arm64 until
this morning.
Rob
^ permalink raw reply
* arm-soc tree was Re: [PATCH] Fix socfpga compilation with early_printk() enabled
From: Pawel Moll @ 2012-10-30 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210290441.25964.arnd@arndb.de>
On Mon, 2012-10-29 at 04:41 +0000, Arnd Bergmann wrote:
> On Sunday 28 October 2012, Pavel Machek wrote:
> > arch/arm/mach-vexpress/v2m.c: vexpress_clk_init(ioremap(V2M_SYSCTL, SZ_4K));
> > include/linux/vexpress.h:void vexpress_clk_init(void __iomem *sp810_base);
> >
> > ...seems vexpress_clk_init is not there, yet... And what is more
> > serious:
> >
> > pavel at amd:~/mainline-altera/linux$ grep mach-vexpress MAINTAINERS
> > pavel at amd:~/mainline-altera/linux$
> >
> > vexpress_clk_of_init(); has same problem.
>
> I've already reported both to Pawel Moll, and he already came back with
> a new series, but we're still trying to work out the dependencies.
Yes, it's been a glitch in -next between arm-soc and clk, but it should
be fine now (as of next-20121030).
Sorry about the hassle
Pawel
^ permalink raw reply
* [PATCH v2 6/6] DRIVERS: ATA: SATA PHY controller driver
From: Vasanth Ananthan @ 2012-10-30 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351612897-14923-1-git-send-email-vasanthananthan@gmail.com>
This patch adds a platform driver and I2C client driver for SATA PHY controller
Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
---
arch/arm/mach-exynos/include/mach/regs-sata.h | 29 +++
drivers/ata/Makefile | 2 +-
drivers/ata/sata_exynos_phy.c | 300 +++++++++++++++++++++++++
3 files changed, 330 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-exynos/include/mach/regs-sata.h
create mode 100644 drivers/ata/sata_exynos_phy.c
diff --git a/arch/arm/mach-exynos/include/mach/regs-sata.h b/arch/arm/mach-exynos/include/mach/regs-sata.h
new file mode 100644
index 0000000..80dd564
--- /dev/null
+++ b/arch/arm/mach-exynos/include/mach/regs-sata.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2010-2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS - SATA PHY controller definition
+ *
+ * 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.
+*/
+
+#define EXYNOS5_SATA_RESET 0x4
+#define RESET_CMN_RST_N (1 << 1)
+#define LINK_RESET 0xF0000
+
+#define EXYNOS5_SATA_MODE0 0x10
+
+#define EXYNOS5_SATA_CTRL0 0x14
+#define CTRL0_P0_PHY_CALIBRATED_SEL (1 << 9)
+#define CTRL0_P0_PHY_CALIBRATED (1 << 8)
+
+#define EXYNOS5_SATA_PHSATA_CTRLM 0xE0
+#define PHCTRLM_REF_RATE (1 << 1)
+#define PHCTRLM_HIGH_SPEED (1 << 0)
+
+#define EXYNOS5_SATA_PHSATA_STATM 0xF0
+#define PHSTATM_PLL_LOCKED (1 << 0)
+
+#define SATA_PHY_CON_RESET 0xF003F
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 43bb38e..6a3a8ee 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_SATA_SIL24) += sata_sil24.o
obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
obj-$(CONFIG_SATA_HIGHBANK) += sata_highbank.o libahci.o
obj-$(CONFIG_SATA_PHY) += sata_phy.o
-obj-$(CONFIG_SATA_EXYNOS) += sata_exynos.o libahci.o
+obj-$(CONFIG_SATA_EXYNOS) += sata_exynos.o sata_exynos_phy.o libahci.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/sata_exynos_phy.c b/drivers/ata/sata_exynos_phy.c
new file mode 100644
index 0000000..ec61db5
--- /dev/null
+++ b/drivers/ata/sata_exynos_phy.c
@@ -0,0 +1,300 @@
+/*
+ * Copyright (c) 2010-2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS - SATA PHY controller driver
+ *
+ * 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.
+*/
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/i2c.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/ahci_platform.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/list.h>
+#include <linux/io.h>
+
+#include <plat/cpu.h>
+
+#include <mach/irqs.h>
+#include <mach/map.h>
+#include <mach/regs-pmu.h>
+#include <mach/regs-sata.h>
+
+#include "sata_phy.h"
+
+#define SATA_TIME_LIMIT 1000
+
+static struct i2c_client *i2c_client;
+
+static struct i2c_driver sataphy_i2c_driver;
+
+struct exynos_sata_phy {
+ void __iomem *mmio;
+ struct resource *mem;
+ struct clk *clk;
+};
+
+static bool sata_is_reg(void __iomem *base, u32 reg, u32 checkbit, u32 status)
+{
+ if ((readl(base + reg) & checkbit) == status)
+ return true;
+ else
+ return false;
+}
+
+static bool wait_for_reg_status(void __iomem *base, u32 reg, u32 checkbit,
+ u32 status)
+{
+ u16 time_limit_cnt = 0;
+ while (!sata_is_reg(base, reg, checkbit, status)) {
+ if (time_limit_cnt == SATA_TIME_LIMIT)
+ return false;
+ udelay(1000);
+ time_limit_cnt++;
+ }
+ return true;
+}
+
+static int sataphy_init(struct sata_phy *phy)
+{
+ int ret;
+ u32 val;
+
+ /* Values to be written to enable 40 bits interface */
+ u8 buf[] = { 0x3A, 0x0B };
+
+ struct exynos_sata_phy *sata_phy;
+
+ if (!i2c_client)
+ return -EPROBE_DEFER;
+
+ sata_phy = (struct exynos_sata_phy *)phy->priv_data;
+
+ clk_enable(sata_phy->clk);
+
+ writel(S5P_PMU_SATA_PHY_CONTROL_EN, EXYNOS5_SATA_PHY_CONTROL);
+
+ val = 0;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->mmio + EXYNOS5_SATA_RESET);
+ val |= 0xFF;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->mmio + EXYNOS5_SATA_RESET);
+ val |= LINK_RESET;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->mmio + EXYNOS5_SATA_RESET);
+ val |= RESET_CMN_RST_N;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->mmio + EXYNOS5_SATA_PHSATA_CTRLM);
+ val &= ~PHCTRLM_REF_RATE;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_PHSATA_CTRLM);
+
+ /* High speed enable for Gen3 */
+ val = readl(sata_phy->mmio + EXYNOS5_SATA_PHSATA_CTRLM);
+ val |= PHCTRLM_HIGH_SPEED;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_PHSATA_CTRLM);
+
+ val = readl(sata_phy->mmio + EXYNOS5_SATA_CTRL0);
+ val |= CTRL0_P0_PHY_CALIBRATED_SEL | CTRL0_P0_PHY_CALIBRATED;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_CTRL0);
+
+ writel(SATA_PHY_GENERATION3, sata_phy->mmio + EXYNOS5_SATA_MODE0);
+
+ ret = i2c_master_send(i2c_client, buf, sizeof(buf));
+ if (ret < 0)
+ return -EINVAL;
+
+ /* release cmu reset */
+ val = readl(sata_phy->mmio + EXYNOS5_SATA_RESET);
+ val &= ~RESET_CMN_RST_N;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->mmio + EXYNOS5_SATA_RESET);
+ val |= RESET_CMN_RST_N;
+ writel(val, sata_phy->mmio + EXYNOS5_SATA_RESET);
+
+ if (wait_for_reg_status(sata_phy->mmio, EXYNOS5_SATA_PHSATA_STATM,
+ PHSTATM_PLL_LOCKED, 1)) {
+ return 0;
+ }
+ return -EINVAL;
+}
+
+static int sataphy_shutdown(struct sata_phy *phy)
+{
+
+ struct exynos_sata_phy *sata_phy;
+
+ sata_phy = (struct exynos_sata_phy *)phy->priv_data;
+
+ clk_disable(sata_phy->clk);
+
+ return 0;
+}
+
+static int __init sata_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *i2c_id)
+{
+ i2c_client = client;
+ return 0;
+}
+
+static int __init sata_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_sata_phy *sataphy;
+ struct sata_phy *phy;
+ struct resource *res;
+ struct device *dev = &pdev->dev;
+ int ret = 0;
+
+ phy = kzalloc(sizeof(struct sata_phy), GFP_KERNEL);
+ if (!phy) {
+ dev_err(&pdev->dev, "failed to allocate memory\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ sataphy = kzalloc(sizeof(struct exynos_sata_phy), GFP_KERNEL);
+ if (!sataphy) {
+ dev_err(dev, "failed to allocate memory\n");
+ ret = -ENOMEM;
+ goto err0;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, "Could not find IO resource\n");
+ ret = -EINVAL;
+ goto err1;
+ }
+
+ sataphy->mem = devm_request_mem_region(dev, res->start,
+ resource_size(res), pdev->name);
+ if (!sataphy->mem) {
+ dev_err(dev, "Could not request IO resource\n");
+ ret = -EINVAL;
+ goto err1;
+ }
+
+ sataphy->mmio =
+ devm_ioremap(dev, res->start, resource_size(res));
+ if (!sataphy->mmio) {
+ dev_err(dev, "failed to remap IO\n");
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ sataphy->clk = devm_clk_get(dev, "sata-phy");
+ if (IS_ERR(sataphy->clk)) {
+ dev_err(dev, "failed to get clk for PHY\n");
+ ret = PTR_ERR(sataphy->clk);
+ goto err3;
+ }
+
+ phy->init = sataphy_init;
+ phy->shutdown = sataphy_shutdown;
+ phy->priv_data = (void *)sataphy;
+ phy->dev = dev;
+
+ ret = sata_add_phy(phy, SATA_PHY_GENERATION3);
+ if (ret < 0)
+ goto err4;
+
+ ret = i2c_add_driver(&sataphy_i2c_driver);
+ if (ret < 0)
+ goto err5;
+
+ platform_set_drvdata(pdev, phy);
+
+ return ret;
+
+ err5:
+ sata_remove_phy(phy);
+
+ err4:
+ clk_disable(sataphy->clk);
+ devm_clk_put(dev, sataphy->clk);
+
+ err3:
+ devm_iounmap(dev, sataphy->mmio);
+
+ err2:
+ devm_release_mem_region(dev, res->start, resource_size(res));
+
+ err1:
+ kfree(sataphy);
+
+ err0:
+ kfree(phy);
+
+ out:
+ return ret;
+}
+
+static int sata_phy_remove(struct platform_device *pdev)
+{
+ struct sata_phy *phy;
+ struct exynos_sata_phy *sataphy;
+
+ phy = platform_get_drvdata(pdev);
+
+ sataphy = (struct exynos_sata_phy *)phy->priv_data;
+ sata_remove_phy(phy);
+
+ kfree(sataphy);
+ kfree(phy);
+
+ return 0;
+}
+
+static const struct of_device_id sata_phy_of_match[] = {
+ { .compatible = "samsung,exynos5-sata-phy", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, sata_phy_of_match);
+
+static const struct i2c_device_id phy_i2c_device_match[] = {
+ { "sata-phy", 0 },
+};
+
+MODULE_DEVICE_TABLE(of, phy_i2c_device_match);
+
+static struct platform_driver sata_phy_driver = {
+ .probe = sata_phy_probe,
+ .remove = sata_phy_remove,
+ .driver = {
+ .name = "sata-phy",
+ .owner = THIS_MODULE,
+ .of_match_table = sata_phy_of_match,
+ },
+};
+
+static struct i2c_driver sataphy_i2c_driver = {
+ .driver = {
+ .name = "sata-phy-i2c",
+ .owner = THIS_MODULE,
+ .of_match_table = phy_i2c_device_match,
+ },
+ .probe = sata_i2c_probe,
+ .id_table = phy_i2c_device_match,
+};
+
+module_platform_driver(sata_phy_driver);
+
+MODULE_DESCRIPTION("EXYNOS SATA PHY DRIVER");
+MODULE_AUTHOR("Vasanth Ananthan, <vasanth.a@samsung.com>");
+MODULE_LICENSE("GPL");
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 5/6] DRIVERS: ATA: SATA controller driver
From: Vasanth Ananthan @ 2012-10-30 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351612897-14923-1-git-send-email-vasanthananthan@gmail.com>
This patch adds a platform driver for SATA controller.
Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
---
arch/arm/mach-exynos/include/mach/regs-pmu.h | 3 +
drivers/ata/Kconfig | 12 ++
drivers/ata/Makefile | 1 +
drivers/ata/sata_exynos.c | 268 ++++++++++++++++++++++++++
4 files changed, 284 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/sata_exynos.c
diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index d4e392b..3716ce8 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -367,4 +367,7 @@
#define EXYNOS5_OPTION_USE_RETENTION (1 << 4)
+/* Only for EXYNOS5250 */
+#define EXYNOS5_SATA_PHY_CONTROL S5P_PMUREG(0x0724)
+
#endif /* __ASM_ARCH_REGS_PMU_H */
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index e3a2972..f3384ed 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -93,6 +93,18 @@ config SATA_PHY
with the framework through the APIs provided and the SATA
device finds and requests for an appropriate PHY device.
+config SATA_EXYNOS
+ bool "Exynos SATA AHCI support"
+ select I2C
+ select HAVE_S3C2410_I2C
+ select I2C_S3C2410
+ select SATA_PHY
+ help
+ This option enables support for Exynos AHCI Serial ATA
+ controllers.
+
+ If unsure, say N.
+
config SATA_FSL
tristate "Freescale 3.0Gbps SATA support"
depends on FSL_SOC
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 3d219a9..43bb38e 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SATA_SIL24) += sata_sil24.o
obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
obj-$(CONFIG_SATA_HIGHBANK) += sata_highbank.o libahci.o
obj-$(CONFIG_SATA_PHY) += sata_phy.o
+obj-$(CONFIG_SATA_EXYNOS) += sata_exynos.o libahci.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/sata_exynos.c b/drivers/ata/sata_exynos.c
new file mode 100644
index 0000000..41dc17d
--- /dev/null
+++ b/drivers/ata/sata_exynos.c
@@ -0,0 +1,268 @@
+/*
+ * Copyright (c) 2010-2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS - SATA controller driver
+ *
+ * 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.
+*/
+
+#include <linux/kernel.h>
+#include <linux/gfp.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/libata.h>
+#include <linux/ahci_platform.h>
+#include <linux/clk.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+
+#include "ahci.h"
+#include "sata_phy.h"
+
+#define MHZ (1000 * 1000)
+
+static const struct ata_port_info ahci_port_info = {
+ .flags = AHCI_FLAG_COMMON,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_ops,
+};
+
+static struct scsi_host_template ahci_platform_sht = {
+ AHCI_SHT("ahci_platform"),
+};
+
+struct exynos_sata {
+ struct clk *sclk;
+ struct clk *clk;
+ struct sata_phy *phy;
+ int irq;
+ unsigned int freq;
+};
+
+static void exynos_sata_parse_dt(struct device_node *np,
+ struct exynos_sata *sata)
+{
+ if (!np)
+ return;
+
+ of_property_read_u32(np, "samsung,sata-freq", &sata->freq);
+}
+
+static int __init exynos_sata_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ata_port_info pi = ahci_port_info;
+ const struct ata_port_info *ppi[] = { &pi, NULL };
+ struct ahci_host_priv *hpriv;
+ struct exynos_sata *sata;
+ struct ata_host *host;
+ struct resource *mem;
+ int n_ports, i, ret;
+
+ sata = devm_kzalloc(dev, sizeof(*sata), GFP_KERNEL);
+ if (!sata) {
+ dev_err(dev, "can't alloc sata\n");
+ return -EINVAL;
+ }
+
+ hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
+ if (!hpriv) {
+ dev_err(dev, "can't alloc ahci_host_priv\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ hpriv->flags |= (unsigned long)pi.private_data;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(dev, "no mmio space\n");
+ ret = -EINVAL;
+ goto err2;
+ }
+
+ sata->irq = platform_get_irq(pdev, 0);
+ if (sata->irq <= 0) {
+ dev_err(dev, "no irq\n");
+ ret = -EINVAL;
+ goto err2;
+ }
+
+ hpriv->mmio = devm_ioremap(dev, mem->start, resource_size(mem));
+ if (!hpriv->mmio) {
+ dev_err(dev, "can't map %pR\n", mem);
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ exynos_sata_parse_dt(dev->of_node, sata);
+
+ sata->sclk = devm_clk_get(dev, "sclk_sata");
+ if (IS_ERR(sata->sclk)) {
+ dev_err(dev, "failed to get sclk_sata\n");
+ ret = PTR_ERR(sata->sclk);
+ goto err3;
+ }
+ clk_enable(sata->sclk);
+
+ clk_set_rate(sata->sclk, sata->freq * MHZ);
+
+ sata->clk = devm_clk_get(dev, "sata");
+ if (IS_ERR(sata->clk)) {
+ dev_err(dev, "failed to get sata clock\n");
+ ret = PTR_ERR(sata->clk);
+ goto err4;
+ }
+ clk_enable(sata->clk);
+
+ /* Get a gen 3 PHY controller */
+
+ sata->phy = sata_get_phy(SATA_PHY_GENERATION3);
+ if (!sata->phy) {
+ dev_err(dev, "failed to get sata phy\n");
+ ret = -EPROBE_DEFER;
+ goto err5;
+ }
+
+ /* Initialize the controller */
+
+ ret = sata_init_phy(sata->phy);
+ if (ret < 0) {
+ dev_err(dev, "failed to initialize sata phy\n");
+ goto err6;
+ }
+
+ ahci_save_initial_config(dev, hpriv, 0, 0);
+
+ /* prepare host */
+ if (hpriv->cap & HOST_CAP_NCQ)
+ pi.flags |= ATA_FLAG_NCQ;
+
+ if (hpriv->cap & HOST_CAP_PMP)
+ pi.flags |= ATA_FLAG_PMP;
+
+ ahci_set_em_messages(hpriv, &pi);
+
+ /* CAP.NP sometimes indicate the index of the last enabled
+ * port, at other times, that of the last possible port, so
+ * determining the maximum port number requires looking at
+ * both CAP.NP and port_map.
+ */
+ n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map));
+
+ host = ata_host_alloc_pinfo(dev, ppi, n_ports);
+ if (!host) {
+ ret = -ENOMEM;
+ goto err7;
+ }
+
+ host->private_data = hpriv;
+
+ if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
+ host->flags |= ATA_HOST_PARALLEL_SCAN;
+ else
+ pr_info(KERN_INFO
+ "ahci: SSS flag set, parallel bus scan disabled\n");
+
+ if (pi.flags & ATA_FLAG_EM)
+ ahci_reset_em(host);
+
+ for (i = 0; i < host->n_ports; i++) {
+ struct ata_port *ap = host->ports[i];
+
+ ata_port_desc(ap, "mmio %pR", mem);
+ ata_port_desc(ap, "port 0x%x", 0x100 + ap->port_no * 0x80);
+
+ /* set enclosure management message type */
+ if (ap->flags & ATA_FLAG_EM)
+ ap->em_message_type = hpriv->em_msg_type;
+
+ /* disabled/not-implemented port */
+ if (!(hpriv->port_map & (1 << i)))
+ ap->ops = &ata_dummy_port_ops;
+ }
+
+ ret = ahci_reset_controller(host);
+ if (ret)
+ goto err7;
+
+ ahci_init_controller(host);
+ ahci_print_info(host, "platform");
+
+ ret = ata_host_activate(host, sata->irq, ahci_interrupt, IRQF_SHARED,
+ &ahci_platform_sht);
+ if (ret)
+ goto err7;
+
+ platform_set_drvdata(pdev, sata);
+
+ return 0;
+
+ err7:
+ sata_shutdown_phy(sata->phy);
+
+ err6:
+ sata_put_phy(sata->phy);
+
+ err5:
+ clk_disable(sata->clk);
+ devm_clk_put(dev, sata->clk);
+
+ err4:
+ clk_disable(sata->sclk);
+ devm_clk_put(dev, sata->sclk);
+
+ err3:
+ devm_iounmap(dev, hpriv->mmio);
+
+ err2:
+ devm_kfree(dev, hpriv);
+
+ err1:
+ devm_kfree(dev, sata);
+
+ return ret;
+}
+
+static int __devexit exynos_sata_remove(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ata_host *host = dev_get_drvdata(dev);
+ struct exynos_sata *sata = platform_get_drvdata(pdev);
+
+ ata_host_detach(host);
+
+ sata_shutdown_phy(sata->phy);
+ sata_put_phy(sata->phy);
+
+ return 0;
+}
+
+static const struct of_device_id ahci_of_match[] = {
+ { .compatible = "samsung,exynos5-sata-ahci", },
+};
+
+MODULE_DEVICE_TABLE(of, ahci_of_match);
+
+static struct platform_driver exynos_sata_driver = {
+ .probe = exynos_sata_probe,
+ .remove = exynos_sata_remove,
+ .driver = {
+ .name = "ahci-sata",
+ .owner = THIS_MODULE,
+ .of_match_table = ahci_of_match,
+ },
+};
+
+module_platform_driver(exynos_sata_driver);
+
+MODULE_DESCRIPTION("EXYNOS SATA DRIVER");
+MODULE_AUTHOR("Vasanth Ananthan, <vasanth.a@samsung.com>");
+MODULE_LICENSE("GPL");
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 4/6] DRIVERS:I2C: I2C driver polling mode support
From: Vasanth Ananthan @ 2012-10-30 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351612897-14923-1-git-send-email-vasanthananthan@gmail.com>
This patch adds polling mode support for i2c s3c-2410 driver.
The I2C_SATAPHY controller lacks an interrupt line but the s3c-2410 driver
is interrupt driven. Hence this support is required for functioning
of the I2C_SATAPHY controller.
Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
---
drivers/i2c/busses/i2c-s3c2410.c | 79 ++++++++++++++++++++++++++++---------
1 files changed, 60 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 3e0335f..5712e40 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -48,6 +48,7 @@
#define QUIRK_S3C2440 (1 << 0)
#define QUIRK_HDMIPHY (1 << 1)
#define QUIRK_NO_GPIO (1 << 2)
+#define QUIRK_SATAPHY (1 << 3)
/* i2c controller state */
enum s3c24xx_i2c_state {
@@ -102,10 +103,14 @@ static struct platform_device_id s3c24xx_driver_ids[] = {
};
MODULE_DEVICE_TABLE(platform, s3c24xx_driver_ids);
+static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c, unsigned long iicstat);
+
#ifdef CONFIG_OF
static const struct of_device_id s3c24xx_i2c_match[] = {
{ .compatible = "samsung,s3c2410-i2c", .data = (void *)0 },
{ .compatible = "samsung,s3c2440-i2c", .data = (void *)QUIRK_S3C2440 },
+ { .compatible = "samsung,exynos5-sata-phy-i2c",
+ .data = (void *)(QUIRK_S3C2440 | QUIRK_SATAPHY | QUIRK_NO_GPIO) },
{ .compatible = "samsung,s3c2440-hdmiphy-i2c",
.data = (void *)(QUIRK_S3C2440 | QUIRK_HDMIPHY | QUIRK_NO_GPIO) },
{},
@@ -146,7 +151,8 @@ static inline void s3c24xx_i2c_master_complete(struct s3c24xx_i2c *i2c, int ret)
if (ret)
i2c->msg_idx = ret;
- wake_up(&i2c->wait);
+ if (!(i2c->quirks & QUIRK_SATAPHY))
+ wake_up(&i2c->wait);
}
static inline void s3c24xx_i2c_disable_ack(struct s3c24xx_i2c *i2c)
@@ -184,6 +190,23 @@ static inline void s3c24xx_i2c_enable_irq(struct s3c24xx_i2c *i2c)
}
+static bool is_ack(struct s3c24xx_i2c *i2c)
+{
+ u32 time_out = i2c->tx_setup;
+
+ while (--time_out) {
+ if (readl(i2c->regs + S3C2410_IICCON)
+ & S3C2410_IICCON_IRQPEND) {
+ if (!(readl(i2c->regs + S3C2410_IICSTAT)
+ & S3C2410_IICSTAT_LASTBIT))
+ return true;
+ }
+ udelay(time_out);
+ }
+
+ return false;
+}
+
/* s3c24xx_i2c_message_start
*
* put the start of a message onto the bus
@@ -227,6 +250,15 @@ static void s3c24xx_i2c_message_start(struct s3c24xx_i2c *i2c,
stat |= S3C2410_IICSTAT_START;
writel(stat, i2c->regs + S3C2410_IICSTAT);
+
+ if (i2c->quirks & QUIRK_SATAPHY) {
+ while ((i2c->msg_num != 0) && is_ack(i2c)) {
+ i2c_s3c_irq_nextbyte(i2c, stat);
+ stat = readl(i2c->regs + S3C2410_IICSTAT);
+ if (stat & S3C2410_IICSTAT_ARBITR)
+ dev_err(i2c->dev, "deal with arbitration loss\n");
+ }
+ }
}
static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c *i2c, int ret)
@@ -552,19 +584,23 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
s3c24xx_i2c_message_start(i2c, msgs);
spin_unlock_irq(&i2c->lock);
- timeout = wait_event_timeout(i2c->wait, i2c->msg_num == 0, HZ * 5);
-
ret = i2c->msg_idx;
- /* having these next two as dev_err() makes life very
- * noisy when doing an i2cdetect */
+ if (!(i2c->quirks & QUIRK_SATAPHY)) {
- if (timeout == 0)
- dev_dbg(i2c->dev, "timeout\n");
- else if (ret != num)
- dev_dbg(i2c->dev, "incomplete xfer (%d)\n", ret);
+ timeout = wait_event_timeout(i2c->wait,
+ i2c->msg_num == 0, HZ * 5);
- /* ensure the stop has been through the bus */
+ /* having these next two as dev_err() makes life very
+ * noisy when doing an i2cdetect */
+
+ if (timeout == 0)
+ dev_dbg(i2c->dev, "timeout\n");
+ else if (ret != num)
+ dev_dbg(i2c->dev, "incomplete xfer (%d)\n", ret);
+
+ /* ensure the stop has been through the bus */
+ }
dev_dbg(i2c->dev, "waiting for bus idle\n");
@@ -710,6 +746,9 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c, unsigned int *got)
if (div1 == 512)
iiccon |= S3C2410_IICCON_TXDIV_512;
+ if (i2c->quirks & QUIRK_SATAPHY)
+ iiccon |= S3C2410_IICCON_SCALE(2);
+
writel(iiccon, i2c->regs + S3C2410_IICCON);
if (i2c->quirks & QUIRK_S3C2440) {
@@ -1023,18 +1062,20 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
* ensure no current IRQs pending
*/
- i2c->irq = ret = platform_get_irq(pdev, 0);
- if (ret <= 0) {
- dev_err(&pdev->dev, "cannot find IRQ\n");
- goto err_iomap;
- }
+ if (!(i2c->quirks & QUIRK_SATAPHY)) {
+ i2c->irq = ret = platform_get_irq(pdev, 0);
+ if (ret <= 0) {
+ dev_err(&pdev->dev, "cannot find IRQ\n");
+ goto err_iomap;
+ }
- ret = request_irq(i2c->irq, s3c24xx_i2c_irq, 0,
+ ret = request_irq(i2c->irq, s3c24xx_i2c_irq, 0,
dev_name(&pdev->dev), i2c);
- if (ret != 0) {
- dev_err(&pdev->dev, "cannot claim IRQ %d\n", i2c->irq);
- goto err_iomap;
+ if (ret != 0) {
+ dev_err(&pdev->dev, "cannot claim IRQ %d\n", i2c->irq);
+ goto err_iomap;
+ }
}
ret = s3c24xx_i2c_register_cpufreq(i2c);
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 3/6] DRIVERS: ATA: SATA PHY utility framework
From: Vasanth Ananthan @ 2012-10-30 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351612897-14923-1-git-send-email-vasanthananthan@gmail.com>
This patch adds SATA PHY utility framework APIs. The framework acts as an
interface between the SATA device and the PHY device. The SATA PHY device
registers itself with the framework through the APIs provided and the SATA
device finds and requests for an appropriate PHY device.
Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
---
drivers/ata/Kconfig | 10 +++++
drivers/ata/Makefile | 1 +
drivers/ata/sata_phy.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++
drivers/ata/sata_phy.h | 44 ++++++++++++++++++++
4 files changed, 159 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/sata_phy.c
create mode 100644 drivers/ata/sata_phy.h
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index e08d322..e3a2972 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -83,6 +83,16 @@ config SATA_AHCI_PLATFORM
If unsure, say N.
+config SATA_PHY
+ bool "SATA PHY Framework"
+ default n
+ help
+ This option enables the SATA PHY utility framework APIs.
+ The framework acts as an interface between the SATA device
+ and the PHY device. The SATA PHY device registers itself
+ with the framework through the APIs provided and the SATA
+ device finds and requests for an appropriate PHY device.
+
config SATA_FSL
tristate "Freescale 3.0Gbps SATA support"
depends on FSL_SOC
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 9329daf..3d219a9 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X) += sata_inic162x.o
obj-$(CONFIG_SATA_SIL24) += sata_sil24.o
obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
obj-$(CONFIG_SATA_HIGHBANK) += sata_highbank.o libahci.o
+obj-$(CONFIG_SATA_PHY) += sata_phy.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/sata_phy.c b/drivers/ata/sata_phy.c
new file mode 100644
index 0000000..e5631a9
--- /dev/null
+++ b/drivers/ata/sata_phy.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (c) 2010-2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS - SATA utility framework.
+ *
+ * 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.
+*/
+
+#include <linux/kernel.h>
+#include <linux/export.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/list.h>
+#include "sata_phy.h"
+
+static LIST_HEAD(phy_list);
+static DEFINE_SPINLOCK(phy_lock);
+
+struct sata_phy *sata_get_phy(enum sata_phy_type type)
+{
+ struct sata_phy *x = NULL;
+ unsigned long flag;
+
+ if (list_empty(&phy_list))
+ return x;
+
+ spin_lock_irqsave(&phy_lock, flag);
+
+ list_for_each_entry(x, &phy_list, head) {
+ if (x->type == type) {
+ get_device(x->dev);
+ break;
+ }
+ }
+
+ spin_unlock_irqrestore(&phy_lock, flag);
+ return x;
+}
+EXPORT_SYMBOL(sata_get_phy);
+
+int sata_add_phy(struct sata_phy *phy, enum sata_phy_type type)
+{
+ unsigned long flag;
+ unsigned int ret = -EINVAL;
+ struct sata_phy *x;
+
+ spin_lock_irqsave(&phy_lock, flag);
+
+ if (!phy)
+ return ret;
+
+ list_for_each_entry(x, &phy_list, head) {
+ if (x->type == type) {
+ dev_err(phy->dev, "transceiver type already exists\n");
+ goto out;
+ }
+ }
+ phy->type = type;
+ list_add_tail(&phy->head, &phy_list);
+ ret = 0;
+
+ out:
+ spin_unlock_irqrestore(&phy_lock, flag);
+ return ret;
+}
+EXPORT_SYMBOL(sata_add_phy);
+
+void sata_remove_phy(struct sata_phy *phy)
+{
+ unsigned long flag;
+ struct sata_phy *x;
+
+ spin_lock_irqsave(&phy_lock, flag);
+
+ if (!phy)
+ return;
+
+ list_for_each_entry(x, &phy_list, head) {
+ if (x->type == phy->type)
+ list_del(&phy->head);
+ }
+
+ spin_unlock_irqrestore(&phy_lock, flag);
+}
+EXPORT_SYMBOL(sata_remove_phy);
+
+void sata_put_phy(struct sata_phy *phy)
+{
+ unsigned long flag;
+
+ spin_lock_irqsave(&phy_lock, flag);
+
+ if (!phy)
+ return;
+
+ put_device(phy->dev);
+ spin_unlock_irqrestore(&phy_lock, flag);
+
+}
+EXPORT_SYMBOL(sata_put_phy);
diff --git a/drivers/ata/sata_phy.h b/drivers/ata/sata_phy.h
new file mode 100644
index 0000000..dc38683
--- /dev/null
+++ b/drivers/ata/sata_phy.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright (c) 2010-2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS - SATA utility framework definitions.
+ *
+ * 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.
+*/
+
+enum sata_phy_type {
+ SATA_PHY_GENERATION1,
+ SATA_PHY_GENERATION2,
+ SATA_PHY_GENERATION3,
+};
+
+struct sata_phy {
+ int (*init) (struct sata_phy *);
+ int (*shutdown) (struct sata_phy *);
+ struct device *dev;
+ void *priv_data;
+ enum sata_phy_type type;
+ struct list_head head;
+};
+
+static inline int sata_init_phy(struct sata_phy *x)
+{
+ if (x && x->init)
+ return x->init(x);
+
+ return -EINVAL;
+}
+
+static inline void sata_shutdown_phy(struct sata_phy *x)
+{
+ if (x && x->shutdown)
+ x->shutdown(x);
+}
+
+struct sata_phy *sata_get_phy(enum sata_phy_type);
+int sata_add_phy(struct sata_phy *, enum sata_phy_type);
+void sata_remove_phy(struct sata_phy *);
+void sata_put_phy(struct sata_phy *);
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 2/6] ARM: EXYNOS5: DT Support for SATA and SATA PHY
From: Vasanth Ananthan @ 2012-10-30 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351612897-14923-1-git-send-email-vasanthananthan@gmail.com>
This patch adds Device Nodes for SATA and SATA PHY device.
Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
---
.../devicetree/bindings/ata/exynos-sata-phy.txt | 14 ++++++++++++++
.../devicetree/bindings/ata/exynos-sata.txt | 17 +++++++++++++++++
arch/arm/boot/dts/exynos5250-smdk5250.dts | 15 +++++++++++++++
arch/arm/boot/dts/exynos5250.dtsi | 18 ++++++++++++++++++
arch/arm/mach-exynos/include/mach/map.h | 3 +++
arch/arm/mach-exynos/mach-exynos5-dt.c | 6 ++++++
6 files changed, 73 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
create mode 100644 Documentation/devicetree/bindings/ata/exynos-sata.txt
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
new file mode 100644
index 0000000..37824fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
@@ -0,0 +1,14 @@
+* Samsung SATA PHY Controller
+
+SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
+Each SATA PHY controller should have its own node.
+
+Required properties:
+- compatible : compatible list, contains "samsung,exynos5-sata-phy"
+- reg : <registers mapping>
+
+Example:
+ sata at ffe07000 {
+ compatible = "samsung,exynos5-sata-phy";
+ reg = <0xffe07000 0x1000>;
+ };
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt b/Documentation/devicetree/bindings/ata/exynos-sata.txt
new file mode 100644
index 0000000..0849f10
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/exynos-sata.txt
@@ -0,0 +1,17 @@
+* Samsung AHCI SATA Controller
+
+SATA nodes are defined to describe on-chip Serial ATA controllers.
+Each SATA controller should have its own node.
+
+Required properties:
+- compatible : compatible list, contains "samsung,exynos5-sata"
+- interrupts : <interrupt mapping for SATA IRQ>
+- reg : <registers mapping>
+- samsung,sata-freq : <frequency in MHz>
+
+Example:
+ sata at ffe08000 {
+ compatible = "samsung,exynos5-sata";
+ reg = <0xffe08000 0x1000>;
+ interrupts = <115>;
+ };
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a352df4..6910deb 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -55,6 +55,21 @@
};
};
+ i2c at 121D0000 {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-max-bus-freq = <40000>;
+ samsung,i2c-slave-addr = <0x38>;
+
+ sata-phy {
+ compatible = "samsung,sata-phy";
+ reg = <0x38>;
+ };
+ };
+
+ sata at 122F0000 {
+ samsung,sata-freq = <66>;
+ };
+
i2c at 12C80000 {
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index dddfd6e..e41520f 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -92,6 +92,17 @@
interrupts = <0 54 0>;
};
+ sata at 122F0000 {
+ compatible = "samsung,exynos5-sata-ahci";
+ reg = <0x122F0000 0x1ff>;
+ interrupts = <0 115 0>;
+ };
+
+ sata-phy at 12170000 {
+ compatible = "samsung,exynos5-sata-phy";
+ reg = <0x12170000 0x1ff>;
+ };
+
i2c at 12C60000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C60000 0x100>;
@@ -156,6 +167,13 @@
#size-cells = <0>;
};
+ i2c at 121D0000 {
+ compatible = "samsung,exynos5-sata-phy-i2c";
+ reg = <0x121D0000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
spi_0: spi at 12d20000 {
compatible = "samsung,exynos4210-spi";
reg = <0x12d20000 0x100>;
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 8480849..ffeb761 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -188,6 +188,9 @@
#define EXYNOS4_PA_SATA 0x12560000
#define EXYNOS4_PA_SATAPHY 0x125D0000
#define EXYNOS4_PA_SATAPHY_CTRL 0x126B0000
+#define EXYNOS5_PA_SATA_PHY_CTRL 0x12170000
+#define EXYNOS5_PA_SATA_PHY_I2C 0x121D0000
+#define EXYNOS5_PA_SATA_BASE 0x122F0000
#define EXYNOS4_PA_SROMC 0x12570000
#define EXYNOS5_PA_SROMC 0x12250000
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c
index db1cd8e..7dbd4cc 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -61,6 +61,12 @@ static const struct of_dev_auxdata exynos5250_auxdata_lookup[] __initconst = {
"exynos4210-spi.1", NULL),
OF_DEV_AUXDATA("samsung,exynos4210-spi", EXYNOS5_PA_SPI2,
"exynos4210-spi.2", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5-sata-ahci", EXYNOS5_PA_SATA_BASE,
+ "exynos5-sata", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5-sata-phy", EXYNOS5_PA_SATA_PHY_CTRL,
+ "exynos5-sata-phy", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5-sata-phy-i2c", EXYNOS5_PA_SATA_PHY_I2C,
+ "exynos5-sata-phy-i2c", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS5_PA_PDMA0, "dma-pl330.0", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS5_PA_PDMA1, "dma-pl330.1", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS5_PA_MDMA1, "dma-pl330.2", NULL),
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 1/6] ARM: EXYNOS5: Clock settings for SATA and SATA PHY
From: Vasanth Ananthan @ 2012-10-30 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351612897-14923-1-git-send-email-vasanthananthan@gmail.com>
This patch adds neccessary clock entries for SATA, SATA PHY and
I2C_SATAPHY
Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
---
arch/arm/mach-exynos/clock-exynos5.c | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c b/arch/arm/mach-exynos/clock-exynos5.c
index c44ca1e..124c54f 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -651,15 +651,20 @@ static struct clk exynos5_init_clocks_off[] = {
.ctrlbit = (1 << 15),
}, {
.name = "sata",
- .devname = "ahci",
+ .devname = "exynos5-sata",
+ .parent = &exynos5_clk_aclk_200.clk,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit = (1 << 6),
}, {
- .name = "sata_phy",
+ .name = "sata-phy",
+ .devname = "exynos5-sata-phy",
+ .parent = &exynos5_clk_aclk_200.clk,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit = (1 << 24),
}, {
- .name = "sata_phy_i2c",
+ .name = "i2c",
+ .devname = "exynos5-sata-phy-i2c",
+ .parent = &exynos5_clk_aclk_200.clk,
.enable = exynos5_clk_ip_fsys_ctrl,
.ctrlbit = (1 << 25),
}, {
@@ -1226,6 +1231,16 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.reg_div = { .reg = EXYNOS5_CLKDIV_TOP0, .shift = 24, .size = 3 },
}, {
.clk = {
+ .name = "sclk_sata",
+ .devname = "exynos5-sata",
+ .enable = exynos5_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 << 24),
+ },
+ .sources = &exynos5_clkset_aclk,
+ .reg_src = { .reg = EXYNOS5_CLKSRC_FSYS, .shift = 24, .size = 1 },
+ .reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 20, .size = 4 },
+ }, {
+ .clk = {
.name = "sclk_gscl_wrap",
.devname = "s5p-mipi-csis.0",
.enable = exynos5_clksrc_mask_gscl_ctrl,
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2 0/6] Adding support for SATA in EXYNO5
From: Vasanth Ananthan @ 2012-10-30 16:01 UTC (permalink / raw)
To: linux-arm-kernel
The following set of patches provides drivers for SATA
and SATA PHY controller and also an interface for the
two entity to interact.
Vasanth Ananthan (6):
ARM: EXYNOS5: Clock settings for SATA and SATA PHY
ARM: EXYNOS5: DT Support for SATA and SATA PHY
DRIVERS: ATA: SATA PHY utility framework
DRIVERS:I2C: I2C driver polling mode support
DRIVERS: ATA: SATA controller driver
DRIVERS: ATA: SATA PHY controller driver
.../devicetree/bindings/ata/exynos-sata-phy.txt | 14 +
.../devicetree/bindings/ata/exynos-sata.txt | 17 ++
arch/arm/boot/dts/exynos5250-smdk5250.dts | 15 +
arch/arm/boot/dts/exynos5250.dtsi | 18 ++
arch/arm/mach-exynos/clock-exynos5.c | 21 ++-
arch/arm/mach-exynos/include/mach/map.h | 3 +
arch/arm/mach-exynos/include/mach/regs-pmu.h | 3 +
arch/arm/mach-exynos/include/mach/regs-sata.h | 29 ++
arch/arm/mach-exynos/mach-exynos5-dt.c | 6 +
drivers/ata/Kconfig | 22 ++
drivers/ata/Makefile | 2 +
drivers/ata/sata_exynos.c | 268 +++++++++++++++++
drivers/ata/sata_exynos_phy.c | 300 ++++++++++++++++++++
drivers/ata/sata_phy.c | 104 +++++++
drivers/ata/sata_phy.h | 44 +++
drivers/i2c/busses/i2c-s3c2410.c | 79 ++++--
16 files changed, 923 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
create mode 100644 Documentation/devicetree/bindings/ata/exynos-sata.txt
create mode 100644 arch/arm/mach-exynos/include/mach/regs-sata.h
create mode 100644 drivers/ata/sata_exynos.c
create mode 100644 drivers/ata/sata_exynos_phy.c
create mode 100644 drivers/ata/sata_phy.c
create mode 100644 drivers/ata/sata_phy.h
--
1.7.4.1
^ permalink raw reply
* [PATCH v3] video: Versatile Express DVI output driver
From: Pawel Moll @ 2012-10-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350405036-17997-1-git-send-email-pawel.moll@arm.com>
Hello again Florian,
On Tue, 2012-10-16 at 17:30 +0100, Pawel Moll wrote:
> Versatile Express' DVI video output can be connected to one the three
> sources - motherboard's CLCD controller or a video signal generated
> by one of the daughterboards.
>
> This driver configures the muxer FPGA so the output displays content
> of one of the framebuffers in the system (0 by default, can be changed
> by user writing to the "fb" sysfs attribute of the muxfpga device).
>
> It will also set up the display formatter mode and keep it up
> to date with mode changes requested by the user (eg. with fbset
> tool).
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
It's just a polite a friendly nag regarding this patch - it's been 2
weeks since I posted this version (and 1.5 month since the first one)...
Does it look good enough or completely wrong?
Cheers!
Pawe?
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030151642.GE29159@arwen.pp.htv.fi>
On Tue, Oct 30, 2012 at 05:16:42PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 02:07:15PM +0000, Mark Brown wrote:
> > > and all of that SoC-specific detail is already hidden behind power
> > > domains, runtime PM, pinctrl, clk API, regulator framework, etc.
> > That's all getting rather open coded, especially if you're going to get
> > down to a situation where you have varying ordering constraints between
> > the different APIs on different SoCs.
> however we need to consider those cases right ? Otherwise we will endup
> pushing something to mainline which will have to be reverted couple
> weeks later after a big rant from Linus ;-)
I'm not sure there's much risk of that either way; if anything it seems
like it ought to be cleaner to have the stuff owned by the SoCs.
> > > and this is one of the issues we're all trying to solve today so we have
> > > single zImage approach for the ARM port.
> > I don't see the relevance of single zImage here; device tree is supposed
> > to solve that one.
> DT is part of the deal. DT alone will solve nothing.
If DT isn't relevant I'm not sure what you're saying about single
zImage? The only relevance I can see for that is the data and
configuration bloating the kernel, something that DT is supposed to
address - this is the main use case where DT has benefits.
> > Well, nothing's going to stop that happening if people are determined
> > enough - one could equally see that there'll be flags getting passed to
> > control the ordering of calls if things are open coded. I would expect
> > that with a power domain style approach any data would be being passed
> > directly and bypassing the driver completely.
> situations like that would be a lot more rare in open coded case, don't
> you think ? Also a lot more local, since they will show up on a driver
> source code which is used in a small set of use cases, instead of being
> part of the pm domain implementation for the entire platform.
I don't see how open coding helps prevent people doing silly things, it
seems like it'd have at most neutral impact (and of course it does
require going round all the drivers every time someone comes up with a
new idea for doing things which is a bit tedious).
> > Essentially all the patches I'm seeing adding pinctrl are totally
> > mindless, most of them are just doing the initial setup on boot and not
> > doing any active management at runtime at all.
> have you considered that might be just a first step ? I have mentioned
> this before. We first add the bare minimum and work on PM optimizations
> later. You can be sure most likely those mindless patches you're seeing
> are probably building blocks for upcoming patches adding sleep/idle
> modes.
The sleep/idle modes are just a basic extension of the same idea, I'd
not anticipate much difference there (and indeed anything where pinmux
power saving makes a meaningful impact will I suspect need to be using
runtime PM to allow SoC wide power savings anyway).
> > A big part of my point here is that it's not at all clear to me that it
> > is the driver which knows what's going on. For SoC-specific IPs you can
> > be confident about how the SoC integration looks but for IPs that get
> > reused widely this becomes less true.
> I don't think so. As long as we keep the meaning of the 'default'
> pinctrl state to mean that this is the working state for the IP,
> underlying pinctrl-$arch implementation should know how to set muxing up
> properly, no ?
But then this comes round to the mindless code that ought to be factored
out :) Only the more interesting cases that do something unusual really
register here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/649eab57/attachment.sig>
^ permalink raw reply
* [PATCH] i2c: mv64xxx: Add support Armada-XP SoC
From: Sergei Shtylyov @ 2012-10-30 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351593581-19555-1-git-send-email-iwamatsu@nigauri.org>
Hello.
On 10/30/2012 01:39 PM, Nobuhiro Iwamatsu wrote:
> The Armada-XP SoC has the same I2C controller as mv64xxxi-i2c.
> This validates to use mv64xxx in this SoC.
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 65dd599..ff53cf4 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -474,7 +474,7 @@ config I2C_MPC
>
> config I2C_MV64XXX
> tristate "Marvell mv64xxx I2C Controller"
> - depends on (MV64X60 || PLAT_ORION)
> + depends on (MV64X60 || PLAT_ORION || MACH_ARMADA_370_XP)
Could remove useless parens, while at it...
WBR, Sergei
^ permalink raw reply
* [PATCH] mmc: at91-mci: remove driver
From: ludovic.desroches @ 2012-10-30 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a9v4otqh.fsf@octavius.laptop.org>
Hi,
Le 10/30/2012 04:38 PM, Chris Ball a ?crit :
> Hi,
>
> On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 11:09 Tue 30 Oct , Chris Ball wrote:
>>> Hi,
>>>
>>> On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> Thanks! Pushed to mmc-next for 3.8.
>>>>
>>>> if you don't mind I prefer to take it via at91
>>>>
>>>> I've a patch series that cleanup the platform_data it's difficult to merge
>>>> with this one
>>>
>>> Hm, I don't understand why it should be difficult to merge. Is it
>>> because this patch modifies arch/arm/mach-at91/include/mach/board.h?
>>>
>>> If so, sounds like we should just take that change out of this patch
>>> and have it go into your platform data cleanup patch, and then I can
>>> merge the drivers/mmc change independently? Let me know what you think.
>> I'm modifing and moiving the board.h so this file will not exist anymore
>>
>> and the platform data are not anymore in arch/arm/mach-at91/include/mach/board.h
>
> Can we take the modification of board.h out of this patch, then,
> leaving just the drivers/mmc/ changes?
Yes I can remove board.h changes from the patch. Jean-Christophe, do you
agree too?
Ludovic
>
> - Chris.
>
^ permalink raw reply
* [PATCH] mmc: at91-mci: remove driver
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-30 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a9v4otqh.fsf@octavius.laptop.org>
On 11:38 Tue 30 Oct , Chris Ball wrote:
> Hi,
>
> On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:09 Tue 30 Oct , Chris Ball wrote:
> >> Hi,
> >>
> >> On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> >> Thanks! Pushed to mmc-next for 3.8.
> >> >
> >> > if you don't mind I prefer to take it via at91
> >> >
> >> > I've a patch series that cleanup the platform_data it's difficult to merge
> >> > with this one
> >>
> >> Hm, I don't understand why it should be difficult to merge. Is it
> >> because this patch modifies arch/arm/mach-at91/include/mach/board.h?
> >>
> >> If so, sounds like we should just take that change out of this patch
> >> and have it go into your platform data cleanup patch, and then I can
> >> merge the drivers/mmc change independently? Let me know what you think.
> > I'm modifing and moiving the board.h so this file will not exist anymore
> >
> > and the platform data are not anymore in arch/arm/mach-at91/include/mach/board.h
>
> Can we take the modification of board.h out of this patch, then,
> leaving just the drivers/mmc/ changes?
If you really insist but for changelog history and bisectable I'll prefer to
do not do so
Best Regards,
J.
^ permalink raw reply
* [PATCH] mmc: at91-mci: remove driver
From: Chris Ball @ 2012-10-30 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030153350.GC19021@game.jcrosoft.org>
Hi,
On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:09 Tue 30 Oct , Chris Ball wrote:
>> Hi,
>>
>> On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> >> Thanks! Pushed to mmc-next for 3.8.
>> >
>> > if you don't mind I prefer to take it via at91
>> >
>> > I've a patch series that cleanup the platform_data it's difficult to merge
>> > with this one
>>
>> Hm, I don't understand why it should be difficult to merge. Is it
>> because this patch modifies arch/arm/mach-at91/include/mach/board.h?
>>
>> If so, sounds like we should just take that change out of this patch
>> and have it go into your platform data cleanup patch, and then I can
>> merge the drivers/mmc change independently? Let me know what you think.
> I'm modifing and moiving the board.h so this file will not exist anymore
>
> and the platform data are not anymore in arch/arm/mach-at91/include/mach/board.h
Can we take the modification of board.h out of this patch, then,
leaving just the drivers/mmc/ changes?
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH] mmc: at91-mci: remove driver
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-30 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ehkgov3a.fsf@octavius.laptop.org>
On 11:09 Tue 30 Oct , Chris Ball wrote:
> Hi,
>
> On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> Thanks! Pushed to mmc-next for 3.8.
> >
> > if you don't mind I prefer to take it via at91
> >
> > I've a patch series that cleanup the platform_data it's difficult to merge
> > with this one
>
> Hm, I don't understand why it should be difficult to merge. Is it
> because this patch modifies arch/arm/mach-at91/include/mach/board.h?
>
> If so, sounds like we should just take that change out of this patch
> and have it go into your platform data cleanup patch, and then I can
> merge the drivers/mmc change independently? Let me know what you think.
I'm modifing and moiving the board.h so this file will not exist anymore
and the platform data are not anymore in arch/arm/mach-at91/include/mach/board.h
Best Regards,
J.
>
> Thanks,
>
> - Chris.
> --
> Chris Ball <cjb@laptop.org> <http://printf.net/>
> One Laptop Per Child
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-30 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030140714.GO4511@opensource.wolfsonmicro.com>
Hi,
On Tue, Oct 30, 2012 at 02:07:15PM +0000, Mark Brown wrote:
> On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 11:24:10AM +0000, Mark Brown wrote:
>
> > > We need some place to put the SoC integration; power domains seem like
> > > the obvious place to me but YMMV. Nothing about having this out of the
>
> > except that pin muxing has nothing to do with power domain. To me that
> > sounds like an abuse of the API.
>
> Well, we can call the API Archibald if we like... what I mean is
I'm sure you know it's not at all about the name and much more about the
semantics ;-)
> something that sits in the system below the device in pretty much
> exactly the way that power domains do.
>
> > > drivers requires that this be done by individual subsystems in isolation
> > > from each other. Half the point here is that for the reusable IPs this
> > > stuff often isn't driver specific at all, it's often more about the SoC
> > > integration than it is about the driver and so you'll get a consistent
> > > pattern for most IPs on the SoC.
>
> > and all of that SoC-specific detail is already hidden behind power
> > domains, runtime PM, pinctrl, clk API, regulator framework, etc.
>
> That's all getting rather open coded, especially if you're going to get
> down to a situation where you have varying ordering constraints between
> the different APIs on different SoCs.
however we need to consider those cases right ? Otherwise we will endup
pushing something to mainline which will have to be reverted couple
weeks later after a big rant from Linus ;-)
> > > > How can you make sure that this will work for at least 50% of the
> > > > drivers ? You just can't. We don't know the implementation details of
> > > > every arch/soc/platform supported by Linux today to make that decision.
>
> > > Well, we've managed to get along for rather a long time with essentially
> > > all architectures implementing this stuff by doing static setup for the
> > > pins on boot. That does suggest we can get a reasonably long way with
>
> > and this is one of the issues we're all trying to solve today so we have
> > single zImage approach for the ARM port.
>
> I don't see the relevance of single zImage here; device tree is supposed
> to solve that one.
DT is part of the deal. DT alone will solve nothing.
> > > something simple, and it does seem to match up with how things usually
> > > look at an electrical level too.
>
> > simple ? I really doubt it. Just look at the amount of code duplication
> > the ARM port had (still has in some places) to handle platform-specific
> > details.
>
> What I'm saying here is that I'm concerned about us ending up with more
> code duplication...
a fair concern.
> > It turned out that drivers weren't very portable when they had to do
> > platform-specific initialization, we were all abusing platform_data to
> > pass strings and/or function pointers down to drivers and so on.
>
> > I'm concerned if we hide pinctrl under e.g. power domains (as said
> > above, it sounds like an abuse of the API to me) we will end up with a
> > situation like above. Maybe not as bad, but still weird-looking.
>
> Well, nothing's going to stop that happening if people are determined
> enough - one could equally see that there'll be flags getting passed to
> control the ordering of calls if things are open coded. I would expect
> that with a power domain style approach any data would be being passed
> directly and bypassing the driver completely.
situations like that would be a lot more rare in open coded case, don't
you think ? Also a lot more local, since they will show up on a driver
source code which is used in a small set of use cases, instead of being
part of the pm domain implementation for the entire platform.
> > > It seems fairly obvious that if we need to add identical bolier plate
> > > code to lots of drivers we're doing something wrong, it's just churn for
> > > little practical gain and a problem if we ever decide to change how this
> > > stuff works in the future.
>
> > I wouldn't consider it boilerplate if you remember that each driver
> > might have different requirements regarding how all of those details
> > need to be handled.
>
> Essentially all the patches I'm seeing adding pinctrl are totally
> mindless, most of them are just doing the initial setup on boot and not
> doing any active management at runtime at all.
have you considered that might be just a first step ? I have mentioned
this before. We first add the bare minimum and work on PM optimizations
later. You can be sure most likely those mindless patches you're seeing
are probably building blocks for upcoming patches adding sleep/idle
modes.
> > We have to consider power consumption, ordering of calls, proper IP
> > setup, IP reuse on multiple platforms (even multiple ARCHes), etc etc,
> > and to get that right outside of the driver - who's the only class that
> > actually knows what it needs to do with its resources - will just be too
> > complex and error-prone.
>
> A big part of my point here is that it's not at all clear to me that it
> is the driver which knows what's going on. For SoC-specific IPs you can
> be confident about how the SoC integration looks but for IPs that get
> reused widely this becomes less true.
I don't think so. As long as we keep the meaning of the 'default'
pinctrl state to mean that this is the working state for the IP,
underlying pinctrl-$arch implementation should know how to set muxing up
properly, no ?
> > I would strongly suggest starting with explicit calls to pinctrl, clk
> > API, etc and if we can really prove later that 95% of the users are
> > "standard", then we can factor code out, but making that assumption now
> > is quite risky IMHO.
>
> Like I say I think we're already seeing a pattern here, the code going
> into most drivers looks *very* similar with lots of the drivers simply
> calling get_select_default().
might be true, but we don't really know if those aren't building blocks
for upcoming PM optimizations IMO.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/973775e3/attachment.sig>
^ permalink raw reply
* [PATCH] mmc: at91-mci: remove driver
From: Chris Ball @ 2012-10-30 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030150113.GB19021@game.jcrosoft.org>
Hi,
On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Thanks! Pushed to mmc-next for 3.8.
>
> if you don't mind I prefer to take it via at91
>
> I've a patch series that cleanup the platform_data it's difficult to merge
> with this one
Hm, I don't understand why it should be difficult to merge. Is it
because this patch modifies arch/arm/mach-at91/include/mach/board.h?
If so, sounds like we should just take that change out of this patch
and have it go into your platform data cleanup patch, and then I can
merge the drivers/mmc change independently? Let me know what you think.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH 1/3] irqchip: Move ARM GIC to drivers/irqchip
From: Thomas Petazzoni @ 2012-10-30 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351608860-24617-2-git-send-email-robherring2@gmail.com>
Rob,
On Tue, 30 Oct 2012 09:54:18 -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Now that we have drivers/irqchip, move GIC irqchip to drivers/irqchip. This
> is necessary to share the GIC with arm and arm64.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> arch/arm/common/Kconfig | 8 --------
> arch/arm/common/Makefile | 1 -
> drivers/irqchip/Kconfig | 8 ++++++++
> drivers/irqchip/Makefile | 1 +
> arch/arm/common/gic.c => drivers/irqchip/irq-gic.c | 0
> drivers/irqchip/irqchip.c | 10 ++++++++++
> drivers/irqchip/irqchip.h | 1 +
> 7 files changed, 20 insertions(+), 9 deletions(-)
What about arch/arm/include/asm/hardware/gic.h ?
Contrary to the current version of the bcm2835 IRQ controller driver
and the armada-370-xp IRQ controller driver, the GIC and VIC drivers
not only expose a <foo>_of_init() function, but also other functions
that are directly used by several non-DT capable ARM sub-architectures.
Of course, it works by leaving gic.h where it is now, but it sounds
strange to have the driver in drivers/irqchip/ and the header file in
arch/arm/include/asm/hardware/, especially if the goal is to be able to
use those drivers in arm64.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] mmc: at91-mci: remove driver
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-30 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87625txrou.fsf@octavius.laptop.org>
On 10:45 Mon 29 Oct , Chris Ball wrote:
> Hi,
>
> On Mon, Oct 29 2012, ludovic.desroches at atmel.com wrote:
> > From: Ludovic Desroches <ludovic.desroches@atmel.com>
> >
> > The at91-mci driver is no more needed since atmel-mci driver supports
> > all Atmel devices.
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> > Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Thanks! Pushed to mmc-next for 3.8.
if you don't mind I prefer to take it via at91
I've a patch series that cleanup the platform_data it's difficult to merge
with this one
Best Regards,
J.
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-30 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZysB2mxj5wZfE0N+iwTE-_AXbOV0bKRP5kSo=1hieKGg@mail.gmail.com>
On Tue, Oct 30, 2012 at 03:16:02PM +0100, Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
> > Essentially all the patches I'm seeing adding pinctrl are totally
> > mindless, most of them are just doing the initial setup on boot and not
> > doing any active management at runtime at all.
> I concludes in some other mails that all Ux500 drivers
> will need to handle atleast two states (default and sleep)
> and some a third state (idle).
Right, that's the other common option and obviously it's just an
extension of the simple hogs which maps very nicely onto the existing PM
states for devices.
> And this is what we're doing in our patches.
> Arguably it can all be pushed to power domains, but that
> will as said mandate all affected systems to implement
> power domains, and effectively moving code from
> drivers/* to arch/arm/* in our case atleast.
As soon as they start adding clock support and so on, yes. Obviously if
they don't want to use any of the features that are offloaded like this
then they could happily ignore it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/1a4adf30/attachment.sig>
^ 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