osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: Re: Oxford Semiconductor's OXCB950 in 8250_pci.c -
msg#00042

List: linux.serial

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

On Wed, 10 May 2006 20:20:49 +0100
Russell King <rmk@xxxxxxxxxxxxxxxx> wrote:

> > > This should probably be pbn_b0_1_115200?
> >
> > The reason was (from the discussion mentioned):
> > > pbn_b0_bt_1_115200 has been used instead
> > > of pbn_b0_1_115200, because the latter is identical to
> > > pbn_default, and the effect should be the same since
> > > OXCB950 is single-port.
> >
> > Seems it is not the problem here (as card partially works). Or should I
> > try changing it?
>
> The reason given there is no longer valid, and is just a preference.
Changed.

> What happens if you:
>
> 1. setserial /dev/ttyS4 spd_cust divisor 104
> 2. set the baud rate to 38400 baud
I got 9600!

> If what I think has happened is correct, 104 should approximate 9600 baud,
> 52 should approximate 19200 baud, 26 should be 38400 baud, and 17 should
> approximate 57600 baud.
Yes, all this is correct, 'CONNECT...' string is the same as in MS Win.
Thanks!

What should be done to avoid such tricks in userspace and how to get
full 'divisor <-> result rate' list?

> It would be helpful if you could confirm that the modem does report the
> real DTE data rate under Windows.
Results:
'Port set to' 'Modem Reports on connect (first is DTE rate)'
300 CONNECT 230400/V34/LAPM/V42B/TX=28800/RX=31200
1200 CONNECT 230400/V34/LAPM/V42B/TX=28800/RX=31200
2400 CONNECT 230400/V34/LAPM/V42B/TX=28800/RX=31200
4800 CONNECT 4800/V34/LAPM/V42B/TX=4800/RX=4800
9600 CONNECT 9600/V34/LAPM/V42B/TX=9600/RX=9600
19200 CONNECT 19200/V34/LAPM/V42B/TX=19200/RX=19200
38400 CONNECT 38400/V34/LAPM/V42B/TX=28800/RX=31200
57600 CONNECT 57600/V34/LAPM/V42B/TX=28800/RX=31200
115200 CONNECT 115200/V34/LAPM/V42B/TX=28800/RX=31200
It seems to be real from 4800 to 115200 (with the same serial card).
On speeds lower than 4800 it looks odd as I can not talk to modem on
such speed.


--
Mikhail Kolesnik
ICQ: 260259143
IRC: mike_k at freenode/#crux, rusnet/#yalta
Jabber: mike_k@xxxxxxxxxxxxxxxx
NIC handle: MKK83-UANIC
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html



Thread at a glance:

Previous Message by Date:

Fw: Re: Oxford Semiconductor's OXCB950 in 8250_pci.c

