1000 Cartões de Visita por 17,00
[1]Cartões Mais Barato Pensando no Produto mais barato que existe? Só aqui é mais barato! [2]Cartões de visita Para você vender mais e lucrar mais. [3]Varios pontos de distribuição em São paulo Entregas em todo Brasil [4]Cartões Mais Barato A Cartoes Mais Barato é contra o spam na rede. Caso você não queira receber nossos e-mails, clique neste [5]link. References 1. http://sorem.onda.com.br/sorem/click.php?s=3b2acc10de360834510fd6e70329c0afe=58817909b7b780614e210f39bef860c6u=http://www.cartoesmaisbarato.com.br 2. http://sorem.onda.com.br/sorem/click.php?s=3b2acc10de360834510fd6e70329c0afe=58817909b7b780614e210f39bef860c6u=http://www.cartoesmaisbarato.com.br/produtos/cartoes-de-visita-verniz-total-frente/5.htm 3. http://sorem.onda.com.br/sorem/click.php?s=3b2acc10de360834510fd6e70329c0afe=58817909b7b780614e210f39bef860c6u=http://cartoesmaisbarato.com.br/index/pontos 4. http://sorem.onda.com.br/sorem/click.php?s=3b2acc10de360834510fd6e70329c0afe=58817909b7b780614e210f39bef860c6u=http://www.cartoesmaisbarato.com.br 5. http://sorem.onda.com.br/sorem/optout.php?s=3b2acc10de360834510fd6e70329c0afe=58817909b7b780614e210f39bef860c6u=http://www.ondaexpress.com.br ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/153929: The umodem driver doesn't support the MTK 3329 GPS chipset.
On Thursday 13 January 2011 14:20:08 Hans Petter Selasky wrote:
The following reply was made to PR usb/153929; it has been noted by GNATS.
From: Hans Petter Selasky hsela...@c2i.net
To: Mykhaylo Yehorov yeho...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: usb/153929: The umodem driver doesn't support the MTK 3329 GPS
chipset. Date: Thu, 13 Jan 2011 14:12:41 +0100
On Thursday 13 January 2011 14:07:22 Mykhaylo Yehorov wrote:
These are changes for searching the closest unlocked data interface.
OK, I will see if I can get your patch committed [with some modifications
which I will do] in not so long.
--HPS
Hi Mykhaylo,
Can you verify the attached patch with your device?
--HPS
=== serial/umodem.c
==
--- serial/umodem.c (revision 218169)
+++ serial/umodem.c (local)
@@ -197,6 +197,8 @@
static usb_error_t umodem_set_comm_feature(struct usb_device *, uint8_t,
uint16_t, uint16_t);
static void umodem_poll(struct ucom_softc *ucom);
+static void umodem_find_data_iface(struct usb_attach_arg *uaa,
+ uint8_t, uint8_t *, uint8_t *);
static const struct usb_config umodem_config[UMODEM_N_TRANSFER] = {
@@ -311,13 +313,30 @@
0 - 1, UDESCSUB_CDC_UNION, 0 - 1);
if ((cud == NULL) || (cud-bLength sizeof(*cud))) {
- device_printf(dev, Missing descriptor.
+ DPRINTF(Missing descriptor.
Assuming data interface is next.\n);
- if (sc-sc_ctrl_iface_no == 0xFF)
+ if (sc-sc_ctrl_iface_no == 0xFF) {
goto detach;
- else
-sc-sc_data_iface_no =
-sc-sc_ctrl_iface_no + 1;
+ } else {
+uint8_t class_match = 0;
+
+/* set default interface number */
+sc-sc_data_iface_no = 0xFF;
+
+/* try to find the data interface backwards */
+umodem_find_data_iface(uaa,
+uaa-info.bIfaceIndex - 1,
+sc-sc_data_iface_no, class_match);
+
+/* try to find the data interface forwards */
+umodem_find_data_iface(uaa,
+uaa-info.bIfaceIndex + 1,
+sc-sc_data_iface_no, class_match);
+
+/* check if nothing was found */
+if (sc-sc_data_iface_no == 0xFF)
+ goto detach;
+ }
} else {
sc-sc_data_iface_no = cud-bSlaveInterface[0];
}
@@ -398,6 +417,36 @@
}
static void
+umodem_find_data_iface(struct usb_attach_arg *uaa,
+uint8_t iface_index, uint8_t *p_data_no, uint8_t *p_match_class)
+{
+ struct usb_interface_descriptor *id;
+ struct usb_interface *iface;
+
+ iface = usbd_get_iface(uaa-device, iface_index);
+
+ /* check for end of interfaces */
+ if (iface == NULL)
+ return;
+
+ id = usbd_get_interface_descriptor(iface);
+
+ /* check for non-matching interface class */
+ if (id-bInterfaceClass != UICLASS_CDC_DATA ||
+ id-bInterfaceSubClass != UISUBCLASS_DATA) {
+ /* if we got a class match then return */
+ if (*p_match_class)
+ return;
+ } else {
+ *p_match_class = 1;
+ }
+
+ DPRINTFN(11, Match at index %u\n, iface_index);
+
+ *p_data_no = id-bInterfaceNumber;
+}
+
+static void
umodem_start_read(struct ucom_softc *ucom)
{
struct umodem_softc *sc = ucom-sc_parent;
=== usbdevs
==
--- usbdevs (revision 218169)
+++ usbdevs (local)
@@ -536,6 +536,7 @@
vendor HAWKING 0x0e66 Hawking
vendor FOSSIL 0x0e67 Fossil, Inc
vendor GMATE 0x0e7e G.Mate, Inc
+vendor MEDIATEK 0x0e8d MediaTek, Inc.
vendor OTI 0x0ea0 Ours Technology
vendor YISO 0x0eab Yiso Wireless Co.
vendor PILOTECH 0x0eaf Pilotech
@@ -2120,6 +2121,9 @@
product MCT USB232 0x0210 USB-232 Interface
product MCT SITECOM_USB232 0x0230 Sitecom USB-232 Products
+/* MediaTek, Inc. */
+product MEDIATEK MTK3329 0x3329 MTK II GPS Receiver
+
/* Meizu Electronics */
product MEIZU M6_SL 0x0140 MiniPlayer M6 (SL)
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/153929: The umodem driver doesn't support the MTK 3329 GPS chipset.
The following reply was made to PR usb/153929; it has been noted by GNATS.
From: Hans Petter Selasky hsela...@c2i.net
To: freebsd-usb@freebsd.org
Cc: Mykhaylo Yehorov yeho...@gmail.com,
freebsd-gnats-sub...@freebsd.org
Subject: Re: usb/153929: The umodem driver doesn't support the MTK 3329 GPS
chipset.
Date: Wed, 2 Feb 2011 19:35:13 +0100
--Boundary-00=_hPaSN1ZTrNWJk0m
Content-Type: Text/Plain;
charset=iso-8859-15
Content-Transfer-Encoding: 7bit
On Thursday 13 January 2011 14:20:08 Hans Petter Selasky wrote:
The following reply was made to PR usb/153929; it has been noted by GNATS.
From: Hans Petter Selasky hsela...@c2i.net
To: Mykhaylo Yehorov yeho...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: usb/153929: The umodem driver doesn't support the MTK 3329 GPS
chipset. Date: Thu, 13 Jan 2011 14:12:41 +0100
On Thursday 13 January 2011 14:07:22 Mykhaylo Yehorov wrote:
These are changes for searching the closest unlocked data interface.
OK, I will see if I can get your patch committed [with some modifications
which I will do] in not so long.
--HPS
Hi Mykhaylo,
Can you verify the attached patch with your device?
--HPS
--Boundary-00=_hPaSN1ZTrNWJk0m
Content-Type: text/x-patch;
charset=iso-8859-15;
name=umodem.patch
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename=umodem.patch
=== serial/umodem.c
==
--- serial/umodem.c(revision 218169)
+++ serial/umodem.c(local)
@@ -197,6 +197,8 @@
static usb_error_t umodem_set_comm_feature(struct usb_device *, uint8_t,
uint16_t, uint16_t);
static void umodem_poll(struct ucom_softc *ucom);
+static void umodem_find_data_iface(struct usb_attach_arg *uaa,
+ uint8_t, uint8_t *, uint8_t *);
static const struct usb_config umodem_config[UMODEM_N_TRANSFER] = {
@@ -311,13 +313,30 @@
0 - 1, UDESCSUB_CDC_UNION, 0 - 1);
if ((cud == NULL) || (cud-bLength sizeof(*cud))) {
- device_printf(dev, Missing descriptor.
+ DPRINTF(Missing descriptor.
Assuming data interface is next.\n);
- if (sc-sc_ctrl_iface_no == 0xFF)
+ if (sc-sc_ctrl_iface_no == 0xFF) {
goto detach;
- else
- sc-sc_data_iface_no =
- sc-sc_ctrl_iface_no + 1;
+ } else {
+ uint8_t class_match = 0;
+
+ /* set default interface number */
+ sc-sc_data_iface_no = 0xFF;
+
+ /* try to find the data interface backwards */
+ umodem_find_data_iface(uaa,
+ uaa-info.bIfaceIndex - 1,
+ sc-sc_data_iface_no, class_match);
+
+ /* try to find the data interface forwards */
+ umodem_find_data_iface(uaa,
+ uaa-info.bIfaceIndex + 1,
+ sc-sc_data_iface_no, class_match);
+
+ /* check if nothing was found */
+ if (sc-sc_data_iface_no == 0xFF)
+ goto detach;
+ }
} else {
sc-sc_data_iface_no = cud-bSlaveInterface[0];
}
@@ -398,6 +417,36 @@
}
static void
+umodem_find_data_iface(struct usb_attach_arg *uaa,
+uint8_t iface_index, uint8_t *p_data_no, uint8_t *p_match_class)
+{
+ struct usb_interface_descriptor *id;
+ struct usb_interface *iface;
+
+ iface = usbd_get_iface(uaa-device, iface_index);
+
+ /* check for end of interfaces */
+ if (iface == NULL)
+ return;
+
+ id = usbd_get_interface_descriptor(iface);
+
+ /* check for non-matching interface class */
+ if (id-bInterfaceClass != UICLASS_CDC_DATA ||
+ id-bInterfaceSubClass != UISUBCLASS_DATA) {
+ /* if we got a class match then return */
+ if (*p_match_class)
+ return;
+ } else {
+ *p_match_class = 1;
+ }
+
+ DPRINTFN(11, Match at index %u\n, iface_index);
+
+ *p_data_no = id-bInterfaceNumber;
+}
+
+static void
umodem_start_read(struct ucom_softc *ucom)
{
struct umodem_softc *sc = ucom-sc_parent;
=== usbdevs
==
--- usbdevs(revision 218169)
+++ usbdevs(local)
@@ -536,6 +536,7 @@
vendor HAWKING0x0e66 Hawking
vendor FOSSIL 0x0e67 Fossil, Inc
vendor
Re: libusb performance on 8.1
On 28/01/2011, at 18:28, Hans Petter Selasky wrote: For this kind of applications ISOCHRONOUS transfers should be used. Then you can have a double buffer guard in the range 1-56ms, regardless of the buffer size the hardware uses. That sounds nice :) I am trying to get it working at the moment, however I'm only finding it capable of 4 or 8 Mb/sec (512 or 1024 byte EP), although perhaps I don't understand how to do ISO transfer properly. BTW do you have a feel for the latency in bulk vs iso? I currently have 5-10 msec of buffering in the hardware which I plan on increasing but I'm not sure what a reasonable amount would be :) I put a logic analyser on my board and it shows fairly regular requests from the hardware (16kbyte bursts every 2msec or so) however I see glitches occasionally - 5.5ms, 7.5ms. I am not sure if they are attributable to userland scheduling (in which case writing a kernel driver should help) or some subtlety in USB itself. Thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: libusb performance on 8.1
On Thursday 03 February 2011 07:56:25 Daniel O'Connor wrote: On 28/01/2011, at 18:28, Hans Petter Selasky wrote: For this kind of applications ISOCHRONOUS transfers should be used. Then you can have a double buffer guard in the range 1-56ms, regardless of the buffer size the hardware uses. That sounds nice :) I am trying to get it working at the moment, however I'm only finding it capable of 4 or 8 Mb/sec (512 or 1024 byte EP), although perhaps I don't understand how to do ISO transfer properly. Hi, You need to set the multiplier to 2 or 3. Then you get 3*1024 bytes at maximum. BTW do you have a feel for the latency in bulk vs iso? I currently have 5-10 msec of buffering in the hardware which I plan on increasing but I'm not sure what a reasonable amount would be :) I put a logic analyser on my board and it shows fairly regular requests from the hardware (16kbyte bursts every 2msec or so) however I see glitches occasionally - 5.5ms, 7.5ms. I am not sure if they are attributable to userland scheduling (in which case writing a kernel driver should help) or some subtlety in USB itself. Are you using two isochronous transfers or just one? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
