All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
To: Jose Abreu <jose.abreu@synopsys.com>,
	Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Eugeniy Paltsev <eugeniy.paltsev@synopsys.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Niklas Cassel <niklas.cassel@linaro.org>,
	Joao Pinto <joao.pinto@synopsys.com>,
	Luis Oliveira <luis.oliveira@synopsys.com>,
	Vitor Soares <vitor.soares@synopsys.com>,
	Nelson Costa <nelson.costa@synopsys.com>,
	Pedro Sousa <pedrom.sousa@synopsys.com>
Subject: [RFC,v3,2/7] dmaengine: Add Synopsys eDMA IP version 0 support
Date: Wed, 16 Jan 2019 14:02:10 +0000	[thread overview]
Message-ID: <5fbdc016-138c-ced0-4dd5-9791bee9d34c@synopsys.com> (raw)

Hi Jose,

On 16/01/2019 10:33, Jose Abreu wrote:
> Hi Gustavo,
> 
> On 1/11/2019 6:33 PM, Gustavo Pimentel wrote:
>> Add support for the eDMA IP version 0 driver for both register maps (legacy
>> and unroll).
>>
>> The legacy register mapping was the initial implementation, which consisted
>> in having all registers belonging to channels multiplexed, which could be
>> change anytime (which could led a race-condition) by view port register
>> (access to only one channel available each time).
>>
>> This register mapping is not very effective and efficient in a multithread
>> environment, which has led to the development of unroll registers mapping,
>> which consists of having all channels registers accessible any time by
>> spreading all channels registers by an offset between them.
>>
>> This version supports a maximum of 16 independent channels (8 write +
>> 8 read), which can run simultaneously.
>>
>> Implements a scatter-gather transfer through a linked list, where the size
>> of linked list depends on the allocated memory divided equally among all
>> channels.
>>
>> Each linked list descriptor can transfer from 1 byte to 4 Gbytes and is
>> alignmented to DWORD.
>>
>> Both SAR (Source Address Register) and DAR (Destination Address Register)
>> are alignmented to byte.
>>
>> Changes:
>> RFC v1->RFC v2:
>>  - Replace comments // (C99 style) by /**/
>>  - Replace magic numbers by defines
>>  - Replace boolean return from ternary operation by a double negation
>>    operation
>>  - Replace QWORD_HI/QWORD_LO macros by upper_32_bits()/lower_32_bits()
>>  - Fix the headers of the .c and .h files according to the most recent
>>    convention
>>  - Fix errors and checks pointed out by checkpatch with --strict option
>>  - Replace patch small description tag from dma by dmaengine
>>  - Refactor code to replace atomic_t by u32 variable type
>> RFC v2->RFC v3:
>>  - Code rewrite to use FIELD_PREP() and FIELD_GET()
>>  - Add define to magic numbers
>>  - Fix minor bugs
>>
>> Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
>> Cc: Vinod Koul <vkoul@kernel.org>
>> Cc: Dan Williams <dan.j.williams@intel.com>
>> Cc: Eugeniy Paltsev <paltsev@synopsys.com>
>> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Cc: Russell King <rmk+kernel@armlinux.org.uk>
>> Cc: Niklas Cassel <niklas.cassel@linaro.org>
>> Cc: Joao Pinto <jpinto@synopsys.com>
>> Cc: Jose Abreu <jose.abreu@synopsys.com>
>> Cc: Luis Oliveira <lolivei@synopsys.com>
>> Cc: Vitor Soares <vitor.soares@synopsys.com>
>> Cc: Nelson Costa <nelson.costa@synopsys.com>
>> Cc: Pedro Sousa <pedrom.sousa@synopsys.com>
> 
>> +void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
>> +{
>> +	struct dw_edma_chan *chan = chunk->chan;
>> +	struct dw_edma *dw = chan->chip->dw;
>> +	u32 tmp;
>> +	u64 llp;
>> +
>> +	dw_edma_v0_core_write_chunk(chunk);
>> +
>> +	if (first) {
>> +		/* Enable engine */
>> +		SET_RW(dw, chan->dir, engine_en, BIT(0));
>> +		/* Interrupt unmask - done, abort */
>> +		tmp = GET_RW(dw, chan->dir, int_mask);
>> +		tmp &= ~FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id));
>> +		tmp &= ~FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id));
>> +		SET_RW(dw, chan->dir, int_mask, tmp);
>> +		/* Linked list error */
>> +		tmp = GET_RW(dw, chan->dir, linked_list_err_en);
>> +		tmp |= FIELD_PREP(EDMA_V0_LINKED_LIST_ERR_MASK, BIT(chan->id));
>> +		SET_RW(dw, chan->dir, linked_list_err_en, tmp);
>> +		/* Channel control */
>> +		SET_CH(dw, chan->dir, chan->id, ch_control1,
>> +		       (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE));
>> +		/* Linked list - low, high */
>> +		llp = cpu_to_le64(chunk->ll_region.paddr);
>> +		SET_CH(dw, chan->dir, chan->id, llp_low, lower_32_bits(llp));
>> +		SET_CH(dw, chan->dir, chan->id, llp_high, upper_32_bits(llp));
>> +	}
>> +	/* Doorbell */
> 
> Not sure if DMA subsystem does this but maybe you need some kind
> of barrier to ensure everything is coherent before granting
> control to eDMA ?

