* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-03 6:42 Kedareswara rao Appana
0 siblings, 0 replies; 10+ messages in thread
From: Kedareswara rao Appana @ 2018-01-03 6:42 UTC (permalink / raw)
To: dan.j.williams, vinod.koul, michal.simek, appanad, lars,
akinobu.mita, joabreu, mike.looijmans, kedare06
Cc: dmaengine, linux-arm-kernel, linux-kernel
When client driver uses dma_get_slave_caps() api,
it checks for certain fields of dma_device struct
currently driver is not settings the directions and addr_widths
fields resulting dma_get_slave_caps() returning failure.
This patch fixes this issue by populating proper values
to the struct dma_device directions and addr_widths fields.
Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
---
Changes for v2:
--> Improved commit message title and description
as suggested by Vinod.
drivers/dma/xilinx/xilinx_dma.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 88d317d..21ac954 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->direction = DMA_MEM_TO_DEV;
chan->id = chan_id;
chan->tdest = chan_id;
+ xdev->common.directions = BIT(DMA_MEM_TO_DEV);
chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
@@ -2415,6 +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->direction = DMA_DEV_TO_MEM;
chan->id = chan_id;
chan->tdest = chan_id - xdev->nr_channels;
+ xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
@@ -2629,6 +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
}
+ xdev->common.dst_addr_widths = BIT(addr_width / 8);
+ xdev->common.src_addr_widths = BIT(addr_width / 8);
xdev->common.device_alloc_chan_resources =
xilinx_dma_alloc_chan_resources;
xdev->common.device_free_chan_resources =
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-08 10:38 Vinod Koul
0 siblings, 0 replies; 10+ messages in thread
From: Vinod Koul @ 2018-01-08 10:38 UTC (permalink / raw)
To: Kedareswara rao Appana
Cc: dan.j.williams, michal.simek, appanad, lars, akinobu.mita,
joabreu, mike.looijmans, kedare06, dmaengine, linux-arm-kernel,
linux-kernel
On Wed, Jan 03, 2018 at 12:12:08PM +0530, Kedareswara rao Appana wrote:
> When client driver uses dma_get_slave_caps() api,
> it checks for certain fields of dma_device struct
> currently driver is not settings the directions and addr_widths
> fields resulting dma_get_slave_caps() returning failure.
>
> This patch fixes this issue by populating proper values
> to the struct dma_device directions and addr_widths fields.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v2:
> --> Improved commit message title and description
> as suggested by Vinod.
>
> drivers/dma/xilinx/xilinx_dma.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 88d317d..21ac954 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_MEM_TO_DEV;
> chan->id = chan_id;
> chan->tdest = chan_id;
> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
>
> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2415,6 +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_DEV_TO_MEM;
> chan->id = chan_id;
> chan->tdest = chan_id - xdev->nr_channels;
> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
>
> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2629,6 +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
> dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
> }
>
> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
> + xdev->common.src_addr_widths = BIT(addr_width / 8);
Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers? What is
value of addr_width here typically? Usually controllers can support
different widths and this is a surprise that you support only one value
^ permalink raw reply [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-08 10:52 Appana Durga Kedareswara Rao
0 siblings, 0 replies; 10+ messages in thread
From: Appana Durga Kedareswara Rao @ 2018-01-08 10:52 UTC (permalink / raw)
To: Vinod Koul
Cc: dan.j.williams@intel.com, michal.simek@xilinx.com,
lars@metafoo.de, akinobu.mita@gmail.com, joabreu@synopsys.com,
mike.looijmans@topic.nl, kedare06@gmail.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Hi Vinod,
Thanks for the review....
<Snip>
>> @@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct
>xilinx_dma_device *xdev,
>> chan->direction = DMA_MEM_TO_DEV;
>> chan->id = chan_id;
>> chan->tdest = chan_id;
>> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
>>
>> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
>> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) { @@ -
>2415,6
>> +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
>> chan->direction = DMA_DEV_TO_MEM;
>> chan->id = chan_id;
>> chan->tdest = chan_id - xdev->nr_channels;
>> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
>>
>> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
>> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) { @@ -
>2629,6
>> +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
>> dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
>> }
>>
>> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> + xdev->common.src_addr_widths = BIT(addr_width / 8);
>
>Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers? What is value
>of addr_width here typically? Usually controllers can support different widths and
>this is a surprise that you support only one value
Controller supports address width of 32 and 64.
addr_width typical values are 32-bit or 64-bit .
Here addr_width is device-tree parameter...
my understanding of src_addr_widths/dst_addr_widths is, it is a bit mask of the
address with in bytes that DMA supports, please correct if my understanding is wrong.
Regards,
Kedar.
>
>--
>~Vinod
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-08 17:06 Vinod Koul
0 siblings, 0 replies; 10+ messages in thread
From: Vinod Koul @ 2018-01-08 17:06 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: dan.j.williams@intel.com, michal.simek@xilinx.com,
lars@metafoo.de, akinobu.mita@gmail.com, joabreu@synopsys.com,
mike.looijmans@topic.nl, kedare06@gmail.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
On Mon, Jan 08, 2018 at 10:52:01AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
>
> Thanks for the review....
> <Snip>
> >> @@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct
> >xilinx_dma_device *xdev,
> >> chan->direction = DMA_MEM_TO_DEV;
> >> chan->id = chan_id;
> >> chan->tdest = chan_id;
> >> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
> >>
> >> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
> >> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) { @@ -
> >2415,6
> >> +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> >> chan->direction = DMA_DEV_TO_MEM;
> >> chan->id = chan_id;
> >> chan->tdest = chan_id - xdev->nr_channels;
> >> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
> >>
> >> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
> >> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) { @@ -
> >2629,6
> >> +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
> >> dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
> >> }
> >>
> >> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
> >> + xdev->common.src_addr_widths = BIT(addr_width / 8);
> >
> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers? What is value
> >of addr_width here typically? Usually controllers can support different widths and
> >this is a surprise that you support only one value
>
> Controller supports address width of 32 and 64.
Then this should have both 32 and 64 values here
> addr_width typical values are 32-bit or 64-bit .
> Here addr_width is device-tree parameter...
> my understanding of src_addr_widths/dst_addr_widths is, it is a bit mask of the
> address with in bytes that DMA supports, please correct if my understanding is wrong.
>
> Regards,
> Kedar.
>
> >
> >--
> >~Vinod
^ permalink raw reply [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-08 17:25 Appana Durga Kedareswara Rao
0 siblings, 0 replies; 10+ messages in thread
From: Appana Durga Kedareswara Rao @ 2018-01-08 17:25 UTC (permalink / raw)
To: Vinod Koul
Cc: dan.j.williams@intel.com, michal.simek@xilinx.com,
lars@metafoo.de, akinobu.mita@gmail.com, joabreu@synopsys.com,
mike.looijmans@topic.nl, kedare06@gmail.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Hi,
<Snip>
>> >> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> >> + xdev->common.src_addr_widths = BIT(addr_width / 8);
>> >
>> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
>> >What is value of addr_width here typically? Usually controllers can
>> >support different widths and this is a surprise that you support only
>> >one value
>>
>> Controller supports address width of 32 and 64.
>
>Then this should have both 32 and 64 values here
Address width is configurable parameter at the h/w level.
Since this IP is a soft IP user can create a design with either
32-bit or 64-bit address configuration.
Currently we are reading this configuration through device-tree (xlnx, addr-width property)
https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git/tree/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt#n19
Based on the h/w configuration setting the dst_addr_widths/src_addr_widths variables in this patch.
Please let me know if you are still not clear with my explanation will explain in detail...
Regards,
Kedar.
>
>> addr_width typical values are 32-bit or 64-bit .
>> Here addr_width is device-tree parameter...
>> my understanding of src_addr_widths/dst_addr_widths is, it is a bit
>> mask of the address with in bytes that DMA supports, please correct if my
>understanding is wrong.
>>
>> Regards,
>> Kedar.
>>
>> >
>> >--
>> >~Vinod
>
>--
>~Vinod
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-09 4:48 Appana Durga Kedareswara Rao
0 siblings, 0 replies; 10+ messages in thread
From: Appana Durga Kedareswara Rao @ 2018-01-09 4:48 UTC (permalink / raw)
To: Vinod Koul
Cc: dan.j.williams@intel.com, michal.simek@xilinx.com,
lars@metafoo.de, akinobu.mita@gmail.com, joabreu@synopsys.com,
mike.looijmans@topic.nl, kedare06@gmail.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Hi,
>On Mon, Jan 08, 2018 at 05:25:01PM +0000, Appana Durga Kedareswara Rao
>wrote:
>> Hi,
>>
>> <Snip>
>> >> >> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> >> >> + xdev->common.src_addr_widths = BIT(addr_width / 8);
>> >> >
>> >> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
>> >> >What is value of addr_width here typically? Usually controllers
>> >> >can support different widths and this is a surprise that you
>> >> >support only one value
>> >>
>> >> Controller supports address width of 32 and 64.
>> >
>> >Then this should have both 32 and 64 values here
>>
>> Address width is configurable parameter at the h/w level.
>> Since this IP is a soft IP user can create a design with either 32-bit
>> or 64-bit address configuration.
>
>and not both right?
Yes not both at the same time...
Axi dma controller can be configured for either 32-bit or 64-bit address...
Regards,
Kedar.
>
>> Currently we are reading this configuration through device-tree (xlnx,
>> addr-width property)
>> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git/tr
>> ee/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt#n19
>> Based on the h/w configuration setting the dst_addr_widths/src_addr_widths
>variables in this patch.
>> Please let me know if you are still not clear with my explanation will explain in
>detail...
>>
>> Regards,
>> Kedar.
>>
>> >
>> >> addr_width typical values are 32-bit or 64-bit .
>> >> Here addr_width is device-tree parameter...
>> >> my understanding of src_addr_widths/dst_addr_widths is, it is a bit
>> >> mask of the address with in bytes that DMA supports, please correct
>> >> if my
>> >understanding is wrong.
>> >>
>> >> Regards,
>> >> Kedar.
>> >>
>> >> >
>> >> >--
>> >> >~Vinod
>> >
>> >--
>> >~Vinod
>
>--
>~Vinod
>--
>To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body
>of a message to majordomo@vger.kernel.org More majordomo info at
>http://vger.kernel.org/majordomo-info.html
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-09 4:48 Vinod Koul
0 siblings, 0 replies; 10+ messages in thread
From: Vinod Koul @ 2018-01-09 4:48 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: dan.j.williams@intel.com, michal.simek@xilinx.com,
lars@metafoo.de, akinobu.mita@gmail.com, joabreu@synopsys.com,
mike.looijmans@topic.nl, kedare06@gmail.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
On Mon, Jan 08, 2018 at 05:25:01PM +0000, Appana Durga Kedareswara Rao wrote:
> Hi,
>
> <Snip>
> >> >> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
> >> >> + xdev->common.src_addr_widths = BIT(addr_width / 8);
> >> >
> >> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
> >> >What is value of addr_width here typically? Usually controllers can
> >> >support different widths and this is a surprise that you support only
> >> >one value
> >>
> >> Controller supports address width of 32 and 64.
> >
> >Then this should have both 32 and 64 values here
>
> Address width is configurable parameter at the h/w level.
> Since this IP is a soft IP user can create a design with either
> 32-bit or 64-bit address configuration.
and not both right?
> Currently we are reading this configuration through device-tree (xlnx, addr-width property)
> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git/tree/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt#n19
> Based on the h/w configuration setting the dst_addr_widths/src_addr_widths variables in this patch.
> Please let me know if you are still not clear with my explanation will explain in detail...
>
> Regards,
> Kedar.
>
> >
> >> addr_width typical values are 32-bit or 64-bit .
> >> Here addr_width is device-tree parameter...
> >> my understanding of src_addr_widths/dst_addr_widths is, it is a bit
> >> mask of the address with in bytes that DMA supports, please correct if my
> >understanding is wrong.
> >>
> >> Regards,
> >> Kedar.
> >>
> >> >
> >> >--
> >> >~Vinod
> >
> >--
> >~Vinod
^ permalink raw reply [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-09 5:04 Vinod Koul
0 siblings, 0 replies; 10+ messages in thread
From: Vinod Koul @ 2018-01-09 5:04 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: dan.j.williams@intel.com, michal.simek@xilinx.com,
lars@metafoo.de, akinobu.mita@gmail.com, joabreu@synopsys.com,
mike.looijmans@topic.nl, kedare06@gmail.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
On Tue, Jan 09, 2018 at 04:48:10AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi,
>
> >On Mon, Jan 08, 2018 at 05:25:01PM +0000, Appana Durga Kedareswara Rao
> >wrote:
> >> Hi,
> >>
> >> <Snip>
> >> >> >> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
> >> >> >> + xdev->common.src_addr_widths = BIT(addr_width / 8);
> >> >> >
> >> >> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
> >> >> >What is value of addr_width here typically? Usually controllers
> >> >> >can support different widths and this is a surprise that you
> >> >> >support only one value
> >> >>
> >> >> Controller supports address width of 32 and 64.
> >> >
> >> >Then this should have both 32 and 64 values here
> >>
> >> Address width is configurable parameter at the h/w level.
> >> Since this IP is a soft IP user can create a design with either 32-bit
> >> or 64-bit address configuration.
> >
> >and not both right?
>
> Yes not both at the same time...
> Axi dma controller can be configured for either 32-bit or 64-bit address...
So my suspicion was correct. I would suggest you to read up on the
documentation again. The src/dst_addr_widths has _nothing_ to do with 32/64
bit addresses used.
It is the capability of the dma controller to do transfers with data width as
8bits, 16 bits, so on. iKey is "data width" and not address type.
This typically translates to DMA FIFO configuration of the controller!
^ permalink raw reply [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-09 7:36 Appana Durga Kedareswara Rao
0 siblings, 0 replies; 10+ messages in thread
From: Appana Durga Kedareswara Rao @ 2018-01-09 7:36 UTC (permalink / raw)
To: Vinod Koul
Cc: dan.j.williams@intel.com, michal.simek@xilinx.com,
lars@metafoo.de, akinobu.mita@gmail.com, joabreu@synopsys.com,
mike.looijmans@topic.nl, kedare06@gmail.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Hi,
Thanks for the review...
>On Tue, Jan 09, 2018 at 04:48:10AM +0000, Appana Durga Kedareswara Rao
>wrote:
>> Hi,
>>
>> >On Mon, Jan 08, 2018 at 05:25:01PM +0000, Appana Durga Kedareswara
>> >Rao
>> >wrote:
>> >> Hi,
>> >>
>> >> <Snip>
>> >> >> >> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> >> >> >> + xdev->common.src_addr_widths = BIT(addr_width / 8);
>> >> >> >
>> >> >> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
>> >> >> >What is value of addr_width here typically? Usually controllers
>> >> >> >can support different widths and this is a surprise that you
>> >> >> >support only one value
>> >> >>
>> >> >> Controller supports address width of 32 and 64.
>> >> >
>> >> >Then this should have both 32 and 64 values here
>> >>
>> >> Address width is configurable parameter at the h/w level.
>> >> Since this IP is a soft IP user can create a design with either
>> >> 32-bit or 64-bit address configuration.
>> >
>> >and not both right?
>>
>> Yes not both at the same time...
>> Axi dma controller can be configured for either 32-bit or 64-bit address...
>
>So my suspicion was correct. I would suggest you to read up on the
>documentation again. The src/dst_addr_widths has _nothing_ to do with 32/64
>bit addresses used.
>
>It is the capability of the dma controller to do transfers with data width as 8bits,
>16 bits, so on. iKey is "data width" and not address type.
>This typically translates to DMA FIFO configuration of the controller!
Thanks for the detailed explanation...
I have gone through the spec again controller does supports 1 byte, 2 byte, 4 byte up to 128 byte transfers.
In order to do variable length transfers user needs to drive a valid value to the tkeep strobe signal at the h/w level.
And user needs to configure the below parameters c_m_axis_mm2s_tdata_width or c_m_axis_s2mm_tdata_width
With desired configuration at the h/w level.
Controller supports data width of 8, 16, 32, 64, 128, 256, 512 and 1,024 bits
(i.e. c_m_axis_mm2s_tdata_width/ c_m_axis_s2mm_tdata_width parameters range)
At the s/w level currently we are getting c_m_axis_mm2s_tdata_width/ c_m_axis_s2mm_tdata_width
Configuration as xlnx,datawidth property in the device-tree.
So proper values for the src/dst_addr width fields should be, datawidth property in bytes.
Please correct me if I am wrong...
Changes looks like below...
Here width is in bytes based on the h/w configuration...
Regards,
Kedar.
>
>--
>~Vinod
---
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -2411,6 +2411,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->direction = DMA_MEM_TO_DEV;
chan->id = chan_id;
chan->tdest = chan_id;
+ xdev->common.directions = BIT(DMA_MEM_TO_DEV);
+ xdev->common.src_addr_widths = BIT(width);
chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
@@ -2428,6 +2430,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
chan->direction = DMA_DEV_TO_MEM;
chan->id = chan_id;
chan->tdest = chan_id - xdev->nr_channels;
+ xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
+ xdev->common.dst_addr_widths = BIT(width);
chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
^ permalink raw reply [flat|nested] 10+ messages in thread
* [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly
@ 2018-01-11 6:21 Vinod Koul
0 siblings, 0 replies; 10+ messages in thread
From: Vinod Koul @ 2018-01-11 6:21 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: dan.j.williams@intel.com, michal.simek@xilinx.com,
lars@metafoo.de, akinobu.mita@gmail.com, joabreu@synopsys.com,
mike.looijmans@topic.nl, kedare06@gmail.com,
dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
On Tue, Jan 09, 2018 at 07:36:11AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi,
>
> Thanks for the review...
>
> >On Tue, Jan 09, 2018 at 04:48:10AM +0000, Appana Durga Kedareswara Rao
> >wrote:
> >> Hi,
> >>
> >> >On Mon, Jan 08, 2018 at 05:25:01PM +0000, Appana Durga Kedareswara
> >> >Rao
> >> >wrote:
> >> >> Hi,
> >> >>
> >> >> <Snip>
> >> >> >> >> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
> >> >> >> >> + xdev->common.src_addr_widths = BIT(addr_width / 8);
> >> >> >> >
> >> >> >> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
> >> >> >> >What is value of addr_width here typically? Usually controllers
> >> >> >> >can support different widths and this is a surprise that you
> >> >> >> >support only one value
> >> >> >>
> >> >> >> Controller supports address width of 32 and 64.
> >> >> >
> >> >> >Then this should have both 32 and 64 values here
> >> >>
> >> >> Address width is configurable parameter at the h/w level.
> >> >> Since this IP is a soft IP user can create a design with either
> >> >> 32-bit or 64-bit address configuration.
> >> >
> >> >and not both right?
> >>
> >> Yes not both at the same time...
> >> Axi dma controller can be configured for either 32-bit or 64-bit address...
> >
> >So my suspicion was correct. I would suggest you to read up on the
> >documentation again. The src/dst_addr_widths has _nothing_ to do with 32/64
> >bit addresses used.
> >
> >It is the capability of the dma controller to do transfers with data width as 8bits,
> >16 bits, so on. iKey is "data width" and not address type.
> >This typically translates to DMA FIFO configuration of the controller!
>
> Thanks for the detailed explanation...
Welcome but I don't understand why you xilinx folks cant wrap your replies,
it is *very* hard to read on screens with 80chars
> I have gone through the spec again controller does supports 1 byte, 2
> byte, 4 byte up to 128 byte transfers.
I think you are talking about length and NOT width
> In order to do variable length transfers user needs to drive a valid value
> to the tkeep strobe signal at the h/w level.
bingo
> And user needs to configure the below parameters c_m_axis_mm2s_tdata_width
> or c_m_axis_s2mm_tdata_width With desired configuration at the h/w level.
> Controller supports data width of 8, 16, 32, 64, 128, 256, 512 and 1,024
> bits (i.e. c_m_axis_mm2s_tdata_width/ c_m_axis_s2mm_tdata_width parameters
> range)
holy cow, did you read that right. and 1024 bit width, how wide is your FIFO
I think you are off the rails here, please get your length and width
concepts right, they are NOT same and refer to different things and cannot be
used interchangably
>
> At the s/w level currently we are getting c_m_axis_mm2s_tdata_width/ c_m_axis_s2mm_tdata_width
> Configuration as xlnx,datawidth property in the device-tree.
>
> So proper values for the src/dst_addr width fields should be, datawidth property in bytes.
> Please correct me if I am wrong...
>
> Changes looks like below...
> Here width is in bytes based on the h/w configuration...
>
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -2411,6 +2411,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_MEM_TO_DEV;
> chan->id = chan_id;
> chan->tdest = chan_id;
> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
> + xdev->common.src_addr_widths = BIT(width);
>
> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2428,6 +2430,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_DEV_TO_MEM;
> chan->id = chan_id;
> chan->tdest = chan_id - xdev->nr_channels;
> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
> + xdev->common.dst_addr_widths = BIT(width);
>
> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
>
>
> Regards,
> Kedar.
>
> >
> >--
> >~Vinod
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-01-11 6:21 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-09 4:48 [v2,1/4] dmaengine: xilinx_dma: populate dma caps properly Vinod Koul
-- strict thread matches above, loose matches on Subject: below --
2018-01-11 6:21 Vinod Koul
2018-01-09 7:36 Appana Durga Kedareswara Rao
2018-01-09 5:04 Vinod Koul
2018-01-09 4:48 Appana Durga Kedareswara Rao
2018-01-08 17:25 Appana Durga Kedareswara Rao
2018-01-08 17:06 Vinod Koul
2018-01-08 10:52 Appana Durga Kedareswara Rao
2018-01-08 10:38 Vinod Koul
2018-01-03 6:42 Kedareswara rao Appana
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).