* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
From: Vinod Koul @ 2011-08-30 10:14 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Magnus Damm, Paul Mundt, linux-sh, linux-kernel, Dan Williams,
Magnus Damm
In-Reply-To: <Pine.LNX.4.64.1108300931220.19151@axis700.grange>
On Tue, 2011-08-30 at 09:54 +0200, Guennadi Liakhovetski wrote:
> On Mon, 29 Aug 2011, Vinod Koul wrote:
> > > >> You should not assign chan->private.
> > > >> Please move this to dma_slave_control API
> > > >
> > > > I haven't seen any reply to this comment and this patch seems to still be
> > > > outstanding, is there an updated version of this patch that I've missed?
> > I don't recall seeing any updated version fixing this
>
> As a matter of fact, when you say "use dma_slave_control API," you
> actually mean the dma_slave_config, right? Then, how is one supposed to
> use it in this case? Shall we be issuing a DMA_SLAVE_CONFIG call inside of
> the filter and check the return code? The problem is, that not all DMA
> controllers on sh-mobile SoCs can service the same slave devices. So, if
> we don't check in the filter we might well get an unsuitable DMA channel.
Here you are assigning to chan->private your specific values, which
should be moved to the dma_slave_config.
But here you are removing the checks, and accepting the first channel
you got, so how do you find channel is suitable or not.
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dma: shdma: transfer based runtime PM
From: Vinod Koul @ 2011-08-30 9:58 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linux-kernel, linux-sh, Dan Williams, Paul Mundt
In-Reply-To: <Pine.LNX.4.64.1108300906590.19151@axis700.grange>
On Tue, 2011-08-30 at 09:12 +0200, Guennadi Liakhovetski wrote:
> On Mon, 29 Aug 2011, Vinod Koul wrote:
> > > > Something like:
> > > > /* since callback is set for last descriptor of chain, we call runtime
> > > > * put for that desc alone
> > > > */
> > > > list_for_each_entry_safe(desc, __desc, sh_chan->ld_queue, node) {
> > > > if (desc->async_tx.callback)
> > > > pm_runtime_put(device);
> > >
> > > Not all dma users have callbacks.
> > Do you have such usage today, at least I dont :)
> > Nevertheless, in tx_submit adding a simple flag in your drivers
> > descriptor structure can tell you whether to call _put() or not. Agreed?
>
> Yes, I agree, that one could make this work too. Still, I do not
> understand how and why this is better to the extent, that I have to
> reimplement my patch, retest and resubmit it. Maybe Dan or Paul have an
> opinion on this?
But wont it make code look simpler and cleaner, you don't reply on your
counters but on pm_runtime infrastructure to do the job. You juts need
to call _put/_get at right places, which IMO l;ooks lot simpler than
current approach
--
~Vinod
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
From: Guennadi Liakhovetski @ 2011-08-30 7:54 UTC (permalink / raw)
To: Vinod Koul
Cc: Magnus Damm, Paul Mundt, linux-sh, linux-kernel, Dan Williams,
Magnus Damm
In-Reply-To: <1314618931.1606.114.camel@vkoul-udesk3>
On Mon, 29 Aug 2011, Vinod Koul wrote:
> On Mon, 2011-08-29 at 17:16 +0900, Magnus Damm wrote:
> > On Mon, Aug 29, 2011 at 5:00 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > > On Fri, Jun 24, 2011 at 05:17:51PM +0530, Koul, Vinod wrote:
> > >> On Fri, 2011-06-24 at 13:56 +0200, Guennadi Liakhovetski wrote:
> > >> > On some sh-mobile systems there are more than one DMA controllers, that
> > >> > can be used for serial ports. Specifying a DMA device in sh-sci platform
> > >> > data unnecessarily restricts the driver to only use one DMA controller.
> > >> >
> > >> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > >> > ---
> > >> > drivers/tty/serial/sh-sci.c | 25 ++++++++-----------------
> > >> > include/linux/serial_sci.h | 2 --
> > >> > 2 files changed, 8 insertions(+), 19 deletions(-)
> > >> >
> > >> > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> > >> > index ebd8629..8711f4e 100644
> > >> > --- a/drivers/tty/serial/sh-sci.c
> > >> > +++ b/drivers/tty/serial/sh-sci.c
> > >> > @@ -1295,12 +1295,8 @@ static bool filter(struct dma_chan *chan, void *slave)
> > >> > dev_dbg(chan->device->dev, "%s: slave ID %d\n", __func__,
> > >> > param->slave_id);
> > >> >
> > >> > - if (param->dma_dev = chan->device->dev) {
> > >> > - chan->private = param;
> > >> > - return true;
> > >> > - } else {
> > >> > - return false;
> > >> > - }
> > >> > + chan->private = param;
> > >> > + return true;
> > >> You should not assign chan->private.
> > >> Please move this to dma_slave_control API
> > >
> > > I haven't seen any reply to this comment and this patch seems to still be
> > > outstanding, is there an updated version of this patch that I've missed?
> I don't recall seeing any updated version fixing this
As a matter of fact, when you say "use dma_slave_control API," you
actually mean the dma_slave_config, right? Then, how is one supposed to
use it in this case? Shall we be issuing a DMA_SLAVE_CONFIG call inside of
the filter and check the return code? The problem is, that not all DMA
controllers on sh-mobile SoCs can service the same slave devices. So, if
we don't check in the filter we might well get an unsuitable DMA channel.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] dma: shdma: transfer based runtime PM
From: Guennadi Liakhovetski @ 2011-08-30 7:12 UTC (permalink / raw)
To: Vinod Koul; +Cc: linux-kernel, linux-sh, Dan Williams, Paul Mundt
In-Reply-To: <1314622113.1606.134.camel@vkoul-udesk3>
On Mon, 29 Aug 2011, Vinod Koul wrote:
> On Mon, 2011-08-29 at 14:21 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 29 Aug 2011, Vinod Koul wrote:
> >
> > > On Fri, 2011-08-26 at 01:11 +0200, Guennadi Liakhovetski wrote:
> > > > On Thu, 25 Aug 2011, Koul, Vinod wrote:
> > > > > Wont it be easy to to do:
> > > > > - pm_runtime_get() in each submit
> > > > > - pm_runtime_put() in each callback
> > > > > Normal case above would work just fine
> > > > > - In terminate case, count the number of issued transactions, and call
> > > > > pm_runtime_put() for each canceled transaction
> > > > > (i am assuming that for each timeout error, the client will call
> > > > > terminate)
> > > >
> > > > As I said, this won't be very easy to do this in a robust way. You'd have
> > > > to scan your list of DMA blocks and see, which of them belong to one
> > > > descriptor, and once you reach the end of that descriptor, issue a put().
> > > > Perhaps, this can be done, but my choice went to the currently presented
> > > > solution.
> > > If you count the number of descriptor submitted in your submitted list
> > > and call _put for each, I see no reason why it wont be simple and better
> > > than current approach.
> >
> > Sorry, I thought, you wanted to avoid extra counting, because runtime-pm
> > counts by itself. Now you propose to count...
> see below it doesn't count but iterate thru list
Yes, sorry, iterating is a better word, but I actually meant "counting" in
a broad sense, of which "iterating" is a particular case:-)
> > > Something like:
> > > /* since callback is set for last descriptor of chain, we call runtime
> > > * put for that desc alone
> > > */
> > > list_for_each_entry_safe(desc, __desc, sh_chan->ld_queue, node) {
> > > if (desc->async_tx.callback)
> > > pm_runtime_put(device);
> >
> > Not all dma users have callbacks.
> Do you have such usage today, at least I dont :)
> Nevertheless, in tx_submit adding a simple flag in your drivers
> descriptor structure can tell you whether to call _put() or not. Agreed?
Yes, I agree, that one could make this work too. Still, I do not
understand how and why this is better to the extent, that I have to
reimplement my patch, retest and resubmit it. Maybe Dan or Paul have an
opinion on this?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 0/4 v8] mmc: tmio, sdhi: provide multiple irq handlers
From: Simon Horman @ 2011-08-30 6:21 UTC (permalink / raw)
To: Chris Ball
Cc: linux-mmc, linux-sh, Paul Mundt, Guennadi Liakhovetski,
Magnus Damm
In-Reply-To: <m2sjolxvs1.fsf@bob.laptop.org>
On Sun, Aug 28, 2011 at 01:58:54PM -0400, Chris Ball wrote:
> Hi Simon,
>
> On Wed, Aug 24 2011, Simon Horman wrote:
> > The SDHI driver already supports making use of up to three interrupt
> > sources.
> >
> > This series breaks up the existing interrupt handler into three handlers,
> > one for sdcard access, one for card detect and one for SDIO interrupts.
> > A cover-all handler, which makes use of these new broken-out handlers
> > is provided for for the case where there is a multiplexed interrupt source.
> >
> > This series also wires up the new IRQ handlers for the mackerel and ag4evm.
> >
> > This series contains the following patches:
> >
> > [PATCH v8 1/4] mmc: tmio: Cache interrupt masks
> > [PATCH v8 2/4] mmc: tmio: Provide separate interrupt handlers
> > [PATCH v8 3/4] mmc: sdhi: Allow name IRQs to use specific handlers
> > [PATCH v8 4/4] ARM: shmobile: ag5evm, ap4: Named SDHI IRQ sources
>
> Thanks, all applied to mmc-next for 3.2, using Guennadi's v9 for 3/4.
Thanks.
I (finally) have SDIO hardware available for testing
and I have verified that the current mmc-next tree
works with a b43-based SDIO wirless network card
(iwscan list shows the available access point).
^ permalink raw reply
* 最新广交会买家库+500万海外买家资源+
From: 每天都有新买家 @ 2011-08-30 5:02 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110930043901506744@altoria.com.ua>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 13420 bytes --]
500���������������������������������������������������������������+������������������������������������������������������+������������������������������������Email���������������������������=���������������������������������������������������������������������������������
500���������������������������������������������������������������+������������������������������������������������������+������������������������������������Email���������������������������=���������������������������������������������������������������������������������
1���������500������������������������������������������������������ ���������������������������500��������������������������������������������������������������������������������� (������������������������������������������������������������������������������������������������������������������������������������������������������������������)���������
2���������������������������������������������������������������Email������������������������������������ ���������������������������600������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������1-2���������������������������������������������������������������EMAIL������������������������������������������������������
3������������������������������������������������������ ���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������5���������������������������������������������
��������������������������������������������������������������������������������� (���������������������������������������������������������������������������������������������������������������������������������������������������������) ������������������������������������������������������ ���������������������������
������������������������������������
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
QQ:1339625218 email: 1339625218@qq.com
������������������������������������:
1������������������������������������������������������������������������������������������,��������������������������������������������������������������� 500-1000���������������������������Email������������������������������������������������������������������������������������������������������������
2���������2009���������������������������������������������������������������piers��������������������������� 1���������������������������
3���������2011������������������109���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
4���������2008������������������2010��������� ������������������+������������������������������������������������������������������������������������������103 104 105 106 107 108 ���������������������������������������������120.6������������������������������������
5������������������������������������������������������������������������,���������451660������������������������������������������������������������������������Email���������
6���������2010������������������������������������������������������������������������PPAI��������������������������������������������� PPAI Members Directory������������������������������������������������������������������������������������������
7���������2010���������������������������������������������������������������������������������������������������������������������(���������������������������������������������������������������)������������������7.2������������������������������������������������������������������������������������������������������������
8���������100���������������������������������������������������������������������������������������������������������������������Email���������
9���������������������������������������������������������������������������������������������������
���������������������������������������������
������������{.n���+���������������������+%���������������������\x17������w������{.n���+������������{���������������{ay���\x1d���������������,j\a������f���������h���������������������������z_������\x03(���������������������j"������\x1a���^[m������������\a������G������������������?���������������&���������~������
^ permalink raw reply
* Re: [PATCH] [RFC] ARM: shmobile: g4evm: Use multiple irq vectors for
From: Simon Horman @ 2011-08-30 3:45 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linux-mmc, linux-sh, Paul Mundt, Magnus Damm
In-Reply-To: <20110826130642.GA13205@verge.net.au>
On Fri, Aug 26, 2011 at 10:06:45PM +0900, Simon Horman wrote:
> On Fri, Aug 26, 2011 at 02:56:50PM +0200, Guennadi Liakhovetski wrote:
> > On Fri, 26 Aug 2011, Simon Horman wrote:
> >
> > > On Fri, Aug 26, 2011 at 02:17:20PM +0200, Guennadi Liakhovetski wrote:
> > > > On Fri, 26 Aug 2011, Simon Horman wrote:
> > > >
> > > > > This patch is based on "ARM: arch-shmobile: Use multiple irq vectors for SDHI"
> > > > >
> > > > > It removes multiplexing of the SDHI vectors and names each IRQ source
> > > > > to allow the SDHI driver to used source-specific handlers.
> > > > >
> > > > > This is untested as I do not have access to a working g4evm.
> > > > >
> > > > > Signed-off-by: Simon Horman <horms@verge.net.au>
> > > > >
> > > > > ---
> > > > >
> > > > > Requires "mmc: sdhi: Allow specific IRQ sources to use corresponding handlers."
> > > > >
> > > > > *** compile tested only ***
> > > > > ---
> > > > > arch/arm/mach-shmobile/board-g4evm.c | 26 ++++++++++++++++++++++-
> > > > > arch/arm/mach-shmobile/intc-sh7377.c | 36 ++++++++++++++++-----------------
> > > >
> > > > This second file should not be here, right?
> > >
> > > I believe that the g4evm uses the sh7377 and that the multiplexing of
> > > SDHIinterrupts for the 7377 need to be removed in order to provide multiple
> > > SDHI irq sources.
> > >
> > > Am I missing something?
> >
> > Maybe not, I just misread your patch description as that it only should
> > touch the board itself. Since intc-sh7377.c has to be touched too, this
> > should be tested, I think. And I don't have any 7377 hardware available.
>
> I agree that this needs to be tested (or dropped).
> And its annoying that neither of us have the hardware at this time.
Hi Guennadi,
I spoke with Magnus yesterday and there doesn't seem to be any realistic
chance of accessing hardware to test this patch on in the near future.
So I would like to just leave it sitting in the mailing list archive as
an RFC for now.
^ permalink raw reply
* Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib implementations
From: Kevin Hilman @ 2011-08-29 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1QqhM1-0003af-U5@rmk-PC.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> Consolidate 24 trivial gpiolib implementions out of mach/gpio.h
> into asm/gpio.h. This is basically the include of asm-generic/gpio.h
> and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep
> as described in Documentation/gpio.txt
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
For OMAP:
Tested-by: Kevin Hilman <khilman@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Also goes for patches 12 & 13 also.
Kevin
^ permalink raw reply
* Re: [PATCH 03/13] ARM: gpio: omap: convert drivers to use asm/gpio.h rather than mach/gpio.h
From: Kevin Hilman @ 2011-08-29 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1QqhJQ-0003a8-T9@rmk-PC.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Kevin Hilman <khilman@ti.com>
^ permalink raw reply
* Re: [PATCH] dma: shdma: transfer based runtime PM
From: Vinod Koul @ 2011-08-29 12:49 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linux-kernel, linux-sh, Dan Williams, Paul Mundt
In-Reply-To: <Pine.LNX.4.64.1108291419410.31184@axis700.grange>
On Mon, 2011-08-29 at 14:21 +0200, Guennadi Liakhovetski wrote:
> On Mon, 29 Aug 2011, Vinod Koul wrote:
>
> > On Fri, 2011-08-26 at 01:11 +0200, Guennadi Liakhovetski wrote:
> > > On Thu, 25 Aug 2011, Koul, Vinod wrote:
> > > > Wont it be easy to to do:
> > > > - pm_runtime_get() in each submit
> > > > - pm_runtime_put() in each callback
> > > > Normal case above would work just fine
> > > > - In terminate case, count the number of issued transactions, and call
> > > > pm_runtime_put() for each canceled transaction
> > > > (i am assuming that for each timeout error, the client will call
> > > > terminate)
> > >
> > > As I said, this won't be very easy to do this in a robust way. You'd have
> > > to scan your list of DMA blocks and see, which of them belong to one
> > > descriptor, and once you reach the end of that descriptor, issue a put().
> > > Perhaps, this can be done, but my choice went to the currently presented
> > > solution.
> > If you count the number of descriptor submitted in your submitted list
> > and call _put for each, I see no reason why it wont be simple and better
> > than current approach.
>
> Sorry, I thought, you wanted to avoid extra counting, because runtime-pm
> counts by itself. Now you propose to count...
see below it doesn't count but iterate thru list
>
> > Something like:
> > /* since callback is set for last descriptor of chain, we call runtime
> > * put for that desc alone
> > */
> > list_for_each_entry_safe(desc, __desc, sh_chan->ld_queue, node) {
> > if (desc->async_tx.callback)
> > pm_runtime_put(device);
>
> Not all dma users have callbacks.
Do you have such usage today, at least I dont :)
Nevertheless, in tx_submit adding a simple flag in your drivers
descriptor structure can tell you whether to call _put() or not. Agreed?
--
~Vinod
>
> > If i read shdma correctly, descriptors are put into ld_queue of channel
> > and any pending should be checked in this list alone.
> > For normal case again you check for the callback to decide if you need
> > to call pm_runtime_put() or not.
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] dma: shdma: transfer based runtime PM
From: Vinod Koul @ 2011-08-29 12:23 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linux-kernel, linux-sh, Dan Williams, Paul Mundt
In-Reply-To: <Pine.LNX.4.64.1108260107550.17190@axis700.grange>
On Fri, 2011-08-26 at 01:11 +0200, Guennadi Liakhovetski wrote:
> On Thu, 25 Aug 2011, Koul, Vinod wrote:
> > Wont it be easy to to do:
> > - pm_runtime_get() in each submit
> > - pm_runtime_put() in each callback
> > Normal case above would work just fine
> > - In terminate case, count the number of issued transactions, and call
> > pm_runtime_put() for each canceled transaction
> > (i am assuming that for each timeout error, the client will call
> > terminate)
>
> As I said, this won't be very easy to do this in a robust way. You'd have
> to scan your list of DMA blocks and see, which of them belong to one
> descriptor, and once you reach the end of that descriptor, issue a put().
> Perhaps, this can be done, but my choice went to the currently presented
> solution.
If you count the number of descriptor submitted in your submitted list
and call _put for each, I see no reason why it wont be simple and better
than current approach.
Something like:
/* since callback is set for last descriptor of chain, we call runtime
* put for that desc alone
*/
list_for_each_entry_safe(desc, __desc, sh_chan->ld_queue, node) {
if (desc->async_tx.callback)
pm_runtime_put(device);
If i read shdma correctly, descriptors are put into ld_queue of channel
and any pending should be checked in this list alone.
For normal case again you check for the callback to decide if you need
to call pm_runtime_put() or not.
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dma: shdma: transfer based runtime PM
From: Guennadi Liakhovetski @ 2011-08-29 12:21 UTC (permalink / raw)
To: Vinod Koul; +Cc: linux-kernel, linux-sh, Dan Williams, Paul Mundt
In-Reply-To: <1314619909.1606.130.camel@vkoul-udesk3>
On Mon, 29 Aug 2011, Vinod Koul wrote:
> On Fri, 2011-08-26 at 01:11 +0200, Guennadi Liakhovetski wrote:
> > On Thu, 25 Aug 2011, Koul, Vinod wrote:
> > > Wont it be easy to to do:
> > > - pm_runtime_get() in each submit
> > > - pm_runtime_put() in each callback
> > > Normal case above would work just fine
> > > - In terminate case, count the number of issued transactions, and call
> > > pm_runtime_put() for each canceled transaction
> > > (i am assuming that for each timeout error, the client will call
> > > terminate)
> >
> > As I said, this won't be very easy to do this in a robust way. You'd have
> > to scan your list of DMA blocks and see, which of them belong to one
> > descriptor, and once you reach the end of that descriptor, issue a put().
> > Perhaps, this can be done, but my choice went to the currently presented
> > solution.
> If you count the number of descriptor submitted in your submitted list
> and call _put for each, I see no reason why it wont be simple and better
> than current approach.
Sorry, I thought, you wanted to avoid extra counting, because runtime-pm
counts by itself. Now you propose to count...
> Something like:
> /* since callback is set for last descriptor of chain, we call runtime
> * put for that desc alone
> */
> list_for_each_entry_safe(desc, __desc, sh_chan->ld_queue, node) {
> if (desc->async_tx.callback)
> pm_runtime_put(device);
Not all dma users have callbacks.
> If i read shdma correctly, descriptors are put into ld_queue of channel
> and any pending should be checked in this list alone.
> For normal case again you check for the callback to decide if you need
> to call pm_runtime_put() or not.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
From: Vinod Koul @ 2011-08-29 11:56 UTC (permalink / raw)
To: Magnus Damm
Cc: Paul Mundt, Guennadi Liakhovetski, linux-sh, linux-kernel,
Dan Williams, Magnus Damm
In-Reply-To: <CANqRtoRn-Csu+Rns6dn6=cJmRqbZfLKXA9brs8Ug9rFvGRn78w@mail.gmail.com>
On Mon, 2011-08-29 at 17:16 +0900, Magnus Damm wrote:
> On Mon, Aug 29, 2011 at 5:00 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Fri, Jun 24, 2011 at 05:17:51PM +0530, Koul, Vinod wrote:
> >> On Fri, 2011-06-24 at 13:56 +0200, Guennadi Liakhovetski wrote:
> >> > On some sh-mobile systems there are more than one DMA controllers, that
> >> > can be used for serial ports. Specifying a DMA device in sh-sci platform
> >> > data unnecessarily restricts the driver to only use one DMA controller.
> >> >
> >> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >> > ---
> >> > drivers/tty/serial/sh-sci.c | 25 ++++++++-----------------
> >> > include/linux/serial_sci.h | 2 --
> >> > 2 files changed, 8 insertions(+), 19 deletions(-)
> >> >
> >> > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> >> > index ebd8629..8711f4e 100644
> >> > --- a/drivers/tty/serial/sh-sci.c
> >> > +++ b/drivers/tty/serial/sh-sci.c
> >> > @@ -1295,12 +1295,8 @@ static bool filter(struct dma_chan *chan, void *slave)
> >> > dev_dbg(chan->device->dev, "%s: slave ID %d\n", __func__,
> >> > param->slave_id);
> >> >
> >> > - if (param->dma_dev = chan->device->dev) {
> >> > - chan->private = param;
> >> > - return true;
> >> > - } else {
> >> > - return false;
> >> > - }
> >> > + chan->private = param;
> >> > + return true;
> >> You should not assign chan->private.
> >> Please move this to dma_slave_control API
> >
> > I haven't seen any reply to this comment and this patch seems to still be
> > outstanding, is there an updated version of this patch that I've missed?
I don't recall seeing any updated version fixing this
--
~Vinod
> This patch is simply making the SCIF driver behave as other drivers
> that support DMA Engine like for instance:
> MMCIF - drivers/mmc/host/sh_mmcif.c
> SDHI - drivers/mmc/host/tmio_mmc_dma.c
> USBHS - drivers/usb/renesas_usbhs/fifo.c
>
> The SIU driver is still acting like the SCIF driver though:
> SIU - sound/soc/sh/siu_pcm.c
>
> If possible I would prefer if the drivers for the SCIF and the SIU
> first could be cleaned up to behave like MMCIF/SDHI/USBHS and then we
> can move to make use of the dma_slave_control API after that.
>
> Any thoughs?
>
> Thanks,
>
> / magnus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 5/7] fbdev: sh_mipi_dsi: add extra dcs settings for
From: Guennadi Liakhovetski @ 2011-08-29 8:45 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <87vctmt9t1.wl%kuninori.morimoto.gx@renesas.com>
On Mon, 29 Aug 2011, Magnus Damm wrote:
> On Thu, Aug 25, 2011 at 1:05 PM, Kuninori Morimoto
> <kuninori.morimoto.gx@renesas.com> wrote:
> > some platform needs extra MIPI dcs to use.
> > this patch add support it.
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > ---
> > drivers/video/sh_mipi_dsi.c | 24 +++++++++++++++++++++++-
> > include/video/sh_mipi_dsi.h | 13 +++++++++++++
> > 2 files changed, 36 insertions(+), 1 deletions(-)
>
> [snip]
>
> > --- a/include/video/sh_mipi_dsi.h
> > +++ b/include/video/sh_mipi_dsi.h
> > @@ -32,12 +32,25 @@ struct sh_mobile_lcdc_chan_cfg;
> > #define SH_MIPI_DSI_HFPBM (1 << 2)
> > #define SH_MIPI_DSI_BL2E (1 << 3)
> >
> > +/*
> > + * x000ccpp
> > + *
> > + * x : 1 use sh_mipi_dcs()
> > + * 0 use sh_mipi_dcs_param()
> > + * cc : cmd
> > + * pp : param
> > + */
> > +#define SH_MIPI_DCS(cmd) (0x10000000 | (cmd & 0xFF) << 8)
> > +#define SH_MIPI_DCS_PARAM(cmd, param) ((cmd & 0xFF) << 8 | (param & 0xFF))
> > +
> > struct sh_mipi_dsi_info {
> > enum sh_mipi_dsi_data_fmt data_format;
> > struct sh_mobile_lcdc_chan_cfg *lcd_chan;
> > unsigned long flags;
> > u32 clksrc;
> > unsigned int vsynw_offset;
> > + u32 *extra_array;
> > + int extra_array_len;
> > };
> >
> > #endif
>
> Hi Morimoto-san,
>
> Thanks for adding support for MIPI-DSI on the Kota2 board. If I
> understand correctly then this patch allows us to use board-specific
> code to setup the MIPI-DSI panel. And this is needed on the Kota2
> board.
>
> I do however wonder if this array is the best approach to adding board
> specific code. My personal take would be to use something like the SYS
> bus support for the LCDC, see callbacks in struct
> sh_mobile_lcdc_sys_bus_ops located in
> include/video/sh_mobile_lcdc.h and board/panel code like
> arch/sh/boards/mach-migor/lcd_qvga.c.
I don't like that array either, but if we want to do this _right_,
callbacks wouldn't be my preference either. I'm not familiar with the set
up: are those values wpecific to the LCD panel or to the board? If it's
the LCD panel, then ideally one would want a display driver for them.
Backlight controlling would want a proper driver too.
> Also, if your board/panel specific code is dealing with backlight on
> MIPI-DSI, perhaps there is a chance this is generic enough to be
> broken out and reused somehow.
Exactly, however, lately I'me coming to an unfortunate conclusion, that
due to a vast variety of embedded systems and their components, many
hardware blocks will ever be only used on a single embedded platform,
running Linux, and only be exposed to a handful of users. So, creating and
maintaining a proper driver for each such block has a good chance to be
considered an overkill...
> Maybe Paul and/or Guennadi has some ideas about this too.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 5/7] fbdev: sh_mipi_dsi: add extra dcs settings for platform
From: Magnus Damm @ 2011-08-29 8:23 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <87vctmt9t1.wl%kuninori.morimoto.gx@renesas.com>
On Thu, Aug 25, 2011 at 1:05 PM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
> some platform needs extra MIPI dcs to use.
> this patch add support it.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> drivers/video/sh_mipi_dsi.c | 24 +++++++++++++++++++++++-
> include/video/sh_mipi_dsi.h | 13 +++++++++++++
> 2 files changed, 36 insertions(+), 1 deletions(-)
[snip]
> --- a/include/video/sh_mipi_dsi.h
> +++ b/include/video/sh_mipi_dsi.h
> @@ -32,12 +32,25 @@ struct sh_mobile_lcdc_chan_cfg;
> #define SH_MIPI_DSI_HFPBM (1 << 2)
> #define SH_MIPI_DSI_BL2E (1 << 3)
>
> +/*
> + * x000ccpp
> + *
> + * x : 1 use sh_mipi_dcs()
> + * 0 use sh_mipi_dcs_param()
> + * cc : cmd
> + * pp : param
> + */
> +#define SH_MIPI_DCS(cmd) (0x10000000 | (cmd & 0xFF) << 8)
> +#define SH_MIPI_DCS_PARAM(cmd, param) ((cmd & 0xFF) << 8 | (param & 0xFF))
> +
> struct sh_mipi_dsi_info {
> enum sh_mipi_dsi_data_fmt data_format;
> struct sh_mobile_lcdc_chan_cfg *lcd_chan;
> unsigned long flags;
> u32 clksrc;
> unsigned int vsynw_offset;
> + u32 *extra_array;
> + int extra_array_len;
> };
>
> #endif
Hi Morimoto-san,
Thanks for adding support for MIPI-DSI on the Kota2 board. If I
understand correctly then this patch allows us to use board-specific
code to setup the MIPI-DSI panel. And this is needed on the Kota2
board.
I do however wonder if this array is the best approach to adding board
specific code. My personal take would be to use something like the SYS
bus support for the LCDC, see callbacks in struct
sh_mobile_lcdc_sys_bus_ops located in
include/video/sh_mobile_lcdc.h and board/panel code like
arch/sh/boards/mach-migor/lcd_qvga.c.
Also, if your board/panel specific code is dealing with backlight on
MIPI-DSI, perhaps there is a chance this is generic enough to be
broken out and reused somehow.
Maybe Paul and/or Guennadi has some ideas about this too.
Thanks,
/ magnus
^ permalink raw reply
* [GIT PULL] rmobile updates for 3.1-rc5
From: Paul Mundt @ 2011-08-29 8:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-sh, linux-kernel
Nothing particularly noteworthy here, mostly random fixes, stubbing in
some clock definitions, and wiring up some platform data.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-3.x.git rmobile-fixes-for-linus
Which contains:
Jesper Juhl (1):
ARM: static should be at beginning of declaration
Kuninori Morimoto (4):
ARM: mach-shmobile: sh7372: Add USB-DMAC support
ARM: mach-shmobile: mackerel: Add USB-DMA ID
ARM: mach-shmobile: clock-sh73a0: tidyup CKSCR main clock selecter
ARM: mach-shmobile: clock-sh7372: fixup USB-DMAC1 settings
Magnus Damm (4):
ARM: mach-shmobile: Use CMT2 for timer on sh7372
ARM: mach-shmobile: Remove 3DG/SGX from sh7372 INTCS
ARM: mach-shmobile: sh7372 MSIOF clock support
ARM: mach-shmobile: sh7372 CMT3 and CMT4 clock support
Simon Horman (2):
ARM: mach-shmobile: ag5evm: SDHI requires waiting for idle
mmc: sdhi, mmcif: zboot: Correct clock disable logic
arch/arm/boot/compressed/mmcif-sh7372.c | 2 +-
arch/arm/boot/compressed/sdhi-sh7372.c | 2 +-
arch/arm/mach-shmobile/board-ag5evm.c | 3 +-
arch/arm/mach-shmobile/board-mackerel.c | 4 +
arch/arm/mach-shmobile/clock-sh7372.c | 29 ++++-
arch/arm/mach-shmobile/clock-sh73a0.c | 2 +-
arch/arm/mach-shmobile/include/mach/sh7372.h | 4 +
arch/arm/mach-shmobile/intc-sh7372.c | 7 +-
arch/arm/mach-shmobile/setup-sh7372.c | 176 +++++++++++++++++++++++---
9 files changed, 199 insertions(+), 30 deletions(-)
^ permalink raw reply
* [GIT PULL] sh updates for 3.1-rc5
From: Paul Mundt @ 2011-08-29 8:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-sh, linux-kernel
This fixes up some unaligned access instruction pairs for SH-2A
toolchains, and other misc fixes. The only thing particularly noteworthy
are the serial runtime PM bits which properly enable context restore on
parts that make effective use of deep sleep states (mostly the R-Mobile
parts at this point), fixing up loss of console issues.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-3.x.git sh-fixes-for-linus
Which contains:
David Engraf (1):
shwdt: fix usage of mod_timer
Magnus Damm (4):
clocksource: sh_cmt: wait for CMCNT on init V2
sh: intc: enable both edges GPIO interrupts on sh7372
serial: sh-sci: fix DMA build by including dma-mapping.h
serial: sh-sci: console Runtime PM support
Paul Gortmaker (1):
sh: Fix conflicting definitions of ptrace_triggered
Paul Mundt (2):
serial: sh-sci: Fix up default regtype probing.
sh: Fix up fallout from cpuidle changes.
Phil Edworthy (2):
sh: Fix unaligned memory access for branches without delay slots
sh: Add unaligned memory access for PC relative intructions
Takashi YOSHII (1):
serial: sh-sci: report CTS as active for get_mctrl
Yoshihiro Shimoda (1):
sh: fix the compile error in setup-sh7757.c
arch/sh/include/asm/ptrace.h | 2 +-
arch/sh/kernel/cpu/sh4a/setup-sh7757.c | 1 +
arch/sh/kernel/idle.c | 2 +-
arch/sh/kernel/traps_32.c | 37 ++++++++++++++++
drivers/clocksource/sh_cmt.c | 34 ++++++++++++++-
drivers/sh/intc/chip.c | 3 +
drivers/tty/serial/sh-sci.c | 71 +++++++++++++++++++++++++++-----
7 files changed, 135 insertions(+), 15 deletions(-)
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
From: Magnus Damm @ 2011-08-29 8:16 UTC (permalink / raw)
To: Paul Mundt
Cc: Koul, Vinod, Guennadi Liakhovetski, linux-sh, linux-kernel,
Dan Williams, Magnus Damm
In-Reply-To: <20110829080047.GJ31809@linux-sh.org>
On Mon, Aug 29, 2011 at 5:00 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Fri, Jun 24, 2011 at 05:17:51PM +0530, Koul, Vinod wrote:
>> On Fri, 2011-06-24 at 13:56 +0200, Guennadi Liakhovetski wrote:
>> > On some sh-mobile systems there are more than one DMA controllers, that
>> > can be used for serial ports. Specifying a DMA device in sh-sci platform
>> > data unnecessarily restricts the driver to only use one DMA controller.
>> >
>> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> > ---
>> > drivers/tty/serial/sh-sci.c | 25 ++++++++-----------------
>> > include/linux/serial_sci.h | 2 --
>> > 2 files changed, 8 insertions(+), 19 deletions(-)
>> >
>> > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> > index ebd8629..8711f4e 100644
>> > --- a/drivers/tty/serial/sh-sci.c
>> > +++ b/drivers/tty/serial/sh-sci.c
>> > @@ -1295,12 +1295,8 @@ static bool filter(struct dma_chan *chan, void *slave)
>> > dev_dbg(chan->device->dev, "%s: slave ID %d\n", __func__,
>> > param->slave_id);
>> >
>> > - if (param->dma_dev = chan->device->dev) {
>> > - chan->private = param;
>> > - return true;
>> > - } else {
>> > - return false;
>> > - }
>> > + chan->private = param;
>> > + return true;
>> You should not assign chan->private.
>> Please move this to dma_slave_control API
>
> I haven't seen any reply to this comment and this patch seems to still be
> outstanding, is there an updated version of this patch that I've missed?
This patch is simply making the SCIF driver behave as other drivers
that support DMA Engine like for instance:
MMCIF - drivers/mmc/host/sh_mmcif.c
SDHI - drivers/mmc/host/tmio_mmc_dma.c
USBHS - drivers/usb/renesas_usbhs/fifo.c
The SIU driver is still acting like the SCIF driver though:
SIU - sound/soc/sh/siu_pcm.c
If possible I would prefer if the drivers for the SCIF and the SIU
first could be cleaned up to behave like MMCIF/SDHI/USBHS and then we
can move to make use of the dma_slave_control API after that.
Any thoughs?
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only channel ID
From: Paul Mundt @ 2011-08-29 8:00 UTC (permalink / raw)
To: Koul, Vinod
Cc: Guennadi Liakhovetski, linux-sh, linux-kernel, Dan Williams,
Magnus Damm
In-Reply-To: <1308916071.1536.4.camel@vkoul-udesk3>
On Fri, Jun 24, 2011 at 05:17:51PM +0530, Koul, Vinod wrote:
> On Fri, 2011-06-24 at 13:56 +0200, Guennadi Liakhovetski wrote:
> > On some sh-mobile systems there are more than one DMA controllers, that
> > can be used for serial ports. Specifying a DMA device in sh-sci platform
> > data unnecessarily restricts the driver to only use one DMA controller.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> > drivers/tty/serial/sh-sci.c | 25 ++++++++-----------------
> > include/linux/serial_sci.h | 2 --
> > 2 files changed, 8 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> > index ebd8629..8711f4e 100644
> > --- a/drivers/tty/serial/sh-sci.c
> > +++ b/drivers/tty/serial/sh-sci.c
> > @@ -1295,12 +1295,8 @@ static bool filter(struct dma_chan *chan, void *slave)
> > dev_dbg(chan->device->dev, "%s: slave ID %d\n", __func__,
> > param->slave_id);
> >
> > - if (param->dma_dev = chan->device->dev) {
> > - chan->private = param;
> > - return true;
> > - } else {
> > - return false;
> > - }
> > + chan->private = param;
> > + return true;
> You should not assign chan->private.
> Please move this to dma_slave_control API
I haven't seen any reply to this comment and this patch seems to still be
outstanding, is there an updated version of this patch that I've missed?
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: sh7372 MSIOF clock support
From: Paul Mundt @ 2011-08-29 7:47 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110826052511.25734.78502.sendpatchset@rxone.opensource.se>
On Fri, Aug 26, 2011 at 02:25:11PM +0900, Magnus Damm wrote:
> Add clock control support for sh7372 MSIOF hardware blocks.
>
> No upstream sh7372 boards are making use of MSIOF0->2,
> but the sh7372 hardware happens to come out of reset with
> all MSIOF MSTP clocks _enabled_, so to save power we need
> to implement a fix in software to shut down unused clocks.
>
> This patch relies on the recently merged
>
> 794d78f drivers: sh: late disabling of clocks V2
>
> to make sure the unused clocks get disabled as expected.
On Fri, Aug 26, 2011 at 02:28:42PM +0900, Magnus Damm wrote:
> Add clock control support for sh7372 CMT hardware blocks.
>
> No upstream sh7372 boards are making use of CMT3 + CMT4,
> but the sh7372 hardware happens to come out of reset with
> all CMT MSTP clocks _enabled_, so to save power we need
> to implement a fix in software to shut down unused clocks.
>
> This patch relies on the recently merged
>
> 794d78f drivers: sh: late disabling of clocks V2
>
> to make sure the unused clocks get disabled as expected.
Both applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] ARM: mach-shmobile: clock-sh7372: fixup USB-DMAC1 settings
From: Paul Mundt @ 2011-08-29 7:47 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <874o16up7v.wl%kuninori.morimoto.gx@renesas.com>
On Wed, Aug 24, 2011 at 08:47:42PM -0700, kuninori.morimoto.gx@renesas.com wrote:
> USB-DMAC1 needs SMSTPCR4/MSTP407 controls, not MSTP214
> this patch tested on mackerel board
>
> Reported-by: Magnus Damm <damm@opensource.se>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> v1 -> v2
>
> - tested on mackerel board
> - fix comment
> - fix MSTPxxx order
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: clock-sh73a0: tidyup CKSCR main clock selecter
From: Paul Mundt @ 2011-08-29 7:27 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <w3pmxozyxra.wl%kuninori.morimoto.gx@renesas.com>
On Fri, Aug 26, 2011 at 12:27:45AM -0700, Kuninori Morimoto wrote:
> MAINCKSEL is [29:28], not [27:24]
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> arch/arm/mach-shmobile/clock-sh73a0.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: report CTS as active for get_mctrl
From: Paul Mundt @ 2011-08-29 7:25 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4E536466.6020604@renesas.com>
On Wed, Aug 24, 2011 at 08:04:00PM +0900, takashi.yoshii.zj@renesas.com wrote:
> Hi,
>
> > This looks reasonable, but what application specifically was hitting
> > this? ...
>
> Well, it was detected by pure test. So, actually, nobody is in trouble :)
> But I think it occurs on anything that use hardware flow control and write(TX).
> Even shell terminal session does. Try invoke "stty crtscts" on your shell.
> It will freeze your terminal session whatever its flow control setting is.
> Or, do like as followings on ssh session, is safer.
> $ stty -F /dev/ttySC1 clocal crtscts -echo
> $ echo x > /dev/ttySC1
> Output 'x' on serial expected, but it stops and no output.
>
Ok, I've applied it as-is without a stable@ reference, as it's unlikely
to be terribly critical going back. I'll let Greg decided whether to pick
it up for stable or not.
^ permalink raw reply
* Re: [PATCH 1/2] sh: Fix unaligned memory access for branches without delay slots
From: Paul Mundt @ 2011-08-29 7:24 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1314028568-7571-1-git-send-email-phil.edworthy@renesas.com>
On Mon, Aug 22, 2011 at 04:56:08PM +0100, Phil Edworthy wrote:
> This patch just clears the return code for those cases where an
> unaligned memory access occurs on branch instructions without a
> delay slot.
>
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
On Wed, Aug 24, 2011 at 11:43:59AM +0100, Phil Edworthy wrote:
> This adds unaligned memory access support for the following instructions:
> mov.w @(disp,PC),Rn
> mov.l @(disp,PC),Rn
>
> These instructions are often used on SH2A toolchains.
>
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> ---
> v3:
> Fixed the PC relative address calculation
> v2:
> Fixed the mov.l case for big endian
> Fixed typo in commit msg
>
> arch/sh/kernel/traps_32.c | 35 +++++++++++++++++++++++++++++++++++
> 1 files changed, 35 insertions(+), 0 deletions(-)
>
Both applied, thanks.
^ permalink raw reply
* Re: [PATCH] sh: fix the compile error in setup-sh7757.c
From: Paul Mundt @ 2011-08-29 7:24 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4E536FC2.7090306@renesas.com>
On Tue, Aug 23, 2011 at 06:15:46PM +0900, Yoshihiro Shimoda wrote:
> Fix the following build errors:
>
> CC arch/sh/kernel/cpu/sh4a/setup-sh7757.o
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:681: error: implicit declaration of function ?DMA_BIT_MASK?
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:681: error: initializer element is not constant
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:681: error: (near initialization for ?usb_ehci_device.dev.coherent_dma_mask?)
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:705: error: initializer element is not constant
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c:705: error: (near initialization for ?usb_ohci_device.dev.coherent_dma_mask?)
> make[3]: *** [arch/sh/kernel/cpu/sh4a/setup-sh7757.o] Error 1
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox