mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Tony Lindgren <tony@atomide.com>,
	Aaro Koskinen <aaro.koskinen@iki.fi>,
	Dominik Brodowski <linux@dominikbrodowski.net>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kernel@vger.kernel.org
Subject: [PATCH 08/22] ARM: omap1: move CF chipselect setup to board file
Date: Thu,  8 Aug 2019 23:22:17 +0200	[thread overview]
Message-ID: <20190808212234.2213262-9-arnd@arndb.de> (raw)
In-Reply-To: <20190808212234.2213262-1-arnd@arndb.de>

There is only one board that uses the omap_cf driver, so
moving the chipselect configuration there does not lead
to code duplication but avoids the use of mach/tc.h
in drivers.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-omap1/board-osk.c | 38 ++++++++++++++++++++++++++++-----
 drivers/pcmcia/Kconfig          |  3 ++-
 drivers/pcmcia/omap_cf.c        | 38 ++++++---------------------------
 3 files changed, 42 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 99ebe4503787..38d73da5d13d 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -149,14 +149,14 @@ static struct resource osk5912_cf_resources[] = {
 	[0] = {
 		.flags	= IORESOURCE_IRQ,
 	},
+	[1] = {
+		.flags = IORESOURCE_MEM,
+	},
 };
 
 static struct platform_device osk5912_cf_device = {
 	.name		= "omap_cf",
 	.id		= -1,
-	.dev = {
-		.platform_data	= (void *) 2 /* CS2 */,
-	},
 	.num_resources	= ARRAY_SIZE(osk5912_cf_resources),
 	.resource	= osk5912_cf_resources,
 };
@@ -267,13 +267,41 @@ static void __init osk_init_smc91x(void)
 	omap_writel(l, EMIFS_CCS(1));
 }
 
-static void __init osk_init_cf(void)
+static void __init osk_init_cf(int seg)
 {
+	struct resource *res = &osk5912_cf_resources[1];
+
 	omap_cfg_reg(M7_1610_GPIO62);
 	if ((gpio_request(62, "cf_irq")) < 0) {
 		printk("Error requesting gpio 62 for CF irq\n");
 		return;
 	}
+
+	switch (seg) {
+	/* NOTE: CS0 could be configured too ... */
+	case 1:
+		res->start = OMAP_CS1_PHYS;
+		break;
+	case 2:
+		res->start = OMAP_CS2_PHYS;
+		break;
+	case 3:
+		res->start = omap_cs3_phys();
+		break;
+	}
+
+	res->end = res->start + SZ_8K - 1;
+	osk5912_cf_device.dev.platform_data = (void *)(uintptr_t)seg;
+
+	/* NOTE:  better EMIFS setup might support more cards; but the
+	 * TRM only shows how to affect regular flash signals, not their
+	 * CF/PCMCIA variants...
+	 */
+	pr_debug("%s: cs%d, previous ccs %08x acs %08x\n", __func__,
+		seg, omap_readl(EMIFS_CCS(seg)), omap_readl(EMIFS_ACS(seg)));
+	omap_writel(0x0004a1b3, EMIFS_CCS(seg));	/* synch mode 4 etc */
+	omap_writel(0x00000000, EMIFS_ACS(seg));	/* OE hold/setup */
+
 	/* the CF I/O IRQ is really active-low */
 	irq_set_irq_type(gpio_to_irq(62), IRQ_TYPE_EDGE_FALLING);
 }
@@ -577,7 +605,7 @@ static void __init osk_init(void)
 	u32 l;
 
 	osk_init_smc91x();