Each readl and writel inside of helper macros (SET_RW/GETRW and SET_CH/GET_CH)
has a memory barrier, that grants that the coherency, however this is platform
dependent.

> 
>> +	SET_RW(dw, chan->dir, doorbell,
>> +	       FIELD_PREP(EDMA_V0_DOORBELL_CH_MASK, chan->id));
>> +}
>> +

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
To: Jose Abreu <jose.abreu@synopsys.com>,
	Gustavo Pimentel <gustavo.pimentel@synopsys.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Eugeniy Paltsev <eugeniy.paltsev@synopsys.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Niklas Cassel <niklas.cassel@linaro.org>,
	Joao Pinto <joao.pinto@synopsys.com>,
	Luis Oliveira <luis.oliveira@synopsys.com>,
	Vitor Soares <vitor.soares@synopsys.com>,
	Nelson Costa <nelson.costa@synopsys.com>,
	Pedro Sousa <pedrom.sousa@synopsys.com>
Subject: Re: [RFC v3 2/7] dmaengine: Add Synopsys eDMA IP version 0 support
Date: Wed, 16 Jan 2019 14:02:10 +0000	[thread overview]
Message-ID: <5fbdc016-138c-ced0-4dd5-9791bee9d34c@synopsys.com> (raw)
In-Reply-To: <c7c2ff4a-5766-d829-ac3f-43fc280a457a@synopsys.com>

Hi Jose,

