Re: Experimental driver for Ricoh Bay1Controller SD Card readers
On 2/16/07, Ivan Babkin <[EMAIL PROTECTED]> wrote: Thank for the job you've done! Your driver works with 1 Gb sd-card (x86_64 suse's 2.16.18.2 kernel). Read rate for me was around 250 Kb/s, write - 28 Kb/s (using dd utility). BTW, I get continuous flow of "sdricoh_cs: timeout waiting for data" messages in dmesg. Works for me too. Using a 512mb SD card, and a 256miniSD in an adaptor. Managed to mount both SD cards and play mp3's off each with mpg321. Literally music to my ears. I used the 0.1 release on the homepage, so it still oopsed on removal when I hadnt unmounted. Laptop is an Acer Travelmate 370 for the record. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
On 2/16/07, Ivan Babkin [EMAIL PROTECTED] wrote: Thank for the job you've done! Your driver works with 1 Gb sd-card (x86_64 suse's 2.16.18.2 kernel). Read rate for me was around 250 Kb/s, write - 28 Kb/s (using dd utility). BTW, I get continuous flow of sdricoh_cs: timeout waiting for data messages in dmesg. Works for me too. Using a 512mb SD card, and a 256miniSD in an adaptor. Managed to mount both SD cards and play mp3's off each with mpg321. Literally music to my ears. I used the 0.1 release on the homepage, so it still oopsed on removal when I hadnt unmounted. Laptop is an Acer Travelmate 370 for the record. James -- iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi! > Apart from that I did the following changes: > - implemented suspend/resume support (not tested very much) > - named the registers > - fixed a bug that caused a major slowdown when modprobed without debug=1 > - added writting support (disabled by default, modprobe with write=1) > Before you enable writting please make sure that you did a proper backup of > the data on the card. Do not use this driver to save important data. Thank for the job you've done! Your driver works with 1 Gb sd-card (x86_64 suse's 2.16.18.2 kernel). Read rate for me was around 250 Kb/s, write - 28 Kb/s (using dd utility). BTW, I get continuous flow of "sdricoh_cs: timeout waiting for data" messages in dmesg. Good luck! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi! Apart from that I did the following changes: - implemented suspend/resume support (not tested very much) - named the registers - fixed a bug that caused a major slowdown when modprobed without debug=1 - added writting support (disabled by default, modprobe with write=1) Before you enable writting please make sure that you did a proper backup of the data on the card. Do not use this driver to save important data. Thank for the job you've done! Your driver works with 1 Gb sd-card (x86_64 suse's 2.16.18.2 kernel). Read rate for me was around 250 Kb/s, write - 28 Kb/s (using dd utility). BTW, I get continuous flow of sdricoh_cs: timeout waiting for data messages in dmesg. Good luck! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi, On Tuesday 13 February 2007 06:47, Pierre Ossman wrote: > Sascha Sommer wrote: > > I still consider this driver experimental, but without documentation this > > is probably not going to change anytime soon. > > The question is now what I should do with the driver? > > Is it worth to be included in the kernel? If yes where and against what > > kernelversion should I send the patch? > > That's up to you. The most important thing for any part of the kernel is > that it must have a maintainer. So if you are ready to keep the driver > up to date and handle the support requests that show, then you should > really submit it. > > Patches should always be sent against the current version of the kernel > (i.e. git HEAD). Usually the latest packaged release will also do. > > (Note that I haven't had time to review your latest version of the driver) > Yes, I'm going to maintain it. There are still some bugs that need to be fixed first, though. I also got a mail from someone else how also did some reverseengineering work for this reader. I'm waiting for his feedback before I will submit a patch that can be included. Thanks. Sascha - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Pierre Ossman, le Tue 13 Feb 2007 06:47:41 +0100, a écrit : > Sascha Sommer wrote: > > I still consider this driver experimental, but without documentation this > > is > > probably not going to change anytime soon. > > The question is now what I should do with the driver? > > Is it worth to be included in the kernel? If yes where and against what > > kernelversion should I send the patch? > > That's up to you. The most important thing for any part of the kernel is > that it must have a maintainer. So if you are ready to keep the driver > up to date and handle the support requests that show, then you should > really submit it. You can mark your Kconfig entry with EXPERIMENTAL for letting people know about the status :) Samuel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Pierre Ossman, le Tue 13 Feb 2007 06:47:41 +0100, a écrit : Sascha Sommer wrote: I still consider this driver experimental, but without documentation this is probably not going to change anytime soon. The question is now what I should do with the driver? Is it worth to be included in the kernel? If yes where and against what kernelversion should I send the patch? That's up to you. The most important thing for any part of the kernel is that it must have a maintainer. So if you are ready to keep the driver up to date and handle the support requests that show, then you should really submit it. You can mark your Kconfig entry with EXPERIMENTAL for letting people know about the status :) Samuel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi, On Tuesday 13 February 2007 06:47, Pierre Ossman wrote: Sascha Sommer wrote: I still consider this driver experimental, but without documentation this is probably not going to change anytime soon. The question is now what I should do with the driver? Is it worth to be included in the kernel? If yes where and against what kernelversion should I send the patch? That's up to you. The most important thing for any part of the kernel is that it must have a maintainer. So if you are ready to keep the driver up to date and handle the support requests that show, then you should really submit it. Patches should always be sent against the current version of the kernel (i.e. git HEAD). Usually the latest packaged release will also do. (Note that I haven't had time to review your latest version of the driver) Yes, I'm going to maintain it. There are still some bugs that need to be fixed first, though. I also got a mail from someone else how also did some reverseengineering work for this reader. I'm waiting for his feedback before I will submit a patch that can be included. Thanks. Sascha - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote: > I still consider this driver experimental, but without documentation this is > probably not going to change anytime soon. > The question is now what I should do with the driver? > Is it worth to be included in the kernel? If yes where and against what > kernelversion should I send the patch? > > That's up to you. The most important thing for any part of the kernel is that it must have a maintainer. So if you are ready to keep the driver up to date and handle the support requests that show, then you should really submit it. Patches should always be sent against the current version of the kernel (i.e. git HEAD). Usually the latest packaged release will also do. (Note that I haven't had time to review your latest version of the driver) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote: I still consider this driver experimental, but without documentation this is probably not going to change anytime soon. The question is now what I should do with the driver? Is it worth to be included in the kernel? If yes where and against what kernelversion should I send the patch? That's up to you. The most important thing for any part of the kernel is that it must have a maintainer. So if you are ready to keep the driver up to date and handle the support requests that show, then you should really submit it. Patches should always be sent against the current version of the kernel (i.e. git HEAD). Usually the latest packaged release will also do. (Note that I haven't had time to review your latest version of the driver) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi,
On Sunday 07 January 2007 10:56, Jiri Slaby wrote:
> Sascha Sommer wrote:
> > Hi,
> >
> > Attached is a very experimental driver for a Ricoh SD Card reader that
> > can be found in some notebooks like the Samsung P35.
> >
> > Whenever a sd card is inserted into one of these notebooks, a virtual
> > pcmcia card will show up:
> >
> > Socket 0:
> > product info: "RICOH", "Bay1Controller", "", ""
> > manfid: 0x, 0x
> >
> > In order to write this driver I hacked qemu to have access to the cardbus
> > bridge containing this card. I then logged the register accesses of the
> > windows xp driver and tryed to analyse them.
> >
> > As the meanings of most of the register are still unknown to me, I
> > consider this driver very experimental. It is possible that this driver
> > might destroy your data or your hardware. Use at your own risk!
> >
> > Other problems:
> > - I only implemented reading support
> > - I only tested with a 128 MB SD card, no idea what would be needed to
> > support other card types
> > - irqs are not supported
> > - dma is not supported
> > - it is very slow
> > - the registers can be found on the cardbus bridge and not on the virtual
> > pcmcia card. The cardbus bridge is already claimed by yenta_socket.
> > Therefore the driver currently uses pci_find_device to find the cardbus
>
> - pci_find_device is no go today. Use pci_get_device (+ pci_dev_get, _put).
> - ioremap->pci_iomap
> - iobase should be __iomem.
> - codingstyle (char* buffer, for(loop, if(data){, ...)
>
Thanks for your feedback and testing.
I fixed the above problems and ran the code through Lindent.
Apart from that I did the following changes:
- implemented suspend/resume support (not tested very much)
- named the registers
- fixed a bug that caused a major slowdown when modprobed without debug=1
- added writting support (disabled by default, modprobe with write=1)
Before you enable writting please make sure that you did a proper backup of
the data on the card. Do not use this driver to save important data.
I still consider this driver experimental, but without documentation this is
probably not going to change anytime soon.
The question is now what I should do with the driver?
Is it worth to be included in the kernel? If yes where and against what
kernelversion should I send the patch?
Thanks
Sascha
KERNEL_VERSION = $(shell uname -r)
KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build
MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc
obj-m += sdricoh_cs.o
default:
$(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
install:
if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi
install -D -m 644 *.ko $(MDIR)
depmod -a
clean:
rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags
rm -rf .tmp_versions
/*
* sdricoh_cs.c - driver for Ricoh Secure Digital Card Readers that can be found
* on some Ricoh RL5c476 II cardbus bridge
*
* Copyright (C) 2006 - 2007 Sascha Sommer <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* FIXME:
* - what about irqs and dma?
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define DRIVER_NAME "sdricoh_cs"
#define DRIVER_VERSION "0.1"
static unsigned int debug = 0;
static unsigned int write = 0;
//#define DEBUG
/* debug macros */
#ifdef DEBUG
#define REGDBG(fmt, arg...) do {\
if (debug > 1) \
printk(KERN_INFO "sdricoh_cs: "fmt, \
##arg); } while (0)
#else
#define REGDBG(fmt, arg...)
#endif
#define DBG(fmt, arg...) do {\
if (debug > 0) \
printk(KERN_INFO "sdricoh_cs: "fmt, \
##arg); } while (0)
#define ERR(fmt, arg...) do {\
printk(KERN_INFO "sdricoh_cs: "fmt, \
##arg); } while (0)
/* i/o region */
#define SDRICOH_PCI_REGION 0
#define SDRICOH_PCI_REGION_SIZE 0x1000
/* registers */
#define R104_VERSION 0x104
#define R200_CMD 0x200
#define R204_CMD_ARG 0x204
#define R208_DATAIO 0x208
#define R20C_RESP0x20c
#define R21C_STATUS 0x21c
#define R2E0_INIT0x2e0
#define R2E4_STATUS_RESP 0x2e4
#define R2F0_RESET 0x2f0
#define R224_CLOCK 0x224
#define R228_POWER 0x228
#define R230_DATA0x230
/* flags for the
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi,
On Sunday 07 January 2007 10:56, Jiri Slaby wrote:
Sascha Sommer wrote:
Hi,
Attached is a very experimental driver for a Ricoh SD Card reader that
can be found in some notebooks like the Samsung P35.
Whenever a sd card is inserted into one of these notebooks, a virtual
pcmcia card will show up:
Socket 0:
product info: RICOH, Bay1Controller, ,
manfid: 0x, 0x
In order to write this driver I hacked qemu to have access to the cardbus
bridge containing this card. I then logged the register accesses of the
windows xp driver and tryed to analyse them.
As the meanings of most of the register are still unknown to me, I
consider this driver very experimental. It is possible that this driver
might destroy your data or your hardware. Use at your own risk!
Other problems:
- I only implemented reading support
- I only tested with a 128 MB SD card, no idea what would be needed to
support other card types
- irqs are not supported
- dma is not supported
- it is very slow
- the registers can be found on the cardbus bridge and not on the virtual
pcmcia card. The cardbus bridge is already claimed by yenta_socket.
Therefore the driver currently uses pci_find_device to find the cardbus
- pci_find_device is no go today. Use pci_get_device (+ pci_dev_get, _put).
- ioremap-pci_iomap
- iobase should be __iomem.
- codingstyle (char* buffer, for(loop, if(data){, ...)
Thanks for your feedback and testing.
I fixed the above problems and ran the code through Lindent.
Apart from that I did the following changes:
- implemented suspend/resume support (not tested very much)
- named the registers
- fixed a bug that caused a major slowdown when modprobed without debug=1
- added writting support (disabled by default, modprobe with write=1)
Before you enable writting please make sure that you did a proper backup of
the data on the card. Do not use this driver to save important data.
I still consider this driver experimental, but without documentation this is
probably not going to change anytime soon.
The question is now what I should do with the driver?
Is it worth to be included in the kernel? If yes where and against what
kernelversion should I send the patch?
Thanks
Sascha
KERNEL_VERSION = $(shell uname -r)
KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build
MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc
obj-m += sdricoh_cs.o
default:
$(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
install:
if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi
install -D -m 644 *.ko $(MDIR)
depmod -a
clean:
rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags
rm -rf .tmp_versions
/*
* sdricoh_cs.c - driver for Ricoh Secure Digital Card Readers that can be found
* on some Ricoh RL5c476 II cardbus bridge
*
* Copyright (C) 2006 - 2007 Sascha Sommer [EMAIL PROTECTED]
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* FIXME:
* - what about irqs and dma?
*/
#include linux/delay.h
#include linux/highmem.h
#include linux/pci.h
#include linux/ioport.h
#include pcmcia/cs_types.h
#include pcmcia/cs.h
#include pcmcia/cistpl.h
#include pcmcia/ciscode.h
#include pcmcia/ds.h
#include pcmcia/cisreg.h
#include asm/io.h
#include linux/mmc/host.h
#include linux/mmc/protocol.h
#define DRIVER_NAME sdricoh_cs
#define DRIVER_VERSION 0.1
static unsigned int debug = 0;
static unsigned int write = 0;
//#define DEBUG
/* debug macros */
#ifdef DEBUG
#define REGDBG(fmt, arg...) do {\
if (debug 1) \
printk(KERN_INFO sdricoh_cs: fmt, \
##arg); } while (0)
#else
#define REGDBG(fmt, arg...)
#endif
#define DBG(fmt, arg...) do {\
if (debug 0) \
printk(KERN_INFO sdricoh_cs: fmt, \
##arg); } while (0)
#define ERR(fmt, arg...) do {\
printk(KERN_INFO sdricoh_cs: fmt, \
##arg); } while (0)
/* i/o region */
#define SDRICOH_PCI_REGION 0
#define SDRICOH_PCI_REGION_SIZE 0x1000
/* registers */
#define R104_VERSION 0x104
#define R200_CMD 0x200
#define R204_CMD_ARG 0x204
#define R208_DATAIO 0x208
#define R20C_RESP0x20c
#define R21C_STATUS 0x21c
#define R2E0_INIT0x2e0
#define R2E4_STATUS_RESP 0x2e4
#define R2F0_RESET 0x2f0
#define R224_CLOCK
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote: > Hi, > > Attached is a very experimental driver for a Ricoh SD Card reader that can be > found in some notebooks like the Samsung P35. > Impressive. Keep up the good work. :) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote: Hi, Attached is a very experimental driver for a Ricoh SD Card reader that can be found in some notebooks like the Samsung P35. Impressive. Keep up the good work. :) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi, Sascha Sommer, le Sun 07 Jan 2007 00:32:26 +0100, a écrit : > Attached is a very experimental driver for a Ricoh SD Card reader that can be > found in some notebooks like the Samsung P35. Yehaaaw! That reader can be found on DELL X300 too. It works almost fine for me, see attached dmesg. These I/O errors didn't prevent me from mounting a card, though. > In order to write this driver I hacked qemu to have access to the cardbus > bridge containing this card. I then logged the register accesses of the > windows xp driver and tryed to analyse them. Great to see people brave enough to do such tedious work :D > - I only tested with a 128 MB SD card, no idea what would be needed to support > other card types Unfortunately, I don't have other cards either. > - only tested with kernel 2.6.18 Tested with 2.6.19 without source change. > apart from all these problems reading an image from my sd card seems to have > worked ;) The IO errors make dd stop on my box. I tried to set TIMEOUT to 1000 (this is a slow card) without better results. Tell me if there are things I can test. I'm not subscribed to linux-kernel, so please remember to Cc me when posting updates, etc. so I can test them. Samuel pccard: PCMCIA card inserted into slot 0 pcmcia: registering new device pcmcia0.0 sdricoh_cs: no version for "struct_module" found: kernel tainted. mmcblk0: mmc0:b370 SD128 123008KiB (ro) mmcblk0: p1 sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data mmcblk0: error 1 sending read/write command end_request: I/O error, dev mmcblk0, sector 32 Buffer I/O error on device mmcblk0, logical block 4 sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data mmcblk0: error 1 sending read/write command end_request: I/O error, dev mmcblk0, sector 56 Buffer I/O error on device mmcblk0, logical block 7 sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data mmcblk0: error 1 sending read/write command end_request: I/O error, dev mmcblk0, sector 80 Buffer I/O error on device mmcblk0, logical block 10 sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data mmcblk0: error 1 sending read/write command end_request: I/O error, dev mmcblk0, sector 112 Buffer I/O error on device mmcblk0, logical block 14 pccard: card ejected from slot 0
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Hi, Sascha Sommer, le Sun 07 Jan 2007 00:32:26 +0100, a écrit : Attached is a very experimental driver for a Ricoh SD Card reader that can be found in some notebooks like the Samsung P35. Yehaaaw! That reader can be found on DELL X300 too. It works almost fine for me, see attached dmesg. These I/O errors didn't prevent me from mounting a card, though. In order to write this driver I hacked qemu to have access to the cardbus bridge containing this card. I then logged the register accesses of the windows xp driver and tryed to analyse them. Great to see people brave enough to do such tedious work :D - I only tested with a 128 MB SD card, no idea what would be needed to support other card types Unfortunately, I don't have other cards either. - only tested with kernel 2.6.18 Tested with 2.6.19 without source change. apart from all these problems reading an image from my sd card seems to have worked ;) The IO errors make dd stop on my box. I tried to set TIMEOUT to 1000 (this is a slow card) without better results. Tell me if there are things I can test. I'm not subscribed to linux-kernel, so please remember to Cc me when posting updates, etc. so I can test them. Samuel pccard: PCMCIA card inserted into slot 0 pcmcia: registering new device pcmcia0.0 sdricoh_cs: no version for struct_module found: kernel tainted. mmcblk0: mmc0:b370 SD128 123008KiB (ro) mmcblk0: p1 sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data mmcblk0: error 1 sending read/write command end_request: I/O error, dev mmcblk0, sector 32 Buffer I/O error on device mmcblk0, logical block 4 sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data mmcblk0: error 1 sending read/write command end_request: I/O error, dev mmcblk0, sector 56 Buffer I/O error on device mmcblk0, logical block 7 sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data mmcblk0: error 1 sending read/write command end_request: I/O error, dev mmcblk0, sector 80 Buffer I/O error on device mmcblk0, logical block 10 sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data sdricoh_cs: timeout waiting for data mmcblk0: error 1 sending read/write command end_request: I/O error, dev mmcblk0, sector 112 Buffer I/O error on device mmcblk0, logical block 14 pccard: card ejected from slot 0
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote:
> Hi,
>
> Attached is a very experimental driver for a Ricoh SD Card reader that can be
> found in some notebooks like the Samsung P35.
>
> Whenever a sd card is inserted into one of these notebooks, a virtual pcmcia
> card will show up:
>
> Socket 0:
> product info: "RICOH", "Bay1Controller", "", ""
> manfid: 0x, 0x
>
> In order to write this driver I hacked qemu to have access to the cardbus
> bridge containing this card. I then logged the register accesses of the
> windows xp driver and tryed to analyse them.
>
> As the meanings of most of the register are still unknown to me, I consider
> this driver very experimental. It is possible that this driver might destroy
> your data or your hardware. Use at your own risk!
>
> Other problems:
> - I only implemented reading support
> - I only tested with a 128 MB SD card, no idea what would be needed to support
> other card types
> - irqs are not supported
> - dma is not supported
> - it is very slow
> - the registers can be found on the cardbus bridge and not on the virtual
> pcmcia card. The cardbus bridge is already claimed by yenta_socket.
> Therefore the driver currently uses pci_find_device to find the cardbus
- pci_find_device is no go today. Use pci_get_device (+ pci_dev_get, _put).
- ioremap->pci_iomap
- iobase should be __iomem.
- codingstyle (char* buffer, for(loop, if(data){, ...)
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Experimental driver for Ricoh Bay1Controller SD Card readers
Sascha Sommer wrote:
Hi,
Attached is a very experimental driver for a Ricoh SD Card reader that can be
found in some notebooks like the Samsung P35.
Whenever a sd card is inserted into one of these notebooks, a virtual pcmcia
card will show up:
Socket 0:
product info: RICOH, Bay1Controller, ,
manfid: 0x, 0x
In order to write this driver I hacked qemu to have access to the cardbus
bridge containing this card. I then logged the register accesses of the
windows xp driver and tryed to analyse them.
As the meanings of most of the register are still unknown to me, I consider
this driver very experimental. It is possible that this driver might destroy
your data or your hardware. Use at your own risk!
Other problems:
- I only implemented reading support
- I only tested with a 128 MB SD card, no idea what would be needed to support
other card types
- irqs are not supported
- dma is not supported
- it is very slow
- the registers can be found on the cardbus bridge and not on the virtual
pcmcia card. The cardbus bridge is already claimed by yenta_socket.
Therefore the driver currently uses pci_find_device to find the cardbus
- pci_find_device is no go today. Use pci_get_device (+ pci_dev_get, _put).
- ioremap-pci_iomap
- iobase should be __iomem.
- codingstyle (char* buffer, for(loop, if(data){, ...)
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Experimental driver for Ricoh Bay1Controller SD Card readers
Hi, Attached is a very experimental driver for a Ricoh SD Card reader that can be found in some notebooks like the Samsung P35. Whenever a sd card is inserted into one of these notebooks, a virtual pcmcia card will show up: Socket 0: product info: "RICOH", "Bay1Controller", "", "" manfid: 0x, 0x In order to write this driver I hacked qemu to have access to the cardbus bridge containing this card. I then logged the register accesses of the windows xp driver and tryed to analyse them. As the meanings of most of the register are still unknown to me, I consider this driver very experimental. It is possible that this driver might destroy your data or your hardware. Use at your own risk! Other problems: - I only implemented reading support - I only tested with a 128 MB SD card, no idea what would be needed to support other card types - irqs are not supported - dma is not supported - it is very slow - the registers can be found on the cardbus bridge and not on the virtual pcmcia card. The cardbus bridge is already claimed by yenta_socket. Therefore the driver currently uses pci_find_device to find the cardbus bridge containing the sd card reader registers. - it will probably crash when you remove the sd card without unmounting first - the ios stuff is not really understood - there are a bunch of extra MMC_APP_CMDs inside the driver - only tested with kernel 2.6.18 apart from all these problems reading an image from my sd card seems to have worked ;) If you are still brave enough to try it out make at least a backup of the data on your sd card. Feedback is highly appreciated. Regards Sascha KERNEL_VERSION = $(shell uname -r) KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc obj-m += sdricoh_cs.o default: $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules install: if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi install -D -m 644 *.ko $(MDIR) depmod -a clean: rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags rm -rf .tmp_versions sdricoh_cs.c.gz Description: GNU Zip compressed data
Experimental driver for Ricoh Bay1Controller SD Card readers
Hi, Attached is a very experimental driver for a Ricoh SD Card reader that can be found in some notebooks like the Samsung P35. Whenever a sd card is inserted into one of these notebooks, a virtual pcmcia card will show up: Socket 0: product info: RICOH, Bay1Controller, , manfid: 0x, 0x In order to write this driver I hacked qemu to have access to the cardbus bridge containing this card. I then logged the register accesses of the windows xp driver and tryed to analyse them. As the meanings of most of the register are still unknown to me, I consider this driver very experimental. It is possible that this driver might destroy your data or your hardware. Use at your own risk! Other problems: - I only implemented reading support - I only tested with a 128 MB SD card, no idea what would be needed to support other card types - irqs are not supported - dma is not supported - it is very slow - the registers can be found on the cardbus bridge and not on the virtual pcmcia card. The cardbus bridge is already claimed by yenta_socket. Therefore the driver currently uses pci_find_device to find the cardbus bridge containing the sd card reader registers. - it will probably crash when you remove the sd card without unmounting first - the ios stuff is not really understood - there are a bunch of extra MMC_APP_CMDs inside the driver - only tested with kernel 2.6.18 apart from all these problems reading an image from my sd card seems to have worked ;) If you are still brave enough to try it out make at least a backup of the data on your sd card. Feedback is highly appreciated. Regards Sascha KERNEL_VERSION = $(shell uname -r) KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc obj-m += sdricoh_cs.o default: $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules install: if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi install -D -m 644 *.ko $(MDIR) depmod -a clean: rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags rm -rf .tmp_versions sdricoh_cs.c.gz Description: GNU Zip compressed data