-	osk_init_cf();
+	osk_init_cf(2); /* CS2 */
 
 	/* Workaround for wrong CS3 (NOR flash) timing
 	 * There are some U-Boot versions out there which configure
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index e004d8da03dc..ca6e2ac2a92f 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -250,7 +250,8 @@ config PCMCIA_VRC4173
 
 config OMAP_CF
 	tristate "OMAP CompactFlash Controller"
-	depends on PCMCIA && ARCH_OMAP16XX
+	depends on PCMCIA
+	depends on ARCH_OMAP16XX || (ARM && COMPILE_TEST)
 	help
 	  Say Y here to support the CompactFlash controller on OMAP.
 	  Note that this doesn't support "True IDE" mode.
diff --git a/drivers/pcmcia/omap_cf.c b/drivers/pcmcia/omap_cf.c
index 0a04eb04f3a2..98df6473034d 100644
--- a/drivers/pcmcia/omap_cf.c
+++ b/drivers/pcmcia/omap_cf.c
@@ -16,13 +16,12 @@
 
 #include <pcmcia/ss.h>
 
-#include <mach/hardware.h>
 #include <asm/io.h>
 #include <linux/sizes.h>
 
-#include <mach/mux.h>
-#include <mach/tc.h>
-
+#include <linux/soc/ti/omap1-io.h>
+#include <linux/soc/ti/omap1-soc.h>
+#include <linux/soc/ti/omap1-mux.h>
 
 /* NOTE:  don't expect this to support many I/O cards.  The 16xx chips have
  * hard-wired timings to support Compact Flash memory cards; they won't work
@@ -205,6 +204,7 @@ static int __init omap_cf_probe(struct platform_device *pdev)
 	struct omap_cf_socket	*cf;
 	int			irq;
 	int			status;
+	struct resource		*res;
 
 	seg = (int) pdev->dev.platform_data;
 	if (seg == 0 || seg > 3)
@@ -215,6 +215,8 @@ static int __init omap_cf_probe(struct platform_device *pdev)
 	if (irq < 0)
 		return -EINVAL;
 
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
 	cf = kzalloc(sizeof *cf, GFP_KERNEL);
 	if (!cf)
 		return -ENOMEM;
@@ -230,24 +232,7 @@ static int __init omap_cf_probe(struct platform_device *pdev)
 		goto fail0;
 	cf->irq = irq;
 	cf->socket.pci_irq = irq;
-
-	switch (seg) {
-	/* NOTE: CS0 could be configured too ... */
-	case 1:
-		cf->phys_cf = OMAP_CS1_PHYS;
-		break;
-	case 2:
-		cf->phys_cf = OMAP_CS2_PHYS;
-		break;
-	case 3:
-		cf->phys_cf = omap_cs3_phys();
-		break;
-	default:
-		goto  fail1;
-	}
-	cf->iomem.start = cf->phys_cf;
-	cf->iomem.end = cf->iomem.end + SZ_8K - 1;
-	cf->iomem.flags = IORESOURCE_MEM;
+	cf->phys_cf = res->start;
 
 	/* pcmcia layer only remaps "real" memory */
 	cf->socket.io_offset = (unsigned long)
@@ -269,15 +254,6 @@ static int __init omap_cf_probe(struct platform_device *pdev)
 
 	pr_info("%s: cs%d on irq %d\n", driver_name, seg, irq);
 
