ppc32: 8xx board-specific platform stuff for fs_enet

This adds board-specific files needed to utilize fs_enet Ethernet driver for MPC885ADS and MPC866ADS.

---

 arch/ppc/Kconfig                     |   47 ++++
 arch/ppc/platforms/Makefile          |    2
 arch/ppc/platforms/fads.h            |    2
 arch/ppc/platforms/mpc866ads_setup.c |  290 ++++++++++++++++++++++++
 arch/ppc/platforms/mpc885ads_setup.c |  408 ++++++++++++++++++++++++++++++++++
 5 files changed, 748 insertions(+), 1 deletions(-)
 create mode 100644 arch/ppc/platforms/mpc866ads_setup.c
 create mode 100644 arch/ppc/platforms/mpc885ads_setup.c

applies-to: f358a802ba9f62bb4777d5f626f2972d1b0fa43b 4c4f454bd8e79fd67bc86aa9a22604f66d682d3b

index 8fa51b0..8e6fcb2 100644
@@ -506,6 +506,53 @@ config WINCEPT
 
 endchoice
 
+menu "Freescale Ethernet driver platform-specific options"
+	depends on FS_ENET
+
+	config MPC8xx_SECOND_ETH
+	bool "Second Ethernet channel"
+	depends on (MPC885ADS || MPC86XADS)
+	default y
+	help
+	  This enables support for second Ethernet on MPC885ADS and MPC86xADS boards.
+	  The latter will use SCC1, for 885ADS you can select it below.
+
+	choice
+		prompt "Second Ethernet channel"
+		depends on MPC8xx_SECOND_ETH
+		default MPC8xx_SECOND_ETH_FEC2
+
+		config MPC8xx_SECOND_ETH_FEC2
+		bool "FEC2"
+		depends on MPC885ADS
+		help
+		  Enable FEC2 to serve as 2-nd Ethernet channel. Note that SMC2
+		  (often 2-nd UART) will not work if this is enabled.
+
+		config MPC8xx_SECOND_ETH_SCC1
+		bool "SCC1"
+		depends on MPC86XADS
+		select MPC8xx_SCC_ENET_FIXED
+		help
+		  Enable SCC1 to serve as 2-nd Ethernet channel. Note that SMC1
+		  (often 1-nd UART) will not work if this is enabled.
+
+		config MPC8xx_SECOND_ETH_SCC3
+		bool "SCC3"
+		depends on MPC885ADS
+		help
+		  Enable SCC3 to serve as 2-nd Ethernet channel. Note that SMC1
+		  (often 1-nd UART) will not work if this is enabled.
+
+	endchoice
+
+	config MPC8xx_SCC_ENET_FIXED
+	depends on MPC8xx_SECOND_ETH_SCC
+	default n
+	bool "Use fixed MII-less mode for SCC Ethernet"
+
+endmenu
+
 choice
 	prompt "Machine Type"
 	depends on 6xx || POWER3 || POWER4

index 7c5cdab..cce6487 100644
@@ -45,6 +45,8 @@ obj-$(CONFIG_SBC82xx)		+= sbc82xx.o
 obj-$(CONFIG_SPRUCE)		+= spruce.o
 obj-$(CONFIG_LITE5200)		+= lite5200.o
 obj-$(CONFIG_EV64360)		+= ev64360.o
+obj-$(CONFIG_MPC86XADS)		+= mpc866ads_setup.o
+obj-$(CONFIG_MPC885ADS)		+= mpc885ads_setup.o
 
 ifeq ($(CONFIG_SMP),y)
 obj-$(CONFIG_PPC_PMAC)		+= pmac_smp.o

index a48fb8d..e1c0b1b 100644
@@ -112,7 +112,7 @@
 
 /* CPM Ethernet through SCC1 or SCC2 */
 
-#ifdef CONFIG_SCC1_ENET		/* Probably 860 variant */
+#if defined(CONFIG_SCC1_ENET) || defined(CONFIG_MPC8xx_SECOND_ETH_SCC1)		/* Probably 860