Hope it is ok forwarding the message as my reply to it seems to be lost somewhere... Begin forwarded message: Date: Wed, 10 May 2006 20:20:49 +0100 From: Russell King <rmk@xxxxxxxxxxxxxxxx> To: Mikhail Kolesnik <mike@xxxxxxxxxxxxxx> Subject: Re: Oxford Semiconductor's OXCB950 in 8250_pci.c On Wed, May 10, 2006 at 09:10:13PM +0300, Mikhail Kolesnik wrote: > On Wed, 10 May 2006 17:36:32 +0100 > Russell King <rmk@xxxxxxxxxxxxxxxx> wrote: > > > On Sun, May 07, 2006 at 10:59:42PM +0300, Mikhail Kolesnik wrote: > > > ... > > > + { PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_CB950, > > > + PCI_ANY_ID, PCI_ANY_ID, 0, 0, > > > + pbn_b0_bt_1_115200 }, > > > > This should probably be pbn_b0_1_115200? > > The reason was (from the discussion mentioned): > > pbn_b0_bt_1_115200 has been used instead > > of pbn_b0_1_115200, because the latter is identical to > > pbn_default, and the effect should be the same since > > OXCB950 is single-port. > > Seems it is not the problem here (as card partially works). Or should I > try changing it? The reason given there is no longer valid, and is just a preference. > > > The problem is that card only works with baud rates from 50 to 2400. > > > The card is connected to a common external modem, which is known to > > > work with any reasonable rates in other PC. > > > > Odd. Maybe the port isn't clocked at the usual frequency, and 115200 > > is the wrong base. > > Is that datasheet of any use here? No - such devices can be used with multiple differing crystals, and the data sheet allows the device to be used with crystals up to 60MHz! > > Well, 1.8432MHz corresponds with a base of 115200, so that's not wrong. > > IS your modem showing the DTE speed in that connect line? If so, 2400 > > baud seems to actually correspond with 230400 baud, which would be a > > rather interesting state of affairs. What does setserial -bav /dev/ttyS4 > > say? > > Yes, the first number is 'DTE data rate' (but modem's chip datasheet > claims it does not support DTE higher than 115200). Note, with ANY > baud from 300 to 2400 result is: > "CONNECT 230400/Vxx/LAPM/Vxxx/TX=xxxxx/RX=xxxxx" > But bauds lower than 1200 do really limit speed. > > # setserial -bav /dev/ttyS4 > /dev/ttyS4, Line 4, UART: 16950/954, Port: 0x3010, IRQ: 11 > Baud_base: 115200, close_delay: 50, divisor: 0 > closing_wait: 3000 > Flags: spd_normal skip_test > > Changing divisor to 8.625 (it is reported to be '8') gave nothing. The "divisor" doesn't do anything in this mode. What happens if you: 1. setserial /dev/ttyS4 spd_cust divisor 104 2. set the baud rate to 38400 baud If what I think has happened is correct, 104 should approximate 9600 baud, 52 should approximate 19200 baud, 26 should be 38400 baud, and 17 should approximate 57600 baud. It would be helpful if you could confirm that the modem does report the real DTE data rate under Windows. I hope that each time you test this it doesn't cost. 8/ -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Date:

PM fromVicky

Hi, em..... I gotta tell you something. Some years ago I used to watch porno often. I always admired those guys cumming. They splashed out so much sperm on their girls, it looked so cool, so manlike. Now I have a girlfriend.. but quantity of my sperm was so scanty, that I felt ill at ease. I was advised to eat green apples but even this didn't help. A month ago I was hanging around at the bar with my best friend. And he said that I should try MAX LOADS. Well, - I thought, - sounds interesting. Next day I came to know that it was really a highly effective all-natural dietary supplement, which not only increases the sperm volume but also improves the sperm quality and the mobility of spermatozoa. Having ordered and tried I was shocked how cool it was. I'd even say, it changed my life. I'm happy. I even became a better lover, knowing how it all would end. By the way, read about MAX LOADS at this site: http://www.weallcreatethis.com/ Yes, that guys have really acceptable prices if you decide to order and ship worldwide. http://www.weallcreatethis.com/ spec you abbe me, utensil . today you banquet me, cajole sniffle . degum you digestion me, burtt cost zinc confession . http://www.weallcreatethis.com/c82/ - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Previous Message by Thread:

Fw: Re: Oxford Semiconductor's OXCB950 in 8250_pci.c

