* [PATCH 0/5] Review request: Cypress c67x00 OTG controller
From: Grant Likely @ 2007-11-24 0:24 UTC (permalink / raw)
To: linux-usb-devel, akpm, dbrownell, gregkh, linuxppc-dev
This patch series is based on the c67x00 work done by Peter Korsgaard and
posted back in April this year.
The Cypress c67x00 is an OTG controller so it can behave as either a host
or gadget controller. This series implements the HCD behaviour.
The c67x00 is found on a number of the Xilinx MLxxx series of boards.
I've been performing my testing on a board derived from the ML403.
My goal is to get this driver queued up for inclusion in 2.6.25, but I've
been looking at this code for so long that I'm going crosseyed and missing
obvious issues. Plus, I am by no means a USB expert and I'm not sure that
I'm using the USB HCD API correctly.
So, this email is a request for review. I've got some time cleared away
to work on this over the next week so I should be able to address comments
quickly with the goal of getting it picked up for the next merge window.
Thanks,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 2/5] USB: Add Cypress c67x00 low level interface code
From: Grant Likely @ 2007-11-24 0:24 UTC (permalink / raw)
To: linux-usb-devel, akpm, dbrownell, gregkh, linuxppc-dev
In-Reply-To: <20071124001203.25361.99294.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
This patch adds the low level support code for the Cypress c67x00 family of
OTG controllers. The low level code is responsible for register access and
implements the software protocol for communicating with the c67x00 device.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/usb/c67x00/c67x00-ll-hpi.c | 512 ++++++++++++++++++++++++++++++++++++
drivers/usb/c67x00/c67x00.h | 236 +++++++++++++++++
2 files changed, 748 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/c67x00/c67x00-ll-hpi.c b/drivers/usb/c67x00/c67x00-ll-hpi.c
new file mode 100644
index 0000000..5e1bd73
--- /dev/null
+++ b/drivers/usb/c67x00/c67x00-ll-hpi.c
@@ -0,0 +1,512 @@
+/*
+ * c67x00-ll-hpi.c: Cypress C67X00 USB Low level interface using HPI
+ *
+ * Copyright (C) 2006-2007 Barco N.V.
+ * Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ * based on multiple host controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+#include <asm/io.h>
+#include <asm/byteorder.h>
+#include "c67x00.h"
+
+/* -------------------------------------------------------------------------- */
+/* Interface definitions */
+
+#define COMM_ACK 0x0FED
+#define COMM_NAK 0xDEAD
+
+#define COMM_CTRL_REG_ADDR 0x01BC
+#define COMM_CTRL_REG_DATA 0x01BE
+#define COMM_CTRL_REG_LOGIC 0x01C0
+#define COMM_WRITE_CTRL_REG 0xCE03
+#define COMM_READ_CTRL_REG 0xCE02
+
+#define COMM_RESET 0xFA50
+#define COMM_EXEC_INT 0xCE01
+#define COMM_INT_NUM 0x01C2
+/* Registers 0 to COMM_REGS-1 */
+#define COMM_R(x) (0x01C4 + 2 * (x))
+
+#define HUSB_SIE_pCurrentTDPtr(x) ( (x) ? 0x01B2 : 0x01B0 )
+#define HUSB_SIE_pTDListDone_Sem(x) ( (x) ? 0x01B8 : 0x01B6 )
+#define HUSB_pEOT 0x01B4
+
+/* Software interrupts */
+/* 114, 115: */
+#define HUSB_SIE_INIT_INT(x) ( (x) ? 0x0073 : 0x0072 )
+#define HUSB_RESET_INT 0x0074 /* 116 */
+
+#define SUSB_INIT_INT 0x0071
+/* -------------------------------------------------------------------------- */
+/* HPI implementation */
+
+/* HPI registers */
+#define HPI_DATA 0
+#define HPI_MAILBOX 1
+#define HPI_ADDR 2
+#define HPI_STATUS 3
+
+/* These functions could also be implemented with SPI of HSS.
+ * This is currently not supported */
+static inline u16 hpi_read_reg(struct c67x00_device *dev, int reg)
+{
+ return __raw_readw(dev->hpi.base + reg * dev->hpi.regstep);
+}
+
+static inline void hpi_write_reg(struct c67x00_device *dev, int reg, u16 value)
+{
+ __raw_writew(value, dev->hpi.base + reg * dev->hpi.regstep);
+}
+
+static inline u16 hpi_read_word_nolock(struct c67x00_device *dev, u16 reg)
+{
+ hpi_write_reg(dev, HPI_ADDR, reg);
+ return hpi_read_reg(dev, HPI_DATA);
+}
+
+static inline u16 hpi_read_word(struct c67x00_device *dev, u16 reg)
+{
+ u16 value;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ value = hpi_read_word_nolock(dev, reg);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+
+ return value;
+}
+
+static inline void hpi_write_word_nolock(struct c67x00_device *dev, u16 reg,
+ u16 value)
+{
+ hpi_write_reg(dev, HPI_ADDR, reg);
+ hpi_write_reg(dev, HPI_DATA, value);
+}
+
+static inline void hpi_write_word(struct c67x00_device *dev, u16 reg, u16 value)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ hpi_write_word_nolock(dev, reg, value);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+}
+
+/*
+ * Only data is little endian, addr has cpu endianess
+ */
+static inline void hpi_write_words_le16(struct c67x00_device *dev, u16 addr,
+ u16 * data, u16 count)
+{
+ unsigned long flags;
+ int i;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+
+ hpi_write_reg(dev, HPI_ADDR, addr);
+ for (i = 0; i < count; i++)
+ hpi_write_reg(dev, HPI_DATA, cpu_to_le16(*data++));
+
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+}
+
+/*
+ * Only data is little endian, addr has cpu endianess
+ */
+static inline void hpi_read_words_le16(struct c67x00_device *dev, u16 addr,
+ u16 * data, u16 count)
+{
+ unsigned long flags;
+ int i;
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ hpi_write_reg(dev, HPI_ADDR, addr);
+ for (i = 0; i < count; i++)
+ *data++ = le16_to_cpu(hpi_read_reg(dev, HPI_DATA));
+
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+}
+
+static inline void hpi_set_bits(struct c67x00_device *dev, u16 reg, u16 mask)
+{
+ u16 value;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ value = hpi_read_word_nolock(dev, reg);
+ hpi_write_word_nolock(dev, reg, value | mask);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+}
+
+static inline void hpi_clear_bits(struct c67x00_device *dev, u16 reg, u16 mask)
+{
+ u16 value;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ value = hpi_read_word_nolock(dev, reg);
+ hpi_write_word_nolock(dev, reg, value & ~mask);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+}
+
+static inline u16 hpi_recv_mbox(struct c67x00_device *dev)
+{
+ u16 value;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ value = hpi_read_reg(dev, HPI_MAILBOX);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+
+ return value;
+}
+
+static inline u16 hpi_send_mbox(struct c67x00_device *dev, u16 value)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ hpi_write_reg(dev, HPI_MAILBOX, value);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+
+ return value;
+}
+
+u16 c67x00_ll_hpi_status(struct c67x00_device * dev)
+{
+ u16 value;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->hw_lock, flags);
+ value = hpi_read_reg(dev, HPI_STATUS);
+ spin_unlock_irqrestore(&dev->hw_lock, flags);
+
+ return value;
+}
+
+void c67x00_ll_hpi_reg_init(struct c67x00_device *dev)
+{
+ int i;
+
+ hpi_recv_mbox(dev);
+ c67x00_ll_hpi_status(dev);
+ hpi_write_word(dev, HPI_IRQ_ROUTING_REG, 0);
+
+ for (i=0; i<C67X00_SIES; i++) {
+ hpi_write_word(dev, SIEMSG_REG(i), 0);
+ hpi_read_word(dev, SIEMSG_REG(i));
+ }
+}
+
+void c67x00_ll_hpi_enable_sofeop(struct c67x00_sie *sie)
+{
+ hpi_set_bits(sie->dev, HPI_IRQ_ROUTING_REG,
+ SOFEOP_TO_HPI_EN(sie->sie_num));
+}
+
+void c67x00_ll_hpi_disable_sofeop(struct c67x00_sie *sie)
+{
+ hpi_clear_bits(sie->dev, HPI_IRQ_ROUTING_REG,
+ SOFEOP_TO_HPI_EN(sie->sie_num));
+}
+
+/* -------------------------------------------------------------------------- */
+/* Transactions */
+
+static inline u16 ll_recv_msg(struct c67x00_device *dev)
+{
+ u16 res;
+
+ res = wait_for_completion_timeout(&dev->lcp.msg_received, 5 * HZ);
+ WARN_ON(!res);
+
+ return (res == 0) ? -EIO : 0;
+}
+
+/* -------------------------------------------------------------------------- */
+
+u16 c67x00_comm_read_ctrl_reg(struct c67x00_device * dev, u16 addr)
+{
+ unsigned long msg, res;
+ int rc;
+
+ mutex_lock(&dev->lcp.mutex);
+ hpi_write_word(dev, COMM_CTRL_REG_ADDR, addr);
+ hpi_send_mbox(dev, COMM_READ_CTRL_REG);
+ rc = ll_recv_msg(dev);
+
+ BUG_ON(rc); /* No return path for error code; crash spectacularly */
+
+ msg = dev->lcp.last_msg;
+ if (msg != COMM_ACK) {
+ dev_warn(&dev->pdev->dev, "COMM_READ_CTRL_REG didn't ACK!\n");
+ res = 0;
+ } else {
+ res = hpi_read_word(dev, COMM_CTRL_REG_DATA);
+ }
+ mutex_unlock(&dev->lcp.mutex);
+ return res;
+}
+
+int c67x00_comm_exec_int(struct c67x00_device *dev, u16 nr,
+ struct c67x00_lcp_int_data *data)
+{
+ int i, rc;
+
+ mutex_lock(&dev->lcp.mutex);
+ hpi_write_word(dev, COMM_INT_NUM, nr);
+ for (i = 0; i < COMM_REGS; i++)
+ hpi_write_word(dev, COMM_R(i), data->regs[i]);
+ hpi_send_mbox(dev, COMM_EXEC_INT);
+ rc = ll_recv_msg(dev);
+ mutex_unlock(&dev->lcp.mutex);
+
+ return rc;
+}
+
+/* -------------------------------------------------------------------------- */
+/* General functions */
+
+u16 c67x00_ll_get_siemsg(struct c67x00_device *dev, int sie)
+{
+ return hpi_read_word(dev, SIEMSG_REG(sie));
+}
+
+void c67x00_ll_set_siemsg(struct c67x00_device *dev, int sie, u16 val)
+{
+ hpi_write_word(dev, SIEMSG_REG(sie), val);
+}
+
+u16 c67x00_ll_get_usb_ctl(struct c67x00_sie *sie)
+{
+ return hpi_read_word(sie->dev, USB_CTL_REG(sie->sie_num));
+}
+
+/* -------------------------------------------------------------------------- */
+/* Host specific functions */
+
+void c67x00_ll_set_husb_eot(struct c67x00_device *dev, u16 value)
+{
+ mutex_lock(&dev->lcp.mutex);
+ hpi_write_word(dev, HUSB_pEOT, value);
+ mutex_unlock(&dev->lcp.mutex);
+}
+
+static inline void c67x00_ll_husb_sie_init(struct c67x00_sie *sie)
+{
+ struct c67x00_device *dev = sie->dev;
+ struct c67x00_lcp_int_data data;
+ int rc;
+
+ rc = c67x00_comm_exec_int(dev, HUSB_SIE_INIT_INT(sie->sie_num), &data);
+ BUG_ON(rc); /* No return path for error code; crash spectacularly */
+}
+
+void c67x00_ll_husb_reset(struct c67x00_sie *sie, int port)
+{
+ struct c67x00_device *dev = sie->dev;
+ struct c67x00_lcp_int_data data;
+ int rc;
+
+ data.regs[0] = 50; /* Reset USB port for 50ms */
+ data.regs[1] = port | (sie->sie_num << 1);
+ rc = c67x00_comm_exec_int(dev, HUSB_RESET_INT, &data);
+ BUG_ON(rc); /* No return path for error code; crash spectacularly */
+}
+
+void c67x00_ll_husb_set_current_td(struct c67x00_sie *sie, u16 addr)
+{
+ hpi_write_word(sie->dev, HUSB_SIE_pCurrentTDPtr(sie->sie_num), addr);
+}
+
+u16 c67x00_ll_husb_get_current_td(struct c67x00_sie *sie)
+{
+ return hpi_read_word(sie->dev, HUSB_SIE_pCurrentTDPtr(sie->sie_num));
+}
+
+/**
+ * c67x00_ll_husb_clear_status - clear the host status bits
+ */
+void c67x00_ll_husb_clear_status(struct c67x00_sie *sie, u16 bits)
+{
+ hpi_write_word(sie->dev, HOST_STAT_REG(sie->sie_num), bits);
+}
+
+u16 c67x00_ll_husb_get_status(struct c67x00_sie *sie)
+{
+ return hpi_read_word(sie->dev, HOST_STAT_REG(sie->sie_num));
+}
+
+u16 c67x00_ll_husb_get_frame(struct c67x00_sie * sie)
+{
+ return hpi_read_word(sie->dev, HOST_FRAME_REG(sie->sie_num));
+}
+
+void c67x00_ll_husb_init_host_port(struct c67x00_sie *sie)
+{
+ /* Set port into host mode */
+ hpi_set_bits(sie->dev, USB_CTL_REG(sie->sie_num), HOST_MODE);
+ c67x00_ll_husb_sie_init(sie);
+ /* Clear interrupts */
+ c67x00_ll_husb_clear_status(sie, HOST_STAT_MASK);
+ /* Check */
+ if (!(hpi_read_word(sie->dev, USB_CTL_REG(sie->sie_num)) & HOST_MODE))
+ dev_warn(sie_dev(sie),
+ "SIE %d not set to host mode\n", sie->sie_num);
+}
+
+void c67x00_ll_husb_reset_port(struct c67x00_sie *sie, int port)
+{
+ /* Clear connect change */
+ c67x00_ll_husb_clear_status(sie, PORT_CONNECT_CHANGE(port));
+
+ /* Enable interrupts */
+ hpi_set_bits(sie->dev, HPI_IRQ_ROUTING_REG,
+ SOFEOP_TO_CPU_EN(sie->sie_num));
+ hpi_set_bits(sie->dev, HOST_IRQ_EN_REG(sie->sie_num),
+ SOF_EOP_IRQ_EN | DONE_IRQ_EN);
+
+ /* Enable pull down transistors */
+ hpi_set_bits(sie->dev, USB_CTL_REG(sie->sie_num), PORT_RES_EN(port));
+}
+
+/* -------------------------------------------------------------------------- */
+void c67x00_ll_susb_init(struct c67x00_sie *sie)
+{
+ struct c67x00_device *dev = sie->dev;
+ struct c67x00_lcp_int_data data;
+ int rc;
+
+ data.regs[1] = 1; /* full speed */
+ data.regs[2] = sie->sie_num + 1;
+ rc = c67x00_comm_exec_int(dev, SUSB_INIT_INT, &data);
+ BUG_ON(rc); /* No return path for error code; crash spectacularly */
+
+ hpi_clear_bits(dev, HPI_IRQ_ROUTING_REG,
+ SOFEOP_TO_HPI_EN(sie->sie_num));
+ hpi_set_bits(dev, HPI_IRQ_ROUTING_REG, SOFEOP_TO_CPU_EN(sie->sie_num));
+}
+
+/* -------------------------------------------------------------------------- */
+
+void c67x00_ll_irq(struct c67x00_device *dev)
+{
+ if ((dev->int_status & MBX_OUT_FLG) == 0)
+ return;
+
+ dev->lcp.last_msg = hpi_recv_mbox(dev);
+ complete(&dev->lcp.msg_received);
+}
+
+/* -------------------------------------------------------------------------- */
+
+int c67x00_ll_reset(struct c67x00_device *dev)
+{
+ int rc;
+
+ mutex_lock(&dev->lcp.mutex);
+ hpi_send_mbox(dev, COMM_RESET);
+ rc = ll_recv_msg(dev);
+ mutex_unlock(&dev->lcp.mutex);
+
+ return rc;
+}
+
+/* -------------------------------------------------------------------------- */
+
+/**
+ * c67x00_write_mem_le16 - write into c67x00 memory
+ * Only data is little endian, addr has cpu endianess.
+ */
+void c67x00_ll_hpi_write_mem_le16(struct c67x00_device *dev, u16 addr, int len,
+ char *data)
+{
+ /* Sanity check */
+ if (addr + len > 0xffff) {
+ dev_err(&dev->pdev->dev,
+ "Trying to write beyond writable region!\n");
+ return;
+ }
+
+ if (addr & 0x01) {
+ /* unaligned access */
+ u16 tmp;
+ tmp = hpi_read_word(dev, addr - 1);
+ tmp = (tmp & 0x00ff) | (*data++ << 8);
+ hpi_write_word(dev, addr - 1, tmp);
+ addr++;
+ len--;
+ }
+
+ hpi_write_words_le16(dev, addr, (u16 *) data, len / 2);
+ data += len & ~0x01;
+ addr += len & ~0x01;
+ len &= 0x01;
+
+ if (len) {
+ u16 tmp;
+ tmp = hpi_read_word(dev, addr);
+ tmp = (tmp & 0xff00) | (*data++);
+ hpi_write_word(dev, addr, tmp);
+ addr++;
+ len--;
+ }
+
+}
+
+/**
+ * c67x00_ll_hpi_read_mem_le16 - read from c67x00 memory
+ * Only data is little endian, addr has cpu endianess.
+ */
+void c67x00_ll_hpi_read_mem_le16(struct c67x00_device *dev, u16 addr, int len,
+ char *data)
+{
+ if (addr & 0x01) {
+ /* unaligned access */
+ u16 tmp;
+ tmp = hpi_read_word(dev, addr - 1);
+ *data++ = (tmp >> 8) & 0x00ff;
+ addr++;
+ len--;
+ }
+
+ hpi_read_words_le16(dev, addr, (u16 *) data, len / 2);
+ data += len & ~0x01;
+ addr += len & ~0x01;
+ len &= 0x01;
+
+ if (len) {
+ u16 tmp;
+ tmp = hpi_read_word(dev, addr);
+ *data++ = tmp & 0x00ff;
+ addr++;
+ len--;
+ }
+}
+
+/* -------------------------------------------------------------------------- */
+
+void c67x00_ll_init(struct c67x00_device *dev)
+{
+ mutex_init(&dev->lcp.mutex);
+ init_completion(&dev->lcp.msg_received);
+}
+
+void c67x00_ll_release(struct c67x00_device *dev)
+{
+}
diff --git a/drivers/usb/c67x00/c67x00.h b/drivers/usb/c67x00/c67x00.h
new file mode 100644
index 0000000..ca8ed69
--- /dev/null
+++ b/drivers/usb/c67x00/c67x00.h
@@ -0,0 +1,236 @@
+/*
+ * c67x00.h: Cypress C67X00 USB register and field definitions
+ *
+ * Copyright (C) 2006-2007 Barco N.V.
+ * Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ * based on multiple host controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+#ifndef _USB_C67X00_H
+#define _USB_C67X00_H
+
+#include <linux/interrupt.h>
+#include <linux/list.h>
+#include <linux/platform_device.h>
+#include <linux/completion.h>
+#include <linux/mutex.h>
+
+/* ---------------------------------------------------------------------
+ * Cypress C67x00 register definitions
+ */
+
+/* Processor control registers */
+/* =========================== */
+
+/* Hardware Revision Register */
+#define HW_REV_REG 0xC004
+
+/* General USB registers */
+/* ===================== */
+
+/* USB Control Register */
+#define USB_CTL_REG(x) ( (x) ? 0xC0AA : 0xC08A )
+
+#define LOW_SPEED_PORT(x) ( (x) ? 0x0800 : 0x0400 )
+#define HOST_MODE 0x0200
+#define PORT_RES_EN(x) ( (x) ? 0x0100 : 0x0080 )
+#define SOF_EOP_EN(x) ( (x) ? 0x0002 : 0x0001 )
+
+/* USB Host only registers */
+/* ======================= */
+
+/* Host n Control Register */
+#define HOST_CTL_REG(x) ((x) ? 0xC0A0 : 0xC080)
+
+#define PREAMBLE_EN 0x0080 /* Preamble enable */
+#define SEQ_SEL 0x0040 /* Data Toggle Sequence Bit Select */
+#define ISO_EN 0x0010 /* Isochronous enable */
+#define ARM_EN 0x0001 /* Arm operation */
+
+/* Host n Interrupt Enable Register */
+#define HOST_IRQ_EN_REG(x) ( (x) ? 0xC0AC : 0xC08C)
+
+#define SOF_EOP_IRQ_EN 0x0200 /* SOF/EOP Interrupt Enable */
+#define DONE_IRQ_EN 0x0001 /* Done Interrupt Enable */
+
+/* Host n status register */
+#define HOST_STAT_REG(x) ( (x) ? 0xC0B0 : 0xC090 )
+
+#define HOST_STAT_MASK 0x02FD
+#define SOF_EOP_IRQ_FLG 0x0200
+#define PORT_CONNECT_CHANGE(x) ( (x) ? 0x0020 : 0x0010 )
+#define PORT_SE0_STATUS(x) ( (x) ? 0x0008 : 0x0004 )
+
+/* Host Frame Register */
+#define HOST_FRAME_REG(x) ( (x) ? 0xC0B6 : 0xC096 )
+
+#define HOST_FRAME_MASK 0x07FF
+
+/* HPI registers */
+/* ============= */
+
+/* HPI Status register */
+#define SOFEOP_FLG(x) (1 << ( (x) ? 12 : 10 ))
+#define SIEMSG_FLAG(x) (1 << (4 + (x)))
+#define MBX_OUT_FLG 0x0001 /* Message out available */
+
+/* Interrupt routing register */
+#define HPI_IRQ_ROUTING_REG 0x0142
+
+#define SOFEOP_TO_HPI_EN(x) ( (x) ? 0x2000 : 0x0800 )
+#define SOFEOP_TO_CPU_EN(x) ( (x) ? 0x1000 : 0x0400 )
+
+/* SIE msg registers */
+#define SIEMSG_REG(x) ( (x) ? 0x0148 : 0x0144 )
+
+#define HUSB_TDListDone 0x1000
+
+#define CY_HCD_BUF_ADDR 0x500 /* Base address for host */
+#define SIE_TD_SIZE 0x200 /* size of the td list */
+#define SIE_TD_BUF_SIZE 0x400 /* size of the data buffer */
+
+#define SIE_TD_OFFSET(host) ( (host) ? (SIE_TD_SIZE+SIE_TD_BUF_SIZE) : 0 )
+#define SIE_BUF_OFFSET(host) (SIE_TD_OFFSET(host) + SIE_TD_SIZE)
+
+/* ---------------------------------------------------------------------
+ * Driver data structures
+ */
+
+struct c67x00_device;
+
+/**
+ * struct c67x00_lcp
+ */
+struct c67x00_lcp {
+ /* Internal use only */
+ struct mutex mutex;
+ struct completion msg_received;
+ u16 last_msg;
+};
+
+/**
+ * struct c67x00_lcp_data
+ */
+#define COMM_REGS 14
+struct c67x00_lcp_int_data {
+ u16 regs[COMM_REGS];
+};
+
+/**
+ * struct c67x00_sie - Common data associated with an SIE
+ * @lock: lock to protect this struct
+ * @private_data: subdriver dependent data
+ * @pdev: platform device associated with this SIE, created in c67x00-drv.c
+ * @irq: subdriver depenent irq handler, set NULL when not used
+ * @msg_received: called when an SIEmsg has been received
+ * @dev: link to common driver structure
+ * @sie_num: SIE number on chip, starting from 0
+ * @mode: SIE mode (host/peripheral/otg/not used)
+ *
+ * Each SIE has a separate platform_device associated with it, because the
+ * hcd needs such a device for itself (TODO: use a struct device instead
+ * of a new platform device).
+ */
+struct c67x00_sie {
+ /* Entries to be used by the subdrivers */
+ spinlock_t lock; /* protect this structure */
+ void *private_data;
+ struct platform_device *pdev;
+ irqreturn_t(*irq) (int irq, struct c67x00_sie * sie);
+ void (*msg_received) (struct c67x00_sie * sie, u16 msg);
+
+ /* Read only: */
+ struct c67x00_device *dev;
+ int sie_num;
+ int mode;
+};
+
+#define sie_dev(s) (&(s)->pdev->dev)
+
+struct c67x00_hpi {
+ void __iomem *base;
+ int regstep;
+};
+
+#define C67X00_SIES 2
+#define C67X00_PORTS 2
+
+/**
+ * struct c67x00_device - Common data structure for a c67x00 instance
+ * @hpi: hpi addresses
+ * @sie: array of sie's on this chip
+ * @pdata: configuration provided by the platform
+ * @hw_lock: hardware lock
+ * @int_status: interrupt status register, only valid in_interrupt()
+ * @lcp: link control protocol dependent data
+ */
+struct c67x00_device {
+ struct c67x00_hpi hpi;
+ struct c67x00_sie sie[C67X00_SIES];
+ struct platform_device *pdev;
+ struct c67x00_platform_data *pdata;
+ spinlock_t hw_lock;
+
+ u16 int_status;
+ struct c67x00_lcp lcp;
+};
+
+/* ---------------------------------------------------------------------
+ * Low level interface functions
+ */
+
+/* Host Port Interface (hpi) functions */
+u16 c67x00_ll_hpi_status(struct c67x00_device *dev);
+void c67x00_ll_hpi_reg_init(struct c67x00_device *dev);
+void c67x00_ll_hpi_enable_sofeop(struct c67x00_sie *sie);
+void c67x00_ll_hpi_disable_sofeop(struct c67x00_sie *sie);
+
+/* General functions */
+u16 c67x00_ll_get_siemsg(struct c67x00_device *dev, int sie);
+void c67x00_ll_set_siemsg(struct c67x00_device *dev, int sie, u16 val);
+u16 c67x00_ll_get_usb_ctl(struct c67x00_sie *sie);
+
+/* Host specific functions */
+void c67x00_ll_set_husb_eot(struct c67x00_device *dev, u16 value);
+void c67x00_ll_husb_reset(struct c67x00_sie *sie, int port);
+void c67x00_ll_husb_set_current_td(struct c67x00_sie *sie, u16 addr);
+u16 c67x00_ll_husb_get_current_td(struct c67x00_sie *sie);
+void c67x00_ll_husb_clear_status(struct c67x00_sie *sie, u16 bits);
+u16 c67x00_ll_husb_get_status(struct c67x00_sie *sie);
+u16 c67x00_ll_husb_get_frame(struct c67x00_sie *sie);
+void c67x00_ll_husb_init_host_port(struct c67x00_sie *sie);
+void c67x00_ll_husb_reset_port(struct c67x00_sie *sie, int port);
+
+/* Slave specific functions */
+void c67x00_ll_susb_init(struct c67x00_sie *sie);
+
+/* Read and write to memory */
+void c67x00_ll_hpi_write_mem_le16(struct c67x00_device *dev, u16 addr,
+ int len, char *data);
+void c67x00_ll_hpi_read_mem_le16(struct c67x00_device *dev, u16 addr,
+ int len, char *data);
+
+/* Called by c67x00_irq to handle lcp interrupts */
+void c67x00_ll_irq(struct c67x00_device *dev);
+
+/* Setup and teardown */
+void c67x00_ll_init(struct c67x00_device *dev);
+void c67x00_ll_release(struct c67x00_device *dev);
+int c67x00_ll_reset(struct c67x00_device *dev);
+
+#endif /* _USB_C67X00_H */
^ permalink raw reply related
* [PATCH 5/5] USB: Add Cypress c67x00 OTG controller driver to Kconfig and Makefiles
From: Grant Likely @ 2007-11-24 0:24 UTC (permalink / raw)
To: linux-usb-devel, akpm, dbrownell, gregkh, linuxppc-dev
In-Reply-To: <20071124001203.25361.99294.stgit@trillian.cg.shawcable.net>
From: Grant Likely <grant.likely@secretlab.ca>
add c67x00 driver to build
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/usb/Kconfig | 2 ++
drivers/usb/Makefile | 2 ++
drivers/usb/c67x00/Kconfig | 22 ++++++++++++++++++++++
drivers/usb/c67x00/Makefile | 14 ++++++++++++++
4 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 7580aa5..a497f96 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -91,6 +91,8 @@ source "drivers/usb/core/Kconfig"
source "drivers/usb/host/Kconfig"
+source "drivers/usb/c67x00/Kconfig"
+
source "drivers/usb/class/Kconfig"
source "drivers/usb/storage/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 516a640..a1ae51d 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -17,6 +17,8 @@ obj-$(CONFIG_USB_SL811_HCD) += host/
obj-$(CONFIG_USB_U132_HCD) += host/
obj-$(CONFIG_USB_R8A66597_HCD) += host/
+obj-$(CONFIG_USB_C67X00_DRV) += c67x00/
+
obj-$(CONFIG_USB_ACM) += class/
obj-$(CONFIG_USB_PRINTER) += class/
diff --git a/drivers/usb/c67x00/Kconfig b/drivers/usb/c67x00/Kconfig
new file mode 100644
index 0000000..efd7923
--- /dev/null
+++ b/drivers/usb/c67x00/Kconfig
@@ -0,0 +1,22 @@
+#
+# Cypress C67x00 USB controller
+#
+config USB_C67X00_DRV
+ tristate "Cypress C67x00 support"
+ # only allowed to be =y if both USB!=m and USB_GADGET!=m
+ depends on (!USB && USB_GADGET) || (!USB_GADGET && USB) || (USB && USB_GADGET)
+ default n
+ help
+ The Cypress C67x00 (EZ-Host/EZ-OTG) chips are dual-role
+ host/peripheral USB controllers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called c67x00.
+
+config USB_C67X00_HCD
+ bool "Cypress C67X00 Host support"
+ depends on USB_C67X00_DRV
+ depends on USB
+ default y
+ help
+ This enables the host functionality of the Cypress C67X00.
diff --git a/drivers/usb/c67x00/Makefile b/drivers/usb/c67x00/Makefile
new file mode 100644
index 0000000..8ff5cd0
--- /dev/null
+++ b/drivers/usb/c67x00/Makefile
@@ -0,0 +1,14 @@
+#
+# Makefile for Cypress C67X00 USB Controller
+#
+
+ifeq ($(CONFIG_USB_DEBUG),y)
+ EXTRA_CFLAGS += -DDEBUG
+endif
+
+obj-$(CONFIG_USB_C67X00_DRV) += c67x00.o
+
+c67x00-y += c67x00-drv.o
+c67x00-y += c67x00-ll-hpi.o
+
+c67x00-$(CONFIG_USB_C67X00_HCD) += c67x00-hcd.o c67x00-sched.o
^ permalink raw reply related
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Jeff Garzik @ 2007-11-24 0:49 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Paul Mundt, linux-ide
In-Reply-To: <20071123175229.GA27143@localhost.localdomain>
Anton Vorontsov wrote:
> Hi all,
>
> Here is the PATA Platform driver using OF infrastructure.
>
> Mostly it's just a wrapper around a bit modified pata_platform
> driver.
>
> Patches are well split for the easier review:
>
> First one factors out platform_device specific bits and modifies
> pata_platform to be a library-alike driver (with platform_device
> default binding).
>
> Second patch is OF-driver itself which is using pata_platform
> "library".
>
> Third patch is PowerPC specific, but I'm still Cc'ing linux-ide,
> just to show how we're using it.
>
>
> As an alternative approach we can use plain pata_platform
> driver, but I'm not sure how Linux OF bindings' ideologists will
> or will not like it.
>
> So, these patches are strongly Request For Comments. Feel free
> to train your nitpicking skills ;-), and/or vote for the option
> you most pleased about (or suggest another?).
Seems reasonable from a libata point of view...
(pata_platform maintainer CC'd)
Jeff
^ permalink raw reply
* Re: [PATCH 0/3] PowerPC: ibm_newemac minor fixes.
From: Benjamin Herrenschmidt @ 2007-11-24 1:18 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <20071123190747.GA25654@ru.mvista.com>
On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote:
> These patches have some minor ibm_newemac fixes.
All 3 patches look good, thanks. I'll sign them off and forward them
to Jeff in my next batch.
Jeff, did you already pick up my previous drop of EMAC patches from last
week for .25 or not ? If not, I will resend the whole lot along with
Valentine's patches sometime next week.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 0/3] PowerPC: ibm_newemac minor fixes.
From: Jeff Garzik @ 2007-11-24 1:20 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, netdev
In-Reply-To: <1195867102.7195.31.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote:
>
>> These patches have some minor ibm_newemac fixes.
>
> All 3 patches look good, thanks. I'll sign them off and forward them
> to Jeff in my next batch.
>
> Jeff, did you already pick up my previous drop of EMAC patches from last
> week for .25 or not ? If not, I will resend the whole lot along with
> Valentine's patches sometime next week.
Just got back from Thanksgiving holiday, and am about to go through the
lot that's sitting in my inbox.
Just let me know what you would prefer me to do, starting from today.
Jeff
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Benjamin Herrenschmidt @ 2007-11-24 1:23 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <20071123175229.GA27143@localhost.localdomain>
On Fri, 2007-11-23 at 20:52 +0300, Anton Vorontsov wrote:
> As an alternative approach we can use plain pata_platform
> driver, but I'm not sure how Linux OF bindings' ideologists will
> or will not like it.
>
> So, these patches are strongly Request For Comments. Feel free
> to train your nitpicking skills ;-), and/or vote for the option
> you most pleased about (or suggest another?).
>
>
> Thanks.
>
> ---
> Down here is "alternative approach".
>
> Probably board-neutral version may be placed somewhere in
> the drivers/of/...? But who will call it: board file, or
> device_initcall for all boards?
.../...
I'm fine with either approaches in fact. I think it's fair enough when
there is existing platform devices to avoid duplicating the whole thing
for an of_platform_device (unless you find a nice way to split to a
library like you just did) and instead, have a "constructor" that
constructs the platform device based on the OF node.
Now, as you pointed out, the question is where to call it... the
initcall has the problem of potentially being called for the wrong board
and the thing having duplicate OF device and platform device created for
it...
One of the thing I've been brewing in my mind is the idea of reworking
the current code that create OF platform devices when walking busses
down, and have it instead call registered constructor functions. The
default ones would then create OF platform devices but one could
override that with constructors creating something else (such as a
platform device).
Now, it's not trivial, as there is a bit of a mixup on whether a "bus"
should create all children and thus define their type (PCI would do such
a thing) or whether the type is defined by the device object itself
which typically would be the case for "generic" busses such as SoCs or
PLBs when creating platform devices. I haven't quite found out a nice
way to enable both possibilities... if you have ideas, please share.
In the meantime, maybe it's best to merge the of_platform_device
approach since Jeff agrees with it.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 0/3] PowerPC: ibm_newemac minor fixes.
From: Benjamin Herrenschmidt @ 2007-11-24 1:31 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, netdev
In-Reply-To: <47477C55.8090209@garzik.org>
On Fri, 2007-11-23 at 20:20 -0500, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > On Fri, 2007-11-23 at 22:07 +0300, Valentine Barshak wrote:
> >
> >> These patches have some minor ibm_newemac fixes.
> >
> > All 3 patches look good, thanks. I'll sign them off and forward them
> > to Jeff in my next batch.
> >
> > Jeff, did you already pick up my previous drop of EMAC patches from last
> > week for .25 or not ? If not, I will resend the whole lot along with
> > Valentine's patches sometime next week.
>
> Just got back from Thanksgiving holiday, and am about to go through the
> lot that's sitting in my inbox.
>
> Just let me know what you would prefer me to do, starting from today.
Then wait for my next batch and ignore previous patches, except the
one titled "ibm_newemac: Fix possible lockup on close" which is a 2.6.24
bug fix.
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 0/8] ibm_newemac: Candidate patches for 2.6.25
From: Jeff Garzik @ 2007-11-24 1:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, linuxppc-dev
In-Reply-To: <1195625198.76200.922309668615.qpush@grosgo>
Benjamin Herrenschmidt wrote:
> Here are the patches I have pending for EMAC. With some non-released
> patches from Hugh Blemings, I get a taishan (440GX) booting now,
> in addition to Ebony (440GP) and various 405GP boards.
>
> This is 2.6.25 material except for patch #1 which has already been
> posted separately and is candidate for 2.6.24 (and possibly stable)
dropping (waiting for resend), as requested
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Fix possible lockup on close
From: Jeff Garzik @ 2007-11-24 1:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071120035134.970DCDDE9E@ozlabs.org>
Benjamin Herrenschmidt wrote:
> It's a bad idea to call flush_scheduled_work from within a
> netdev->stop because the linkwatch will occasionally take the
> rtnl lock from a workqueue context, and thus that can deadlock.
>
> This reworks things a bit in that area to avoid the problem.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
applied #upstream-fixes (2.6.24-rc)
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Vitaly Bordug @ 2007-11-24 2:35 UTC (permalink / raw)
To: avorontsov; +Cc: Benjamin, linuxppc-dev, linux-ide
In-Reply-To: <20071123175229.GA27143@localhost.localdomain>
On Fri, 23 Nov 2007 20:52:29 +0300
Anton Vorontsov wrote:
> Hi all,
>
> Here is the PATA Platform driver using OF infrastructure.
>
> Mostly it's just a wrapper around a bit modified pata_platform
> driver.
>
> Patches are well split for the easier review:
>
> First one factors out platform_device specific bits and modifies
> pata_platform to be a library-alike driver (with platform_device
> default binding).
>
> Second patch is OF-driver itself which is using pata_platform
> "library".
>
> Third patch is PowerPC specific, but I'm still Cc'ing linux-ide,
> just to show how we're using it.
>
>
> As an alternative approach we can use plain pata_platform
> driver, but I'm not sure how Linux OF bindings' ideologists will
> or will not like it.
>
> So, these patches are strongly Request For Comments. Feel free
> to train your nitpicking skills ;-), and/or vote for the option
> you most pleased about (or suggest another?).
>
I vote for of_platform_device, since we seem to dodge the clash
with platform_device here.
The code looks good, so I'm going to ack all 3 patches and if there will
be no more nagging, I'm inclined to ask Kumar to queue this for the next merge window.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Jeff Garzik @ 2007-11-24 2:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, auke-jan.h.kok, linuxppc-dev
In-Reply-To: <20071116073821.548CCDDDF4@ozlabs.org>
Benjamin Herrenschmidt wrote:
> The e1000 driver stores the content of the PCI resources into
> unsigned long's before ioremapping. This breaks on 32 bits
> platforms that support 64 bits MMIO resources such as ppc 44x.
>
> This fixes it by removing those temporary variables and passing
> directly the result of pci_resource_start/len to ioremap.
>
> The side effect is that I removed the assignments to the netdev
> fields mem_start, mem_end and base_addr, which are totally useless
> for PCI devices.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> --
>
> drivers/net/e1000/e1000_main.c | 18 +++++-------------
> 1 file changed, 5 insertions(+), 13 deletions(-)
Looks good to me. auke?
^ permalink raw reply
* Re: [PATCH 1/2][2.6.24] ehea: Improve tx packets counting
From: Jeff Garzik @ 2007-11-24 3:09 UTC (permalink / raw)
To: Thomas Klein
Cc: Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200711211737.58789.osstklei@de.ibm.com>
Thomas Klein wrote:
> Using own tx_packets counter instead of firmware counters.
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
>
> ---
> drivers/net/ehea/ehea.h | 2 +-
> drivers/net/ehea/ehea_main.c | 9 +++++++--
> 2 files changed, 8 insertions(+), 3 deletions(-)
applies 1-2 to #upstream-fixes
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 4/5] USB: add Cypress c67x00 OTG controller HCD driver
From: Alan Stern @ 2007-11-24 3:56 UTC (permalink / raw)
To: Grant Likely; +Cc: akpm, linuxppc-dev, dbrownell, linux-usb-devel, gregkh
In-Reply-To: <20071124002446.25361.88850.stgit@trillian.cg.shawcable.net>
On Fri, 23 Nov 2007, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> This patch adds HDC support for the Cypress c67x00 family of devices.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> +static void c67x00_sched_done(unsigned long __c67x00)
> +{
> + struct c67x00_hcd *c67x00 = (struct c67x00_hcd *)__c67x00;
> + struct c67x00_urb_priv *urbp, *tmp;
> + struct usb_hcd *hcd = c67x00_hcd_to_hcd(c67x00);
> + struct urb *urb;
> + int status;
> +
> + spin_lock(&c67x00->lock);
> +
> + /* Loop over the done list and give back all the urbs */
> + list_for_each_entry_safe(urbp, tmp, &c67x00->done_list, hep_node) {
> + urb = urbp->urb;
> + status = urbp->status;
> +
> + c67x00_release_urb(c67x00, urb);
> +
> + usb_hcd_unlink_urb_from_ep(hcd, urb);
> + usb_hcd_giveback_urb(hcd, urb, status);
> + }
> + spin_unlock(&c67x00->lock);
> +}
You need to release the spinlock around the call to
usb_hcd_giveback_urb(). Otherwise you will deadlock if the completion
routine submits another URB.
Alan Stern
^ permalink raw reply
* Re: [PATCH 1/5] USB: Make usb_hcd_irq work for multi-role USB controllers w/ shared irq
From: Greg KH @ 2007-11-24 5:10 UTC (permalink / raw)
To: Grant Likely; +Cc: akpm, linuxppc-dev, dbrownell, linux-usb-devel
In-Reply-To: <20071124002431.25361.23974.stgit@trillian.cg.shawcable.net>
On Fri, Nov 23, 2007 at 05:24:31PM -0700, Grant Likely wrote:
> From: Peter Korsgaard <peter.korsgaard@barco.com>
>
> Some multi-role (host/peripheral) USB controllers use a shared interrupt
> line for all parts of the chip. Export usb_hcd_irq so drivers can call it
> from their interrupt handler instead of duplicating code.
> Drivers pass an irqnum of 0 to usb_add_hcd to signal that the interrupt handler
> shouldn't be registerred by the core.
What about for platforms where irq 0 is a valid irq?
thanks,
greg k-h
^ permalink raw reply
* RE: Xilinx Linux git server available
From: Stephen Neuendorffer @ 2007-11-24 5:54 UTC (permalink / raw)
To: Peter Korsgaard, Grant Likely; +Cc: linuxppc-dev, Wolfgang Reissnegger
In-Reply-To: <87wssae11t.fsf@macbook.be.48ers.dk>
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
It was the edk-derived driver for the uartlite.. The functionality is now provided by the open source driver.
Steve
-----Original Message-----
From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx.com@ozlabs.org on behalf of Peter Korsgaard
Sent: Thu 11/22/2007 7:45 AM
To: Grant Likely
Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger
Subject: Re: Xilinx Linux git server available
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
>> Ok, I had a quick look at the tree and saw a uartlite-alternative.c -
>> What's that about?
Grant> What directory is that in? I had looked in drivers/serial and only
Grant> saw uartlite.c:
It's gone now (I accidently ended up browsing an earlier version
before):
http://git.xilinx.com/cgi-bin/gitweb.cgi?p=linux-2.6-xlnx.git;a=commit;h=9912d5bf98f969324e1d4f12210adccd1530de68
--
Bye, Peter Korsgaard
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 1849 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH 0/3] OF-platform PATA driver
From: Paul Mundt @ 2007-11-24 7:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, linux-ide
In-Reply-To: <4747751D.4060802@garzik.org>
On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote:
> Anton Vorontsov wrote:
> >Here is the PATA Platform driver using OF infrastructure.
> >
> >Mostly it's just a wrapper around a bit modified pata_platform
> >driver.
> >
> >Patches are well split for the easier review:
> >
> >First one factors out platform_device specific bits and modifies
> >pata_platform to be a library-alike driver (with platform_device
> >default binding).
> >
The only issue I have here is that this library-like version has subtle
semantic changes that will break existing drivers.
irq_flags exists in struct pata_platform_info precisely for the IRQ
resource IRQ flags (as opposed to the IORESOURCE flags, which are what
the IRQ resource flags refer to instead). This change takes that for
granted and just assumes we're going to be using the res->flags, which is
both an invalid assumption, and will utterly break blackfin and others
that depend on it.
Incidentally, we already have an include/linux/pata_platform.h. If this
is going to be library-like, through the prototypes in there, rather than
splitting them up betewen include/linux and drivers/ata. We don't need
two headers.
These patches basically look fine to me otherwise, though it would be
nice if the semantic-changing bits had been abstracted. So as long as the
old irq_flags behaviour is maintained and that irq_res->flags stuff is
ripped out, I'll add my Acked-by as well.
^ permalink raw reply
* Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-24 11:37 UTC (permalink / raw)
To: linuxppc-embedded
I am following developments regarding device trees for xilinx boards
both here and on the microblaze list.
I am trying to get a grasp on what they will really do for me and
what using them will demand.
Please correct any misperceptions:
As I understand it devicetrees are basically just a tree structured
binary database describing the hardware.
They have some heritage in OpenFirmware.
There are tools to convert some human readable representations into
the binary form.
There appear to be tools to take xilinx firmware projects and create
a devicetree database from it
A BSP using devicetree's configures its hardware, drivers etc, by
querying the devicetree database.
It it possible to pass the device tree database independent of the
kernel itself some what similar to the way many bootloaders pass initrd
filesystems.
So in the end I write a BSP that could support a wide variety of
hardware and compile a single kernel that could be passed different
devicetree databases representing different xilinx firmware, and still
hope to work.
But in return for making the BSP more generic (sort of), I now have
to somehow get the correct devicetree database passed for each different
firmware set that I load.
I am having some difficulty grasping the significant advantages to
this.
If the firmware for a given target is not fairly static - and I load
different firmware depending on what I am doing all the time, then I
know have to manage both a bit file for the firmware, and a devicetree
file describing it to the kernel.
Currently for base hardware we maintain as much design consistancy
as possible accross all our different cards/firmware.
particular hardware/firmware blocks/IP's may or may not be present -
but if present they are always the same - the Same Uartlite at the same
location, on the same irq, same for PIC's, TEMAC's ...
For the most part it makes the most sense for us to use code to
detect the presence/absence of specific baseline hardware and then to
load non-base custom drivers after boot.
What am missing about devicetrees that would make me more
interested in them ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: oops trying to execute sh
From: John Tyner @ 2007-11-24 14:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711211149210.3338@eon.cs.ucr.edu>
This is ppc. I'm in the midst of trying to get powerpc to boot, but our
boards are running an old version of ppcboot that can't be upgraded, so
I'm having to figure out the translation to the open firmware stuff.
By the way, this is an 860t, not c... typo.
Do you have any suggestions about getting ppc to boot? I'd like to try to
at least get the board booting so I can hand the user space stuff off to
someone else while I do the powerpc port.
Thanks,
John
> On Wed, 21 Nov 2007 11:54:01 -0800 (PST)
> John Charles Tyner wrote:
>
> > I'm trying to boot linux 2.6.22.9 on an mpc860c rev d4.
> >
> ppc or powerpc?
>
>
> > When init trys to spawn sh, during the exec, the kernel oopses as
> > seen below:
> This looks like coherency problem, or kernel picks wrong entry off
> cputable.
> I think I recall something similar when I lost a hunk applying patch for
> new e300 core.
> ... or not. The game across that ff8.. value is very confusing.
>
> --
> Sincerely, Vitaly
On Wed, Nov 21, 2007 at 11:54:01AM -0800, John Charles Tyner wrote:
> I'm trying to boot linux 2.6.22.9 on an mpc860c rev d4.
>
> When init trys to spawn sh, during the exec, the kernel oopses as seen
> below:
>
> ## Starting application at 0x00400000 ...
>
> loaded at: 00400000 004EF15C
> board data at: 03F9FBC0 03F9FBFC
> relocated to: 00404044 00404080
> zimage at: 00404E74 004EC662
> avail ram: 004F0000 04000000
>
> Linux/PPC load: console=ttyCPM,38400
> Uncompressing Linux...done.
> Now booting the kernel
> Linux version 2.6.22.9 (jtyner@johnnyedge) (gcc version 4.2.1) #113 Wed Nov
> 21 10:49:36 PST 2007
> Zone PFN ranges:
> DMA 0 -> 16384
> Normal 16384 -> 16384
> early_node_map[1] active PFN ranges
> 0: 0 -> 16384
> Built 1 zonelists. Total pages: 16256
> Kernel command line: console=ttyCPM,38400
> PID hash table entries: 256 (order: 8, 1024 bytes)
> Decrementer Frequency = 183750000/60
> Console: colour dummy device 80x25
> cpm_uart: console: compat mode
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 63244k available (880k kernel code, 268k data, 444k init, 0k
> highmem)
> Mount-cache hash table entries: 512
> ADDSI: Init
> io scheduler noop registered (default)
> Serial: CPM driver $Revision: 0.02 $
> ttyCPM0 at MMIO 0xc5000a80 (irq = 20) is a CPM UART
> mice: PS/2 mouse device common for all mice
> Freeing unused kernel memory: 444k init
> init started: BusyBox v1.8.0 (2007-11-16 14:24:51 PST)
> starting pid 103, tty '': '/bin/sh'
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: c0044ed0 LR: c0044ff0 CTR: 00000001
> REGS: c3c0bd00 TRAP: 0300 Not tainted (2.6.22.9)
> MSR: 00009032 <EE,ME,IR,DR> CR: 30099099 XER: a0008c7f
> DAR: ff80103f, DSISR: c0000000
> TASK = c0288070[103] 'init' THREAD: c3c0a000
> GPR00: c0044ff0 c3c0bdb0 c0288070 ff800fff 00000000 7faf8000 00000000
> 00000000
> GPR08: c01a8f58 c017d91c 00000002 c0179cd0 30099093 1007687c 00000002
> c00f8744
> GPR16: 00000000 c00f0a64 c011d1ac c00f0aa4 c00f0a90 c0120000 00000001
> 00000003
> GPR24: c3c1ce00 00000000 c0180000 c0247550 00000000 c3c0bdc8 c0179cd0
> ff800fff
> NIP [c0044ed0] remove_vma+0x14/0x70
> LR [c0044ff0] exit_mmap+0xc4/0xf0
> Call Trace:
> [c3c0bdb0] [c3c0bdc8] 0xc3c0bdc8 (unreliable)
> [c3c0bdc0] [c0044ff0] exit_mmap+0xc4/0xf0
> [c3c0bdf0] [c000f74c] mmput+0x50/0xd4
> [c3c0be00] [c00591f4] flush_old_exec+0x3b8/0x7a8
> [c3c0be50] [c0086cc0] load_elf_binary+0x2e8/0x1454
> [c3c0bee0] [c005892c] search_binary_handler+0x58/0x12c
> [c3c0bf00] [c0059d64] do_execve+0x13c/0x1f0
> [c3c0bf20] [c00089b4] sys_execve+0x50/0x90
> [c3c0bf40] [c0002a40] ret_from_syscall+0x0/0x38
> Instruction dump:
> 7d808120 38210040 4e800020 83c30000 4bffff18 38a00000 4bffff9c 7c0802a6
> 9421fff0 bfc10008 90010014 7c7f1b78 <81230040> 83c3000c 2f890000 419e0018
>
> The interesting thing is that r3 points to something funny. While tracing
> this problem down, I replaced the remove_vma function with the following:
>
> /*
> * Close a vm structure and free it, returning the next.
> */
> static struct vm_area_struct * __attribute__((__noinline__))
> __remove_vma(struct vm_area_struct *vma)
> {
>
> struct vm_area_struct *next = vma->vm_next;
>
> might_sleep();
> if (vma->vm_ops && vma->vm_ops->close)
> vma->vm_ops->close(vma);
> if (vma->vm_file)
> fput(vma->vm_file);
> mpol_free(vma_policy(vma));
> kmem_cache_free(vm_area_cachep, vma);
> return next;
> }
>
> static struct vm_area_struct *remove_vma(struct vm_area_struct *vma)
> {
> asm volatile (
> "lis 4,-128\n"
> "ori 4,4,4095\n"
> "tweq 3,4\n"
> "lwz 5,0(1)\n"
> "tweq 3,4\n"
> );
> return __remove_vma( vma );
> }
>
> With this code, the kernel oopses on the *second* tweq instruction:
>
> Kernel BUG at c0045fd4 [verbose debug info unavailable]
> Oops: Exception in kernel mode, sig: 5 [#1]
> NIP: c0045fd4 LR: c00460a0 CTR: 00000001
> REGS: c3c0bd10 TRAP: 0700 Not tainted (2.6.22.9)
> MSR: 00029032 <EE,ME,IR,DR> CR: 30099099 XER: a0008c7f
> TASK = c0292b40[103] 'init' THREAD: c3c0a000
> GPR00: 00000001 c3c0bdc0 c0292b40 ff800fff ff800fff c3c0bdf0 00000000
> 00000000
> GPR08: c0219398 c017d91c 00000002 c0179cd0 30099093 1007687c 00000002
> c00f8744
> GPR16: 00000000 c00f0a64 c011d1ac c00f0aa4 c00f0a90 c0120000 00000001
> 00000003
> GPR24: c3c32e00 00000000 c0180000 c0247080 00000000 c3c0bdc8 c0179cd0
> c017641c
> NIP [c0045fd4] remove_vma+0x10/0x18
> LR [c00460a0] exit_mmap+0xc4/0xf0
> Call Trace:
> [c3c0bdc0] [c0046074] exit_mmap+0x98/0xf0 (unreliable)
> [c3c0bdf0] [c000f74c] mmput+0x50/0xd4
> [c3c0be00] [c005920c] flush_old_exec+0x3b8/0x7a8
> [c3c0be50] [c0086cd8] load_elf_binary+0x2e8/0x1454
> [c3c0bee0] [c0058944] search_binary_handler+0x58/0x12c
> [c3c0bf00] [c0059d7c] do_execve+0x13c/0x1f0
> [c3c0bf20] [c00089b4] sys_execve+0x50/0x90
> [c3c0bf40] [c0002a40] ret_from_syscall+0x0/0x38
> Instruction dump:
> 7fe4fb78 4800a0ed 80010014 7fc3f378 7c0803a6 bbc10008 38210010 4e800020
> 3c80ff80 60840fff 7c832008 80a10000 <7c832008> 4bffff7c 7c0802a6 9421ffd0
>
> The access of memory through r1 seems to corrupt r3, and always with the
> same value. The problem isn't necessarily here, though. If I modify my
> remove_vma function to cause and correct the problem (by saving r3 prior
> to the memory access and restoring it afterwards), I just get the same
> problem in some other part of the code, but the oops is always caused
> because the base register for some memory access is set to ff800fff.
>
> I applied a recent patch I found that corrects the address returned by
> cpm_dpram_addr and its use in cpu_uart_cpm1.h, and I've created my own
> platform setup file by copying the mpc866ads setup enough to get the
> console uart (SMC1) to work.
>
> If there is any other information I can or need to provide, let me
> know. Any help would be greatly appreciated.
>
> Thanks,
> John
--
John Tyner
jtyner@cs.ucr.edu
^ permalink raw reply
* shekr06@lzu.cn;puyq@lzu.cn;zhang_wei@lzu.cn
From: Bai Shuwei @ 2007-11-24 15:19 UTC (permalink / raw)
To: linuxppc-embedded, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
hi, all
I bought a SMC1500 stepper motor card. And it can connect with host
through parallel port. My target board is PowerPC 440, which hasn't
parrallel port. So I bought a PCI to Parallel line for SMC1500. But when I
run the stepper motor, I find it's not stable. I doubt there are somthing
wrong with my PCI to Parallel line. So I beg somebody can tell me where I
can bought the appropriate conversion line from PCI to parallel, and does
somebody give me some idea about how to control my stepper motor
through PowerPC 440? thx all
Best Regards!
Buroc
--
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
URL: oss.lzu.edu.cn
Email: baishuwei@gmail.com, buroc@126.com
[-- Attachment #2: Type: text/html, Size: 1016 bytes --]
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-24 17:12 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <47480CF0.7090105@dlasys.net>
On 11/24/07, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> I am following developments regarding device trees for xilinx boards
> both here and on the microblaze list.
>
> I am trying to get a grasp on what they will really do for me and
> what using them will demand.
>
> Please correct any misperceptions:
>
> As I understand it devicetrees are basically just a tree structured
> binary database describing the hardware.
> They have some heritage in OpenFirmware.
> There are tools to convert some human readable representations into
> the binary form.
> There appear to be tools to take xilinx firmware projects and create
> a devicetree database from it
> A BSP using devicetree's configures its hardware, drivers etc, by
> querying the devicetree database.
> It it possible to pass the device tree database independent of the
> kernel itself some what similar to the way many bootloaders pass initrd
> filesystems.
Yes, you are correct in all of the above.
One more point; it is also possible to bind the device tree up with
the kernel so you've got a single image just like old times. :-)
>
> So in the end I write a BSP that could support a wide variety of
> hardware and compile a single kernel that could be passed different
> devicetree databases representing different xilinx firmware, and still
> hope to work.
> But in return for making the BSP more generic (sort of), I now have
> to somehow get the correct devicetree database passed for each different
> firmware set that I load.
Yes; either by changes the device tree blob; or having a different
kernel+device tree image for each FPGA bitstream. In the later case,
the kernel can be compiled once and then bound to multiple dt blobs
(creating multiple images)
>
> I am having some difficulty grasping the significant advantages to
> this.
> If the firmware for a given target is not fairly static - and I load
> different firmware depending on what I am doing all the time, then I
> know have to manage both a bit file for the firmware, and a devicetree
> file describing it to the kernel.
> Currently for base hardware we maintain as much design consistancy
> as possible accross all our different cards/firmware.
> particular hardware/firmware blocks/IP's may or may not be present -
> but if present they are always the same - the Same Uartlite at the same
> location, on the same irq, same for PIC's, TEMAC's ...
> For the most part it makes the most sense for us to use code to
> detect the presence/absence of specific baseline hardware and then to
> load non-base custom drivers after boot.
The board description has to live *somewhere*. For powerpc (and
microblaze) we've decided that for generic stuff, it makes sense to
use the device tree data structure to describe the hardware. It makes
the platform code simpler because the platform code no longer needs to
explicitly instantiate drivers for each device on the board. Instead
it registers part of the device tree with the of_platform bus and lets
the drivers handle binding themselves.
That being said, using the device tree does not preclude using
platform code to setup devices *where it makes sense to do so*. Many
things are one-off board specific things that are not well described
with the device tree. For example, we've been debating how to handle
on board sound which use common codec chips, but have custom wireup.
The codec chip can use a common driver, but the wireup is handled with
an ALSA 'fabric' driver that is pretty much a one-off for the board.
It probably makes more sense for the fabric driver to be instantiated
by the platform code rather than trying to do a full device tree
representation.
>
> What am missing about devicetrees that would make me more
> interested in them ?
To put it all in perspective, for Virtex support in arch/ppc
registration of devices is data driven. Look at
arch/ppc/syslib/virtex_devices.c which contains a table of platform
devices which the Virtex platform code iterates over. In arch/powerpc
we're *still* data driven; it's just that the data is no longer
compiled into a static structure. Plus, in the transition we've moved
from needed per-device platform data structures to a more expressive
format. Also, per-board platform support code has become much simpler
(compare ml300.c in arch/ppc with platforms/40x/virtex.c)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/5] USB: Make usb_hcd_irq work for multi-role USB controllers w/ shared irq
From: Alan Cox @ 2007-11-24 17:03 UTC (permalink / raw)
To: Greg KH; +Cc: akpm, dbrownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <20071124051039.GA11029@suse.de>
On Fri, 23 Nov 2007 21:10:39 -0800
Greg KH <gregkh@suse.de> wrote:
> On Fri, Nov 23, 2007 at 05:24:31PM -0700, Grant Likely wrote:
> > From: Peter Korsgaard <peter.korsgaard@barco.com>
> >
> > Some multi-role (host/peripheral) USB controllers use a shared interrupt
> > line for all parts of the chip. Export usb_hcd_irq so drivers can call it
> > from their interrupt handler instead of duplicating code.
> > Drivers pass an irqnum of 0 to usb_add_hcd to signal that the interrupt handler
> > shouldn't be registerred by the core.
>
> What about for platforms where irq 0 is a valid irq?
There are no such platforms. Linus made that absolutely clear every time
this came up before
0 - No IRQ
A platform with a physical or bus IRQ of 0 needs to remap it to a
different constant.
Alan
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/5] USB: Make usb_hcd_irq work for multi-role USB controllers w/ shared irq
From: Grant Likely @ 2007-11-24 17:15 UTC (permalink / raw)
To: Alan Cox; +Cc: akpm, linuxppc-dev, Greg KH, linux-usb-devel, dbrownell
In-Reply-To: <20071124170307.773d7317@the-village.bc.nu>
On 11/24/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Fri, 23 Nov 2007 21:10:39 -0800
> Greg KH <gregkh@suse.de> wrote:
>
> > On Fri, Nov 23, 2007 at 05:24:31PM -0700, Grant Likely wrote:
> > > From: Peter Korsgaard <peter.korsgaard@barco.com>
> > >
> > > Some multi-role (host/peripheral) USB controllers use a shared interrupt
> > > line for all parts of the chip. Export usb_hcd_irq so drivers can call it
> > > from their interrupt handler instead of duplicating code.
> > > Drivers pass an irqnum of 0 to usb_add_hcd to signal that the interrupt handler
> > > shouldn't be registerred by the core.
> >
> > What about for platforms where irq 0 is a valid irq?
>
> There are no such platforms. Linus made that absolutely clear every time
> this came up before
>
> 0 - No IRQ
>
> A platform with a physical or bus IRQ of 0 needs to remap it to a
> different constant.
Regardless, I should probably use the NO_IRQ macro instead.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/5] USB: Make usb_hcd_irq work for multi-role USB controllers w/ shared irq
From: David Brownell @ 2007-11-24 17:50 UTC (permalink / raw)
To: Alan Cox; +Cc: akpm, Greg KH, linux-usb-devel, linuxppc-dev
In-Reply-To: <20071124170307.773d7317@the-village.bc.nu>
On Saturday 24 November 2007, Alan Cox wrote:
> >
> > What about for platforms where irq 0 is a valid irq?
>
> There are no such platforms. Linus made that absolutely clear every time
> this came up before
>
> 0 - No IRQ
>
> A platform with a physical or bus IRQ of 0 needs to remap it to a
> different constant.
However it's also common practice to use negative numbers to
flag "this is no IRQ" ... avoiding all confusions with zero.
- platform_get_irq(), platform_get_irq_byname() ... never
return zero, they return irq (positive) or errno
- PNP initializes invalid IRQs to "-1", and pnp_check_irq()
handles irq zero as in-range
- I'm sure I've seen negative numbers used elsewhere too
Something like
#define is_valid_irq(x) ((x) >= 0)
would work better than expecting sudden agreement everywhere
about a single number representing "this is not an IRQ".
- Dave
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Jochen Friedrich @ 2007-11-24 17:53 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071123005121.4d38d877@kernel.crashing.org>
Hi Vitaly,
>>> + printk(KERN_ERR "%s(): Not able to issue CPM command\n",
>>> + __FUNCTION__);
>>> + return -EIO;
>>>
>> Do these need to be protected with a spin lock?
>>
> Even that might be not enough - we may have simultaneous call of this func in non-smp case...
> I was thinking of some kind of refcount, so one that is going to issue CPM command, must do say pq_cpmp_get()
> and another driver won't be able to mangle with cpcr while it's not done with previous request.
>
> Yet I am not telling it was better the way it used to be - this approach looks okay but needs some efforts to defend against
> deadlocks while we are at it
Wouldn't spin_lock_irqsave() prevent a deadlock?
Thanks,
Jochen
^ 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