From: Alan Cox <alan@linux.intel.com>
To: Paul Schilling <paul.s.schilling@gmail.com>
Cc: Ben Dooks <ben-linux@fluff.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Russell King <linux@arm.linux.org.uk>,
Greg Kroah-Hartman <gregkh@suse.de>,
Boojin Kim <boojin.kim@samsung.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
Date: Tue, 1 Nov 2011 19:55:17 +0000 [thread overview]
Message-ID: <20111101195517.5334482c@bob.linux.org.uk> (raw)
In-Reply-To: <CAC=G6sxm9YJZsi_+Zq7YVYsQrw1SAFvnroPxGyH7JGRn7ko5nw@mail.gmail.com>
> The opinion part... I needed a timer to switch from transmit to
> receive after the FIFO was empty. I started by using the low
> resolution timer using jiffies first. I found that wasn't high enough
> resolution, so I switched to the Linux HRT. Currently I have both
> versions that can be selected by conditional compile. Should I
> just remove the low resolution timer completely or leave it in.
I would just remove the low res one. They should degrade to low res
timer equivalence anyway.
> Second, I have a chunk of code that if it could be made to work
> could off load the receiving to DMA up to the last couple of bytes
> then switch back to interrupts for the token byte. Should I leave
> that code in a #if 0 statement or should I just delete it.
Is it something that you are likely to debug or someone is going to
debug shortly ?
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: alan@linux.intel.com (Alan Cox)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
Date: Tue, 1 Nov 2011 19:55:17 +0000 [thread overview]
Message-ID: <20111101195517.5334482c@bob.linux.org.uk> (raw)
In-Reply-To: <CAC=G6sxm9YJZsi_+Zq7YVYsQrw1SAFvnroPxGyH7JGRn7ko5nw@mail.gmail.com>
> The opinion part... ?I needed a timer to switch from transmit to
> receive after the FIFO was empty. ?I started by using the low
> resolution timer using jiffies first. ?I found that wasn't high enough
> resolution, so I switched to the Linux HRT. Currently I have both
> versions that can be selected by conditional compile. ?Should I
> just remove the low resolution timer completely or leave it in.
I would just remove the low res one. They should degrade to low res
timer equivalence anyway.
> Second, I have a chunk of code that if it could be made to work
> could off load the receiving to DMA up to the last couple of bytes
> then switch back to interrupts for the token byte. ?Should I leave
> that code in a #if 0 statement or should I just delete it.
Is it something that you are likely to debug or someone is going to
debug shortly ?
WARNING: multiple messages have this Message-ID (diff)
From: Alan Cox <alan@linux.intel.com>
To: Paul Schilling <paul.s.schilling@gmail.com>
Cc: Ben Dooks <ben-linux@fluff.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Russell King <linux@arm.linux.org.uk>,
Greg Kroah-Hartman <gregkh@suse.de>,
Boojin Kim <boojin.kim@samsung.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
Date: Tue, 1 Nov 2011 19:55:17 +0000 [thread overview]
Message-ID: <20111101195517.5334482c@bob.linux.org.uk> (raw)
In-Reply-To: <CAC=G6sxm9YJZsi_+Zq7YVYsQrw1SAFvnroPxGyH7JGRn7ko5nw@mail.gmail.com>
> The opinion part... I needed a timer to switch from transmit to
> receive after the FIFO was empty. I started by using the low
> resolution timer using jiffies first. I found that wasn't high enough
> resolution, so I switched to the Linux HRT. Currently I have both
> versions that can be selected by conditional compile. Should I
> just remove the low resolution timer completely or leave it in.
I would just remove the low res one. They should degrade to low res
timer equivalence anyway.
> Second, I have a chunk of code that if it could be made to work
> could off load the receiving to DMA up to the last couple of bytes
> then switch back to interrupts for the token byte. Should I leave
> that code in a #if 0 statement or should I just delete it.
Is it something that you are likely to debug or someone is going to
debug shortly ?
next prev parent reply other threads:[~2011-11-01 19:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <samsung_rs485>
2011-10-22 3:46 ` [PATCH 02/14] ARM : SAMSUNG : Add RS485 support Paul Schilling
2011-10-22 3:46 ` Paul Schilling
2011-10-22 3:46 ` Paul Schilling
2011-10-22 13:47 ` Russell King - ARM Linux
2011-10-22 13:47 ` Russell King - ARM Linux
2011-10-22 13:47 ` Russell King - ARM Linux
2011-10-23 17:12 ` Paul Schilling
2011-10-23 17:12 ` Paul Schilling
2011-10-23 17:12 ` Paul Schilling
2011-10-23 20:20 ` Russell King - ARM Linux
2011-10-23 20:20 ` Russell King - ARM Linux
2011-10-23 20:20 ` Russell King - ARM Linux
2011-11-01 12:18 ` Alan Cox
2011-11-01 12:18 ` Alan Cox
2011-11-01 14:57 ` Paul Schilling
2011-11-01 14:57 ` Paul Schilling
2011-11-01 14:57 ` Paul Schilling
2011-11-01 19:12 ` Paul Schilling
2011-11-01 19:12 ` Paul Schilling
2011-11-01 19:12 ` Paul Schilling
2011-11-01 19:22 ` Paul Schilling
2011-11-01 19:22 ` Paul Schilling
2011-11-01 19:22 ` Paul Schilling
2011-11-01 19:55 ` Alan Cox [this message]
2011-11-01 19:55 ` Alan Cox
2011-11-01 19:55 ` Alan Cox
2011-11-04 10:18 ` Nicolas Ferre
2011-11-04 10:18 ` Nicolas Ferre
2011-11-04 10:18 ` Nicolas Ferre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111101195517.5334482c@bob.linux.org.uk \
--to=alan@linux.intel.com \
--cc=ben-linux@fluff.org \
--cc=boojin.kim@samsung.com \
--cc=gregkh@suse.de \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nicolas.pitre@linaro.org \
--cc=paul.s.schilling@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.