Hope it is ok forwarding the message as my reply to it seems to be lost somewhere... Begin forwarded message: Date: Wed, 10 May 2006 20:20:49 +0100 From: Russell King <rmk@xxxxxxxxxxxxxxxx> To: Mikhail Kolesnik <mike@xxxxxxxxxxxxxx> Subject: Re: Oxford Semiconductor's OXCB950 in 8250_pci.c On Wed, May 10, 2006 at 09:10:13PM +0300, Mikhail Kolesnik wrote: > On Wed, 10 May 2006 17:36:32 +0100 > Russell King <rmk@xxxxxxxxxxxxxxxx> wrote: > > > On Sun, May 07, 2006 at 10:59:42PM +0300, Mikhail Kolesnik wrote: > > > ... > > > + { PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_CB950, > > > + PCI_ANY_ID, PCI_ANY_ID, 0, 0, > > > + pbn_b0_bt_1_115200 }, > > > > This should probably be pbn_b0_1_115200? > > The reason was (from the discussion mentioned): > > pbn_b0_bt_1_115200 has been used instead > > of pbn_b0_1_115200, because the latter is identical to > > pbn_default, and the effect should be the same since > > OXCB950 is single-port. > > Seems it is not the problem here (as card partially works). Or should I > try changing it? The reason given there is no longer valid, and is just a preference. > > > The problem is that card only works with baud rates from 50 to 2400. > > > The card is connected to a common external modem, which is known to > > > work with any reasonable rates in other PC. > > > > Odd. Maybe the port isn't clocked at the usual frequency, and 115200 > > is the wrong base. > > Is that datasheet of any use here? No - such devices can be used with multiple differing crystals, and the data sheet allows the device to be used with crystals up to 60MHz! > > Well, 1.8432MHz corresponds with a base of 115200, so that's not wrong. > > IS your modem showing the DTE speed in that connect line? If so, 2400 > > baud seems to actually correspond with 230400 baud, which would be a > > rather interesting state of affairs. What does setserial -bav /dev/ttyS4 > > say? > > Yes, the first number is 'DTE data rate' (but modem's chip datasheet > claims it does not support DTE higher than 115200). Note, with ANY > baud from 300 to 2400 result is: > "CONNECT 230400/Vxx/LAPM/Vxxx/TX=xxxxx/RX=xxxxx" > But bauds lower than 1200 do really limit speed. > > # setserial -bav /dev/ttyS4 > /dev/ttyS4, Line 4, UART: 16950/954, Port: 0x3010, IRQ: 11 > Baud_base: 115200, close_delay: 50, divisor: 0 > closing_wait: 3000 > Flags: spd_normal skip_test > > Changing divisor to 8.625 (it is reported to be '8') gave nothing. The "divisor" doesn't do anything in this mode. What happens if you: 1. setserial /dev/ttyS4 spd_cust divisor 104 2. set the baud rate to 38400 baud If what I think has happened is correct, 104 should approximate 9600 baud, 52 should approximate 19200 baud, 26 should be 38400 baud, and 17 should approximate 57600 baud. It would be helpful if you could confirm that the modem does report the real DTE data rate under Windows. I hope that each time you test this it doesn't cost. 8/ -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Thread:

KYDEI ENTERPRISE (H.K) CO.LTD.

KYDEI ENTERPRISE (H.K) CO.LTD. 29-32/F., 30 Queen?s Road Central, Hong Kong, HONG KONG. Dear Sir/Madam, We the management, members and staff of Kydei Enterprise (H.K)co. ltd, will be very glad if you can represent us in your country as a medium of receiving payments for goods supplied to our customers in North America. We deal in Chinese art and interior design and the global need for our goods has given rise to a significant increase in our customer base world wide. Commission for your services is subject to negotiation upon acceptance of our proposal. In anticipation of your acceptance of our proposal, I am taking the liberty of explaining in detail the requirements and need for your services. I am an exporter based in Hong Kong who exports Chinese art and interior design. Due to the growing trend for the need for Chinese arts and interior design in North America and the world in general, there has been an upsurge in my customer base and the need for me to expand my business to meet up with the new responsibility at hand. I assume you understand the need for every business to grow and expand to increase profit. As a result of this development, I have had the need to extend my customer base to North America. However, it is only logical that changes are put in place to meet up with the demands of a speedy intercontinental monetary transaction as time is always a factor in effective business management. To give you a better understanding of what your responsibilities will be as my private payment agent, it is important that you understand some difficulties that I am faced with pr esently in receiving funds from clients in North America. Firstly, most payments for goods are drawn in checks and it takes approximately two-four weeks for checks from other continents to clear with our local banks. These delays mostly result in our late response to orders and we sometimes loose clients to other suppliers. Secondly, we experience high tariffs and foreign exchange charges as funds will have to be converted by our banks to local currencies as they are cleared with our banks and re converted to foreign currency as we place orders for supplies from our international suppliers. As you can see, the back and forth process of currency conversion, results to high charges for foreign exchange thereby resulting to increase in cost of doing business. But with your assistance, funds that are to be used for supplies will be sent directly by you to my supplies there by avoiding the intercontinental banking processing time between Asia and North America.
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!