Hi,
Here is the driver for the reader I have.
Plus one fix for hangs on unclean removal introduced my changes in block core.
This is just writen and debbuged, but works very well now.
I don't know if possible, but I would like to see that in 2.6.36, because
this is new driver, so no posiibility of regressions.
Best regards,
Maxim Levitsky
Now that del_gendisk syncs, we better start rejecting requests right away.
Signed-off-by: Maxim Levitsky <[email protected]>
---
drivers/memstick/core/mspro_block.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/memstick/core/mspro_block.c b/drivers/memstick/core/mspro_block.c
index 8327e24..8d27c13 100644
--- a/drivers/memstick/core/mspro_block.c
+++ b/drivers/memstick/core/mspro_block.c
@@ -1330,13 +1330,14 @@ static void mspro_block_remove(struct memstick_dev *card)
struct mspro_block_data *msb = memstick_get_drvdata(card);
unsigned long flags;
- del_gendisk(msb->disk);
- dev_dbg(&card->dev, "mspro block remove\n");
spin_lock_irqsave(&msb->q_lock, flags);
msb->eject = 1;
blk_start_queue(msb->queue);
spin_unlock_irqrestore(&msb->q_lock, flags);
+ del_gendisk(msb->disk);
+ dev_dbg(&card->dev, "mspro block remove\n");
+
blk_cleanup_queue(msb->queue);
msb->queue = NULL;
--
1.7.0.4
Signed-off-by: Maxim Levitsky <[email protected]>
---
MAINTAINERS | 6 +
drivers/memstick/host/Kconfig | 13 +
drivers/memstick/host/Makefile | 1 +
drivers/memstick/host/r592.c | 920 ++++++++++++++++++++++++++++++++++++++++
drivers/memstick/host/r592.h | 178 ++++++++
5 files changed, 1118 insertions(+), 0 deletions(-)
create mode 100644 drivers/memstick/host/r592.c
create mode 100644 drivers/memstick/host/r592.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 88fcb7c..7ebdd32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4822,6 +4822,12 @@ S: Maintained
F: drivers/mtd/nand/r822.c
F: drivers/mtd/nand/r822.h
+RICOH R5C592 MEMORYSTICK DRIVER
+M: Maxim Levitsky <[email protected]>
+S: Maintained
+F: drivers/memstick/host/r592.c
+F: drivers/memstick/host/r592.h
+
RISCOM8 DRIVER
S: Orphan
F: Documentation/serial/riscom8.txt
diff --git a/drivers/memstick/host/Kconfig b/drivers/memstick/host/Kconfig
index 4ce5c8d..7022a2a 100644
--- a/drivers/memstick/host/Kconfig
+++ b/drivers/memstick/host/Kconfig
@@ -30,3 +30,16 @@ config MEMSTICK_JMICRON_38X
To compile this driver as a module, choose M here: the
module will be called jmb38x_ms.
+
+config MEMSTICK_R592
+ tristate "Ricoh R5C592 MemoryStick interface support (EXPERIMENTAL)"
+ depends on EXPERIMENTAL && PCI
+
+ help
+ Say Y here if you want to be able to access MemoryStick cards with
+ the Ricoh R5C592 MemoryStick card reader (which is part of 5 in one
+ multifunction reader)
+
+ To compile this driver as a module, choose M here: the module will
+ be called r592.
+
diff --git a/drivers/memstick/host/Makefile b/drivers/memstick/host/Makefile
index 12530e4..ad63c16 100644
--- a/drivers/memstick/host/Makefile
+++ b/drivers/memstick/host/Makefile
@@ -8,3 +8,4 @@ endif
obj-$(CONFIG_MEMSTICK_TIFM_MS) += tifm_ms.o
obj-$(CONFIG_MEMSTICK_JMICRON_38X) += jmb38x_ms.o
+obj-$(CONFIG_MEMSTICK_R592) += r592.o
diff --git a/drivers/memstick/host/r592.c b/drivers/memstick/host/r592.c
new file mode 100644
index 0000000..bff5bc3
--- /dev/null
+++ b/drivers/memstick/host/r592.c
@@ -0,0 +1,920 @@
+/*
+ * Copyright (C) 2010 - Maxim Levitsky
+ * driver for Ricoh memstick readers
+ *
+ * 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/module.h>
+#include <linux/freezer.h>
+#include <linux/jiffies.h>
+#include <linux/interrupt.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/kthread.h>
+#include <linux/sched.h>
+#include <linux/highmem.h>
+#include <asm/byteorder.h>
+#include "r592.h"
+
+static int enable_dma = 1;
+static int debug;
+
+static char *tpc_names[] = {
+ "MS_TPC_READ_MG_STATUS",
+ "MS_TPC_READ_LONG_DATA",
+ "MS_TPC_READ_SHORT_DATA",
+ "MS_TPC_READ_REG",
+ "MS_TPC_READ_QUAD_DATA",
+ "MS_INVALID",
+ "MS_TPC_GET_INT",
+ "MS_TPC_SET_RW_REG_ADRS",
+ "MS_TPC_EX_SET_CMD",
+ "MS_TPC_WRITE_QUAD_DATA",
+ "MS_TPC_WRITE_REG",
+ "MS_TPC_WRITE_SHORT_DATA",
+ "MS_TPC_WRITE_LONG_DATA",
+ "MS_TPC_SET_CMD",
+};
+
+
+static char *dbg_tpc_name(int tpc)
+{
+ return tpc_names[tpc-1];
+}
+
+/* Read a register*/
+static inline u32 r592_read_reg(struct r592_device *dev, int address)
+{
+ u32 value = le32_to_cpu(readl(dev->mmio + address));
+ dbg_reg("reg #%02d == 0x%08x", address, value);
+ return value;
+}
+
+/* Write a register */
+static inline void r592_write_reg(struct r592_device *dev,
+ int address, u32 value)
+{
+ dbg_reg("reg #%02d <- 0x%08x", address, value);
+ writel(cpu_to_le32(value), dev->mmio + address);
+ mmiowb();
+}
+
+/* Reads a big endian DWORD register */
+static inline u32 r592_read_reg_be(struct r592_device *dev, int address)
+{
+ return be32_to_cpu(r592_read_reg(dev, address));
+}
+
+/* Writes a big endian DWORD register */
+static inline void r592_write_reg_be(struct r592_device *dev,
+ int address, u32 value)
+{
+ return r592_write_reg(dev, address, cpu_to_be32(value));
+}
+
+/* Set specific bits in a register (little endian)*/
+static inline void r592_set_reg_mask(struct r592_device *dev,
+ int address, u32 mask)
+{
+ u32 reg = readl(dev->mmio + address);
+ dbg_reg("reg #%02d |= 0x%08x (old =0x%08x)", address, mask, reg);
+ writel(cpu_to_le32(reg | mask) , dev->mmio + address);
+ mmiowb();
+}
+
+/* Clear specific bits in a register (little endian)*/
+static inline void r592_clear_reg_mask(struct r592_device *dev,
+ int address, u32 mask)
+{
+ u32 reg = readl(dev->mmio + address);
+ dbg_reg("reg #%02d &= 0x%08x (old = 0x%08x, mask = 0x%08x)",
+ address, ~mask, reg, mask);
+ writel(cpu_to_le32(reg & ~mask), dev->mmio + address);
+ mmiowb();
+}
+
+/* Wait till specific bits are set/clear in a register */
+/* Note that this is intended for waits that take very little time */
+static inline int r592_reg_wait(struct r592_device *dev, int address,
+ u32 mask, u32 wanted_mask)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(2000);
+
+ if ((r592_read_reg(dev, address) & mask) == wanted_mask)
+ return 0;
+
+ while (time_before(jiffies, timeout)) {
+ if ((r592_read_reg(dev, address) & mask) == wanted_mask)
+ return 0;
+ cpu_relax();
+ }
+ return -ETIME;
+}
+
+
+/* Enable/disable device */
+/* A common part of initialization between serial and parallel mode */
+/* This is not enough to actually use the device */
+static void r592_enable_device(struct r592_device *dev, bool enable)
+{
+ u32 reg = enable ? 3 : 0;
+ dbg("%sabling the device", enable ? "en" : "dis");
+ r592_write_reg(dev, R592_REG32, reg);
+
+ /* These error bits aren't used.
+ Still they are usefull for debug */
+ r592_clear_reg_mask(dev, R592_REG_MSC,
+ R592_REG_MSC_FIFO_USER_ORN | R592_REG_MSC_FIFO_MISMATH);
+}
+
+
+/* Set serial/parallel mode */
+static void r592_set_mode(struct r592_device *dev, bool parallel_mode)
+{
+ r592_set_reg_mask(dev, R592_IO, R592_IO_RESET);
+ msleep(100);
+
+ if (!parallel_mode) {
+ dbg("enabling serial mode");
+ r592_write_reg(dev, R592_REG36, 1);
+ } else {
+ dbg("enabling parallel mode");
+ r592_set_reg_mask(dev, R592_REG32, R592_REG32_20);
+
+ r592_clear_reg_mask(dev, R592_IO,
+ R592_IO_SERIAL1 | R592_IO_SERIAL2);
+
+ r592_write_reg(dev, R592_REG36, 3);
+ }
+}
+
+static void r592_reset(struct r592_device *dev)
+{
+ dbg("resetting device due to error");
+ /* TODO: extend 'card' interface to add a reset there */
+ /*dev->host->card->reset(dev->host->card);*/
+}
+
+
+/* Tests if there is an CRC error */
+static int r592_test_io_error(struct r592_device *dev)
+{
+ if (r592_read_reg(dev, R592_STATUS) &
+ (R592_STATUS_SEND_ERR | R592_STATUS_RECV_ERR)) {
+ dbg("got CRC error");
+ return -EILSEQ;
+ }
+ return 0;
+}
+
+/* Wait for empty fifo. Mostly precation */
+static int r592_wait_fifo_empty(struct r592_device *dev)
+{
+ /* Ensure fifo is ready */
+ int error = r592_reg_wait(dev, R592_REG_MSC,
+ R592_REG_MSC_FIFO_EMPTY, R592_REG_MSC_FIFO_EMPTY);
+
+ if (error) {
+ dbg("wait for FIFO empty failed");
+ return error;
+ }
+
+ return 0;
+}
+
+/* Activates the DMA transfer from to FIFO */
+static void r592_start_dma(struct r592_device *dev, bool is_write)
+{
+ unsigned long flags;
+ u32 reg;
+ spin_lock_irqsave(&dev->irq_lock, flags);
+
+ /* Ack interrupts (just in case) + enable them */
+ r592_clear_reg_mask(dev, R592_REG_MSC, DMA_IRQ_ACK_MASK);
+ r592_set_reg_mask(dev, R592_REG_MSC, DMA_IRQ_EN_MASK);
+
+ /* Set DMA address */
+ r592_write_reg(dev, R592_FIFO_DMA, sg_dma_address(&dev->req->sg));
+
+ /* Enable the DMA */
+ reg = r592_read_reg(dev, R592_FIFO_DMA_SETTINGS);
+ reg |= R592_FIFO_DMA_SETTINGS_EN;
+
+ if (!is_write)
+ reg |= R592_FIFO_DMA_SETTINGS_DIR;
+ else
+ reg &= ~R592_FIFO_DMA_SETTINGS_DIR;
+ r592_write_reg(dev, R592_FIFO_DMA_SETTINGS, reg);
+
+ spin_unlock_irqrestore(&dev->irq_lock, flags);
+}
+
+/* Cleanups DMA related settings */
+static void r592_stop_dma(struct r592_device *dev, int error)
+{
+ r592_clear_reg_mask(dev, R592_FIFO_DMA_SETTINGS,
+ R592_FIFO_DMA_SETTINGS_EN);
+
+ r592_write_reg(dev, R592_FIFO_DMA,
+ dev->scrath_dma_page_physical_address);
+
+ r592_clear_reg_mask(dev, R592_REG_MSC, DMA_IRQ_EN_MASK);
+ r592_clear_reg_mask(dev, R592_REG_MSC, DMA_IRQ_ACK_MASK);
+ dev->dma_error = error;
+}
+
+/* Test if hardware supports DMA */
+static void r592_check_dma(struct r592_device *dev)
+{
+ dev->dma_capable = enable_dma &&
+ (r592_read_reg(dev, R592_FIFO_DMA_SETTINGS) &
+ R592_FIFO_DMA_SETTINGS_CAP);
+}
+
+/* Transfers fifo contents in/out using DMA */
+static int r592_transfer_fifo_dma(struct r592_device *dev)
+{
+ int len, sg_count;
+ bool is_write;
+
+ if (!dev->dma_capable || !dev->req->long_data)
+ return -EINVAL;
+
+ len = dev->req->sg.length;
+ is_write = dev->req->data_dir == WRITE;
+
+ if (len != R592_LFIFO_SIZE)
+ return -EINVAL;
+
+ dbg_verbose("doing dma transfer");
+
+ dev->dma_error = 0;
+ INIT_COMPLETION(dev->dma_done);
+
+ /* TODO: hidden assumption about nenth beeing always 1 */
+ sg_count = dma_map_sg(&dev->pci_dev->dev, &dev->req->sg, 1, is_write ?
+ PCI_DMA_TODEVICE : PCI_DMA_FROMDEVICE);
+
+ if (sg_count != 1 ||
+ (sg_dma_len(&dev->req->sg) < dev->req->sg.length)) {
+ dbg("problem in dma_map_sg");
+ return -EIO;
+ }
+
+ r592_start_dma(dev, is_write);
+
+ /* Wait for DMA completion */
+ if (!wait_for_completion_timeout(
+ &dev->dma_done, msecs_to_jiffies(1000))) {
+ message("DMA timeout");
+ r592_stop_dma(dev, -ETIMEDOUT);
+ }
+
+ /* Cleanup */
+ return dev->dma_error;
+}
+
+/* writes the FIFO in 4 byte chunks
+ if lenght isn't 4 byte aligned, it spills remaining bytes into 'spill' buffer
+ it also accepts spill from former write
+ to flush a write, just call this with null buffer */
+static void r592_write_fifo_pio(struct r592_device *dev,
+ struct dword_buffer *spill, unsigned char *buffer, int len)
+{
+ unsigned char dword[4] = {0};
+
+ if (!buffer) {
+ buffer = dword;
+ len = sizeof(dword);
+ }
+
+ /* flush spill from former write */
+ while (spill->len < 4 && len) {
+ spill->dword[spill->len++] = *buffer++;
+ len--;
+ }
+
+ if (spill->len == 4) {
+ r592_write_reg_be(dev, R592_FIFO_PIO, *(u32 *)spill->dword);
+ spill->len = 0;
+ }
+
+ if (!len)
+ return;
+
+ /* write full dwords */
+ while (len >= 4) {
+ r592_write_reg_be(
+ dev, R592_FIFO_PIO, *(u32 *)buffer);
+ buffer += 4;
+ len -= 4;
+ }
+
+ /* put remaining bytes to the spill */
+ while (len--)
+ spill->dword[spill->len++] = *buffer++;
+}
+
+/* Read a fifo in 4 bytes chunks.
+ if input doesn't fit the buffer, it places bytes of last dword in spill
+ buffer, so that they don't get lost
+ on last read, just throw these away
+*/
+static void r592_read_fifo_pio(struct r592_device *dev,
+ struct dword_buffer *spill, unsigned char *buffer, int len)
+{
+ int i;
+ u32 tmp;
+
+ for (i = 0 ; len && i < spill->len ; i++) {
+ *buffer++ = spill->dword[i];
+ len--;
+ spill->len--;
+ }
+
+ if (spill->len) {
+ memmove(spill->dword, spill->dword + i, spill->len);
+ return;
+ }
+
+ while (len >= 4) {
+ *(u32 *)buffer = r592_read_reg_be(
+ dev, R592_FIFO_PIO);
+ buffer += 4;
+ len -= 4;
+ }
+
+ if (!len)
+ return;
+
+ tmp = r592_read_reg_be(dev, R592_FIFO_PIO);
+
+ spill->len = 4;
+ while (len--) {
+ *buffer++ = tmp & 0xFF;
+ tmp >>= 8;
+ spill->len--;
+ }
+
+ for (i = 0 ; i < spill->len ; i++) {
+ spill->dword[i] = tmp & 0xFF;
+ tmp >>= 8;
+ }
+
+ return;
+}
+
+/* Transfers actual data using PIO. */
+static int r592_transfer_fifo_pio(struct r592_device *dev)
+{
+ unsigned char *buffer;
+ struct dword_buffer spill = {{0}, 0};
+ unsigned long flags;
+
+ bool is_write = dev->req->tpc >= MS_TPC_SET_RW_REG_ADRS;
+ int p_len, p_offset, len, offset;
+ struct page *page;
+
+
+ if (!dev->req) {
+ dbg("pio transfer called without request!");
+ return -EINVAL;
+ }
+
+ if (!dev->req->long_data) {
+ if (is_write) {
+ r592_write_fifo_pio(dev, &spill, dev->req->data,
+ dev->req->data_len);
+ r592_write_fifo_pio(dev, &spill, NULL, 0);
+ } else
+ r592_read_fifo_pio(dev, &spill, dev->req->data,
+ dev->req->data_len);
+ return 0;
+ }
+
+ spin_lock_irqsave(&dev->atomic_lock, flags);
+
+ len = dev->req->sg.length;
+ offset = dev->req->sg.offset;
+
+ while (len) {
+
+ p_offset = offset_in_page(offset);
+ p_len = min((int)(PAGE_SIZE - p_offset), len);
+
+ page = nth_page(sg_page(&dev->req->sg), offset >> PAGE_SHIFT);
+ buffer = kmap_atomic(page, KM_BIO_SRC_IRQ) + p_offset;
+
+
+ /* Do the transfer fifo<->memory*/
+ if (is_write)
+ r592_write_fifo_pio(dev, &spill, buffer, p_len);
+ else
+ r592_read_fifo_pio(dev, &spill, buffer, p_len);
+
+ kunmap_atomic(buffer - p_offset, KM_BIO_SRC_IRQ);
+
+ offset += p_len;
+ len -= p_len;
+
+ }
+
+ if (is_write)
+ r592_write_fifo_pio(dev, &spill, NULL, 0);
+
+ spin_unlock_irqrestore(&dev->atomic_lock, flags);
+ return 0;
+}
+
+
+/* Executes one TPC (data is read/written from small or large fifo) */
+static void r592_process_request(struct r592_device *dev)
+{
+ bool is_write = dev->req->tpc >= MS_TPC_SET_RW_REG_ADRS;
+ int len, error;
+ u32 status, reg;
+
+ if (!dev->req) {
+ dbg("r592_process_request with no request!");
+ return;
+ }
+
+ len = dev->req->long_data ?
+ dev->req->sg.length : dev->req->data_len;
+
+ /* Ensure that FIFO can hold the input data */
+ WARN_ON(len > R592_LFIFO_SIZE);
+ if (len > R592_LFIFO_SIZE) {
+ error = -EINVAL;
+ goto out;
+ }
+
+ dbg("executing %s LEN=%d", dbg_tpc_name(dev->req->tpc), len);
+
+
+ /* Set IO direction */
+ if (is_write)
+ r592_set_reg_mask(dev, R592_IO, R592_IO_DIRECTION);
+ else
+ r592_clear_reg_mask(dev, R592_IO, R592_IO_DIRECTION);
+
+
+ error = r592_wait_fifo_empty(dev);
+ if (error)
+ goto out;
+
+ /* Transfer write data */
+ if (is_write) {
+ error = r592_transfer_fifo_dma(dev);
+ if (error)
+ error = r592_transfer_fifo_pio(dev);
+ }
+
+ if (error)
+ goto out;
+
+ /* Trigger the TPC */
+ reg = (len << R592_TPC_EXEC_LEN_SHIFT) |
+ (dev->req->tpc << R592_TPC_EXEC_TPC_SHIFT) |
+ R592_TPC_EXEC_BIG_FIFO;
+
+ r592_write_reg(dev, R592_TPC_EXEC, reg);
+
+ /* Wait for TPC completion */
+ status = R592_STATUS_RDY;
+ if (dev->req->need_card_int)
+ status |= R592_STATUS_CED;
+
+ error = r592_reg_wait(dev, R592_STATUS, status, status);
+ if (error) {
+ dbg("card didn't respond");
+ goto out;
+ }
+
+ /* Test IO errors */
+ error = r592_test_io_error(dev);
+ if (error)
+ goto out;
+
+ /* Read data from FIFO */
+ if (!is_write) {
+ error = r592_transfer_fifo_dma(dev);
+
+ if (error)
+ error = r592_transfer_fifo_pio(dev);
+ }
+
+ /* read INT reg. This can be shortened with shifts, but that way
+ its more readable */
+ if (dev->parallel_mode && dev->req->need_card_int) {
+
+ dev->req->int_reg = 0;
+ status = r592_read_reg(dev, R592_STATUS);
+
+ if (status & R592_STATUS_P_CMDNACK)
+ dev->req->int_reg |= MEMSTICK_INT_CMDNAK;
+
+ if (status & R592_STATUS_P_BREQ)
+ dev->req->int_reg |= MEMSTICK_INT_BREQ;
+
+ if (status & R592_STATUS_P_INTERR)
+ dev->req->int_reg |= MEMSTICK_INT_ERR;
+
+ if (status & R592_STATUS_P_CED)
+ dev->req->int_reg |= MEMSTICK_INT_CED;
+ }
+out:
+ dev->req->error = error;
+ r592_clear_reg_mask(dev, R592_REG_MSC, R592_REG_MSC_LED);
+ return;
+}
+
+/* Main request processing thread */
+static int r592_process_thread(void *data)
+{
+ int error;
+ struct r592_device *dev = (struct r592_device *)data;
+
+ while (!kthread_should_stop()) {
+
+ try_to_freeze();
+ set_current_state(TASK_INTERRUPTIBLE);
+ error = memstick_next_req(dev->host, &dev->req);
+
+ if (error) {
+
+ if (error == -EAGAIN) {
+ dbg_verbose("IO: end of data, sleeping now");
+ } else {
+ dbg("IO: unknown error from "
+ "memstick_next_req %d", error);
+ }
+
+ schedule();
+ } else {
+ set_current_state(TASK_RUNNING);
+ dbg_verbose("IO: got request, processing it");
+ r592_process_request(dev);
+ if (dev->req->error)
+ r592_reset(dev);
+ }
+ }
+
+ return 0;
+}
+
+/* Reprogram chip to detect change in card state */
+/* eg, if card is detected, arm it to detect removal, and vice versa */
+static void r592_update_card_detect(struct r592_device *dev, bool enable)
+{
+ u32 reg = r592_read_reg(dev, R592_REG_MSC);
+ bool card_detected = reg & R592_REG_MSC_PRSNT;
+
+ dbg("update card detect. Card state: %s", card_detected ?
+ "present" : "absent");
+
+ reg &= ~(R592_REG_MSC_IRQ_REMOVE | R592_REG_MSC_IRQ_INSERT);
+
+ if (enable) {
+ if (card_detected)
+ reg |= (R592_REG_MSC_IRQ_REMOVE << 16);
+ else
+ reg |= (R592_REG_MSC_IRQ_INSERT << 16);
+ }
+
+ r592_write_reg(dev, R592_REG_MSC, reg);
+}
+
+/* Timer routine that fires 1 second after last card detection event, */
+static void r592_detect_timer(long unsigned int data)
+{
+ struct r592_device *dev = (struct r592_device *)data;
+ r592_update_card_detect(dev, true);
+ memstick_detect_change(dev->host);
+}
+
+/* Interrupt handler */
+static irqreturn_t r592_irq(int irq, void *data)
+{
+ struct r592_device *dev = (struct r592_device *)data;
+ irqreturn_t ret = IRQ_NONE;
+ u32 reg;
+ u16 irq_enable, irq_status;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->irq_lock, flags);
+
+ if (dev->insuspend)
+ goto unlock;
+
+ reg = r592_read_reg(dev, R592_REG_MSC);
+ irq_enable = reg >> 16;
+ irq_status = reg & 0xFFFF;
+
+ /* Ack the interrupts */
+ reg &= ~irq_status;
+ r592_write_reg(dev, R592_REG_MSC, reg);
+
+ /* Get the IRQ status minus bits that aren't enabled */
+ irq_status & (irq_enable);
+
+ /* Due to limitation of memstick core, we don't look at bits that
+ indicate that card was removed/inserted and/or present */
+ if (irq_status & (R592_REG_MSC_IRQ_INSERT | R592_REG_MSC_IRQ_REMOVE)) {
+
+ ret = IRQ_HANDLED;
+
+ message("IRQ: card %s", irq_status & R592_REG_MSC_IRQ_INSERT ?
+ "added" : "removed");
+
+ /* Ack the interrupt */
+ r592_clear_reg_mask(dev, R592_REG_MSC, R592_REG_MSC_IRQ_INSERT |
+ R592_REG_MSC_IRQ_REMOVE);
+
+ mod_timer(&dev->detect_timer, jiffies + msecs_to_jiffies(500));
+ goto unlock;
+ }
+
+ if (irq_status &
+ (R592_REG_MSC_FIFO_DMA_DONE | R592_REG_MSC_FIFO_DMA_ERR)) {
+ ret = IRQ_HANDLED;
+
+ if (irq_status & R592_REG_MSC_FIFO_DMA_ERR) {
+ dbg("IRQ: DMA error");
+ r592_stop_dma(dev, -EIO);
+ } else {
+ dbg_verbose("IRQ: dma done");
+ r592_stop_dma(dev, 0);
+ }
+
+ complete(&dev->dma_done);
+ goto unlock;
+ }
+
+
+ dbg("got unhandled IRQ status = %x", reg);
+unlock:
+ spin_unlock_irqrestore(&dev->irq_lock, flags);
+ return ret;
+}
+
+/* External inteface: set settings */
+static int r592_set_param(struct memstick_host *host,
+ enum memstick_param param,
+ int value)
+{
+ struct r592_device *dev = memstick_priv(host);
+
+ switch (param) {
+ case MEMSTICK_POWER:
+ switch (value) {
+ case MEMSTICK_POWER_ON:
+ r592_enable_device(dev, true);
+ break;
+ case MEMSTICK_POWER_OFF:
+ r592_enable_device(dev, false);
+ break;
+ default:
+ return -EINVAL;
+ }
+ break;
+ case MEMSTICK_INTERFACE:
+ switch (value) {
+ case MEMSTICK_SERIAL:
+ r592_set_mode(dev, 0);
+ dev->parallel_mode = 0;
+ dev->host->caps &= ~MEMSTICK_CAP_AUTO_GET_INT;
+ break;
+ case MEMSTICK_PAR4:
+ r592_set_mode(dev, 1);
+ dev->host->caps |= MEMSTICK_CAP_AUTO_GET_INT;
+ dev->parallel_mode = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/* External interface: submit requests */
+static void r592_submit_req(struct memstick_host *host)
+{
+ struct r592_device *dev = memstick_priv(host);
+
+ dbg("new request from user");
+ wake_up_process(dev->io_thread);
+ dbg("woke IO thread...");
+}
+
+
+static const struct pci_device_id r592_pci_id_tbl[] = {
+
+ { PCI_VDEVICE(RICOH, 0x0592), },
+ { },
+};
+
+/* Main entry */
+int r592_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ int error = -ENOMEM;
+ struct memstick_host *host;
+ struct r592_device *dev;
+
+ /* Allocate memory */
+ host = memstick_alloc_host(sizeof(struct r592_device), &pdev->dev);
+ if (!host)
+ goto error1;
+
+ dev = memstick_priv(host);
+ dev->host = host;
+ dev->pci_dev = pdev;
+ pci_set_drvdata(pdev, dev);
+
+
+ /* pci initialization */
+ error = pci_enable_device(pdev);
+ if (error)
+ goto error2;
+
+ pci_set_master(pdev);
+ error = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+ if (error)
+ goto error3;
+
+ error = pci_request_regions(pdev, DRV_NAME);
+ if (error)
+ goto error3;
+
+ dev->mmio = pci_ioremap_bar(pdev, 0);
+ if (!dev->mmio)
+ goto error4;
+
+
+ dev->irq = pdev->irq;
+ spin_lock_init(&dev->irq_lock);
+ spin_lock_init(&dev->atomic_lock);
+ init_completion(&dev->dma_done);
+ setup_timer(&dev->detect_timer,
+ r592_detect_timer, (long unsigned int)dev);
+
+ /* Host initialization */
+ host->caps = MEMSTICK_CAP_PAR4;
+ host->request = r592_submit_req;
+ host->set_param = r592_set_param;
+ r592_check_dma(dev);
+
+
+ dev->io_thread = kthread_run(r592_process_thread, dev, "r592");
+ if (IS_ERR(dev->io_thread)) {
+ error = PTR_ERR(dev->io_thread);
+ goto error5;
+ }
+
+ /* This is just a precation, so don't fail */
+ dev->scrath_dma_page = dma_alloc_from_coherent(pdev->dev, PAGE_SIZE,
+ &dev->scrath_dma_page_physical_address, &error);
+
+ if (error) {
+ dev->scrath_dma_page = NULL;
+ dev->scrath_dma_page_physical_address = 0;
+ }
+ r592_stop_dma(dev , 0);
+
+
+ if (request_irq(dev->irq, &r592_irq, IRQF_SHARED,
+ DRV_NAME, dev))
+ goto error6;
+
+ r592_update_card_detect(dev, true);
+ if (memstick_add_host(host))
+ goto error7;
+
+ message("driver succesfully loaded");
+ return 0;
+error7:
+ free_irq(dev->irq, dev);
+error6:
+ if (dev->scrath_dma_page)
+ dma_free_coherent(&pdev->dev, PAGE_SIZE, dev->scrath_dma_page,
+ dev->scrath_dma_page_physical_address);
+ kthread_stop(dev->io_thread);
+error5:
+ iounmap(dev->mmio);
+error4:
+ pci_release_regions(pdev);
+error3:
+ pci_disable_device(pdev);
+error2:
+ memstick_free_host(host);
+error1:
+ return error;
+}
+
+
+void r592_remove(struct pci_dev *pdev)
+{
+ int error = 0;
+ struct r592_device *dev = pci_get_drvdata(pdev);
+
+ /* Stop the processing thread.
+ That ensures that we don't take more requests */
+ kthread_stop(dev->io_thread);
+
+ while (!error && dev->req) {
+ dev->req->error = -ETIME;
+ error = memstick_next_req(dev->host, &dev->req);
+ }
+ memstick_remove_host(dev->host);
+
+ free_irq(dev->irq, dev);
+ iounmap(dev->mmio);
+ pci_release_regions(pdev);
+ pci_disable_device(pdev);
+ memstick_free_host(dev->host);
+
+ if (dev->scrath_dma_page)
+ dma_free_coherent(&pdev->dev, PAGE_SIZE, dev->scrath_dma_page,
+ dev->scrath_dma_page_physical_address);
+
+}
+
+int r592_suspend(struct device *core_dev)
+{
+ struct pci_dev *pdev = to_pci_dev(core_dev);
+ struct r592_device *dev = pci_get_drvdata(pdev);
+ unsigned long flags;
+
+ memstick_suspend_host(dev->host);
+
+ spin_lock_irqsave(&dev->irq_lock, flags);
+ dev->insuspend = 1;
+ spin_unlock_irqrestore(&dev->irq_lock, flags);
+ synchronize_irq(dev->irq);
+
+ r592_stop_dma(dev, -ETIME);
+ r592_update_card_detect(dev, false);
+ del_timer_sync(&dev->detect_timer);
+ return 0;
+}
+
+int r592_resume(struct device *core_dev)
+{
+ unsigned long flags;
+ struct pci_dev *pdev = to_pci_dev(core_dev);
+ struct r592_device *dev = pci_get_drvdata(pdev);
+
+ spin_lock_irqsave(&dev->irq_lock, flags);
+ dev->insuspend = 0;
+ spin_unlock_irqrestore(&dev->irq_lock, flags);
+ r592_update_card_detect(dev, true);
+
+ memstick_resume_host(dev->host);
+ return 0;
+}
+
+
+SIMPLE_DEV_PM_OPS(r592_pm_ops, r592_suspend, r592_resume);
+MODULE_DEVICE_TABLE(pci, r592_pci_id_tbl);
+
+
+static struct pci_driver r852_pci_driver = {
+ .name = DRV_NAME,
+ .id_table = r592_pci_id_tbl,
+ .probe = r592_probe,
+ .remove = r592_remove,
+ .driver.pm = &r592_pm_ops,
+};
+
+static __init int r592_module_init(void)
+{
+ return pci_register_driver(&r852_pci_driver);
+}
+
+static void __exit r592_module_exit(void)
+{
+ pci_unregister_driver(&r852_pci_driver);
+}
+
+module_init(r592_module_init);
+module_exit(r592_module_exit);
+
+
+module_param(enable_dma, bool, S_IRUGO);
+MODULE_PARM_DESC(enable_dma, "Enable usage of the DMA (default)");
+module_param(debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, "Debug level (0-2)");
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Maxim Levitsky <[email protected]>");
+MODULE_DESCRIPTION("Ricoh R5C592 Memstick/Memstick PRO card reader driver");
diff --git a/drivers/memstick/host/r592.h b/drivers/memstick/host/r592.h
new file mode 100644
index 0000000..05c8da9
--- /dev/null
+++ b/drivers/memstick/host/r592.h
@@ -0,0 +1,178 @@
+/*
+ * Copyright (C) 2010 - Maxim Levitsky
+ * driver for Ricoh memstick readers
+ *
+ * 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/memstick.h>
+#include <linux/spinlock.h>
+#include <linux/interrupt.h>
+#include <linux/workqueue.h>
+#include <linux/ctype.h>
+
+
+
+/* write to this reg (number,len) triggers TPC execution */
+#define R592_TPC_EXEC 0x00
+#define R592_TPC_EXEC_LEN_SHIFT 16 /* Bits 16..25 are TPC len */
+#define R592_TPC_EXEC_BIG_FIFO (1 << 26) /* If bit 26 is set, large fifo is used (reg 48) */
+#define R592_TPC_EXEC_TPC_SHIFT 28 /* Bits 28..31 are the TPC number */
+
+
+/* Window for small TPC fifo (big endian)*/
+/* reads and writes always are done in 8 byte chunks */
+/* Not used in driver, because large fifo does better job */
+#define R592_SFIFO 0x08
+
+
+/* Status register (ms int, small fifo, IO)*/
+#define R592_STATUS 0x10
+ /* Parallel INT bits */
+#define R592_STATUS_P_CMDNACK (1 << 16) /* INT reg: NACK (parallel mode) */
+#define R592_STATUS_P_BREQ (1 << 17) /* INT reg: card ready (parallel mode)*/
+#define R592_STATUS_P_INTERR (1 << 18) /* INT reg: int error (parallel mode)*/
+#define R592_STATUS_P_CED (1 << 19) /* INT reg: command done (parallel mode) */
+
+ /* Fifo status */
+#define R592_STATUS_SFIFO_FULL (1 << 20) /* Small Fifo almost full (last chunk is written) */
+#define R592_STATUS_SFIFO_EMPTY (1 << 21) /* Small Fifo empty */
+
+ /* Error detection via CRC */
+#define R592_STATUS_SEND_ERR (1 << 24) /* Send failed */
+#define R592_STATUS_RECV_ERR (1 << 25) /* Recieve failed */
+
+ /* Card state */
+#define R592_STATUS_RDY (1 << 28) /* RDY signal recieved */
+#define R592_STATUS_CED (1 << 29) /* INT: Command done (serial mode)*/
+#define R592_STATUS_SFIFO_INPUT (1 << 30) /* Small fifo recieved data*/
+
+
+#define R592_SFIFO_SIZE 32 /* total size of small fifo is 32 bytes */
+#define R592_SFIFO_PACKET 8 /* packet size of small fifo */
+
+/* IO control */
+#define R592_IO 0x18
+ /* 5 */
+#define R592_IO_16 (1 << 16) /* Set by default, can be cleared */
+#define R592_IO_18 (1 << 18) /* Set by default, can be cleared */
+ /* 5 */
+#define R592_IO_SERIAL1 (1 << 20) /* Set by default, can be cleared, (cleared on parallel) */
+#define R592_IO_22 (1 << 22) /* Set by default, can be cleared */
+ /* 4 or 5*/
+#define R592_IO_DIRECTION (1 << 24) /* TPC direction (1 write 0 read) */
+#define R592_IO_26 (1 << 26) /* Set by default, can be cleared */
+ /* 4 8, or C*/
+#define R592_IO_SERIAL2 (1 << 30) /* Set by default, can be cleared (cleared on parallel), serial doesn't work if unset */
+#define R592_IO_RESET (1 << 31) /* Reset, sets defaults*/
+
+
+/* Unknown register 1 (enables internal blocks ???)*/
+#define R592_REG32 0x20 /* bits 0-7 writeable */
+#define R592_REG32_0 (1 << 0) /* set on start, cleared on stop - must be set*/
+#define R592_REG32_1 (1 << 1) /* set on start, cleared on stop - must be set*/
+#define R592_REG32_3 (1 << 3) /* must be clear */
+#define R592_REG32_20 (1 << 5) /* set before switch to parallel */
+
+/* Unknown register (clock control???)*/
+#define R592_REG36 0x24
+#define R592_REG36_0 (1 << 0) /* set on init, never reset (enable clock engine???)*/
+#define R592_REG36_1 (1 << 1) /* set after switch to parallel (fast clock??)*/
+
+
+/* IRQ,card detection,large fifo (first word irq status, second enable) */
+/* IRQs are ACKed by clearing the bits */
+#define R592_REG_MSC 0x28
+#define R592_REG_MSC_PRSNT (1 << 1) /* card present (only status)*/
+#define R592_REG_MSC_IRQ_INSERT (1 << 8) /* detect insert / card insered */
+#define R592_REG_MSC_IRQ_REMOVE (1 << 9) /* detect removal / card removed */
+#define R592_REG_MSC_FIFO_EMPTY (1 << 10) /* fifo is empty */
+#define R592_REG_MSC_FIFO_DMA_DONE (1 << 11) /* dma enable / dma done */
+
+#define R592_REG_MSC_FIFO_USER_ORN (1 << 12) /* set if software reads empty fifo (if R592_REG_MSC_FIFO_EMPTY is set) */
+#define R592_REG_MSC_FIFO_MISMATH (1 << 13) /* set if amount of data in fifo doesn't match amount in TPC */
+#define R592_REG_MSC_FIFO_DMA_ERR (1 << 14) /* IO failure */
+#define R592_REG_MSC_LED (1 << 15) /* clear to turn led off (only status)*/
+
+#define DMA_IRQ_ACK_MASK (R592_REG_MSC_FIFO_DMA_DONE | R592_REG_MSC_FIFO_DMA_ERR)
+#define DMA_IRQ_EN_MASK (DMA_IRQ_ACK_MASK << 16)
+
+/* DMA address for large FIFO read/writes*/
+#define R592_FIFO_DMA 0x2C
+
+/* PIO access to large FIFO (512 bytes) (big endian)*/
+#define R592_FIFO_PIO 0x30
+#define R592_LFIFO_SIZE 512 /* large fifo size */
+
+
+/* large FIFO DMA settings */
+#define R592_FIFO_DMA_SETTINGS 0x34
+#define R592_FIFO_DMA_SETTINGS_EN (1 << 0) /* DMA enabled */
+#define R592_FIFO_DMA_SETTINGS_DIR (1 << 1) /* Dma direction (1 read, 0 write) */
+#define R592_FIFO_DMA_SETTINGS_CAP (1 << 24) /* Dma is aviable */
+
+
+/* Maybe just an delay */
+/* Bits 17..19 are just number */
+/* bit 16 is set, then bit 20 is waited */
+/* time to wait is about 50 spins * 2 ^ (bits 17..19) */
+/* seems to be possible just to ignore */
+#define R592_REG56 0x38
+#define R592_REG56_START (1 << 16) /* Start bit */
+#define R592_REG56_WAIT (1 << 20) /* HW set this after the delay */
+
+/* Scrach register, written (0xABCD00) when error happens - not used*/
+#define R592_REG_DEBUG 0x3C
+
+struct r592_device {
+ struct pci_dev *pci_dev;
+ struct memstick_host *host; /* host backpointer */
+ struct memstick_request *req; /* current request */
+
+ /* Registers, IRQ */
+ void __iomem *mmio;
+ int irq;
+ int insuspend;
+ spinlock_t irq_lock;
+ struct timer_list detect_timer;
+
+
+ struct task_struct *io_thread;
+ bool parallel_mode;
+
+
+ /* DMA area */
+ int dma_capable;
+ int dma_error;
+ struct completion dma_done;
+ void *scrath_dma_page;
+ u32 scrath_dma_page_physical_address;
+ spinlock_t atomic_lock; /* used to enter atomic mode only in PIO */
+};
+
+
+struct dword_buffer {
+ unsigned char dword[4];
+ unsigned char len;
+};
+
+
+#define DRV_NAME "r592"
+
+
+#define dbg(format, ...) \
+ if (debug) \
+ printk(KERN_DEBUG DRV_NAME ": " format "\n", ## __VA_ARGS__)
+
+#define dbg_verbose(format, ...) \
+ if (debug > 1) \
+ printk(KERN_DEBUG DRV_NAME ": " format "\n", ## __VA_ARGS__)
+
+#define dbg_reg(format, ...) \
+ if (debug > 2) \
+ printk(KERN_DEBUG DRV_NAME ": " format "\n", ## __VA_ARGS__)
+
+#define message(format, ...) \
+ printk(KERN_INFO DRV_NAME ": " format "\n", ## __VA_ARGS__)
--
1.7.0.4
I see two immediate problems with this patch:
1. On cosmetic level, custom debug macros should not be employed. Device
core already have this functionality (dynamic debug levels and such). Please,
use dev_dbg and friends for print-outs.
2. On a structural level, I'd rather prefer host drivers to not start their
own threads. If you look at both current host implementations, they operate
in callback fashion. Apart from saving some resources, this reduces the
amount of problems encountered during suspend/resume and shutdown.
--- On Tue, 3/8/10, Maxim Levitsky <[email protected]> wrote:
> Now that del_gendisk syncs, we better
> start rejecting requests right away.
I don't quite see why this change is needed. My understanding is, user
accessible interface should be marked as removed as early, as possible.
>
> Signed-off-by: Maxim Levitsky <[email protected]>
> ---
> drivers/memstick/core/mspro_block.c |? ? 5
> +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/memstick/core/mspro_block.c
> b/drivers/memstick/core/mspro_block.c
> index 8327e24..8d27c13 100644
> --- a/drivers/memstick/core/mspro_block.c
> +++ b/drivers/memstick/core/mspro_block.c
> @@ -1330,13 +1330,14 @@ static void
> mspro_block_remove(struct memstick_dev *card)
> ??? struct mspro_block_data *msb =
> memstick_get_drvdata(card);
> ??? unsigned long flags;
>
> -??? del_gendisk(msb->disk);
> -??? dev_dbg(&card->dev, "mspro block
> remove\n");
> ??? spin_lock_irqsave(&msb->q_lock,
> flags);
> ??? msb->eject = 1;
> ??? blk_start_queue(msb->queue);
> ???
> spin_unlock_irqrestore(&msb->q_lock, flags);
>
> +??? del_gendisk(msb->disk);
> +??? dev_dbg(&card->dev, "mspro block
> remove\n");
> +
> ??? blk_cleanup_queue(msb->queue);
> ??? msb->queue = NULL;
>
> --
> 1.7.0.4
>
>
On Wed, 2010-08-04 at 00:57 -0700, Alex Dubov wrote:
> I see two immediate problems with this patch:
>
> 1. On cosmetic level, custom debug macros should not be employed. Device
> core already have this functionality (dynamic debug levels and such). Please,
> use dev_dbg and friends for print-outs.
This allows much easier control for debug.
Single module parameter is enough to adjust it.
This helps me help users.
(Eg, kernel compilation is out of question)
>
> 2. On a structural level, I'd rather prefer host drivers to not start their
> own threads. If you look at both current host implementations, they operate
> in callback fashion. Apart from saving some resources, this reduces the
> amount of problems encountered during suspend/resume and shutdown.
This isn't possible.
Hardware doesn't support interrupts on memstick bus changes, it only
supports DMA done from/to internal FIFO, and DMA it only possible for
512 byte TPCs.
Best regards,
Maxim Levitsky
On Wed, 2010-08-04 at 00:50 -0700, Alex Dubov wrote:
> --- On Tue, 3/8/10, Maxim Levitsky <[email protected]> wrote:
>
> > Now that del_gendisk syncs, we better
> > start rejecting requests right away.
>
>
> I don't quite see why this change is needed. My understanding is, user
> accessible interface should be marked as removed as early, as possible.
The problem here is that del_gendisk, syncs the device.
This is new change, made after you did your drivers.
I have this problem on jMicron too (which otherwise works fine).
PS:
I have a copy of your ms_block.c.
I would would be very happy if you share with me, what problems does it
still have (besides need of trivial port for changes in block system,
because I want to push it upstream too.
I have MS DUO 64M to test it against.
Best regards,
Maxim Levitsky
On Wed, 2010-08-04 at 19:48 +0300, Maxim Levitsky wrote:
> On Wed, 2010-08-04 at 00:57 -0700, Alex Dubov wrote:
> > I see two immediate problems with this patch:
> >
> > 1. On cosmetic level, custom debug macros should not be employed. Device
> > core already have this functionality (dynamic debug levels and such). Please,
> > use dev_dbg and friends for print-outs.
> This allows much easier control for debug.
> Single module parameter is enough to adjust it.
> This helps me help users.
> (Eg, kernel compilation is out of question)
>
>
> >
> > 2. On a structural level, I'd rather prefer host drivers to not start their
> > own threads. If you look at both current host implementations, they operate
> > in callback fashion. Apart from saving some resources, this reduces the
> > amount of problems encountered during suspend/resume and shutdown.
> This isn't possible.
> Hardware doesn't support interrupts on memstick bus changes, it only
> supports DMA done from/to internal FIFO, and DMA it only possible for
> 512 byte TPCs.
>
Another question.
I see that current code ignores MEMSTICK_CAP_AUTO_GET_INT
Instread mspro_blk.c enables this capability for parallel mode, assuming
that hw supports it. Its true in my case, but might not be true in other
cases.
I think I should fix that, right?
Also I see that you bath TPC_READ_LONG_DATA/TPC_READ_LONG_DATA
Does that mean that every HW sector is larger that 512?
If so, you are doing copy on write, right?
I have small caching in my sm_ftl of last sector. It helps performance a
lot.
Also I want to clarify that the only kind of interrupts supported by hw
(besides usual card detection interrupt), is DMA done interrupt.
Thats why I have to use thread.
Doing polling in r592_submit_req (which runs in atomic context is just
cruel).
Besides, under moderate IO load, the IO thread doesn't sleep, thus there
is no overhead of wake/sleep.
Best regards,
Maxim Levitsky
On Wed, 2010-08-04 at 19:53 +0300, Maxim Levitsky wrote:
> On Wed, 2010-08-04 at 00:50 -0700, Alex Dubov wrote:
> > --- On Tue, 3/8/10, Maxim Levitsky <[email protected]> wrote:
> >
> > > Now that del_gendisk syncs, we better
> > > start rejecting requests right away.
> >
> >
> > I don't quite see why this change is needed. My understanding is, user
> > accessible interface should be marked as removed as early, as possible.
>
> The problem here is that del_gendisk, syncs the device.
> This is new change, made after you did your drivers.
>
> I have this problem on jMicron too (which otherwise works fine).
The problem is that card check thread explicitly calls ->stop before
removing the device.
In case of mspro_blk.c that stops the request queue.
Attempt to call del_gendisk with stopped request queue hangs due to
syncing.
>
>
> PS:
>
> I have a copy of your ms_block.c.
> I would would be very happy if you share with me, what problems does it
> still have (besides need of trivial port for changes in block system,
> because I want to push it upstream too.
>
> I have MS DUO 64M to test it against.
>
>
Best regards,
Maxim Levitsky
> Maxim Levitsky wrote:
> > On Wed, 2010-08-04 at 00:57 -0700, Alex Dubov wrote:
> > > I see two immediate problems with this patch:
> > >
> > > 1. On cosmetic level, custom debug macros should
> not be employed. Device
> > > core already have this functionality (dynamic
> debug levels and such). Please,
> > > use dev_dbg and friends for print-outs.
> > This allows much easier control for debug.
> > Single module parameter is enough to adjust it.
> > This helps me help users.
> > (Eg, kernel compilation is out of question)
I doubt it will be that useful, but it's not my call to make anyway.
> >
> >
> > >
> > > 2. On a structural level, I'd rather prefer host
> drivers to not start their
> > > own threads. If you look at both current host
> implementations, they operate
> > > in callback fashion. Apart from saving some
> resources, this reduces the
> > > amount of problems encountered during
> suspend/resume and shutdown.
> > This isn't possible.
> > Hardware doesn't support interrupts on memstick bus
> changes, it only
> > supports DMA done from/to internal FIFO, and DMA it
> only possible for
> > 512 byte TPCs.
> >
>
How depressing.
>
> Another question.
>
> I see that current code ignores MEMSTICK_CAP_AUTO_GET_INT
> Instread mspro_blk.c enables this capability for parallel
> mode, assuming
> that hw supports it. Its true in my case, but might not be
> true in other
> cases.
> I think I should fix that, right?
This is mandated by the spec. INT should be available automatically in
parallel mode, and some hardware does it in serial as well.
>
> Also I see that you bath
> TPC_READ_LONG_DATA/TPC_READ_LONG_DATA
> Does that mean that every HW sector is larger that 512?
> If so, you are doing copy on write, right?
> I have small caching in my sm_ftl of last sector. It helps
> performance a
> lot.
That's how its called in the spec.
Sectors can be larger than 512b on Pro-HG sticks, and there's additional
TPC_READ/WRITE_QUAD_DATA which operates on larger quantities.
>
>
> Also I want to clarify that the only kind of interrupts
> supported by hw
> (besides usual card detection interrupt), is DMA done
> interrupt.
> Thats why I have to use thread.
> Doing polling in r592_submit_req (which runs in atomic
> context is just
> cruel).
Yes, I see you have a timed wait there.
> Besides, under moderate IO load, the IO thread doesn't
> sleep, thus there
> is no overhead of wake/sleep.
>
>
> Best regards,
> Maxim Levitsky
>
>
> From: Maxim Levitsky <[email protected]>
> Subject: Re: [PATCH 1/2] MEMSTICK: fix hangs on unexpected device removal in mspro_blk
> > >
> > > > Now that del_gendisk syncs, we better
> > > > start rejecting requests right away.
> > >
> > >
> > > I don't quite see why this change is needed. My
> understanding is, user
> > > accessible interface should be marked as removed
> as early, as possible.
> >
> > The problem here is that del_gendisk, syncs the
> device.
> > This is new change, made after you did your drivers.
> >
> > I have this problem on jMicron too (which otherwise
> works fine).
> The problem is that card check thread explicitly calls
> ->stop before
> removing the device.
> In case of mspro_blk.c that stops the request queue.
> Attempt to call del_gendisk with stopped request queue
> hangs due to
> syncing.
Well, ok. Sounds good.
> >
> > I have a copy of your ms_block.c.
> > I would would be very happy if you share with me, what
> problems does it
> > still have (besides need of trivial port for changes
> in block system,
> > because I want to push it upstream too.
> >
> > I have MS DUO 64M to test it against.
> >
I've got two rather different implementations of ms_block, if I remember
correctly. Both suffer from random data corruptions, thanks to my
inexplicable desire to write the state machine as tightly, as possible.
Only the later one does the spec mandated geometry correctly - I actually
wrote the first version before I've seen the spec for the first time.
On Thu, 2010-08-05 at 01:30 -0700, Alex Dubov wrote:
> > Maxim Levitsky wrote:
> > > On Wed, 2010-08-04 at 00:57 -0700, Alex Dubov wrote:
> > > > I see two immediate problems with this patch:
> > > >
> > > > 1. On cosmetic level, custom debug macros should
> > not be employed. Device
> > > > core already have this functionality (dynamic
> > debug levels and such). Please,
> > > > use dev_dbg and friends for print-outs.
> > > This allows much easier control for debug.
> > > Single module parameter is enough to adjust it.
> > > This helps me help users.
> > > (Eg, kernel compilation is out of question)
>
> I doubt it will be that useful, but it's not my call to make anyway.
>
>
> > >
> > >
> > > >
> > > > 2. On a structural level, I'd rather prefer host
> > drivers to not start their
> > > > own threads. If you look at both current host
> > implementations, they operate
> > > > in callback fashion. Apart from saving some
> > resources, this reduces the
> > > > amount of problems encountered during
> > suspend/resume and shutdown.
> > > This isn't possible.
> > > Hardware doesn't support interrupts on memstick bus
> > changes, it only
> > > supports DMA done from/to internal FIFO, and DMA it
> > only possible for
> > > 512 byte TPCs.
> > >
> >
>
> How depressing.
>
> >
> > Another question.
> >
> > I see that current code ignores MEMSTICK_CAP_AUTO_GET_INT
> > Instread mspro_blk.c enables this capability for parallel
> > mode, assuming
> > that hw supports it. Its true in my case, but might not be
> > true in other
> > cases.
> > I think I should fix that, right?
>
> This is mandated by the spec. INT should be available automatically in
> parallel mode, and some hardware does it in serial as well.
>
> >
> > Also I see that you bath
> > TPC_READ_LONG_DATA/TPC_READ_LONG_DATA
> > Does that mean that every HW sector is larger that 512?
> > If so, you are doing copy on write, right?
> > I have small caching in my sm_ftl of last sector. It helps
> > performance a
> > lot.
>
>
> That's how its called in the spec.
> Sectors can be larger than 512b on Pro-HG sticks, and there's additional
> TPC_READ/WRITE_QUAD_DATA which operates on larger quantities.
But not on ordinary PRO, right?
Small question, can I use Pro-HG stick in my reader that is designed for
Standard/PRO only? Does your subsystem support it?
8-bit mode really isn't supported here, but it is optional I am sure.
>
> >
> >
> > Also I want to clarify that the only kind of interrupts
> > supported by hw
> > (besides usual card detection interrupt), is DMA done
> > interrupt.
> > Thats why I have to use thread.
> > Doing polling in r592_submit_req (which runs in atomic
> > context is just
> > cruel).
>
> Yes, I see you have a timed wait there.
>
Alex, how should I proceed in merge of my driver?
Do you have any objections against it now?
Best regards,
Maxim Levitsky
> >
> > That's how its called in the spec.
> > Sectors can be larger than 512b on Pro-HG sticks, and
> there's additional
> > TPC_READ/WRITE_QUAD_DATA which operates on larger
> quantities.
> But not on ordinary PRO, right?
Pro sectors are normally 512 bytes.
>
> Small question, can I use Pro-HG stick in my reader that is
> designed for
> Standard/PRO only? Does your subsystem support it?
It should work. It works for me on TI, which has no 8b mode either.
> >
>
> Alex, how should I proceed in merge of my driver?
> Do you have any objections against it now?
>
I may have done a thing or two differently, but otherwise no objection.
I suppose, you should ask Andrew Morton to put it in.
On Thu, 2010-08-05 at 04:48 -0700, Alex Dubov wrote:
> > >
> > > That's how its called in the spec.
> > > Sectors can be larger than 512b on Pro-HG sticks, and
> > there's additional
> > > TPC_READ/WRITE_QUAD_DATA which operates on larger
> > quantities.
> > But not on ordinary PRO, right?
>
> Pro sectors are normally 512 bytes.
>
> >
> > Small question, can I use Pro-HG stick in my reader that is
> > designed for
> > Standard/PRO only? Does your subsystem support it?
>
> It should work. It works for me on TI, which has no 8b mode either.
In that case, is there an upper limit on sector size?
>
> > >
> >
> > Alex, how should I proceed in merge of my driver?
> > Do you have any objections against it now?
> >
>
> I may have done a thing or two differently, but otherwise no objection.
> I suppose, you should ask Andrew Morton to put it in.
Ok, will do.
Best regards,
Maxim Levitsky
On Thu, 2010-08-05 at 01:30 -0700, Alex Dubov wrote:
> > Maxim Levitsky wrote:
> > > On Wed, 2010-08-04 at 00:57 -0700, Alex Dubov wrote:
> > > > I see two immediate problems with this patch:
> > > >
> > > > 1. On cosmetic level, custom debug macros should
> > not be employed. Device
> > > > core already have this functionality (dynamic
> > debug levels and such). Please,
> > > > use dev_dbg and friends for print-outs.
> > > This allows much easier control for debug.
> > > Single module parameter is enough to adjust it.
> > > This helps me help users.
> > > (Eg, kernel compilation is out of question)
>
> I doubt it will be that useful, but it's not my call to make anyway.
>
>
> > >
> > >
> > > >
> > > > 2. On a structural level, I'd rather prefer host
> > drivers to not start their
> > > > own threads. If you look at both current host
> > implementations, they operate
> > > > in callback fashion. Apart from saving some
> > resources, this reduces the
> > > > amount of problems encountered during
> > suspend/resume and shutdown.
> > > This isn't possible.
> > > Hardware doesn't support interrupts on memstick bus
> > changes, it only
> > > supports DMA done from/to internal FIFO, and DMA it
> > only possible for
> > > 512 byte TPCs.
> > >
> >
>
> How depressing.
>
> >
> > Another question.
> >
> > I see that current code ignores MEMSTICK_CAP_AUTO_GET_INT
> > Instread mspro_blk.c enables this capability for parallel
> > mode, assuming
> > that hw supports it. Its true in my case, but might not be
> > true in other
> > cases.
> > I think I should fix that, right?
>
> This is mandated by the spec. INT should be available automatically in
> parallel mode, and some hardware does it in serial as well.
Thinking again about that I agree with you.
Then I can remove 2 more lines from my driver.
Btw, I want to add a callback from driver to card driver to be able to
reset card in case of error (windows driver does that in case of any
error)
I would use most of the mspro_block_resume for the implementation for
mspro.
Any objections, suggestions?
>
> >
> > Also I see that you bath
> > TPC_READ_LONG_DATA/TPC_READ_LONG_DATA
> > Does that mean that every HW sector is larger that 512?
> > If so, you are doing copy on write, right?
> > I have small caching in my sm_ftl of last sector. It helps
> > performance a
> > lot.
>
>
> That's how its called in the spec.
> Sectors can be larger than 512b on Pro-HG sticks, and there's additional
> TPC_READ/WRITE_QUAD_DATA which operates on larger quantities.
>
> >
> >
> > Also I want to clarify that the only kind of interrupts
> > supported by hw
> > (besides usual card detection interrupt), is DMA done
> > interrupt.
> > Thats why I have to use thread.
> > Doing polling in r592_submit_req (which runs in atomic
> > context is just
> > cruel).
>
> Yes, I see you have a timed wait there.
>
>
> > Besides, under moderate IO load, the IO thread doesn't
> > sleep, thus there
> > is no overhead of wake/sleep.
> >
> >
> > Best regards,
> > Maxim Levitsky
> >
Best regards,
Maxim Levitsky
On Thu, 2010-08-05 at 15:30 +0300, Maxim Levitsky wrote:
> On Thu, 2010-08-05 at 04:48 -0700, Alex Dubov wrote:
> > > >
> > > > That's how its called in the spec.
> > > > Sectors can be larger than 512b on Pro-HG sticks, and
> > > there's additional
> > > > TPC_READ/WRITE_QUAD_DATA which operates on larger
> > > quantities.
> > > But not on ordinary PRO, right?
> >
> > Pro sectors are normally 512 bytes.
> >
> > >
> > > Small question, can I use Pro-HG stick in my reader that is
> > > designed for
> > > Standard/PRO only? Does your subsystem support it?
> >
> > It should work. It works for me on TI, which has no 8b mode either.
> In that case, is there an upper limit on sector size?
Also, you don't use the MS_TPC_READ_QUAD_DATA at all.
So mspro_blk.c won't work with >512 bytes/sector disk?
Or there is some compatibility?
Best regards,
Maxim Levitsky
On Thu, 2010-08-05 at 01:43 -0700, Alex Dubov wrote:
> > From: Maxim Levitsky <[email protected]>
> > Subject: Re: [PATCH 1/2] MEMSTICK: fix hangs on unexpected device removal in mspro_blk
> > > >
> > > > > Now that del_gendisk syncs, we better
> > > > > start rejecting requests right away.
> > > >
> > > >
> > > > I don't quite see why this change is needed. My
> > understanding is, user
> > > > accessible interface should be marked as removed
> > as early, as possible.
> > >
> > > The problem here is that del_gendisk, syncs the
> > device.
> > > This is new change, made after you did your drivers.
> > >
> > > I have this problem on jMicron too (which otherwise
> > works fine).
> > The problem is that card check thread explicitly calls
> > ->stop before
> > removing the device.
> > In case of mspro_blk.c that stops the request queue.
> > Attempt to call del_gendisk with stopped request queue
> > hangs due to
> > syncing.
>
> Well, ok. Sounds good.
>
>
> > >
> > > I have a copy of your ms_block.c.
> > > I would would be very happy if you share with me, what
> > problems does it
> > > still have (besides need of trivial port for changes
> > in block system,
> > > because I want to push it upstream too.
> > >
> > > I have MS DUO 64M to test it against.
> > >
>
> I've got two rather different implementations of ms_block, if I remember
> correctly. Both suffer from random data corruptions, thanks to my
> inexplicable desire to write the state machine as tightly, as possible.
> Only the later one does the spec mandated geometry correctly - I actually
> wrote the first version before I've seen the spec for the first time.
By 'spec mandated geometry' you mean the fact the card needs to be
broken into zones, somewhat like XD?
Best regards,
Maxim Levitsky
>
> By 'spec mandated geometry' you mean the fact the card
> needs to be
> broken into zones, somewhat like XD?
>
Yes, and in fancy fashion.
First zone should have at most 494 useful logical blocks, other zones - 496.
16 physical blocks per zone are considered local spares, 2 first blocks in
zone 1 must be identical and contain factory information.
> > > > >
> > > > > That's how its called in the spec.
> > > > > Sectors can be larger than 512b on
> Pro-HG sticks, and
> > > > there's additional
> > > > > TPC_READ/WRITE_QUAD_DATA which operates
> on larger
> > > > quantities.
> > > > But not on ordinary PRO, right?
> > >
> > > Pro sectors are normally 512 bytes.
> > >
> > > >
> > > > Small question, can I use Pro-HG stick in my
> reader that is
> > > > designed for
> > > > Standard/PRO only? Does your subsystem
> support it?
> > >
> > > It should work. It works for me on TI, which has
> no 8b mode either.
> > In that case, is there an upper limit on sector size?
> Also, you don't use the MS_TPC_READ_QUAD_DATA at all.
> So mspro_blk.c won't work with >512 bytes/sector disk?
> Or there is some compatibility?
>
The code can work with arbitrarily sized pages, 512b
value is not hard coded. All that is needed is to slightly alter
h_mspro_block_transfer_data function, given, of course, that adapters
support longer transfer sizes.
>
> Btw, I want to add a callback from driver to card driver to
> be able to
> reset card in case of error (windows driver does that in
> case of any
> error)
>
> I would use most of the mspro_block_resume for the
> implementation for
> mspro.
>
> Any objections, suggestions?
>
Just toggle a power on it. Power off/power on will do the full reset of
the controller and the media. You don't have to reinitialize it, as you
are sure that it's the same stick.
> >
> > >
> > > Small question, can I use Pro-HG stick in my
> reader that is
> > > designed for
> > > Standard/PRO only? Does your subsystem support
> it?
> >
> > It should work. It works for me on TI, which has no 8b
> mode either.
> In that case, is there an upper limit on sector size?
>
Good code has no artificially induced limits. Less than machine page.
On Fri, 2010-08-06 at 00:43 -0700, Alex Dubov wrote:
> > > > > >
> > > > > > That's how its called in the spec.
> > > > > > Sectors can be larger than 512b on
> > Pro-HG sticks, and
> > > > > there's additional
> > > > > > TPC_READ/WRITE_QUAD_DATA which operates
> > on larger
> > > > > quantities.
> > > > > But not on ordinary PRO, right?
> > > >
> > > > Pro sectors are normally 512 bytes.
> > > >
> > > > >
> > > > > Small question, can I use Pro-HG stick in my
> > reader that is
> > > > > designed for
> > > > > Standard/PRO only? Does your subsystem
> > support it?
> > > >
> > > > It should work. It works for me on TI, which has
> > no 8b mode either.
> > > In that case, is there an upper limit on sector size?
> > Also, you don't use the MS_TPC_READ_QUAD_DATA at all.
> > So mspro_blk.c won't work with >512 bytes/sector disk?
> > Or there is some compatibility?
> >
>
> The code can work with arbitrarily sized pages, 512b
> value is not hard coded. All that is needed is to slightly alter
> h_mspro_block_transfer_data function, given, of course, that adapters
> support longer transfer
No, I mean if I go and buy memstick PRO HG, that has > 512 bytes/sector,
will it work with current code?
Btw, there is currently no way of telling core about maximum transfer
length.
Here absolute maximum is 1024 (number of bit that _might_ hold TPC
length), and FIFO size is 512 bytes (maybe its possible to use fifo
twice)
Best regards,
Maxim Levitsky
On Fri, 2010-08-06 at 00:59 -0700, Alex Dubov wrote:
> >
> > Btw, I want to add a callback from driver to card driver to
> > be able to
> > reset card in case of error (windows driver does that in
> > case of any
> > error)
> >
> > I would use most of the mspro_block_resume for the
> > implementation for
> > mspro.
> >
> > Any objections, suggestions?
> >
>
> Just toggle a power on it. Power off/power on will do the full reset of
> the controller and the media. You don't have to reinitialize it, as you
> are sure that it's the same stick.
Yea, but after such reboot, the device will be in serial mode. So, I
will need to send switch TPC to device. My driver doesn't know how to do
that...., so it would be nice to have callback to the core.
Best regards,
Maxim Levitsky
> > >
> > > Btw, I want to add a callback from driver to card
> driver to
> > > be able to
> > > reset card in case of error (windows driver does
> that in
> > > case of any
> > > error)
> > >
> > > I would use most of the mspro_block_resume for
> the
> > > implementation for
> > > mspro.
> > >
> > > Any objections, suggestions?
> > >
> >
> > Just toggle a power on it. Power off/power on will do
> the full reset of
> > the controller and the media. You don't have to
> reinitialize it, as you
> > are sure that it's the same stick.
>
> Yea, but after such reboot, the device will be in serial
> mode. So, I
> will need to send switch TPC to device. My driver doesn't
> know how to do
> that...., so it would be nice to have callback to the
> core.
>
Lets ask a different question: why do you think this
particular functionality is needed at all? Have you encountered any
problems which require it (I haven't, btw)?
Windows drivers do a lot of things, but it does not mean all of them must
be copied literally.
> > > > > > >
> > > > > > > That's how its called in the
> spec.
> > > > > > > Sectors can be larger than
> 512b on
> > > Pro-HG sticks, and
> > > > > > there's additional
> > > > > > > TPC_READ/WRITE_QUAD_DATA
> which operates
> > > on larger
> > > > > > quantities.
> > > > > > But not on ordinary PRO, right?
> > > > >
> > > > > Pro sectors are normally 512 bytes.
> > > > >
> > > > > >
> > > > > > Small question, can I use Pro-HG
> stick in my
> > > reader that is
> > > > > > designed for
> > > > > > Standard/PRO only? Does your
> subsystem
> > > support it?
> > > > >
> > > > > It should work. It works for me on TI,
> which has
> > > no 8b mode either.
> > > > In that case, is there an upper limit on
> sector size?
> > > Also, you don't use the MS_TPC_READ_QUAD_DATA at
> all.
> > > So mspro_blk.c won't work with >512
> bytes/sector disk?
> > > Or there is some compatibility?
> > >
> >
> > The code can work with arbitrarily sized pages, 512b
> > value is not hard coded. All that is needed is to
> slightly alter
> > h_mspro_block_transfer_data function, given, of
> course, that adapters
> > support longer transfer
>
> No, I mean if I go and buy memstick PRO HG, that has >
> 512 bytes/sector,
> will it work with current code?
>
> Btw, there is currently no way of telling core about
> maximum transfer
> length.
> Here absolute maximum is 1024 (number of bit that _might_
> hold TPC
> length), and FIFO size is 512 bytes (maybe its possible to
> use fifo
> twice)
>
On TI adapters, FIFO can be reused and DMA restarted. Jmicron adapters are
funny beasts, but their team is keen to support MSpro-HG, so at some
point it will be fully possible, though, probably, not with every version
of the chipset.
On Sat, 2010-08-07 at 06:15 -0700, Alex Dubov wrote:
> > > > > > > >
> > > > > > > > That's how its called in the
> > spec.
> > > > > > > > Sectors can be larger than
> > 512b on
> > > > Pro-HG sticks, and
> > > > > > > there's additional
> > > > > > > > TPC_READ/WRITE_QUAD_DATA
> > which operates
> > > > on larger
> > > > > > > quantities.
> > > > > > > But not on ordinary PRO, right?
> > > > > >
> > > > > > Pro sectors are normally 512 bytes.
> > > > > >
> > > > > > >
> > > > > > > Small question, can I use Pro-HG
> > stick in my
> > > > reader that is
> > > > > > > designed for
> > > > > > > Standard/PRO only? Does your
> > subsystem
> > > > support it?
> > > > > >
> > > > > > It should work. It works for me on TI,
> > which has
> > > > no 8b mode either.
> > > > > In that case, is there an upper limit on
> > sector size?
> > > > Also, you don't use the MS_TPC_READ_QUAD_DATA at
> > all.
> > > > So mspro_blk.c won't work with >512
> > bytes/sector disk?
> > > > Or there is some compatibility?
> > > >
> > >
> > > The code can work with arbitrarily sized pages, 512b
> > > value is not hard coded. All that is needed is to
> > slightly alter
> > > h_mspro_block_transfer_data function, given, of
> > course, that adapters
> > > support longer transfer
> >
> > No, I mean if I go and buy memstick PRO HG, that has >
> > 512 bytes/sector,
> > will it work with current code?
> >
> > Btw, there is currently no way of telling core about
> > maximum transfer
> > length.
> > Here absolute maximum is 1024 (number of bit that _might_
> > hold TPC
> > length), and FIFO size is 512 bytes (maybe its possible to
> > use fifo
> > twice)
> >
>
> On TI adapters, FIFO can be reused and DMA restarted. Jmicron adapters are
> funny beasts, but their team is keen to support MSpro-HG, so at some
> point it will be fully possible, though, probably, not with every version
> of the chipset.
>
I still need an answer for whether HG sticks need MS_TPC_READ_QUAD_DATA
to be used.
But anyway, I buy a HG stick and see how it works.
Best regards,
Maxim Levitsky
On Sat, 2010-08-07 at 06:12 -0700, Alex Dubov wrote:
> > > >
> > > > Btw, I want to add a callback from driver to card
> > driver to
> > > > be able to
> > > > reset card in case of error (windows driver does
> > that in
> > > > case of any
> > > > error)
> > > >
> > > > I would use most of the mspro_block_resume for
> > the
> > > > implementation for
> > > > mspro.
> > > >
> > > > Any objections, suggestions?
> > > >
> > >
> > > Just toggle a power on it. Power off/power on will do
> > the full reset of
> > > the controller and the media. You don't have to
> > reinitialize it, as you
> > > are sure that it's the same stick.
> >
> > Yea, but after such reboot, the device will be in serial
> > mode. So, I
> > will need to send switch TPC to device. My driver doesn't
> > know how to do
> > that...., so it would be nice to have callback to the
> > core.
> >
>
> Lets ask a different question: why do you think this
> particular functionality is needed at all? Have you encountered any
> problems which require it (I haven't, btw)?
I would image using this to verify that stick is still in place on I/O
error.
If I just power down/up it, it will loose state, for example IO mode,
reg range, etc...
But anyway, this isn't very important.
Best regards,
Maxim Levitsky
Hi,
I have few more questions about memsticks.
First of all, I need an explanation of overwrite flag.
You already explained it to me once, but I still not sure about few
things.
#define MEMSTICK_OVERWRITE_UDST 0x10
This one I understand, thinking about xD again, I think it is very
handy.
My idea (from xD of course) is that copyonwrite is done this way:
1. read old sector
2. allocate new sector
2. write what was just read to new sector.
3. erase old sector.
Could you explain when I need to set and reset the
MEMSTICK_OVERWRITE_UDST?
#define MEMSTICK_OVERWRITE_PGST1 0x20
#define MEMSTICK_OVERWRITE_PGST0 0x40
I suppose these indicate that page(sector) contains incorrect data, just
like in xD there is page status?
Again, better explanation is welcome.
Also, should I touch that flag when I update sector?
#define MEMSTICK_OVERWRITE_BKST 0x80
This marks bad blocks?
Another question is about write of oob data.
When I write it, overwrite flag is updated, or I need to use
MEMSTICK_CP_OVERWRITE to update it?
I think former is true.
When I write a sector, I just write 0 to management flag, right?
And last question,
If I use MEMSTICK_CP_BLOCK, can I start reading a block from non-zero
page offset?
And surely last question, what is 'MS_CMD_BLOCK_END'
Thanks again for all help so far,
Best regards,
Maxim Levitsky
--- On Sat, 7/8/10, Maxim Levitsky <[email protected]> wrote:
> From: Maxim Levitsky <[email protected]>
> Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader.
> To: "Alex Dubov" <[email protected]>
> Cc: "LKML" <[email protected]>
> Received: Saturday, 7 August, 2010, 8:58 AM
> On Sat, 2010-08-07 at 06:15 -0700,
> Alex Dubov wrote:
> > > > > > > > >
> > > > > > > > > That's how its
> called in the
> > > spec.
> > > > > > > > > Sectors can be
> larger than
> > > 512b on
> > > > > Pro-HG sticks, and
> > > > > > > > there's additional
> > > > > > > > >
> TPC_READ/WRITE_QUAD_DATA
> > > which operates
> > > > > on larger
> > > > > > > > quantities.
> > > > > > > > But not on ordinary PRO,
> right?
> > > > > > >
> > > > > > > Pro sectors are normally 512
> bytes.
> > > > > > >
> > > > > > > >
> > > > > > > > Small question, can I
> use Pro-HG
> > > stick in my
> > > > > reader that is
> > > > > > > > designed for
> > > > > > > > Standard/PRO only? Does
> your
> > > subsystem
> > > > > support it?
> > > > > > >
> > > > > > > It should work. It works for
> me on TI,
> > > which has
> > > > > no 8b mode either.
> > > > > > In that case, is there an upper
> limit on
> > > sector size?
> > > > > Also, you don't use the
> MS_TPC_READ_QUAD_DATA at
> > > all.
> > > > > So mspro_blk.c won't work with >512
> > > bytes/sector disk?
> > > > > Or there is some compatibility?
> > > > >
> > > >
> > > > The code can work with arbitrarily sized
> pages, 512b
> > > > value is not hard coded. All that is needed
> is to
> > > slightly alter
> > > > h_mspro_block_transfer_data function, given,
> of
> > > course, that adapters
> > > > support longer transfer
> > >
> > > No, I mean if I go and buy memstick PRO HG, that
> has >
> > > 512 bytes/sector,
> > > will it work with current code?
> > >
> > > Btw, there is currently no way of telling core
> about
> > > maximum transfer
> > > length.
> > > Here absolute maximum is 1024 (number of bit that
> _might_
> > > hold TPC
> > > length), and FIFO size is 512 bytes (maybe its
> possible to
> > > use fifo
> > > twice)
> > >
> >
> > On TI adapters, FIFO can be reused and DMA restarted.
> Jmicron adapters are
> > funny beasts, but their team is keen to support
> MSpro-HG, so at some
> > point it will be fully possible, though, probably, not
> with every version
> > of the chipset.
> >
>
> I still need an answer for whether HG sticks need
> MS_TPC_READ_QUAD_DATA
> to be used.
No, they work fine with LONG_DATA, at least the ones I tried.
>
> But anyway, I buy a HG stick and see how it works.
This is always a right thing to do.
>
> Best regards,
> Maxim Levitsky
>
>
--- On Sat, 7/8/10, Maxim Levitsky <[email protected]> wrote:
> > > > >
> > > > > Btw, I want to add a callback from
> driver to card
> > > driver to
> > > > > be able to
> > > > > reset card in case of error (windows
> driver does
> > > that in
> > > > > case of any
> > > > > error)
> > > > >
> > > > > I would use most of the
> mspro_block_resume for
> > > the
> > > > > implementation for
> > > > > mspro.
> > > > >
> > > > > Any objections, suggestions?
> > > > >
> > > >
> > > > Just toggle a power on it. Power off/power
> on will do
> > > the full reset of
> > > > the controller and the media. You don't have
> to
> > > reinitialize it, as you
> > > > are sure that it's the same stick.
> > >
> > > Yea, but after such reboot, the device will be in
> serial
> > > mode. So, I
> > > will need to send switch TPC to device. My driver
> doesn't
> > > know how to do
> > > that...., so it would be nice to have callback to
> the
> > > core.
> > >
> >
> > Lets ask a different question: why do you think this
> > particular functionality is needed at all? Have you
> encountered any
> > problems which require it (I haven't, btw)?
>
> I would image using this to verify that stick is still in
> place on I/O
> error.
>
> If I just power? down/up it, it will loose state, for
> example IO mode,
> reg range, etc...
>
> But anyway, this isn't very important.
>
My point was, that problems are better solved as they come.
Windows drivers do a lot of things (like SCSI device emulation), but it
doesn't mean all of them are necessary. Adding code "just because" often
means more work later on.
> Hi,
>
> I have few more questions about memsticks.
>
> First of all, I need an explanation of overwrite flag.
> You already explained it to me once, but I still not sure
> about few
> things.
Overwrite register can be accessed either as part of extra data access
or separately (CP_OVERWRITE access mode).
>
> #define MEMSTICK_OVERWRITE_UDST? 0x10
> This one I understand, thinking about xD again, I think it
> is very
> handy.
>
> My idea (from xD of course) is that copyonwrite is done
> this way:
>
> 1. read old sector
> 2. allocate new sector
> 2. write what was just read to new sector.
> 3. erase old sector.
This is correct.
>
> Could you explain when I need to set and reset the
> MEMSTICK_OVERWRITE_UDST?
UDST flag should be set when you're marking the block for
reallocation during the read/modify/write cycle. You read the existing
physical block, mark it with UDST flag (setting it to zero), then write
different physical block on behalf of the same logical one, then erase the
original block. The UDST flag is supposed to guard against a situation,
whereupon power fails during the write cycle and you're left with two
physical blocks mapped to the same logical one (so the one marked with
zero UDST value is supposedly "known good").
>
>
> #define MEMSTICK_OVERWRITE_PGST1 0x20
> #define MEMSTICK_OVERWRITE_PGST0 0x40
> I suppose these indicate that page(sector) contains
> incorrect data, just
> like in xD there is page status?
> Again, better explanation is welcome.
> Also, should I touch that flag when I update sector?
>
>
>
> #define MEMSTICK_OVERWRITE_BKST? 0x80
> This marks bad blocks?
BKST set to zero indicates that the whole block is bad and shouldn't be
used.
PGST1:0 has several values:
11: default, r/w page
10: reserved value, shouldn't be used
01: page is read-only (soft write-protect)
00: page is accessible, but the value is not guaranteed (faulty page that
sort-of works)
That's what the spec says.
>
>
>
> Another question is about write of oob data.
> When I write it, overwrite flag is updated, or I need to
> use
> MEMSTICK_CP_OVERWRITE to update it?
> I think former is true.
As I mentioned above, it can be accessed either as part of extra data
or separately.
>
> When I write a sector, I just write 0 to management flag,
> right?
You shouldn't touch management_flag at all, as far as I can tell.
It's only used to indicate special purpose blocks, such as factory
written boot blocks, volatile look-up table blocks (for systems with
tight RAM requirements) and DRM marked blocks which I has no info about.
>
>
> And last question,
> If I use MEMSTICK_CP_BLOCK, can I start reading a block
> from non-zero
> page offset?
Yes, it starts from the user specified page address and auto increments it
until the current block end is hit.
>
>
> And surely last question, what is 'MS_CMD_BLOCK_END'
This command is used to terminate the currently ongoing block operation.
If you are using one of the auto-increment modes (with CP_BLOCK set) but
do not want to access all the pages until the block end, you must issue
this command after the desired number of pages is transferred to return
the media's state machine to the initial state. This command never hurts,
as you can guess.
>
>
> Thanks again for all help so far,
>
You're welcome.
On Sun, 2010-08-08 at 07:26 -0700, Alex Dubov wrote:
> > Hi,
> >
> > I have few more questions about memsticks.
> >
> > First of all, I need an explanation of overwrite flag.
> > You already explained it to me once, but I still not sure
> > about few
> > things.
>
> Overwrite register can be accessed either as part of extra data access
> or separately (CP_OVERWRITE access mode).
>
> >
> > #define MEMSTICK_OVERWRITE_UDST 0x10
> > This one I understand, thinking about xD again, I think it
> > is very
> > handy.
> >
> > My idea (from xD of course) is that copyonwrite is done
> > this way:
> >
> > 1. read old sector
> > 2. allocate new sector
> > 2. write what was just read to new sector.
> > 3. erase old sector.
>
> This is correct.
>
> >
> > Could you explain when I need to set and reset the
> > MEMSTICK_OVERWRITE_UDST?
>
> UDST flag should be set when you're marking the block for
> reallocation during the read/modify/write cycle. You read the existing
> physical block, mark it with UDST flag (setting it to zero), then write
> different physical block on behalf of the same logical one, then erase the
> original block. The UDST flag is supposed to guard against a situation,
> whereupon power fails during the write cycle and you're left with two
> physical blocks mapped to the same logical one (so the one marked with
> zero UDST value is supposedly "known good").
>
>
> >
> >
> > #define MEMSTICK_OVERWRITE_PGST1 0x20
> > #define MEMSTICK_OVERWRITE_PGST0 0x40
> > I suppose these indicate that page(sector) contains
> > incorrect data, just
> > like in xD there is page status?
> > Again, better explanation is welcome.
> > Also, should I touch that flag when I update sector?
> >
> >
> >
> > #define MEMSTICK_OVERWRITE_BKST 0x80
> > This marks bad blocks?
>
> BKST set to zero indicates that the whole block is bad and shouldn't be
> used.
>
> PGST1:0 has several values:
> 11: default, r/w page
> 10: reserved value, shouldn't be used
> 01: page is read-only (soft write-protect)
> 00: page is accessible, but the value is not guaranteed (faulty page that
> sort-of works)
>
> That's what the spec says.
Thank you very much.
>
> >
> >
> >
> > Another question is about write of oob data.
> > When I write it, overwrite flag is updated, or I need to
> > use
> > MEMSTICK_CP_OVERWRITE to update it?
> > I think former is true.
>
> As I mentioned above, it can be accessed either as part of extra data
> or separately.
>
> >
> > When I write a sector, I just write 0 to management flag,
> > right?
>
> You shouldn't touch management_flag at all, as far as I can tell.
> It's only used to indicate special purpose blocks, such as factory
> written boot blocks, volatile look-up table blocks (for systems with
> tight RAM requirements) and DRM marked blocks which I has no info about.
>
> >
> >
> > And last question,
> > If I use MEMSTICK_CP_BLOCK, can I start reading a block
> > from non-zero
> > page offset?
>
> Yes, it starts from the user specified page address and auto increments it
> until the current block end is hit.
>
> >
> >
> > And surely last question, what is 'MS_CMD_BLOCK_END'
>
> This command is used to terminate the currently ongoing block operation.
> If you are using one of the auto-increment modes (with CP_BLOCK set) but
> do not want to access all the pages until the block end, you must issue
> this command after the desired number of pages is transferred to return
> the media's state machine to the initial state. This command never hurts,
> as you can guess.
That what I expected, thanks!
>
> >
> >
> > Thanks again for all help so far,
> >
>
> You're welcome.
Thank you very much!
Best regards,
Maxim Levitsky
On Sun, 2010-08-08 at 18:07 +0300, Maxim Levitsky wrote:
> On Sun, 2010-08-08 at 07:26 -0700, Alex Dubov wrote:
> > > Hi,
> > >
> > > I have few more questions about memsticks.
> > >
> > > First of all, I need an explanation of overwrite flag.
> > > You already explained it to me once, but I still not sure
> > > about few
> > > things.
> >
> > Overwrite register can be accessed either as part of extra data access
> > or separately (CP_OVERWRITE access mode).
> >
Few more questions I gathered today.
I currently assume that if I set req->need_card_int, the driver will
wait till device raises MEMSTICK_INT_CED regardless of serial/parallel
mode. This bit is always available on serial line.
Is that OK to assume?
Another thing that I want to ask is about writes to overwrite/managment
flag.
Common sense tells me that I can write the flash many times, but write
can only clear bits. Therefore if I write 0xFF, this just means do
nothing.
Probably same applies to data content, but that isn't much of the use.
Thats why I see that default (good) value of bits in overwrite flag is
1.
This is correct I assume?
Another interesting thing I observed was that MEMSTICK_INT_ERR can mean
a correctable error, therefore it shouldn't alone reject read/write of
a sector. (I think that it means that one of
MEMSTICK_STATUS1_UCFG..MEMSTICK_STATUS1_DTER is set)
Same question about this.
Best regards,
Maxim Levitsky
>
> I currently assume that if I set req->need_card_int, the
> driver will
> wait till device raises MEMSTICK_INT_CED regardless of
> serial/parallel
> mode. This bit is always available on serial line.
> Is that OK to assume?
I'm not quite sure about this question.
Normally, when you wait for the media interrupt, you want to see the whole
value of the INT register (CED by itself doesn't indicate successful
command completion; in fact it's value is undefined in presence of other
INT flags, like BREQ or CMDNK). In parallel mode, host is required to
fetch all meaningful INT bits from the media bus, while in serial mode
this is only possible, if host supports automatic INT retrieval (the host
will issue GET_INT tpc behind the scenes before alerting the software).
>
> Another thing that I want to ask is about writes to
> overwrite/managment
> flag.
> Common sense tells me that I can write the flash many
> times, but write
> can only clear bits. Therefore if I write 0xFF, this just
> means do
> nothing.
> Probably same applies to data content, but that isn't much
> of the use.
Yes, all memsticks are NAND flash, so writing 1s has no effect whatsoever.
> Thats why I see that default (good) value of bits in
> overwrite flag is
> 1.
> This is correct I assume?
Yes, a direct consequence of the above.
>
>
> Another interesting thing I observed was that
> MEMSTICK_INT_ERR can mean
> a correctable error,? therefore it shouldn't
> alone? reject read/write of
> a sector. (I think that it means that one of
> MEMSTICK_STATUS1_UCFG..MEMSTICK_STATUS1_DTER is set)
> Same question about this.
>
There are three groups of error flags. While overwrite_flag register is
accessible as part of extra data, being the indicator of block goodness
it earned its own error flag:
DTER (UCDT) - error (uncorrectable) in data area
EXER (UCEX) - error (uncorrectable) in extra data area
FGER (UCFG) - error (uncorrectable) in overwrite_flag register
Uncorrectable error means that you've got some bit errors in the data
you've obtained from the media. If uncorrectable flag is not set, it
means that media's ECC circuit managed to correct the bit flip. The
desired way of action is, of course, to reallocate the block before it
develops an uncorrectable failure.
On Sun, 2010-08-08 at 23:31 -0700, Alex Dubov wrote:
> >
> > I currently assume that if I set req->need_card_int, the
> > driver will
> > wait till device raises MEMSTICK_INT_CED regardless of
> > serial/parallel
> > mode. This bit is always available on serial line.
> > Is that OK to assume?
>
> I'm not quite sure about this question.
> Normally, when you wait for the media interrupt, you want to see the whole
> value of the INT register (CED by itself doesn't indicate successful
> command completion; in fact it's value is undefined in presence of other
> INT flags, like BREQ or CMDNK). In parallel mode, host is required to
> fetch all meaningful INT bits from the media bus, while in serial mode
> this is only possible, if host supports automatic INT retrieval (the host
> will issue GET_INT tpc behind the scenes before alerting the software).
Ok, maybe I didn't explain myself correctly.
Device is in serial mode.
I set need_card_int
I send a command.
<here I assume that driver waits for CED bit, which is exposed on data
line, if CED won't be set, driver/hardware will timeout>
I send GET_INT _once_, look at flags. If I see CED, no NACK, then ok,
otherwise I send error result.
>
> >
> > Another thing that I want to ask is about writes to
> > overwrite/managment
> > flag.
> > Common sense tells me that I can write the flash many
> > times, but write
> > can only clear bits. Therefore if I write 0xFF, this just
> > means do
> > nothing.
> > Probably same applies to data content, but that isn't much
> > of the use.
>
> Yes, all memsticks are NAND flash, so writing 1s has no effect whatsoever.
>
> > Thats why I see that default (good) value of bits in
> > overwrite flag is
> > 1.
> > This is correct I assume?
>
> Yes, a direct consequence of the above.
I suspect that managment flag also has default value of 0xFF, and these
'special' features (drm, boot block, temporary table) clear bits out of
it.
>
> >
> >
> > Another interesting thing I observed was that
> > MEMSTICK_INT_ERR can mean
> > a correctable error, therefore it shouldn't
> > alone reject read/write of
> > a sector. (I think that it means that one of
> > MEMSTICK_STATUS1_UCFG..MEMSTICK_STATUS1_DTER is set)
> > Same question about this.
> >
>
> There are three groups of error flags. While overwrite_flag register is
> accessible as part of extra data, being the indicator of block goodness
> it earned its own error flag:
>
> DTER (UCDT) - error (uncorrectable) in data area
> EXER (UCEX) - error (uncorrectable) in extra data area
> FGER (UCFG) - error (uncorrectable) in overwrite_flag register
>
> Uncorrectable error means that you've got some bit errors in the data
> you've obtained from the media. If uncorrectable flag is not set, it
> means that media's ECC circuit managed to correct the bit flip. The
> desired way of action is, of course, to reallocate the block before it
> develops an uncorrectable failure.
That I understand clearly.
I ask what the meaning of MEMSTICK_INT_ERR is.
I expect it to be set if any of (un) correctable errors are found.
Therefore if MEMSTICK_INT_ERR, I can't report error instantly, but I
need to look at status1 to see if error is correctable or not.
This is correct?
Best regards,
Maxim Levitsky
I have another question.
Looking at ms_block.c, I see that it sometimes changes register window.
This doesn't look good.
I see it does put the register window back, but still its a bit obscure.
I added tracking of current register window, so every time I send
MS_TPC_SET_RW_REG_ADRS I note the ranges.
And read/write functions now always attempt to send
MS_TPC_SET_RW_REG_ADRS. If the window is same as was set last time, TPC
is skipped.
However, I am thinking, that maybe I should always write both param and
extra register? I just write 0xFF to extra register and thats all.
Windows driver does that partially. It writes 0xFF to managmemt and
0xF8 to overwrite flag (why???), but doesn't touch the LBA. I don't
think that matters.
It also always sends the MS_TPC_SET_RW_REG_ADRS, which I don't like.
Best regards,
Maxim Levitsky
About INT bits, I still don't understand them exactly.
First of all we have 4 meaningful bits.
In parallel mode these are exposed on data lines, in serial mode only
MEMSTICK_INT_CED is.
And I can always send MS_TPC_GET_INT or just read the registers.
#define MEMSTICK_INT_CMDNAK 0x01
#define MEMSTICK_INT_BREQ 0x20
#define MEMSTICK_INT_ERR 0x40
#define MEMSTICK_INT_CED 0x80
Now, I send a command to device, say MS_CMD_BLOCK_READ.
What bits I need to poll until I can be sure that command is completed?
Also the MEMSTICK_INT_BREQ tells that input is available in firmware
buffer (to read using TPC_READ_LONG_DATA)?
Is that true that MEMSTICK_INT_BREQ is a summary of fifo full/empty bits
in status0?
And same about MEMSTICK_INT_ERR and status1.
I try my best to create a driver that actually works, simple, and error
free, even in unusual conditions.
Thats why I am asking all these questions.
Thanks for help,
Best regards,
Maxim Levitsky
> About INT bits, I still don't
> understand them exactly.
>
> First of all we have 4 meaningful bits.
> In parallel mode these are exposed on data lines, in serial
> mode only
> MEMSTICK_INT_CED is.
> And I can always send MS_TPC_GET_INT or just read the
> registers.
>
> #define MEMSTICK_INT_CMDNAK 0x01
This bit means command was not acknowledged by the media (media not ready).
> #define MEMSTICK_INT_BREQ???0x20
This bit means media is ready for long data transfer (either in or out).
> #define MEMSTICK_INT_ERR? ? 0x40
This bit means that some error had occurred during command execution.
> #define MEMSTICK_INT_CED? ? 0x80
This bit marks a completion of the command, but it may switch value in
between, so it is not that reliable by itself.
>
>
> Now, I send a command to device, say MS_CMD_BLOCK_READ.
> What bits I need to poll until I can be sure that command
> is completed?
All of them.
>
> Also the MEMSTICK_INT_BREQ tells that input is available in
> firmware
> buffer (to read using TPC_READ_LONG_DATA)?
>
Not exactly. BREQ signal indicated that media's state machine is in the
mode to pump data in or out. You wait for it, than you do the data
transfer (it works the same with READ and WRITE).
>
>
> Is that true that MEMSTICK_INT_BREQ is a summary of fifo
> full/empty bits
> in status0?
This can not be relied upon. Sony states, that only BREQ bit must be used
in block transfer operations. BE/BF bits are probably of more use in
memstick IO cards (there exists such a beast).
>
> And same about MEMSTICK_INT_ERR and status1.
status1 errors apply only to data errors (bit flips).
There are errors in command execution that do not result in bit flips,
rather data can not be delivered at all or command/parameters are invalid.
>
> I try my best to create a driver that actually works,
> simple, and error
> free, even in unusual conditions.
> Thats why I am asking all these questions.
>
> Thanks for help,
> Best regards,
> Maxim Levitsky
>
>
> Received: Monday, 9 August, 2010, 8:30 AM
> I have another question.
>
> Looking at ms_block.c, I see that it sometimes changes
> register window.
> This doesn't look good.
> I see it does put the register window back, but still its a
> bit obscure.
It looks very good, in fact, it is the Sony specified way to operate
the media. MS Pro works quite the same, it just needs fewer operations
to actually access data.
>
> I added tracking of current register window, so every time
> I send
> MS_TPC_SET_RW_REG_ADRS I note the ranges.
> And read/write functions now always attempt to send
> MS_TPC_SET_RW_REG_ADRS. If the window is same as was?
> set last time, TPC
> is skipped.
Sure it is. The media will remember the window set.
Media has all its registers in a sort of flat file. SET_RW_REG_ADDR
selects the subset of the registers that will receive the data delivered
within TPC. This subset is remembered until power off or until changed.
>
> However, I am thinking, that maybe I should always write
> both param and
> extra register? I just write 0xFF to extra register and
> thats all.
You should write into a param register when you want to alter the command
parameters. You cannot do so during auto incrementing block access, for
example.
But, if you're using the auto incrementing write, you will have to write
extra register for every page transferred.
That's where changing RW_REG_ADDR comes handy.
> Windows driver does that partially. It writes 0xFF to
> managmemt and
> 0xF8 to overwrite flag (why???)
It's a factory default.
Try to read it from some empty block. :-)
(My theory is that missing bits contain invisible ECC data).
> I don't
> think that matters.
> It also always sends the MS_TPC_SET_RW_REG_ADRS, which I
> don't like.
>
This only reduces the performance slightly. SET_RW_REG_ADDR does not
influence the media's state machine as far as I can tell, unless you try
to push it during the data transfer cycle (whereupon you will end up
having a literal value of the tpc in the media data buffer).
On Tue, 2010-08-10 at 01:12 -0700, Alex Dubov wrote:
> > Received: Monday, 9 August, 2010, 8:30 AM
> > I have another question.
> >
> > Looking at ms_block.c, I see that it sometimes changes
> > register window.
> > This doesn't look good.
> > I see it does put the register window back, but still its a
> > bit obscure.
>
> It looks very good, in fact, it is the Sony specified way to operate
> the media. MS Pro works quite the same, it just needs fewer operations
> to actually access data.
>
> >
> > I added tracking of current register window, so every time
> > I send
> > MS_TPC_SET_RW_REG_ADRS I note the ranges.
> > And read/write functions now always attempt to send
> > MS_TPC_SET_RW_REG_ADRS. If the window is same as was
> > set last time, TPC
> > is skipped.
>
> Sure it is. The media will remember the window set.
> Media has all its registers in a sort of flat file. SET_RW_REG_ADDR
> selects the subset of the registers that will receive the data delivered
> within TPC. This subset is remembered until power off or until changed.
I know everything you have just said.
I just want to point out that code in many places assumes that register
window is the same as set on device initialization.
However some code changes the register window, and therefore has to
change it back at the end of execution.
If error happens, window can be left changed, while rest of code thinks
it isn't changed.
Thats is why a tracking of it would eliminate the problem safely.
>
>
> >
> > However, I am thinking, that maybe I should always write
> > both param and
> > extra register? I just write 0xFF to extra register and
> > thats all.
>
> You should write into a param register when you want to alter the command
> parameters. You cannot do so during auto incrementing block access, for
> example.
>
> But, if you're using the auto incrementing write, you will have to write
> extra register for every page transferred.
But what if I fill extra register with 0xFF?
And besides on reads, the fact that I *write* the extra register before
I execute read command shouldn't matter at all regardless of what I
write there.
On writes however I *do* need to write extra register anyway with proper
values.
Therefore I see no reason why I can't set write window to cover both
param and extra register, and leave it always like that.
>
> That's where changing RW_REG_ADDR comes handy.
>
> > Windows driver does that partially. It writes 0xFF to
> > managmemt and
> > 0xF8 to overwrite flag (why???)
>
> It's a factory default.
> Try to read it from some empty block. :-)
> (My theory is that missing bits contain invisible ECC data).
>
>
> > I don't
> > think that matters.
> > It also always sends the MS_TPC_SET_RW_REG_ADRS, which I
> > don't like.
> >
>
> This only reduces the performance slightly. SET_RW_REG_ADDR does not
> influence the media's state machine as far as I can tell, unless you try
> to push it during the data transfer cycle (whereupon you will end up
> having a literal value of the tpc in the media data buffer).
Indeed. Maybe I too should just send the MS_TPC_SET_RW_REG_ADRS at start
of command, and know that nothing will go south....
Even if that reduces performance by 0.2%, it isn't big deal. Data
corruptions is very big deal.
Best regards,
Maxim Levitsky
On Tue, 2010-08-10 at 00:53 -0700, Alex Dubov wrote:
> > About INT bits, I still don't
> > understand them exactly.
> >
> > First of all we have 4 meaningful bits.
> > In parallel mode these are exposed on data lines, in serial
> > mode only
> > MEMSTICK_INT_CED is.
> > And I can always send MS_TPC_GET_INT or just read the
> > registers.
> >
> > #define MEMSTICK_INT_CMDNAK 0x01
>
> This bit means command was not acknowledged by the media (media not ready).
>
> > #define MEMSTICK_INT_BREQ 0x20
>
> This bit means media is ready for long data transfer (either in or out).
>
> > #define MEMSTICK_INT_ERR 0x40
>
> This bit means that some error had occurred during command execution.
>
> > #define MEMSTICK_INT_CED 0x80
>
> This bit marks a completion of the command, but it may switch value in
> between, so it is not that reliable by itself.
>
> >
> >
> > Now, I send a command to device, say MS_CMD_BLOCK_READ.
> > What bits I need to poll until I can be sure that command
> > is completed?
>
> All of them.
>
> >
> > Also the MEMSTICK_INT_BREQ tells that input is available in
> > firmware
> > buffer (to read using TPC_READ_LONG_DATA)?
> >
>
> Not exactly. BREQ signal indicated that media's state machine is in the
> mode to pump data in or out. You wait for it, than you do the data
> transfer (it works the same with READ and WRITE).
>
> >
> >
> > Is that true that MEMSTICK_INT_BREQ is a summary of fifo
> > full/empty bits
> > in status0?
>
> This can not be relied upon. Sony states, that only BREQ bit must be used
> in block transfer operations. BE/BF bits are probably of more use in
> memstick IO cards (there exists such a beast).
Even better.
>
> >
> > And same about MEMSTICK_INT_ERR and status1.
>
> status1 errors apply only to data errors (bit flips).
> There are errors in command execution that do not result in bit flips,
> rather data can not be delivered at all or command/parameters are invalid.
Understood.
However if I get MEMSTICK_INT_ERR, I should also look at status1,
because there might be correctable error.
Thank you very much.
Best regards,
Maxim Levitsky
> I know everything you have just said.
> I just want to point out that code in many places assumes
> that register
> window is the same as set on device initialization.
It's not.
Can you please point at a particular place?
> > But, if you're using the auto incrementing write, you
> will have to write
> > extra register for every page transferred.
> But what if I fill extra register with 0xFF?
> And besides on reads, the fact that I *write* the extra
> register before
> I execute read command shouldn't matter at all regardless
> of what I
> write there.
> On writes however I *do* need to write extra register
> anyway with proper
> values.
>
> Therefore I see no reason why I can't set write window to
> cover both
> param and extra register, and leave it always like that.
Because when you do autoincrementing write you _can not_ write into param register. You will break the command execution.
On the other thought, it may be unnecessary to write unique extra data to every page, so one full register write at the beginning of the command may do. Considering, that legacy memstick is not going to evolve, this may be reasonable assumption.
> result in bit flips,
> > rather data can not be delivered at all or
> command/parameters are invalid.
> Understood.
> However if I get MEMSTICK_INT_ERR, I should also look at
> status1,
> because there might be correctable error.
>
>
I don't remember the details, but it may be, that status1 errors do not
raise INT_ERR (or do not always raise?). The idea is, first you check
INT_ERR. If command completed successfully and you received the data, you
may still need to check status1 for possible bit flips.
Some experimentation may be required, especially for the case of
correctable errors. After all, they should not prevent the command from
successful completion, yet action should be taken on them (at the very
least - log warning, just like with normal disks).
On Wed, 2010-08-11 at 01:08 -0700, Alex Dubov wrote:
> > I know everything you have just said.
> > I just want to point out that code in many places assumes
> > that register
> > window is the same as set on device initialization.
>
> It's not.
> Can you please point at a particular place?
>
> > > But, if you're using the auto incrementing write, you
> > will have to write
> > > extra register for every page transferred.
> > But what if I fill extra register with 0xFF?
> > And besides on reads, the fact that I *write* the extra
> > register before
> > I execute read command shouldn't matter at all regardless
> > of what I
> > write there.
> > On writes however I *do* need to write extra register
> > anyway with proper
> > values.
> >
> > Therefore I see no reason why I can't set write window to
> > cover both
> > param and extra register, and leave it always like that.
>
> Because when you do autoincrementing write you _can not_ write into param register. You will break the command execution.
Thanks, I finally understand you, so you are objection to write of
_param_ register, not the _extra_.
I agree with you.
>
> On the other thought, it may be unnecessary to write unique extra data to every page, so one full register write at the beginning of the command may do. Considering, that legacy memstick is not going to evolve, this may be reasonable assumption.
Indeed that what I do now.
Maximum I might need to clear page status bits, but I can do that later
after I write the block.
This won't be any performance impact because amount of bad pages
shouldn't be normally greater that zero.
(Otherwise there will be data loss...)
One interesting thing that I just want your opinion on is what to do
with correctable errors.
Common sense suggests to relocate the sector + and mark it bad.
But I don't know how common such sectors are, and thus I could do more
harm that good by marking too many sectors as bad.
Of course all such problems are reason why today flash devices contain
the FTL inside, and can improve/define it in the way they want.
No more questions for now, thank you very much for help.
I hope I create ms_block.c soon, and put that old problem to the rest.
As time permits I will also port your driver for xD portion of jMicron
device (which I have).
Best regards,
Maxim Levitsky
> Maximum I might need to clear page status bits, but I can
> do that later
> after I write the block.
> This won't be any performance impact because amount of bad
> pages
> shouldn't be normally greater that zero.
> (Otherwise there will be data loss...)
These things do degrade. I think, memsticks do write-verify, so bad blocks
will appear during write and can be marked as such without any data loss.
>
> One interesting thing that I just want your opinion on is
> what to do
> with correctable errors.
> Common sense suggests to relocate the sector + and mark it
> bad.
> But I don't know how common such sectors are, and thus I
> could do more
> harm that good by marking too many sectors as bad.
I agree that number of writes to the media should be kept minimal.
So bad (in either way) blocks encountered should be logged, but not
touched, unless the error appears during an actual write/modify operation.
>
> I hope I create ms_block.c soon, and put that old problem
> to the rest.
If you have time and desire, try to put a low level format option in -
some function to erase all blocks, except the system ones.
>
> As time permits I will also port your driver for xD portion
> of jMicron
> device (which I have).
By the way, I've got some errata for the newer JMicron chipsets. If they
have not contacted you yet, I'll forward it to you.
Apparently, the values I was using to configure a jmicron memstick
interface only work with some chipset revisions. So they've sent me the
following message.
If you've got a working jmicron adapter handy, you may want to try these
changes.
-----------------
We found that there is a definition problem in your code about
JMicron MS Controller.
Our new product would get problem with this part.
Following is the bit definition in our code.
// --- Clock Control Register - Offset 0x48 --- //
// D[31:4] Reserved
// D[3] Force MMIO Control. 0: Control by PCI CNFG, 1: Control
by MMIO.
// D[2:0] Clock MUX Select
#define MSHC_CLKMUX_CONTROL_BY_MMIO 0x00000008
#define MSHC_CLKMUX_CLK_40MHZ 0x00000001
#define MSHC_CLKMUX_CLK_50MHZ 0x00000002
#define MSHC_CLKMUX_CLK_62_5MHZ 0x00000004
#define MSHC_CLKMUX_CLK_60MHZ 0x00000010 // Must
set PCICnfg Offset BCh D[0] to 1
#define MSHC_CLKMUX_CLK_OFF 0x00000000
#define MSHC_CLKMUX_CLK_MASK 0x00000017
Driver have to set this register to 0x08 to clear default clock
setting.
And then set its value with specfic clock setting (EX: 40MHz ->
0x09, 50MHz -> 0x0A) to change clock.
(For MS Pro-HG, we suggest to use 50MHz with 8-bit parallel mode.)
Besides, driver have to set the register to 40MHz setting before
identify MS card for safe.
On Thu, 2010-08-12 at 00:22 -0700, Alex Dubov wrote:
> > Maximum I might need to clear page status bits, but I can
> > do that later
> > after I write the block.
> > This won't be any performance impact because amount of bad
> > pages
> > shouldn't be normally greater that zero.
> > (Otherwise there will be data loss...)
>
>
> These things do degrade. I think, memsticks do write-verify, so bad blocks
> will appear during write and can be marked as such without any data loss.
>
> >
> > One interesting thing that I just want your opinion on is
> > what to do
> > with correctable errors.
> > Common sense suggests to relocate the sector + and mark it
> > bad.
> > But I don't know how common such sectors are, and thus I
> > could do more
> > harm that good by marking too many sectors as bad.
>
> I agree that number of writes to the media should be kept minimal.
> So bad (in either way) blocks encountered should be logged, but not
> touched, unless the error appears during an actual write/modify operation.
>
> >
> > I hope I create ms_block.c soon, and put that old problem
> > to the rest.
>
> If you have time and desire, try to put a low level format option in -
> some function to erase all blocks, except the system ones.
>
> >
> > As time permits I will also port your driver for xD portion
> > of jMicron
> > device (which I have).
>
> By the way, I've got some errata for the newer JMicron chipsets. If they
> have not contacted you yet, I'll forward it to you.
Yeah, I didn't done anything at that direction, but eventually I get to
it.
Best regards,
Maxim Levitsky