variant */
/* Bits in parallel I/O port registers that have to be set/cleared
* to configure the pins for SCC1 use.
* TCLK - CLK1, RCLK - CLK2.

initialization */
+ setbits32(immap->im_cpm.cp_pbpar, PB_ENET_TENA);
+ setbits32(immap->im_cpm.cp_pbdir, PB_ENET_TENA);
+
+}
+
+static void mpc866ads_fixup_enet_pdata(struct platform_device *pdev,
+ int fs_no)
+{
+ struct fs_platform_info *fpi = pdev->dev.platform_data;
+
+ volatile cpm8xx_t *cp;
+ bd_t *bd = (bd_t *) __res;
+ char *e;
+ int i;
+
+ /* Get pointer to Communication Processor */
+ cp = cpmp;
+ switch (fs_no) {
+ case fsid_fec1:
+ fpi = &mpc8xx_fec_pdata[0];
+ fpi->init_ioports = &setup_fec1_ioports;
+
+ break;
+ case fsid_scc1:
+ fpi = &mpc8xx_scc_pdata;
+ fpi->init_ioports = &setup_scc1_ioports;
+
+ break;
+ default:
+ break;
+ }
+
+ pdev->dev.platform_data = fpi;
+ fpi->fs_no = fs_no;
+
+ e = (unsigned char *)&bd->bi_enetaddr;
+ for (i = 0; i < 6; i++)
+ fpi->macaddr[i] = *e++;
+
+ fpi->macaddr[5 - pdev->id]++;
+
+}
+
+static void mpc866ads_fixup_fec_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for FEC devices only */
+ if (strcmp(pdev->name, "fsl-cpm-fec"))
+ return;
+ mpc866ads_fixup_enet_pdata(pdev, fsid_fec1 + pdev->id - 1);
+}
+
+static void mpc866ads_fixup_scc_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for SCC devices only */
+ if (strcmp(pdev->name, "fsl-cpm-scc"))
+ return;
+
+ mpc866ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
+}
+
+static int mpc866ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {
+ "fsl-cpm-fec", mpc866ads_fixup_fec_enet_pdata}, {
+ "fsl-cpm-scc", mpc866ads_fixup_scc_enet_pdata},};
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
+
+int __init mpc866ads_init(void)
+{
+ printk(KERN_NOTICE "mpc866ads: Init\n");
+
+ mpc866_nonplatform_device_init();
+ platform_notify = mpc866ads_platform_notify;
+
+ identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+
+ ppc_sys_device_remove(MPC8xx_CPM_FEC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC3);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC4);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC2);
+
+ return 0;
+}
+
+arch_initcall(mpc866ads_init);

