Menu
▾
▴
sdio-linux-devel — mail list for SDIO users and developers
You can subscribe to this list here.
| 2007 |
Jan
(3) |
Feb
(2) |
Mar
(6) |
Apr
(11) |
May
(4) |
Jun
(20) |
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Daniel C. <dc...@po...> - 2010-02-10 06:20:50
|
On Tue, Feb 9, 2010 at 11:07 PM, Paul Lever <Pau...@at...> wrote: > The AR6001 is not compatible with the ath9k driver. Sorry, I meant ar6k, e.g. the driver available as part of this project or maybe http://svn.openmoko.org/developers/sameo/patches (the ath9k list seems to be used occasionally to discuss things other than ath9k, such as the atheros 5k, ar9170 usb, and 6k lines.) BTW I found another possibility, but no one seems to resell them (except perhaps http://www.wpi-group.com/ ) so I'm waiting to see if I get replies to some email sent today to Aiconn and WPG. Aiconn Dual Bands WiFi SDIO Card – WM3536A WM3536A is a 11a/b/g WiFi SDIO card designed to mechanically fit the standard SD socket. It uses Atheros AR6001 chipset which performs best in 11a bands and we can provide similar driver supports as WM3236AQ/WS178Q. http://www.aiconn.com.tw/newsite/product_006.htm Thanks for pointing out the incorrectness, -- Daniel JB Clark | Free Software Activist | http://pobox.com/~dclark |
|
From: Daniel C. <dc...@po...> - 2010-02-10 04:06:47
|
Does anyone know of a source for Atheros AR6001 (ath9k driver) based SDIO cards suitable for end-user use that are compatible with sdio-linux, or have any unused ones they would be willing to sell? History: http://thread.gmane.org/gmane.linux.drivers.ath9k.devel/2625/focus=3230 Thanks, -- Daniel JB Clark | Free Software Activist | http://pobox.com/~dclark |
|
From: Uri S. <ur...@ya...> - 2007-07-30 08:33:18
|
Hi,=0A=0A=0AMy name is Uri Shkolnik, and I'm Software Architect at Siano Mo= bile Silicon, Inc.=0A=0ASiano is a leading company in MDTV (Mobile Digital = TV), see http://www.siano-ms.com and numerous Internet references.=0A=0ASia= no products (also) have an SDIO interface, and they had already been ported= to many environments (Such as Nucleus, Windows Mobile, Windows CE, REX, an= d more).=0A=0AUntil now Siano has proprietary SDIO stack for Linux, "solder= ed" to the target hardware.=0A=0AWith the publication of the community SDIO= stack, we (at Siano) decided that we prefer to make our products to work w= ith it, instead of the proprietary stack option.=0A=0AHowever, we do not ha= ve Linux kernel gurus, and our R&D Linux kernel knowledge is moderate.=0A= =0ASince the task is quite big (add MDTV to the exist function section is f= ar from been trivial, and that is just one issue), I would like to ask if s= omeone from the SDIO stack developers, and/or some other guru would like to= help & monitor our work.=0A=0A=0ABest Regards,=0A=0AUri Shkolnik=0A=0A=0A= =0A =0A=0A=0A=0A=0A ________________________________________________= ____________________________________=0ALuggage? GPS? Comic books? =0ACheck = out fitting gifts for grads at Yahoo! Search=0Ahttp://search.yahoo.com/sear= ch?fr=3Doni_on_mail&p=3Dgraduation+gifts&cs=3Dbz |
|
From: Kari N. <ka...@gm...> - 2007-07-26 07:11:13
|
Hi, I have tested pharos GPS received for some while now, there seams to be some problem in NMEA messages. Quite regularly I get messages where check sum doesn't match for example >$GPGSV,3,3,12,02,00,000,,30,00,000,,01,00,000,,26,0,000,*7E I don't have NMEA specifications but according to http://www.kh-gps.de/nmea-faq.htm I can "decode" message, it seams to lack one 0 after ,,26,0 (corrected message below) >$GPGSV,3,3,12,02,00,000,,30,00,000,,01,00,000,,26,00,000,*7E No the check sum is correct. No traces for uart overrun can be seen (I had all traces on). The errors seam to increase when processing increases on my HW (not in GPS module), so seams to be problem in uart reading. Any ideas, how to continue solving this problem? PS. noticed little bug in uart initialization WriteRegister(pDevice, UART_FIFO_CNTRL_REG, UART_DATA_8_BITS | UART_FIFO_ENABLE); should clearly be WriteRegister(pDevice, UART_FIFO_CNTRL_REG, UART_FIFO_TRIGGER_8 | UART_FIFO_ENABLE); but didn't help at all. Tried with other FIFO triggers, had no effect |
|
From: Nicolas P. <ni...@ca...> - 2007-07-23 00:07:45
|
FYI Nicolas ---------- Forwarded message ---------- Date: Sun, 22 Jul 2007 18:52:44 +0200 From: Pierre Ossman <drz...@dr...> To: LKML <lin...@vg...> Cc: Nicolas Pitre <ni...@ca...> Subject: [ANNOUNCE] SDIO soon in mainline I am happy to announce that SDIO support will soon be a standard feature in Linux. No more proprietary stacks with all the troubles (legal and technical) that go with them. The new code is written from scratch by yours truly and Nicolas Pitre. There were several stacks out there that were recently made available under the GPL, but none of them were in any shape to be merged into the kernel. Current status is that basic functionality is in place. There is a driver model (with device matching and module auto-loading) and functions for easy register access. It is also possible to receive interrupts from the card. There is only one driver in the tree right now (for the standard GPS interface), but it should be complete enough for everyone to see how the API works. The pieces still missing are mostly performance related: - No clock speed change. - No wide bus support - Interrupts are polled - No support for combo (mem+IO) cards The last point is unlikely to change as neither Nicolas nor I currently possess such a card. As usual, patches/hardware is welcome. So what we'd like to see now is extensive testing. Try the stack out on every MMC controller you can find and review as much of the code as possible. With some luck, we'll be able to get this ready in time for the next merge window. You can find the code in -mm and as just the SDIO stuff on top of Linus' tree: git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git#sdio (PS. I've posted this both to LKML and LAKML. Interested readers should probably check both lists for replies) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org |
|
From: Nicolas P. <ni...@ca...> - 2007-07-18 19:06:00
|
On Wed, 18 Jul 2007, Paul Lever wrote: > The GPS interface is a rather inefficient continuous stream of cmd52's > over the bus. On slow machine it may not keep up. You could turn on some > of the debug messages in the GPS driver and see what is coming in off > the device. BTW, the SDIO code scheduled for mainline integration available from git://git2.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git in the "sdio" branch has a fully functional and rock solid GPS driver now. It works fine, even with polled IRQs, with no noticeable load on the system. I invite anyone interested to have a look and even contribute more drivers and/or improvements if possible. Nicolas |
|
From: Paul L. <pl...@at...> - 2007-07-18 18:00:54
|
I'm not sure if you didn't add in another truncation with the=20 (pInstance->Size* 1024). Paul L ________________________________ From: Kari Nalli [mailto:ka...@gm...]=20 Sent: Wednesday, July 18, 2007 1:41 AM To: sdi...@li... Subject: [Sdio-linux-devel] bug in sdio_memory_os.c? Hi, I had some problems with 128MB SD memory card=20 ----------------clip from log-------------- [ 443.115173] +SDIO Memory Function: CreateDisk=20 [ 443.119995] SDIO Memory Function: block size 512=20 [ 443.124847 ] SDIO Memory Function: setting block size 512=20 [ 443.130615] SDIO Memory Function: setting up DMA=20 [ 443.135681] SDIO Memory Function: CreateDisk: size 245760 (Size=20 123008, FileSysBlockSize 512)=20 =2E.. and later...=20 [ 445.515045] -SDIO Memory Function: AsyncCompletionLast=20 [ 445.521118] p1=20 [ 445.522979] sdmem0: p1 exceeds device capacity ----------------clip from log-------------- Now looking at code on sdio_memory_os.c:=20 set_capacity(pInstance->Config.pGenDisk,pInstance->Size/pInstance-=20 >FileSysBlockSize*1024); This causes rounding errors and disk size 245760 after changing code to set_capacity(pInstance-> Config.pGenDisk , (pInstance->Size*=20 1024)/pInstance->FileSysBlockSize); The 128 MB card is functional (card has only one partition) and=20 /sys/block/sdmem0/sdmem0p1# more size -> 245919 sectors which is bigger=20 than originally calculated (245760)=20 So is this bug on driver or is there some reason way calculation was=20 originally done way it was? BR, Kari |
|
From: Paul L. <pl...@at...> - 2007-07-18 16:12:57
|
The GPS interface is a rather inefficient continuous stream of cmd52's=20
over the bus. On slow machine it may not keep up. You could turn on some=20
of the debug messages in the GPS driver and see what is coming in off=20
the device.
Paul L
________________________________
From: boku [mailto:bok...@gm...]=20
Sent: Wednesday, July 18, 2007 4:43 AM
To: sdi...@li...
Subject: [Sdio-linux-devel] Using cat pharos GPS data
Hi,
I use cat /dev/ttyxx to check if there's data from pharos GPS. It=20
did output some text data such
$GP.... 0,50.0,50.0*05=20
But why the "cat" doesn't quit? It just hanged there unless I type=20
"Ctrl+C" to quit.=20
Is it correct?=20
=20
<ps> I checked some message and found while upper application uses=20
gps_start_tx() and it did use CMD 52 to write pharos UART IER register.=20
After that, it is hanged.=20
=20
BR,=20
Victor
|
|
From: boku <bok...@gm...> - 2007-07-18 11:43:13
|
Hi,
I use cat /dev/ttyxx to check if there's data from pharos GPS. It did
output some text data such
$GP.... 0,50.0,50.0*05
But why the "cat" doesn't quit? It just hanged there unless I type "Ctrl+C"
to quit.
Is it correct?
<ps> I checked some message and found while upper application uses
gps_start_tx() and it did use CMD 52 to write pharos UART IER register.
After that, it is hanged.
BR,
Victor
|
|
From: Kari N. <ka...@gm...> - 2007-07-18 08:40:53
|
Hi, I had some problems with 128MB SD memory card ----------------clip from log-------------- [ 443.115173] +SDIO Memory Function: CreateDisk [ 443.119995] SDIO Memory Function: block size 512 [ 443.124847 ] SDIO Memory Function: setting block size 512 [ 443.130615] SDIO Memory Function: setting up DMA [ 443.135681] SDIO Memory Function: CreateDisk: size 245760 (Size 123008, FileSysBlockSize 512) ... and later... [ 445.515045] -SDIO Memory Function: AsyncCompletionLast [ 445.521118] p1 [ 445.522979] sdmem0: p1 exceeds device capacity ----------------clip from log-------------- Now looking at code on sdio_memory_os.c: set_capacity(pInstance->Config.pGenDisk,pInstance->Size/pInstance- >FileSysBlockSize*1024); This causes rounding errors and disk size 245760 after changing code to set_capacity(pInstance->Config.pGenDisk , (pInstance->Size* 1024)/pInstance->FileSysBlockSize); The 128 MB card is functional (card has only one partition) and /sys/block/sdmem0/sdmem0p1# more size -> 245919 sectors which is bigger than originally calculated (245760) So is this bug on driver or is there some reason way calculation was originally done way it was? BR, Kari |
|
From: Paul L. <pl...@at...> - 2007-07-17 16:43:46
|
In the function driver's PSDFUNCTION pFunction structure there is a
pContext member. You can use this for whatever the driver needs. The
samples in src/function use this.
=20
Regards
=20
Paul
_____ =20
From: Leon lee [mailto:as...@ms...]=20
Sent: Tuesday, July 17, 2007 9:19 AM
To: sdi...@li...
Subject: [Sdio-linux-devel] About device information
Hi,
I am porting our wireless product to Linux.
I think that the register/unregister functions of SDIO stack are similar
to those of PCI.
However, pci allows us to store private data=20
pci_set_drvdata(pci_dev, net_dev);=20
In other word, we need to use global variable to store our private data.
Check AR6000 :
function/wlan/ar6000/hif/hif.c
TARGET_FUNCTION_CONTEXT FunctionContext =3D {
.function.pProbe =3D hifDeviceInserted,=20
.function.pRemove =3D hifDeviceRemoved,
}
hifDeviceInserted(SDFUNCTION *function, SDDEVICE *handle)
{
device =3D addHifDevice(handle); <=3D=3D=3D=3D=3D hifDevice[=
0]
}
hifDeviceRemoved(SDFUNCTION *function, SDDEVICE *handle)=20
{
device =3D getHifDevice(handle); <=3D=3D=3D=3D=3D=3D hifDevi=
ce[0]
}
Therefore, I think that we can follow the method of PCI to store device
information
linux/pci.h
struct pci_dev {
struct device dev; /* Generic device interface */=20
}
static inline void pci_set_drvdata (struct pci_dev *pdev, void *data);
Any suggestion ?
Regards,
Leon
|
|
From: Leon l. <as...@ms...> - 2007-07-17 16:19:27
|
Hi,
I am porting our wireless product to Linux.
I think that the register/unregister functions of SDIO stack are similar to
those of PCI.
However, pci allows us to store private data
pci_set_drvdata(pci_dev, net_dev);
In other word, we need to use global variable to store our private data.
Check AR6000 :
function/wlan/ar6000/hif/hif.c
TARGET_FUNCTION_CONTEXT FunctionContext = {
.function.pProbe = hifDeviceInserted,
.function.pRemove = hifDeviceRemoved,
}
hifDeviceInserted(SDFUNCTION *function, SDDEVICE *handle)
{
device = addHifDevice(handle); <===== hifDevice[0]
}
hifDeviceRemoved(SDFUNCTION *function, SDDEVICE *handle)
{
device = getHifDevice(handle); <====== hifDevice[0]
}
Therefore, I think that we can follow the method of PCI to store device
information
linux/pci.h
struct pci_dev {
struct device dev; /* Generic device interface */
}
static inline void pci_set_drvdata (struct pci_dev *pdev, void *data);
Any suggestion ?
Regards,
Leon
|
|
From: Paul L. <pl...@at...> - 2007-07-10 03:59:50
|
It is just exposed as a serial port device. You can cat the contents.
Paul
-----Original Message-----
From: boku [mailto:bok...@gm...]=20
Sent: Monday, July 09, 2007 7:34 PM
To: sdi...@li...
Subject: [Sdio-linux-devel] How to testing Pharos GPS?
Hi,
I've got a Pharos gps and try to test if it works in sdio-linux=20
stack with the functional driver. I check /proc/devices and found=20
there's a ttyGPS node with major number 254. So what next could I do to=20
test it? Use gpsd or some other direct UART command?
Thank you!
Regards,
------------------------------------------------------------------------
-
This SF.net email is sponsored by DB2 Express Download DB2 Express C -=20
the FREE version of DB2 express and take control of your XML. No limits.=20
Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Sdio-linux-devel mailing list
Sdi...@li...
https://lists.sourceforge.net/lists/listinfo/sdio-linux-devel
|
|
From: boku <bok...@gm...> - 2007-07-10 02:34:05
|
Hi,
I've got a Pharos gps and try to test if it works in sdio-linux
stack with the functional driver. I check /proc/devices and found
there's a ttyGPS node with major number 254. So what next could I do
to test it? Use gpsd or some other direct UART command?
Thank you!
Regards,
|
|
From: boku <bok...@gm...> - 2007-07-03 11:31:48
|
Hi,
I'm porting my BT device to the SDIO stack protocols, the problem I met
while probing the BT function driver is the func class in the BT function
driver can be specified as 0x02 and 0x03 but the number read from my BT
device is 0x01. I'd like to ask:
1. Is the 0x02, 0x03 func class are defined in SDIO spec for bluetooth
devices?
2. Could I add 0x01 to the Ids[] in the sdio_bt_os.c?
static SD_PNP_INFO Ids[] = {
{.SDIO_FunctionClass = 0x02}, /* SDIO-BLUETOOTH SDIO standard interface
code */
{.SDIO_FunctionClass = 0x03},
{}
};
Thanks~
|
|
From: boku <bok...@gm...> - 2007-06-22 01:56:51
|
Hi,
Is there any statistics about the data transfer performance for SD
memory disk such as using iozone etc?
Thank you~
Regards,
|
|
From: Paul L. <pl...@at...> - 2007-06-18 23:41:27
|
The PCI interface portion of the standard host controller driver is a very small part of the code. It can be easily be replaced with code that sets the appropriate addresses for the Std host controller registers in a local bus connected Std Host Controller. This has been done a number of times. =20 Paul _____ =20 From: Ravi Patel [mailto:re...@gm...]=20 Sent: Monday, June 18, 2007 4:34 PM To: sdi...@li... Subject: [Sdio-linux-devel] Non-PCI SDIO HCD Driver Hi, I wanted to know that does the SDIO Linux framework supports Non-PCI SDIO Host Controller Device. If not, does anyone has non-pci driver version for SDIO_STDHCD Thanks, Ravi |
|
From: Ravi P. <re...@gm...> - 2007-06-18 23:34:11
|
Hi, I wanted to know that does the SDIO Linux framework supports Non-PCI SDIO Host Controller Device. If not, does anyone has non-pci driver version for SDIO_STDHCD Thanks, Ravi |
|
From: Paul L. <pl...@at...> - 2007-06-14 16:36:19
|
You can use the standard Linux network utils for the WLAN card. You can
use the BlueZ tools for Bluetooth. You can just dump a serial port for
GPS.
=20
Paul
_____ =20
From: boku [mailto:bok...@gm...]=20
Sent: Thursday, June 14, 2007 2:22 AM
To: sdi...@li...
Subject: [Sdio-linux-devel] Applications for SDIO functions
Hi,
I checked those supported devices for this project currently. But
don't know whether I can verify or run applications on the devices
through this sdio driver architectures. Does the manufacturers support
their respective applications to run the devices?=20
I didn't see any info about such usage, especially on GPS and Bluetooth
devices. (As for WLAN, we should be able to use Linux network utilities,
right?)=20
=20
Regards,=20
=20
|
|
From: boku <bok...@gm...> - 2007-06-14 09:21:45
|
Hi,
I checked those supported devices for this project currently. But don't
know whether I can verify or run applications on the devices through this
sdio driver architectures. Does the manufacturers support their respective
applications to run the devices?
I didn't see any info about such usage, especially on GPS and Bluetooth
devices. (As for WLAN, we should be able to use Linux network utilities,
right?)
Regards,
|
|
From: boku <bok...@gm...> - 2007-06-14 08:23:10
|
Hi,
Finally, the SD mem can mounted to file system. The only difference I
try is to create a no-partition number device for 254,0.
And mount my sd card to it.
WHy are there such difference by using (254,0) and (254,1)?
Anyway, I'll procede to test the read/write functions on the sd mem card.
Thank you!
Regards,
|
|
From: Paul L. <pl...@at...> - 2007-06-14 04:11:16
|
Yes
_____ =20
From: boku [mailto:bok...@gm...]=20
Sent: Wednesday, June 13, 2007 9:00 PM
To: sdi...@li...
Subject: [Sdio-linux-devel] Can SDHC use interrupt to handle the
multiple block data completion even if No DMA
Hi,=20
As title, will the behavior okay even under the situation?=20
Is it related to the bus driver's ASYNC or SYNC operation behaviors?=20
=20
Thank you!
Regards,
=20
|
|
From: boku <bok...@gm...> - 2007-06-14 04:00:15
|
Hi,
As title, will the behavior okay even under the situation?
Is it related to the bus driver's ASYNC or SYNC operation behaviors?
Thank you!
Regards,
|
|
From: Nicolas P. <ni...@ca...> - 2007-06-12 17:04:19
|
On Tue, 12 Jun 2007, Werner Almesberger wrote: > Nicolas Pitre wrote: > > Because of that, if you're targeting the latest mainline kernel, I > > strongly suggest that you consider writing a host driver for the > > existing MMC/SD stack in mainline. The current SDIO effort is based on > > that. > > Okay, I'll have a look at it. How far is AR6001 support from working > with the "new" SDIO stack ? We need that rather urgently, at least at > a proof of concept level. It is still a bit far off. > If AR6001 will take some time to work with the "new" stack, the best > approach is probably if we use sdio-linux with an old kernel for our > hardware testing, and then work with the "new" stack in parallel. Most probably the best course of action if you're in a hurry. Nicolas |
|
From: Werner A. <we...@op...> - 2007-06-12 16:50:10
|
Nicolas Pitre wrote: > I'm currently working closely with Pierre Ossman to add SDIO support > into mainline. Perfect ! > While the sdio-linux code base has its value as an already functional > SDIO stack, it has some structural and major style issues that makes it > impossible to ever be considered for mainline. Yup :-( > Because of that, if you're targeting the latest mainline kernel, I > strongly suggest that you consider writing a host driver for the > existing MMC/SD stack in mainline. The current SDIO effort is based on > that. Okay, I'll have a look at it. How far is AR6001 support from working with the "new" SDIO stack ? We need that rather urgently, at least at a proof of concept level. If AR6001 will take some time to work with the "new" stack, the best approach is probably if we use sdio-linux with an old kernel for our hardware testing, and then work with the "new" stack in parallel. Thanks, - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina we...@al... / /_http://www.almesberger.net/____________________________________________/ |
1 message has been excluded from this view by a project administrator.