On 16/01/2019 10:33, Jose Abreu wrote:
> Hi Gustavo,
> 
> On 1/11/2019 6:33 PM, Gustavo Pimentel wrote:
>> Add support for the eDMA IP version 0 driver for both register maps (legacy
>> and unroll).
>>
>> The legacy register mapping was the initial implementation, which consisted
>> in having all registers belonging to channels multiplexed, which could be
>> change anytime (which could led a race-condition) by view port register
>> (access to only one channel available each time).
>>
>> This register mapping is not very effective and efficient in a multithread
>> environment, which has led to the development of unroll registers mapping,
>> which consists of having all channels registers accessible any time by
>> spreading all channels registers by an offset between them.
>>
>> This version supports a maximum of 16 independent channels (8 write +
>> 8 read), which can run simultaneously.
>>
>> Implements a scatter-gather transfer through a linked list, where the size
>> of linked list depends on the allocated memory divided equally among all
>> channels.
>>
>> Each linked list descriptor can transfer from 1 byte to 4 Gbytes and is
>> alignmented to DWORD.
>>
>> Both SAR (Source Address Register) and DAR (Destination Address Register)
>> are alignmented to byte.
>>
>> Changes:
>> RFC v1->RFC v2:
>>  - Replace comments // (C99 style) by /**/
>>  - Replace magic numbers by defines
>>  - Replace boolean return from ternary operation by a double negation
>>    operation
>>  - Replace QWORD_HI/QWORD_LO macros by upper_32_bits()/lower_32_bits()
>>  - Fix the headers of the .c and .h files according to the most recent
>>    convention
>>  - Fix errors and checks pointed out by checkpatch with --strict option
>>  - Replace patch small description tag from dma by dmaengine
>>  - Refactor code to replace atomic_t by u32 variable type
>> RFC v2->RFC v3:
>>  - Code rewrite to use FIELD_PREP() and FIELD_GET()
>>  - Add define to magic numbers
>>  - Fix minor bugs
>>
>> Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
>> Cc: Vinod Koul <vkoul@kernel.org>
>> Cc: Dan Williams <dan.j.williams@intel.com>
>> Cc: Eugeniy Paltsev <paltsev@synopsys.com>
>> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Cc: Russell King <rmk+kernel@armlinux.org.uk>
>> Cc: Niklas Cassel <niklas.cassel@linaro.org>
>> Cc: Joao Pinto <jpinto@synopsys.com>
>> Cc: Jose Abreu <jose.abreu@synopsys.com>
>> Cc: Luis Oliveira <lolivei@synopsys.com>
>> Cc: Vitor Soares <vitor.soares@synopsys.com>
>> Cc: Nelson Costa <nelson.costa@synopsys.com>
>> Cc: Pedro Sousa <pedrom.sousa@synopsys.com>
> 
>> +void dw_edma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
>> +{
>> +	struct dw_edma_chan *chan = chunk->chan;
>> +	struct dw_edma *dw = chan->chip->dw;
>> +	u32 tmp;
>> +	u64 llp;
>> +
>> +	dw_edma_v0_core_write_chunk(chunk);
>> +
>> +	if (first) {
>> +		/* Enable engine */
>> +		SET_RW(dw, chan->dir, engine_en, BIT(0));
>> +		/* Interrupt unmask - done, abort */
>> +		tmp = GET_RW(dw, chan->dir, int_mask);
>> +		tmp &= ~FIELD_PREP(EDMA_V0_DONE_INT_MASK, BIT(chan->id));
>> +		tmp &= ~FIELD_PREP(EDMA_V0_ABORT_INT_MASK, BIT(chan->id));
>> +		SET_RW(dw, chan->dir, int_mask, tmp);
>> +		/* Linked list error */
>> +		tmp = GET_RW(dw, chan->dir, linked_list_err_en);
>> +		tmp |= FIELD_PREP(EDMA_V0_LINKED_LIST_ERR_MASK, BIT(chan->id));
>> +		SET_RW(dw, chan->dir, linked_list_err_en, tmp);
>> +		/* Channel control */
>> +		SET_CH(dw, chan->dir, chan->id, ch_control1,
>> +		       (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE));
>> +		/* Linked list - low, high */
>> +		llp = cpu_to_le64(chunk->ll_region.paddr);
>> +		SET_CH(dw, chan->dir, chan->id, llp_low, lower_32_bits(llp));
>> +		SET_CH(dw, chan->dir, chan->id, llp_high, upper_32_bits(llp));
>> +	}
>> +	/* Doorbell */
> 
> Not sure if DMA subsystem does this but maybe you need some kind
> of barrier to ensure everything is coherent before granting
> control to eDMA ?

Each readl and writel inside of helper macros (SET_RW/GETRW and SET_CH/GET_CH)
has a memory barrier, that grants that the coherency, however this is platform
dependent.

> 
>> +	SET_RW(dw, chan->dir, doorbell,
>> +	       FIELD_PREP(EDMA_V0_DOORBELL_CH_MASK, chan->id));
>> +}
>> +