initialization */
+ setbits32(immap->im_cpm.cp_pepar, PE_ENET_TENA);
+ clrbits32(immap->im_cpm.cp_pedir, PE_ENET_TENA);
+ setbits32(immap->im_cpm.cp_peso, PE_ENET_TENA);
+
+ out_be32(bcsr_io + 1, in_be32(bcsr_io + 1) | BCSR1_ETHEN);
+ iounmap(bcsr_io);
+}
+
+static void mpc885ads_fixup_enet_pdata(struct platform_device *pdev,
+ int fs_no)
+{
+ struct fs_platform_info *fpi = pdev->dev.platform_data;
+
+ volatile cpm8xx_t *cp;
+ bd_t *bd = (bd_t *) __res;
+ char *e;
+ int i;
+
+ /* Get pointer to Communication Processor */
+ cp = cpmp;
+ switch (fs_no) {
+ case fsid_fec1:
+ fpi = &mpc8xx_fec_pdata[0];
+ fpi->init_ioports = &setup_fec1_ioports;
+ break;
+ case fsid_fec2:
+ fpi = &mpc8xx_fec_pdata[1];
+ fpi->init_ioports = &setup_fec2_ioports;
+ break;
+ case fsid_scc3:
+ fpi = &mpc8xx_scc_pdata;
+ fpi->init_ioports = &setup_scc3_ioports;
+ mpc885ads_scc_phy_init(fpi->phy_addr);
+ break;
+ default:
+ break;
+ }
+
+ pdev->dev.platform_data = fpi;
+ fpi->fs_no = fs_no;
+
+ e = (unsigned char *)&bd->bi_enetaddr;
+ for (i = 0; i < 6; i++)
+ fpi->macaddr[i] = *e++;
+
+ fpi->macaddr[5 - pdev->id]++;
+
+}
+
+static void mpc885ads_fixup_fec_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for FEC devices only */
+ if (!strstr(pdev->name, "fsl-cpm-fec"))
+ return;
+ mpc885ads_fixup_enet_pdata(pdev, fsid_fec1 + pdev->id - 1);
+}
+
+static void __init mpc885ads_fixup_scc_enet_pdata(struct platform_device *pdev,
+ int idx)
+{
+ /* This is for SCC devices only */
+ if (!strstr(pdev->name, "fsl-cpm-scc"))
+ return;
+
+ mpc885ads_fixup_enet_pdata(pdev, fsid_scc1 + pdev->id - 1);
+}
+
+/* SCC ethernet controller does not have MII management channel. FEC1 MII
+ * channel is used to communicate with the 10Mbit PHY.
+ */
+
+#define MII_ECNTRL_PINMUX 0x4
+#define FEC_ECNTRL_PINMUX 0x00000004
+#define FEC_RCNTRL_MII_MODE 0x00000004
+
+/* Make MII read/write commands.
+ */
+#define mk_mii_write(REG, VAL, PHY_ADDR) (0x50020000 | (((REG) & 0x1f) << 18) | \
+ ((VAL) & 0xffff) | ((PHY_ADDR) << 23))
+
+static void mpc885ads_scc_phy_init(char phy_addr)
+{
+ volatile immap_t *immap;
+ volatile fec_t *fecp;
+ bd_t *bd;
+
+ bd = (bd_t *) __res;
+ immap = (immap_t *) IMAP_ADDR; /* pointer to internal registers */
+ fecp = &(immap->im_cpm.cp_fec);
+
+ /* Enable MII pins of the FEC1
+ */
+ setbits16(immap->im_ioport.iop_pdpar,0x0080);
+ clrbits16(immap->im_ioport.iop_pddir,0x0080);
+ /* Set MII speed to 2.5 MHz
+ */
+ out_be32(&fecp->fec_mii_speed,
+ ((((bd->bi_intfreq + 4999999) / 2500000) / 2) & 0x3F) << 1);
+
+ /* Enable FEC pin MUX
+ */
+ setbits32(fecp->fec_ecntrl, MII_ECNTRL_PINMUX);
+ setbits32(fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
+
+ out_be32(&fecp->fec_mii_data, mk_mii_write(MII_BMCR, BMCR_ISOLATE, phy_addr));
+ udelay(100);
+ out_be32(&fecp->fec_mii_data,
+ mk_mii_write(MII_ADVERTISE,
+ ADVERTISE_10HALF | ADVERTISE_CSMA,phy_addr));
+ udelay(100);
+
+ /* Disable FEC MII settings
+ */
+ clrbits32(fecp->fec_ecntrl, MII_ECNTRL_PINMUX);
+ clrbits32(fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
+ out_be32(&fecp->fec_mii_speed, 0);
+}
+
+static int mpc885ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {
+ "fsl-cpm-fec", mpc885ads_fixup_fec_enet_pdata}, {
+ "fsl-cpm-scc", mpc885ads_fixup_scc_enet_pdata},};
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
+
+int __init mpc885ads_init(void)
+{
+ printk(KERN_NOTICE "mpc885ads: Init\n");
+
+ mpc885_nonplatform_device_init();
+ platform_notify = mpc885ads_platform_notify;
+
+ identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+
+#ifdef CONFIG_MPC8xx_SECOND_ETH_SCC3
+ ppc_sys_device_remove(MPC8xx_CPM_FEC2);
+#endif
+#ifdef CONFIG_MPC8xx_SECOND_ETH_FEC2
+ ppc_sys_device_remove(MPC8xx_CPM_SCC3);
+#endif
+
+ ppc_sys_device_remove(MPC8xx_CPM_SCC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC2);
+ ppc_sys_device_remove(MPC8xx_CPM_SCC4);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC1);
+ ppc_sys_device_remove(MPC8xx_CPM_SMC2);
+
+ return 0;
+}
+
+arch_initcall(mpc885ads_init);
---
Sincerely,
Vitaly