-	/* NOTE:  better EMIFS setup might support more cards; but the
-	 * TRM only shows how to affect regular flash signals, not their
-	 * CF/PCMCIA variants...
-	 */
-	pr_debug("%s: cs%d, previous ccs %08x acs %08x\n", driver_name,
-		seg, omap_readl(EMIFS_CCS(seg)), omap_readl(EMIFS_ACS(seg)));
-	omap_writel(0x0004a1b3, EMIFS_CCS(seg));	/* synch mode 4 etc */
-	omap_writel(0x00000000, EMIFS_ACS(seg));	/* OE hold/setup */
-
 	/* CF uses armxor_ck, which is "always" available */
 
 	pr_debug("%s: sts %04x cfg %04x control %04x %s\n", driver_name,
-- 
2.20.0


  parent reply	other threads:[~2019-08-08 21:30 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190808212234.2213262-1-arnd@arndb.de>
2019-08-08 21:22 ` [PATCH 01/22] ARM: omap1: innovator: pass lcd control address as pdata Arnd Bergmann
2019-08-09 11:29   ` Bartlomiej Zolnierkiewicz
2019-08-08 21:22 ` [PATCH 02/22] ARM: omap1: make omapfb standalone compilable Arnd Bergmann
2019-08-09 11:32   ` Bartlomiej Zolnierkiewicz
2019-08-09 11:43     ` Arnd Bergmann
2019-08-09 14:36       ` Bartlomiej Zolnierkiewicz
2019-08-09 19:55         ` Arnd Bergmann
2019-08-12  9:21           ` Bartlomiej Zolnierkiewicz
2019-08-08 21:22 ` [PATCH 03/22] ARM: omap1: move omap15xx local bus handling to usb.c Arnd Bergmann
2019-08-09  5:32   ` Felipe Balbi
2019-08-10 10:28   ` Christoph Hellwig
2019-08-08 21:22 ` [PATCH 04/22] ARM: omap1: move ohci phy power handling to board files Arnd Bergmann
2019-08-08 21:22 ` [PATCH 05/22] ARM: omap1: move mach/usb.h to include/linux/soc Arnd Bergmann
2019-08-08 21:22 ` [PATCH 06/22] ARM: omap1: move some headers " Arnd Bergmann
2019-08-08 21:22 ` [PATCH 07/22] ARM: omap1: move perseus spi pinconf to board file Arnd Bergmann
2019-08-08 22:24   ` Mark Brown
2019-08-09 11:29     ` Arnd Bergmann
2019-08-09 12:01       ` Mark Brown
2019-08-08 21:22 ` Arnd Bergmann [this message]
2019-08-08 21:22 ` [PATCH 09/22] fbdev: omap: avoid using mach/*.h files Arnd Bergmann
2019-08-09 11:34   ` Bartlomiej Zolnierkiewicz
2019-08-08 21:22 ` [PATCH 10/22] usb: omap: avoid mach/*.h headers Arnd Bergmann
2019-08-09  5:38   ` Greg Kroah-Hartman
2019-08-08 21:22 ` [PATCH 11/22] clocksource: ti-dmtimer: avoid using mach/hardware.h Arnd Bergmann
2019-08-09  7:01   ` Daniel Lezcano
2019-08-09  7:33     ` Arnd Bergmann
2019-08-09  7:57       ` Daniel Lezcano
2019-08-08 21:22 ` [PATCH 12/22] serial: 8250/omap1: include linux/soc/ti/omap1-soc.h Arnd Bergmann
2019-08-08 21:22 ` [PATCH 13/22] input: omap: void using mach/*.h headers Arnd Bergmann
2019-08-08 21:42   ` Dmitry Torokhov
2019-08-08 21:46     ` Arnd Bergmann
2019-08-08 22:19       ` Dmitry Torokhov
2019-08-08 23:39         ` Sebastian Reichel
2019-08-09 11:23           ` Arnd Bergmann
2019-08-08 21:22 ` [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf Arnd Bergmann
2019-08-13 10:36   ` Tony Lindgren
2019-08-13 11:02     ` Arnd Bergmann
2019-08-13 18:11       ` Aaro Koskinen
2019-08-13 19:33         ` Arnd Bergmann
2019-08-14  7:49           ` Tony Lindgren
2019-08-14 10:36             ` Arnd Bergmann
2019-08-14 13:40               ` Tony Lindgren
2019-08-16  8:34               ` Aaro Koskinen
2019-08-27 16:33                 ` Arnd Bergmann
2019-08-27 19:04                   ` Aaro Koskinen
2019-08-28 13:02                     ` Arnd Bergmann
2019-08-28 18:23                       ` Aaro Koskinen
2019-08-28 18:45                         ` Tony Lindgren
2019-08-08 21:41 ` [PATCH 15/22] ARM: omap1: move mach/*.h into mach directory Arnd Bergmann
2019-08-08 21:41   ` [PATCH 16/22] ARM: omap1: move clk support into a single file Arnd Bergmann
2019-08-08 21:41   ` [PATCH 17/22] ARM: omap1: remove some dead clock code Arnd Bergmann
2019-08-08 21:41   ` [PATCH 18/22] ARM: omap1: clk: rework 'struct clk' Arnd Bergmann
2019-08-08 21:41   ` [PATCH 19/22] ARM: omap1: clk: use common_clk-like callbacks Arnd Bergmann
2019-08-08 21:43 ` [PATCH 20/22] ARM: omap1: clk: use clk_init_data Arnd Bergmann
2019-08-08 21:43   ` [PATCH 21/22] ARM: omap1: use common clk framework Arnd Bergmann
2019-08-14 21:10     ` Aaro Koskinen
2019-08-15  7:10       ` Arnd Bergmann
2019-08-08 21:47 ` [PATCH 22/22] ARM: omap1: enable multiplatform Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190808212234.2213262-9-arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=aaro.koskinen@iki.fi \
    --cc=b.zolnierkie@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=tomi.valkeinen@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®