Thanks!

             reply	other threads:[~2019-01-16 14:02 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 14:02 Gustavo Pimentel [this message]
2019-01-16 14:02 ` [RFC v3 2/7] dmaengine: Add Synopsys eDMA IP version 0 support Gustavo Pimentel
  -- strict thread matches above, loose matches on Subject: below --
2019-02-06 18:06 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-02-06 18:06 ` [RFC v3 1/7] " Gustavo Pimentel
2019-02-02 10:07 [RFC,v3,1/7] " Vinod Koul
2019-02-02 10:07 ` [RFC v3 1/7] " Vinod Koul
2019-02-01 11:23 [RFC,v3,1/7] " Gustavo Pimentel
2019-02-01 11:23 ` [RFC v3 1/7] " Gustavo Pimentel
2019-02-01  4:14 [RFC,v3,1/7] " Vinod Koul
2019-02-01  4:14 ` [RFC v3 1/7] " Vinod Koul
2019-01-31 11:33 [RFC,v3,1/7] " Gustavo Pimentel
2019-01-31 11:33 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-23 13:08 [RFC,v3,1/7] " Vinod Koul
2019-01-23 13:08 ` [RFC v3 1/7] " Vinod Koul
2019-01-21 15:59 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-21 15:59 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-21 15:49 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-01-21 15:49 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-21 15:48 [RFC,v3,1/7] " Gustavo Pimentel
2019-01-21 15:48 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-21  9:21 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Gustavo Pimentel
2019-01-21  9:21 ` [RFC v3 5/7] " Gustavo Pimentel
2019-01-21  9:14 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-01-21  9:14 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-20 11:47 [RFC,v3,1/7] " Vinod Koul
2019-01-20 11:47 ` [RFC v3 1/7] " Vinod Koul
2019-01-20 11:44 [RFC,v3,1/7] " Vinod Koul
2019-01-20 11:44 ` [RFC v3 1/7] " Vinod Koul
2019-01-19 16:21 [RFC,v3,1/7] " Andy Shevchenko
2019-01-19 16:21 ` [RFC v3 1/7] " Andy Shevchenko
2019-01-19 15:45 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Andy Shevchenko
2019-01-19 15:45 ` [RFC v3 5/7] " Andy Shevchenko
2019-01-17  5:03 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Vinod Koul
2019-01-17  5:03 ` [RFC v3 7/7] " Vinod Koul
2019-01-16 11:56 [RFC,v3,7/7] " Gustavo Pimentel
2019-01-16 11:56 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-16 11:53 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-01-16 11:53 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-16 10:45 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Jose Abreu
2019-01-16 10:45 ` [RFC v3 7/7] " Jose Abreu
2019-01-16 10:33 [RFC,v3,2/7] dmaengine: Add Synopsys eDMA IP version 0 support Jose Abreu
2019-01-16 10:33 ` [RFC v3 2/7] " Jose Abreu
2019-01-16 10:21 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Jose Abreu
2019-01-16 10:21 ` [RFC v3 1/7] " Jose Abreu
2019-01-15 13:02 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-15 13:02 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-15 12:48 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Gustavo Pimentel
2019-01-15 12:48 ` [RFC v3 5/7] " Gustavo Pimentel
2019-01-15  5:45 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Andy Shevchenko
2019-01-15  5:45 ` [RFC v3 7/7] " Andy Shevchenko
2019-01-15  5:43 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Andy Shevchenko
2019-01-15  5:43 ` [RFC v3 5/7] " Andy Shevchenko
2019-01-14 14:41 [RFC,v3,4/7] PCI: Add Synopsys endpoint EDDA Device id Bjorn Helgaas
2019-01-14 14:41 ` [RFC v3 4/7] " Bjorn Helgaas
2019-01-14 11:44 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-14 11:44 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-14 11:38 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Gustavo Pimentel
2019-01-14 11:38 ` [RFC v3 5/7] " Gustavo Pimentel
2019-01-11 19:48 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Andy Shevchenko
2019-01-11 19:48 ` [RFC v3 7/7] " Andy Shevchenko
2019-01-11 19:47 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Andy Shevchenko
2019-01-11 19:47 ` [RFC v3 5/7] " Andy Shevchenko
2019-01-11 18:33 [RFC,v3,7/7] dmaengine: Add Synopsys eDMA IP test and sample driver Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 7/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,6/7] MAINTAINERS: Add Synopsys eDMA IP driver maintainer Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 6/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,5/7] dmaengine: Add Synopsys eDMA IP PCIe glue-logic Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 5/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,4/7] PCI: Add Synopsys endpoint EDDA Device id Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 4/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,3/7] dmaengine: Add Synopsys eDMA IP version 0 debugfs support Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 3/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,2/7] dmaengine: Add Synopsys eDMA IP version 0 support Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 2/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC,v3,1/7] dmaengine: Add Synopsys eDMA IP core driver Gustavo Pimentel
2019-01-11 18:33 ` [RFC v3 1/7] " Gustavo Pimentel
2019-01-11 18:33 [RFC v3 0/6] dmaengine: Add Synopsys eDMA IP driver (version 0) Gustavo Pimentel

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=5fbdc016-138c-ced0-4dd5-9791bee9d34c@synopsys.com \
    --to=gustavo.pimentel@synopsys.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=eugeniy.paltsev@synopsys.com \
    --cc=joao.pinto@synopsys.com \
    --cc=jose.abreu@synopsys.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=luis.oliveira@synopsys.com \
    --cc=nelson.costa@synopsys.com \
    --cc=niklas.cassel@linaro.org \
    --cc=pedrom.sousa@synopsys.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=vitor.soares@synopsys.com \
    --cc=vkoul@kernel.org \
    /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.