Hi Vitaly,

Some line breakage here?

Strange formatting?

Marcelo,
Thanks for review, will fix.

Guess the proper place for setbits/clrbits should be asm-ppc/io.h?

Sincerely,
Vitaly

Yes, think so.

Paul, you're OK with the following definitions on asm-ppc/io.h?

+/* access ports */
+#define setbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) | (_v)) +#define clrbits32(_addr, _v) out_be32(&(_addr), in_be32(&(_addr)) & ~(_v)) +
+#define setbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) | (_v)) +#define clrbits16(_addr, _v) out_be16(&(_addr), in_be16(&(_addr)) & ~(_v))

Many.

Check for instance git-diff-tree -p e37b0c9670fed2264661ade1beb5c228dec29c96

Shouldn't these go into some non-arch specific location? I hate making drivers only build on a give arch.

- kumar

Hmm, what is the worth? IIRC, in_be* stuff is defined for only ppc-specific archs(ppc(64),ppc,powerpc).

Sincerely,
Vitaly

Hi Kumar,

I dont really know the policy for driver placement, but it seems that it works on a case by case basis.

The files in arch/ppc/8xx_io/ (which is what I think you refer to as candidates for drivers/), are:

1) commproc.c
Basic API for dpram access. Core code.

2) micropatch.c
microcode update code/data. Core code.

3) cs4218.h
4) cs4218_tdm.c

cs4218 does not compile at the moment due to syntatical problems, I've fixed them up and the driver compiles, but I don't know if it works (patch attached).

I would not be surprised if the driver has been broken since long time ago.

Does anyone have hardware to test it? Dan?

Otherwise we should remove it from the tree, since its unmaintained and unused.

5) enet.c
6) fec.c

The ENET/FEC network drivers are obseleted by fs_enet.

However there are some PHY descriptions in fec.c which are missing from fs_enet - we'd better make sure to have them all in the new driver before removing the old one.

Aris, would you mind looking into this?

Once we have that we can set a deadline at Documentation/feature-removal.txt if desired.

Other than those there are no 8xx drivers in arch/ppc/ AFAIK.

@@ -1380,7 +1381,7 @@
}

static DEFINE_TIMER(beep_timer, cs_nosound, 0, 0);
-};
+//};

static void cs_mksound(unsigned int hz, unsigned int ticks) {
@@ -1462,7 +1463,7 @@
}

