On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote:
> On 09/12/2016 18:56, Vinod Koul wrote:
> > Right, but in that case the fallback would be PIO mode, and if that is
> > not availble (IIRC some f your devices don't) then reject the usage with
> > EAGAIN.
> Maybe I'm missing something, but I
On Fri, Dec 09, 2016 at 07:23:17PM +0100, Mason wrote:
> [ Dropping Mans to preserve his peace-of-mind ]
>
> On 09/12/2016 18:56, Vinod Koul wrote:
> > On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
> >> On 09/12/2016 18:17, Vinod Koul wrote:
> >>
> >>> On Fri, Dec 09, 2016 at 11:25:57AM +
[ Dropping Mans to preserve his peace-of-mind ]
On 09/12/2016 18:56, Vinod Koul wrote:
> On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
>> On 09/12/2016 18:17, Vinod Koul wrote:
>>
>>> On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
What concrete solution do you
On Fri, Dec 09, 2016 at 11:26:06PM +0530, Vinod Koul wrote:
> On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
> > On 09/12/2016 18:17, Vinod Koul wrote:
> >
> > > On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
> > >>
> > >> What concrete solution do you propose?
> > >
> >
On Fri, Dec 09, 2016 at 06:34:15PM +0100, Mason wrote:
> On 09/12/2016 18:17, Vinod Koul wrote:
>
> > On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
> >>
> >> What concrete solution do you propose?
> >
> > I have already proposed two solutions.
> >
> > A) Request a channel only
On Fri, Dec 09, 2016 at 05:28:01PM +, Måns Rullgård wrote:
> Vinod Koul writes:
>
> > On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
> >>
> >> What concrete solution do you propose?
> >
> > I have already proposed two solutions.
> >
> > A) Request a channel only when you ne
On 09/12/2016 18:17, Vinod Koul wrote:
> On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
>>
>> What concrete solution do you propose?
>
> I have already proposed two solutions.
>
> A) Request a channel only when you need it. Obviously we can't do virtual
> channels with this (th
Vinod Koul writes:
> On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
>>
>> What concrete solution do you propose?
>
> I have already proposed two solutions.
>
> A) Request a channel only when you need it. Obviously we can't do virtual
> channels with this (though we should still
On Fri, Dec 09, 2016 at 11:25:57AM +0100, Sebastian Frias wrote:
>
> What concrete solution do you propose?
I have already proposed two solutions.
A) Request a channel only when you need it. Obviously we can't do virtual
channels with this (though we should still use virt-channels framework).
Th
Sebastian Frias writes:
> On 09/12/16 07:59, Vinod Koul wrote:
>> On Thu, Dec 08, 2016 at 04:48:18PM +, Måns Rullgård wrote:
>>> Vinod Koul writes:
>>>
To make it efficient, disregarding your Sbox HW issue, the solution is
virtual channels. You can delink physical channels and virt
Sebastian Frias writes:
> On 09/12/16 07:59, Vinod Koul wrote:
>> On Thu, Dec 08, 2016 at 04:48:18PM +, Måns Rullgård wrote:
>>> Vinod Koul writes:
>>>
To make it efficient, disregarding your Sbox HW issue, the solution is
virtual channels. You can delink physical channels and virt
On 09/12/16 07:59, Vinod Koul wrote:
> On Thu, Dec 08, 2016 at 04:48:18PM +, Måns Rullgård wrote:
>> Vinod Koul writes:
>>
>>> To make it efficient, disregarding your Sbox HW issue, the solution is
>>> virtual channels. You can delink physical channels and virtual channels. If
>>> one has SW c
On Thu, Dec 08, 2016 at 04:48:18PM +, Måns Rullgård wrote:
> Vinod Koul writes:
>
> > To make it efficient, disregarding your Sbox HW issue, the solution is
> > virtual channels. You can delink physical channels and virtual channels. If
> > one has SW controlled MUX then a channel can service
Vinod Koul writes:
> To make it efficient, disregarding your Sbox HW issue, the solution is
> virtual channels. You can delink physical channels and virtual channels. If
> one has SW controlled MUX then a channel can service any client. For few
> controllers request lines are hard wired so they c
Vinod Koul writes:
> On Thu, Dec 08, 2016 at 11:44:53AM +, Måns Rullgård wrote:
>> Vinod Koul writes:
>>
>> > On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>> >> Vinod Koul writes:
>> >>
>> >> > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>> >> >>
>> >
On Thu, Dec 08, 2016 at 11:54:51AM +0100, Mason wrote:
> On 08/12/2016 11:39, Vinod Koul wrote:
>
> > On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
> >
> >> Vinod Koul writes:
> >>
> >>> On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>
> That's not going
Vinod Koul writes:
> On Thu, Dec 08, 2016 at 12:20:30PM +, Måns Rullgård wrote:
>> >
>> > I'm far from claiming that drivers/tty/serial/sh-sci.c is perfect, but
>> > it does request DMA channels at open time, not at probe time.
>>
>> In the part quoted above, I said most drivers request dma
On Thu, Dec 08, 2016 at 04:43:53PM +0100, Mason wrote:
> On 08/12/2016 16:40, Vinod Koul wrote:
>
> > FWIW look at ALSA-dmaengine lib, thereby every audio driver that uses it. I
> > could find other examples and go on and on, but that's besides the point and
> > looks like you don't want to listen
On 08/12/2016 16:40, Vinod Koul wrote:
> FWIW look at ALSA-dmaengine lib, thereby every audio driver that uses it. I
> could find other examples and go on and on, but that's besides the point and
> looks like you don't want to listen to people telling you something..
Hello Vinod,
FWIW, your syst
On Thu, Dec 08, 2016 at 12:20:30PM +, Måns Rullgård wrote:
> >
> > I'm far from claiming that drivers/tty/serial/sh-sci.c is perfect, but
> > it does request DMA channels at open time, not at probe time.
>
> In the part quoted above, I said most drivers request dma channels in
> their probe or
On Thu, Dec 08, 2016 at 11:44:53AM +, Måns Rullgård wrote:
> Vinod Koul writes:
>
> > On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
> >> Vinod Koul writes:
> >>
> >> > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
> >> >>
> >> >> That's not going to work v
Mason writes:
> On 08/12/2016 13:44, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 08/12/2016 13:20, Måns Rullgård wrote:
>>>
The only problem we have is that nobody envisioned hardware where the
dma engine indicates completion slightly too soon. I suspect there's a
fifo or
On 08/12/2016 13:44, Måns Rullgård wrote:
> Mason writes:
>
>> On 08/12/2016 13:20, Måns Rullgård wrote:
>>
>>> The only problem we have is that nobody envisioned hardware where the
>>> dma engine indicates completion slightly too soon. I suspect there's a
>>> fifo or such somewhere, and the in
Mason writes:
> On 08/12/2016 13:20, Måns Rullgård wrote:
>
>> The only problem we have is that nobody envisioned hardware where the
>> dma engine indicates completion slightly too soon. I suspect there's a
>> fifo or such somewhere, and the interrupt is triggered when the last
>> byte has been
On 08/12/2016 13:20, Måns Rullgård wrote:
> The only problem we have is that nobody envisioned hardware where the
> dma engine indicates completion slightly too soon. I suspect there's a
> fifo or such somewhere, and the interrupt is triggered when the last
> byte has been placed in the fifo rath
On Thu, Dec 8, 2016 at 1:20 PM, Måns Rullgård wrote:
> Geert Uytterhoeven writes:
>> On Thu, Dec 8, 2016 at 12:44 PM, Måns Rullgård wrote:
>>> Vinod Koul writes:
On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
> Vinod Koul writes:
> > On Tue, Dec 06, 2016 at 01:14:2
Geert Uytterhoeven writes:
> Hi Måns,
>
> On Thu, Dec 8, 2016 at 12:47 PM, Måns Rullgård wrote:
>> Geert Uytterhoeven writes:
>>> On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote:
On 08/12/2016 11:39, Vinod Koul wrote:
> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>
Geert Uytterhoeven writes:
> On Thu, Dec 8, 2016 at 12:44 PM, Måns Rullgård wrote:
>> Vinod Koul writes:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
Vinod Koul writes:
> On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>> That's not going to
On 08/12/2016 13:03, Geert Uytterhoeven wrote:
> Måns Rullgård wrote:
>
>> Geert Uytterhoeven writes:
>>
>>> Can you fall back to PIO if requesting a channel fails?
>>
>> Why are we debating this nonsense? There is an easy fix that doesn't
>> require changing the semantics of existing functions o
Hi Måns,
On Thu, Dec 8, 2016 at 12:47 PM, Måns Rullgård wrote:
> Geert Uytterhoeven writes:
>> On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote:
>>> On 08/12/2016 11:39, Vinod Koul wrote:
On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
> Vinod Koul writes:
>> On Tue, De
On Thu, Dec 8, 2016 at 12:44 PM, Måns Rullgård wrote:
> Vinod Koul writes:
>> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>>> Vinod Koul writes:
>>> > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>>> >> That's not going to work very well. Device drivers typi
Geert Uytterhoeven writes:
> On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote:
>> On 08/12/2016 11:39, Vinod Koul wrote:
>>> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
Vinod Koul writes:
> On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>> That's not
Vinod Koul writes:
> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>> Vinod Koul writes:
>>
>> > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>> >>
>> >> That's not going to work very well. Device drivers typically request
>> >> dma channels in their probe f
Vinod Koul writes:
> On Wed, Dec 07, 2016 at 04:44:55PM +, Måns Rullgård wrote:
>> Vinod Koul writes:
>> >>
>> >> What you're proposing, Vinod, is to make a channel exclusive
>> >> to a driver, as long as the driver has not explicitly released
>> >> the channel, via dma_release_channel(), r
On Thu, Dec 8, 2016 at 11:54 AM, Mason wrote:
> On 08/12/2016 11:39, Vinod Koul wrote:
>> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>>> Vinod Koul writes:
On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
> That's not going to work very well. Device dri
On 08/12/2016 11:39, Vinod Koul wrote:
> On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
>
>> Vinod Koul writes:
>>
>>> On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
That's not going to work very well. Device drivers typically request
dma channels i
On Wed, Dec 07, 2016 at 04:45:58PM +, Måns Rullgård wrote:
> Vinod Koul writes:
>
> > On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
> >>
> >> That's not going to work very well. Device drivers typically request
> >> dma channels in their probe functions or when the device i
On Wed, Dec 07, 2016 at 04:44:55PM +, Måns Rullgård wrote:
> Vinod Koul writes:
> >>
> >> What you're proposing, Vinod, is to make a channel exclusive
> >> to a driver, as long as the driver has not explicitly released
> >> the channel, via dma_release_channel(), right?
> >
> > Precisely, but
Vinod Koul writes:
> On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>>
>> That's not going to work very well. Device drivers typically request
>> dma channels in their probe functions or when the device is opened.
>> This means that reserving one of the few channels there will i
Vinod Koul writes:
> On Tue, Dec 06, 2016 at 01:42:31PM +0100, Mason wrote:
>> On 06/12/2016 06:12, Vinod Koul wrote:
>>
>> > On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
>> >
>> >> Is there a way to write a driver within the existing framework?
>> >
>> > I think so, looking back at
On Tue, Dec 06, 2016 at 01:42:31PM +0100, Mason wrote:
> On 06/12/2016 06:12, Vinod Koul wrote:
>
> > On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
> >
> >> Is there a way to write a driver within the existing framework?
> >
> > I think so, looking back at comments from Russell, I do te
On Tue, Dec 06, 2016 at 01:14:20PM +, Måns Rullgård wrote:
>
> That's not going to work very well. Device drivers typically request
> dma channels in their probe functions or when the device is opened.
> This means that reserving one of the few channels there will inevitably
> make some other
On 06/12/2016 16:34, Måns Rullgård wrote:
> Mason writes:
>
>> Meh. The two controller blocks share the I/O pins to the outside
>> world, so it's not possible to have two concurrent accesses.
>
> OK, you failed to mention that part. Why are there two controllers at
> all if only one or the othe
Mason writes:
> On 06/12/2016 14:14, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> On 06/12/2016 06:12, Vinod Koul wrote:
>>>
On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
> Is there a way to write a driver within the existing framework?
I think so, looking back
On 06/12/2016 14:14, Måns Rullgård wrote:
> Mason wrote:
>
>> On 06/12/2016 06:12, Vinod Koul wrote:
>>
>>> On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
>>>
Is there a way to write a driver within the existing framework?
>>>
>>> I think so, looking back at comments from Russell, I
Mason writes:
> On 06/12/2016 06:12, Vinod Koul wrote:
>
>> On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
>>
>>> Is there a way to write a driver within the existing framework?
>>
>> I think so, looking back at comments from Russell, I do tend to agree with
>> that. Is there a specific
On 06/12/2016 06:12, Vinod Koul wrote:
> On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
>
>> Is there a way to write a driver within the existing framework?
>
> I think so, looking back at comments from Russell, I do tend to agree with
> that. Is there a specific reason why sbox can't be
On Tue, Nov 29, 2016 at 07:25:02PM +0100, Mason wrote:
Sorry I was away for a week in meeting with laptop down.
> [ Nothing new added below.
> Vinod, was the description of my HW's quirks clear enough?
Yes
> Is there a way to write a driver within the existing framework?
I think so, lookin
[ Nothing new added below.
Vinod, was the description of my HW's quirks clear enough?
Is there a way to write a driver within the existing framework?
How can I get that HW block supported upstream?
Regards. ]
On 25/11/2016 13:46, Mason wrote:
> On 25/11/2016 05:55, Vinod Koul wrote:
>
>>
On 25/11/2016 15:37, Måns Rullgård wrote:
> Mason writes:
>
>> On 25/11/2016 14:11, Måns Rullgård wrote:
>>
>>> Mason writes:
>>>
It seems there is a disconnect between what Linux expects - an IRQ
when the transfer is complete - and the quirks of this HW :-(
On this system, th
Mason writes:
> On 25/11/2016 16:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> I've had several talks with the HW dev, and I don't think they
>>> anticipated the need to mux the 3 channels. In their minds,
>>> customers would choose at most 3 devices to support, and
>>> assign one channel t
On 25/11/2016 16:12, Måns Rullgård wrote:
> Mason writes:
>
>> I've had several talks with the HW dev, and I don't think they
>> anticipated the need to mux the 3 channels. In their minds,
>> customers would choose at most 3 devices to support, and
>> assign one channel to each device statically.
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 02:40:21PM +, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
>> >> Russell King - ARM Linux writes:
>> >>
>> >> > On Fri, Nov 25, 2016 at 01:50:35PM
Mason writes:
> On 25/11/2016 15:17, Russell King - ARM Linux wrote:
>> On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
>>> Russell King - ARM Linux writes:
>>>
On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
>> It wo
On 25/11/2016 15:17, Russell King - ARM Linux wrote:
> On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>>> On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
Russell King - ARM Linux writes:
> It would be unfair to augment
On Fri, Nov 25, 2016 at 02:40:21PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
>
> > On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
> >> Russell King - ARM Linux writes:
> >>
> >> > On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
> >> >> Russell
Mason writes:
> On 25/11/2016 15:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 25/11/2016 12:57, Måns Rullgård wrote:
>>>
The same DMA unit is also used for SATA, which is an off the shelf
Designware controller with an in-kernel driver. This interrupt timing
glitch can ac
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
>> >> Russell King - ARM Linux writes:
>> >> > It would be unfair to augment the API and
Mason writes:
> On 25/11/2016 14:11, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> It seems there is a disconnect between what Linux expects - an IRQ
>>> when the transfer is complete - and the quirks of this HW :-(
>>>
>>> On this system, there are MBUS "agents" connected via a "switch box".
>
On Fri, Nov 25, 2016 at 02:03:20PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
>
> > On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
> >> Russell King - ARM Linux writes:
> >> > It would be unfair to augment the API and add the burden on everyone
> >> > for the
On 25/11/2016 15:12, Måns Rullgård wrote:
> Mason writes:
>
>> On 25/11/2016 12:57, Måns Rullgård wrote:
>>
>>> The same DMA unit is also used for SATA, which is an off the shelf
>>> Designware controller with an in-kernel driver. This interrupt timing
>>> glitch can actually explain some interm
On 25/11/2016 14:11, Måns Rullgård wrote:
> Mason writes:
>
>> It seems there is a disconnect between what Linux expects - an IRQ
>> when the transfer is complete - and the quirks of this HW :-(
>>
>> On this system, there are MBUS "agents" connected via a "switch box".
>> An agent fires an IRQ w
Mason writes:
> On 25/11/2016 12:57, Måns Rullgård wrote:
>
>> The same DMA unit is also used for SATA, which is an off the shelf
>> Designware controller with an in-kernel driver. This interrupt timing
>> glitch can actually explain some intermittent errors I've observed with
>> it.
>
> FWIW, n
On 25/11/2016 12:57, Måns Rullgård wrote:
> The same DMA unit is also used for SATA, which is an off the shelf
> Designware controller with an in-kernel driver. This interrupt timing
> glitch can actually explain some intermittent errors I've observed with
> it.
FWIW, newer chips embed an AHCI c
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>> > It would be unfair to augment the API and add the burden on everyone
>> > for the new API when 99.999% of the world doesn't require it.
>>
>> I don't think
On Fri, Nov 25, 2016 at 01:50:35PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
> > It would be unfair to augment the API and add the burden on everyone
> > for the new API when 99.999% of the world doesn't require it.
>
> I don't think making this particular dma driver wait for
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 01:07:05PM +, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
>> >> Looking at thread and discussion now, first thinking would be to ensure
>> >> the trans
On Fri, Nov 25, 2016 at 01:07:05PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
>
> > On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
> >> Looking at thread and discussion now, first thinking would be to ensure
> >> the transaction is completed properly and then isr
Mason writes:
> On 25/11/2016 05:55, Vinod Koul wrote:
>
>> On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote:
>>
>>> On my platform, setting up a DMA transfer is a two-step process:
>>>
>>> 1) configure the "switch box" to connect a device to a memory channel
>>> 2) configure the transfer de
Russell King - ARM Linux writes:
> On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
>> Looking at thread and discussion now, first thinking would be to ensure
>> the transaction is completed properly and then isr fired. You may need
>> to talk to your HW designers to find a way for tha
On 25/11/2016 05:55, Vinod Koul wrote:
> On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote:
>
>> On my platform, setting up a DMA transfer is a two-step process:
>>
>> 1) configure the "switch box" to connect a device to a memory channel
>> 2) configure the transfer details (address, size, com
On Fri, Nov 25, 2016 at 10:25:49AM +0530, Vinod Koul wrote:
> Looking at thread and discussion now, first thinking would be to ensure
> the transaction is completed properly and then isr fired. You may need
> to talk to your HW designers to find a way for that. It is quite common
> that DMA control
Vinod Koul writes:
> On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote:
>> Hello,
>>
>> On my platform, setting up a DMA transfer is a two-step process:
>>
>> 1) configure the "switch box" to connect a device to a memory channel
>> 2) configure the transfer details (address, size, command)
On Wed, Nov 23, 2016 at 11:25:44AM +0100, Mason wrote:
> Hello,
>
> On my platform, setting up a DMA transfer is a two-step process:
>
> 1) configure the "switch box" to connect a device to a memory channel
> 2) configure the transfer details (address, size, command)
>
> When the transfer is don
Mason writes:
> On 24/11/2016 15:17, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> [ 35.085854] SETUP DMA
>>> [ 35.088272] START NAND TRANSFER
>>> [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq
>>> [ 35.096882] tango_dma_callback from vchan_complete
>>> [ 45.102513] DONE FAKE
On 24/11/2016 15:17, Måns Rullgård wrote:
> Mason wrote:
>
>> [ 35.085854] SETUP DMA
>> [ 35.088272] START NAND TRANSFER
>> [ 35.091670] tangox_dma_pchan_start from tangox_dma_irq
>> [ 35.096882] tango_dma_callback from vchan_complete
>> [ 45.102513] DONE FAKE SPINNING
>>
>> So the IRQ
Mason writes:
>>> I'm confused. Are you saying there is no solution to my problem
>>> within the existing DMA framework?
>>>
>>> In its current form, the tangox-dma.c driver will fail randomly
>>> for writes to a device (SATA, NFC).
>>>
>>> Maybe an extra hook can be added to the DMA framework?
>
On 23/11/2016 18:21, Måns Rullgård wrote:
> Mason writes:
>
>> On 23/11/2016 13:13, Måns Rullgård wrote:
>>
>>> Mason wrote:
>>>
On my platform, setting up a DMA transfer is a two-step process:
1) configure the "switch box" to connect a device to a memory channel
2) configure
Mason writes:
> On 23/11/2016 13:13, Måns Rullgård wrote:
>
>> Mason wrote:
>>
>>> On my platform, setting up a DMA transfer is a two-step process:
>>>
>>> 1) configure the "switch box" to connect a device to a memory channel
>>> 2) configure the transfer details (address, size, command)
>>>
>>>
On 23/11/2016 13:13, Måns Rullgård wrote:
> Mason wrote:
>
>> On my platform, setting up a DMA transfer is a two-step process:
>>
>> 1) configure the "switch box" to connect a device to a memory channel
>> 2) configure the transfer details (address, size, command)
>>
>> When the transfer is done,
Mason writes:
> Hello,
>
> On my platform, setting up a DMA transfer is a two-step process:
>
> 1) configure the "switch box" to connect a device to a memory channel
> 2) configure the transfer details (address, size, command)
>
> When the transfer is done, the sbox setup can be torn down,
> and
81 matches
Mail list logo
