I want to configure the OXPCIe954 to nDTR auto flow contorol (I want the RS-485
ports).
I add the following code at driver open com port.
WRITE_REGISTER_UCHAR(Port_Addr + 7, 0);
WRITE_REGISTER_UCHAR(Port_Addr + 0xA0 + 5, 0x30);
But the ports are not able to send and receive data. (If I use the ox
Neo Jia wrote:
> hi,
>
> Will the current GRUB 2 trunk from SVN repository contain the PCI
> searil port card support?
>
> I would like to try it out as my mb doesn't have a onboad serial port.
Hi Neo,
Not at this time. Please wait a bit until legal stuff has been completed
so it can be merged.
hi,
Will the current GRUB 2 trunk from SVN repository contain the PCI
searil port card support?
I would like to try it out as my mb doesn't have a onboad serial port.
Thanks,
Neo
On Fri, Nov 14, 2008 at 11:24 AM, <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2008 at 08:05:37PM +0200, Vesa J??sk
On Thu, Nov 13, 2008 at 08:05:37PM +0200, Vesa J??skel?inen wrote:
> Hi Don,
>
> Thanks for the patch!
>
Here is a new patch incorporating your comments.
(Still waiting on legal about the copyright assignment, I'm sure it'll
happen - someday.)
Signed-off-by: Donald D. Dugger <[EMAIL PROTECTED]
On Thu, Nov 13, 2008 at 08:05:37PM +0200, Vesa J??skel?inen wrote:
>
> Why not hide the legacy comports if they are not there and we can auto
> detect that?
I went back and forth on this. I finally decided that COM1 to COM4 are
so firmly a part of the PC design I should leave them (note that if
Hi Don,
Thanks for the patch!
[EMAIL PROTECTED] wrote:
> On Sun, Nov 09, 2008 at 10:57:30PM +0100, Robert Millan wrote:
>> On Sat, Nov 08, 2008 at 06:58:19PM -0700, [EMAIL PROTECTED] wrote:
>>> I think this is pretty much what I'm in the middle of doing. I want to
>>> put the infrastructure in p
On Sun, Nov 09, 2008 at 10:57:30PM +0100, Robert Millan wrote:
> On Sat, Nov 08, 2008 at 06:58:19PM -0700, [EMAIL PROTECTED] wrote:
> > I think this is pretty much what I'm in the middle of doing. I want to
> > put the infrastructure in place so that we can handle an arbitrary PCI
> > device but I
On Sun, Nov 09, 2008 at 10:57:30PM +0100, Robert Millan wrote:
>...
> Nice! Aside from base baud and configuration function, I assume we'd also
> want to specify the I/O port?
Yep, I/O port and base baud are the only two device specific items
we need since we don't do interrupts. Doing a table
Robert Millan wrote:
> On Sat, Nov 08, 2008 at 06:58:19PM -0700, [EMAIL PROTECTED] wrote:
>> Note that what I'm doing will make the serial module dependent upon the
>> pci module but I don't see that that's a big concern. Pretty much any
>> modern machine will have a PCI bus so scanning it should
On Sat, Nov 08, 2008 at 06:58:19PM -0700, [EMAIL PROTECTED] wrote:
> I think this is pretty much what I'm in the middle of doing. I want to
> put the infrastructure in place so that we can handle an arbitrary PCI
> device but I will only put the actual code in to handle the PCI card that
> I have
I think this is pretty much what I'm in the middle of doing. I want to
put the infrastructure in place so that we can handle an arbitrary PCI
device but I will only put the actual code in to handle the PCI card that
I have (the only one I can test).
What I'm doing is creating a table that matches
Robert Millan wrote:
> Sounds good. But do we have support for "weak" symbol dependencies a la
> dlym() ?
I tried it once while traveling and you can dynamically check for
function symbols and then start using them if they are loaded. Thou... I
do not know how reference counting is then affected.
On Sat, Nov 08, 2008 at 02:23:32PM +0200, Vesa Jääskeläinen wrote:
> >
> > Why not use PCI ID to support this particular card? This way Donald doesn't
> > have to support all cards, but the base is laid out so more cards can be
> > added
> > in the future.
>
> I have nothing against that. But i
Robert Millan wrote:
> On Fri, Nov 07, 2008 at 06:52:21PM +0200, Vesa Jääskeläinen wrote:
>> [EMAIL PROTECTED] wrote:
>>> Bad news, I heard back from the two people who wrote the PCI serial
>>> code for Linux (Russell King & Ted Tso) and they both agree that,
>>> no matter how the ambiguity got int
On Fri, Nov 07, 2008 at 06:52:21PM +0200, Vesa Jääskeläinen wrote:
> [EMAIL PROTECTED] wrote:
> > Bad news, I heard back from the two people who wrote the PCI serial
> > code for Linux (Russell King & Ted Tso) and they both agree that,
> > no matter how the ambiguity got into the Linux source files
[EMAIL PROTECTED] wrote:
> Bad news, I heard back from the two people who wrote the PCI serial
> code for Linux (Russell King & Ted Tso) and they both agree that,
> no matter how the ambiguity got into the Linux source files, their
> intent was that the code was GPL v2 only.
>
> That being the cas
ecisse." - D. Gale
> [EMAIL PROTECTED]
> Ph: (303)443-3786
>
> >-Original Message-
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED]
> >On Behalf Of Dugger, Donald D
> >Sent: Thursday, November 06, 2008 9:30 AM
> >To: The development of GRUB 2
ale
[EMAIL PROTECTED]
Ph: (303)443-3786
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]
>On Behalf Of Dugger, Donald D
>Sent: Thursday, November 06, 2008 9:30 AM
>To: The development of GRUB 2
>Subject: RE: [PATCH] PCI serial card support
>
sse." - D. Gale
[EMAIL PROTECTED]
Ph: (303)443-3786
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]
>On Behalf Of Robert Millan
>Sent: Thursday, November 06, 2008 9:07 AM
>To: The development of GRUB 2
>Subject: Re: [PATCH] PCI serial card
On Thu, Nov 06, 2008 at 07:28:57AM -0800, Dugger, Donald D wrote:
> The Linux driver has over 600
> lines of customized code for over 100 different devices
> to do this task. Trying to duplicate that code from
> scratch is rather unfeasible.
Before we continue, did you check if that code in parti
008 8:02 AM
>To: The development of GRUB 2
>Subject: Re: [PATCH] PCI serial card support
>
>On Wed, Nov 05, 2008 at 07:37:50AM -0800, Dugger, Donald D wrote:
>>
>> Hmmm, this is getting a litte more complex than I had hoped
>but so be
>> it. The problem is that to d
On Wed, Nov 05, 2008 at 07:37:50AM -0800, Dugger, Donald D wrote:
>
> Hmmm, this is getting a litte more complex than I had hoped but
> so be it. The problem is that to do this you need more than just
> a PCI ID to base_baud map, now you have to be able to enumerate
> serial devices, both multi-p
>-Original Message-
>...
>> what happens if you have 2 different PCI cards installed,
>
>Then serial.mod can handle multiple terminals (it already
>does, just not for PCI cards) via `serial' command, and use
>the PCI calls to gather info about them whenever they're to be used.
>
Hmmm, t
On Tue, Nov 04, 2008 at 10:24:38AM -0800, Dugger, Donald D wrote:
> You can create an internal table that maps PCI ID to base baud[1]
I'd prefer that a lot. Users don't necessarily have an idea on what
magic value they need.
> but now you are tied to the PCI subsystem and you get into issues of
>
>There are some serial boards where you have to give N * IO
>base addresses in order to support all N COMs. Actually there
>are even more complex cards than this one. Some supporting
>much higher than 921600 as maximum speed. Some needing even
>different kinds of formulas in order to get pro
Robert Millan wrote:
> On Mon, Nov 03, 2008 at 04:38:02PM -0800, [EMAIL PROTECTED] wrote:
>> The problem with using a PCI serial card for the console is that many
>> PCI cards use a different crystal than the IBM PC standard. This means
>> that serial drivers wind up computing the wrong divisor wh
n
>Sent: Tuesday, November 04, 2008 8:40 AM
>To: The development of GRUB 2
>Subject: Re: [PATCH] PCI serial card support
>
>On Mon, Nov 03, 2008 at 04:38:02PM -0800,
>[EMAIL PROTECTED] wrote:
>> The problem with using a PCI serial card for the console is
>that many
>> PC
On Mon, Nov 03, 2008 at 04:38:02PM -0800, [EMAIL PROTECTED] wrote:
> The problem with using a PCI serial card for the console is that many
> PCI cards use a different crystal than the IBM PC standard. This means
> that serial drivers wind up computing the wrong divisor when trying to
> set the bau
The problem with using a PCI serial card for the console is that many
PCI cards use a different crystal than the IBM PC standard. This means
that serial drivers wind up computing the wrong divisor when trying to
set the baud rate. This patch solves this problem by adding the `--base'
parameter to
29 matches
Mail list logo