static MACHINE mach_cs4218 = {
- .owner = THIS_MODULE,
+// .owner = THIS_MODULE,
.name = "HIOX CS4218",
.name2 = "Built-in Sound",
.dma_alloc = CS_Alloc,
@@ -2475,6 +2476,7 @@
volatile smc_t *sp;
volatile smc_uart_t *up;
volatile immap_t *immap;
+ unsigned long dp_addr;

has_sound = 0;

I'm on it

--
Aristeu

I don't particularly like these macros, but I'm tired of fighting about it. If you follow the usage path, you will see it's only used in the CPM drivers, and I wish people would just use the data structure pointers to access these ports/bits with standard C code and then place any synchronization instructions properly. There are some cases where you have to be quite careful about how you read and write some control registers, and I think this opens the possibility to just be sloppy and make mistakes since the read/write is hidden within the macro.

Yes, I have hardware to test it. I will do that one of these days.

Thanks.

	-- Dan

Hi Dan,

We did not fight about it, did we??? I don't understand what you mean.

We need to agree on technical points. If you see a problem with the macros, you need to teach us about them.

The requirement for in/out inline functions is to force the compiler not to reorder instructions, but I suppose you are talking about the clrbit/setbit macros? Or about both?

The in/out inline functions unify access to conf. registers.

Jeff Garzik gave me a list of reasons for using the inline macros which is quite educational:

* Easier reviewing. One cannot easily distinguish between writing to normal kernel virtual memory and "magic" memory that produces magicaly side effects such as initiating DMA of a net packet.

* Compiler safety. As the code is written now, you have no guarantees that the compiler won't combine two stores to the same location, etc. Accessor macros are a convenient place to add compiler barriers or 'volatile' notations that the MPC8xx code lacks.

* Maintainable. foo_read[bwl] or foo_read{8,16,32} are preferred because that's the way other bus accessors look like -- yes even embedded SoC buses benefit from these code patterns. You want your driver to look like other drivers as much as possible.
* Convenience. The accessors can be a zero overhead memory read/write at a minimum. But they can also be convenient places to use special memory read/write instructions that specify uncached memop, compiler barriers, memory barriers, etc.

And Paulus wrote some important points:

Generally on PowerPC you need to use at least the eieio instruction to prevent reordering of the loads and stores to the device. It's possible that 8xx is sufficiently in-order that you get away without putting in barrier instructions (eieio or sync), but it's not good practice to omit them.

You can use accessors such as in_be32 and in_le32 in this situation, when you have a kernel virtual address that is already mapped to the device.

Here you're talking about the setbit/clrbit macros which combine read/write.

Its simply for the sake of readability, since the C text for "out_be32(xxx, in_be32(xxx) |& zzzz)" is quite large.

Do you think that the macro is a potential for introduction of mistakes?

We don't have any synchronization between read-modify-write operations to conf. registers now, can you mention the cases where read and write need some sort of synchronization?

In any way, those can just not use the macros, right?

Sincerely, I don't care very much for setbit/clrbit macros, I just think that they make the code easier to read.

OK ;)

We have been slowly working on moving drivers out of arch/ppc and into drivers/ so that subsystem maintainers could get proper review of them.

Well #1 & #2 aren't what I would call drivers at all. I would consider them syslib/ candidates. Hopefully, someone will

If its still good, I would guessing /drivers/audio or snd, but neither seem to exist. I wondering where sound card drivers live these days.

Agreed.

Good deal. Are we really removing anything (except maybe cs4218)?

- kumar

Move them there? Yeah... We can add that to the 8xx TODO list if its interesting.

snd/ I think... Someone needs to test the driver. I think we should just fixup the syntactical problems and mark it as BROKEN until someone (Dan?) confirms it works.

FEC certainly and cs4218 seems like a candidate.

Thanks for your comments!

Since I'm probably the only one left in the world with this hardware, it probably doesn't make sense to keep it around. I know people have used it in the past as an example of how to program the TDM on the 8xx, but it's not necessary to keep it around for that reason.

Thanks.

	-- Dan

I would just wait and move them to arch/powerpc/sysdev whenever 8xx moves over to arch/powerpc. No reason to move the files twice.

Agreed.

Well cs4218 depends on Dan's feedback. As far as FEC, I see that we replaced it with something else. So we should feel free to remove it from 8xx_io as long as we feel that the new driver will work for people and update the in kernel platforms for it.

- kumar

Vitaly,

It also sounds to me that mpc885_nonplatform_device_init() initialization suits board_init() time, instead of post-start_kernel() do_initcalls(). No?

Well, maybe, but it actually works and since this approach prevents messing up the m8xx_setup.c with #ifdef hell, I prefer the additional initialization to be there.

If this is odd, I'll proceed with the right way of course.

Sincerely,
Vitaly

No need to mess with m8xx_setup.c, just define your own board_init() function:

+void __init
+board_init(void)
+{

+       ppc_md.time_init = cyc_rtc_init;
+       ppc_md.set_rtc_time = cyc_set_rtc_time;
+       ppc_md.get_rtc_time = cyc_get_rtc_time;
+       ppc_md.restart = cyc_8xx_restart;

+}