Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1420451 > unrolled thread

Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver  support Vinod Koul <vinod.koul@intel.com> - 2016-06-13 07:50 +0200
    RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver  support Appana Durga Kedareswara Rao <appana.durga.rao@xilinx.com> - 2016-06-14 10:20 +0200
      Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver  support Vinod Koul <vinod.koul@intel.com> - 2016-06-15 18:50 +0200
        RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver  support Appana Durga Kedareswara Rao <appana.durga.rao@xilinx.com> - 2016-06-16 09:20 +0200
          Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver  support Vinod Koul <vinod.koul@intel.com> - 2016-06-21 17:40 +0200
            Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver  support Vinod Koul <vinod.koul@intel.com> - 2016-06-21 19:20 +0200
              RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver  support Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@xilinx.com> - 2016-06-21 19:50 +0200
            RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver  support Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@xilinx.com> - 2016-06-21 20:00 +0200

#1420451 — Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

On Wed, Jun 08, 2016 at 07:40:52AM +0000, Appana Durga Kedareswara Rao wrote:
> > > +static void zynqmp_dma_desc_config_eod(struct zynqmp_dma_chan *chan,
> > > +void *desc)
> > 
> > eod? 80 line?

What's eod?

> > > +int zynqmp_dma_channel_set_config(struct dma_chan *dchan,
> > > +				  struct zynqmp_dma_config *cfg)
> > > +{
> > > +	struct zynqmp_dma_chan *chan = to_chan(dchan);
> > > +
> > > +	chan->config.ovrfetch = cfg->ovrfetch;
> > > +	chan->config.has_sg = cfg->has_sg;
> > 
> > is this HW capability? if so why would anyone not like to use it!
> 
> Yes it is HW capability. It can be either in simple mode or SG mode
> Earlier In the driver this configuration is read from the device-tree 
> But as per lars and your suggestion moved it as runtime config parameters.

If sg mode is available why would anyone _not_ want it?

I do not think there is point to have this

> 
> > 
> > > +	chan->config.ratectrl = cfg->ratectrl;
> > > +	chan->config.src_issue = cfg->src_issue;
> > > +	chan->config.src_burst_len = cfg->src_burst_len;
> > > +	chan->config.dst_burst_len = cfg->dst_burst_len;
> > 
> > can you describe these parameters?
> ratectl:
> Rate control can be independently enabled per channel. When rate control is enabled, the
> DMA channel uses the rate control count to schedule successive data read transactions.

And how is this used by client?

> src_issue:
> Tells outstanding transaction on SRC.

This should be read only then, right?

> Burst_len: 
> Configures the burst length of the src and dst transfers...

Hmmm, but you are on memcpy, so that should be programmed for throughput?

> > 
> > How would a client know how to configure them?
> 
> With the default values of the config parameters driver will work.

But how will client know what is default!

> If user has specific requirement to change these parameters they can pass
> It to the driver using set_config API and all these parameters are
> Documented in the include/linux/dma/xilinx_dma.h file...

Can you give me an example where user would like to do that

-- 
~Vinod

[toc] | [next] | [standalone]

#1421652

Hi Vinod,

	Thanks for the review...

> 
> On Wed, Jun 08, 2016 at 07:40:52AM +0000, Appana Durga Kedareswara Rao
> wrote:
> > > > +static void zynqmp_dma_desc_config_eod(struct zynqmp_dma_chan
> > > > +*chan, void *desc)
> > >
> > > eod? 80 line?
> 
> What's eod?

End of descriptor...

> 
> > > > +int zynqmp_dma_channel_set_config(struct dma_chan *dchan,
> > > > +				  struct zynqmp_dma_config *cfg) {
> > > > +	struct zynqmp_dma_chan *chan = to_chan(dchan);
> > > > +
> > > > +	chan->config.ovrfetch = cfg->ovrfetch;
> > > > +	chan->config.has_sg = cfg->has_sg;
> > >
> > > is this HW capability? if so why would anyone not like to use it!
> >
> > Yes it is HW capability. It can be either in simple mode or SG mode
> > Earlier In the driver this configuration is read from the device-tree
> > But as per lars and your suggestion moved it as runtime config parameters.
> 
> If sg mode is available why would anyone _not_ want it?
> 
> I do not think there is point to have this

You mean always keep the device in SG mode and provide an option 
For simple dma mode if user want to use simple DMA mode??

There are few features that are available in the simple DMA mode won't
Available in SG mode like write only DMA , read only DMA mode etc...

> 
> >
> > >
> > > > +	chan->config.ratectrl = cfg->ratectrl;
> > > > +	chan->config.src_issue = cfg->src_issue;
> > > > +	chan->config.src_burst_len = cfg->src_burst_len;
> > > > +	chan->config.dst_burst_len = cfg->dst_burst_len;
> > >
> > > can you describe these parameters?
> > ratectl:
> > Rate control can be independently enabled per channel. When rate
> > control is enabled, the DMA channel uses the rate control count to schedule
> successive data read transactions.
> 
> And how is this used by client?

When rate control is enabled, ZDMA channel uses the rate control count
To schedule successive data read transactions I mean kind of flow control to schedule 
Transactions at fixed intervals instead of pumping the transfers without delay or whenever bus is available

Rate control count register definition (11:0):
Scheduling interval for SRC AXI transaction, only used if rate control is enabled 


> 
> > src_issue:
> > Tells outstanding transaction on SRC.
> 
> This should be read only then, right?

It is a Read/Write register
http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html 
By default it is configured for Max transactions.
If user want to limit it they can limit it using this config option.

> 
> > Burst_len:
> > Configures the burst length of the src and dst transfers...
> 
> Hmmm, but you are on memcpy, so that should be programmed for throughput?

Yes...

> 
> > >
> > > How would a client know how to configure them?
> >
> > With the default values of the config parameters driver will work.
> 
> But how will client know what is default!

Default values means IP default state after reset.
If user not aware of the above parameters also still the driver will work for basic functionality.
Do you want me to implement one more API get_config so that 
Whenever user will call the get_config he will know the default values
Of the config parameters?

> 
> > If user has specific requirement to change these parameters they can
> > pass It to the driver using set_config API and all these parameters
> > are Documented in the include/linux/dma/xilinx_dma.h file...
> 
> Can you give me an example where user would like to do that


I am using customized dma test client.
There I am calling this set_config API before triggering memcpy/SG operations.

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

[toc] | [prev] | [next] | [standalone]

#1423226

On Tue, Jun 14, 2016 at 08:18:09AM +0000, Appana Durga Kedareswara Rao wrote:
> > > Yes it is HW capability. It can be either in simple mode or SG mode
> > > Earlier In the driver this configuration is read from the device-tree
> > > But as per lars and your suggestion moved it as runtime config parameters.
> > 
> > If sg mode is available why would anyone _not_ want it?
> > 
> > I do not think there is point to have this
> 
> You mean always keep the device in SG mode and provide an option 
> For simple dma mode if user want to use simple DMA mode??

Yes, why would anyone want to use single if sg is available?

> 
> There are few features that are available in the simple DMA mode won't
> Available in SG mode like write only DMA , read only DMA mode etc...

Can you explain what these are, how they are used by clients?

> > > > > +	chan->config.ratectrl = cfg->ratectrl;
> > > > > +	chan->config.src_issue = cfg->src_issue;
> > > > > +	chan->config.src_burst_len = cfg->src_burst_len;
> > > > > +	chan->config.dst_burst_len = cfg->dst_burst_len;
> > > >
> > > > can you describe these parameters?
> > > ratectl:
> > > Rate control can be independently enabled per channel. When rate
> > > control is enabled, the DMA channel uses the rate control count to schedule
> > successive data read transactions.
> > 
> > And how is this used by client?
> 
> When rate control is enabled, ZDMA channel uses the rate control count
> To schedule successive data read transactions I mean kind of flow control to schedule 
> Transactions at fixed intervals instead of pumping the transfers without delay or whenever bus is available
> 
> Rate control count register definition (11:0):
> Scheduling interval for SRC AXI transaction, only used if rate control is enabled 

Okay, why would anyone want transactions at fixed interval. We are talking
about DMA, so please give me transfers without delay or whenever bus is
available!


> > > src_issue:
> > > Tells outstanding transaction on SRC.
> > 
> > This should be read only then, right?
> 
> It is a Read/Write register
> http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html 
> By default it is configured for Max transactions.
> If user want to limit it they can limit it using this config option.

And why would they want that?

> > > Burst_len:
> > > Configures the burst length of the src and dst transfers...
> > 
> > Hmmm, but you are on memcpy, so that should be programmed for throughput?
> 
> Yes...

So max burst lengths then, why would anyone configure lesser?

> > > > How would a client know how to configure them?
> > >
> > > With the default values of the config parameters driver will work.
> > 
> > But how will client know what is default!
> 
> Default values means IP default state after reset.
> If user not aware of the above parameters also still the driver will work for basic functionality.
> Do you want me to implement one more API get_config so that 
> Whenever user will call the get_config he will know the default values
> Of the config parameters?

Looking at above I think we do not warrant programming them. Assume defaults
in your driver for performance. Like max burst lengths, Max transactions,
without delay scheduling.

If you disagree, which is fine, please provide the cases where a client
would need to program these to different values.

> > > If user has specific requirement to change these parameters they can
> > > pass It to the driver using set_config API and all these parameters
> > > are Documented in the include/linux/dma/xilinx_dma.h file...
> > 
> > Can you give me an example where user would like to do that
> 
> I am using customized dma test client.
> There I am calling this set_config API before triggering memcpy/SG operations.

Well that is precisely a  problem. The generic applications wont know "your"
custom API and will not configure that!

-- 
~Vinod

[toc] | [prev] | [next] | [standalone]

#1423733

Hi Vinod,

	Thanks for the review...

> 
> On Tue, Jun 14, 2016 at 08:18:09AM +0000, Appana Durga Kedareswara Rao
> wrote:
> > > > Yes it is HW capability. It can be either in simple mode or SG
> > > > mode Earlier In the driver this configuration is read from the
> > > > device-tree But as per lars and your suggestion moved it as runtime config
> parameters.
> > >
> > > If sg mode is available why would anyone _not_ want it?
> > >
> > > I do not think there is point to have this
> >
> > You mean always keep the device in SG mode and provide an option For
> > simple dma mode if user want to use simple DMA mode??
> 
> Yes, why would anyone want to use single if sg is available?
> 
> >
> > There are few features that are available in the simple DMA mode won't
> > Available in SG mode like write only DMA , read only DMA mode etc...
> 
> Can you explain what these are, how they are used by clients?

Currently it is not implemented but there are cases like,

We want to initialize the some region with known value, then write only dma helps
We want to read dummy data from the fifo, then read only dma helps.
Best case is SPI fifo.

> 
> > > > > > +	chan->config.ratectrl = cfg->ratectrl;
> > > > > > +	chan->config.src_issue = cfg->src_issue;
> > > > > > +	chan->config.src_burst_len = cfg->src_burst_len;
> > > > > > +	chan->config.dst_burst_len = cfg->dst_burst_len;
> > > > >
> > > > > can you describe these parameters?
> > > > ratectl:
> > > > Rate control can be independently enabled per channel. When rate
> > > > control is enabled, the DMA channel uses the rate control count to
> > > > schedule
> > > successive data read transactions.
> > >
> > > And how is this used by client?
> >
> > When rate control is enabled, ZDMA channel uses the rate control count
> > To schedule successive data read transactions I mean kind of flow
> > control to schedule Transactions at fixed intervals instead of pumping
> > the transfers without delay or whenever bus is available
> >
> > Rate control count register definition (11:0):
> > Scheduling interval for SRC AXI transaction, only used if rate control
> > is enabled
> 
> Okay, why would anyone want transactions at fixed interval. We are talking
> about DMA, so please give me transfers without delay or whenever bus is
> available!

Could be that there are certain IPs that requires delay in b/w transactions.
Since IP is providing this feature we are exploring it to the user.

> 
> 
> > > > src_issue:
> > > > Tells outstanding transaction on SRC.
> > >
> > > This should be read only then, right?
> >
> > It is a Read/Write register
> > http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascal
> > e-registers.html By default it is configured for Max transactions.
> > If user want to limit it they can limit it using this config option.
> 
> And why would they want that?

Could be that there are certain IPs that my not support burst operations or
May not support all burst lengths it will be helpful.
Since IP is providing the feature, we are exploring it to the user.

> 
> > > > Burst_len:
> > > > Configures the burst length of the src and dst transfers...
> > >
> > > Hmmm, but you are on memcpy, so that should be programmed for
> throughput?
> >
> > Yes...
> 
> So max burst lengths then, why would anyone configure lesser?

Depends on the destination and source IPs.

> 
> > > > > How would a client know how to configure them?
> > > >
> > > > With the default values of the config parameters driver will work.
> > >
> > > But how will client know what is default!
> >
> > Default values means IP default state after reset.
> > If user not aware of the above parameters also still the driver will work for
> basic functionality.
> > Do you want me to implement one more API get_config so that Whenever
> > user will call the get_config he will know the default values Of the
> > config parameters?
> 
> Looking at above I think we do not warrant programming them. Assume defaults
> in your driver for performance. Like max burst lengths, Max transactions,
> without delay scheduling.
> 
> If you disagree, which is fine, please provide the cases where a client would
> need to program these to different values.

As said above there are use cases for SPI and others but currently we didn't tested
It.

> 
> > > > If user has specific requirement to change these parameters they
> > > > can pass It to the driver using set_config API and all these
> > > > parameters are Documented in the include/linux/dma/xilinx_dma.h file...
> > >
> > > Can you give me an example where user would like to do that
> >
> > I am using customized dma test client.
> > There I am calling this set_config API before triggering memcpy/SG
> operations.
> 
> Well that is precisely a  problem. The generic applications wont know "your"
> custom API and will not configure that!

As said above, generic application can work with default values. 
These are not custom parameters and we can say these are the dma parameters.
i.e we can generalize these and provide it to user as generic API.


Regards,
Kedar.

> 
> --
> ~Vinod

[toc] | [prev] | [next] | [standalone]

#1427883

On Thu, Jun 16, 2016 at 07:19:38AM +0000, Appana Durga Kedareswara Rao wrote:
> Hi Vinod,
> 
> 	Thanks for the review...
> 
> > 
> > On Tue, Jun 14, 2016 at 08:18:09AM +0000, Appana Durga Kedareswara Rao
> > wrote:
> > > > > Yes it is HW capability. It can be either in simple mode or SG
> > > > > mode Earlier In the driver this configuration is read from the
> > > > > device-tree But as per lars and your suggestion moved it as runtime config
> > parameters.
> > > >
> > > > If sg mode is available why would anyone _not_ want it?
> > > >
> > > > I do not think there is point to have this
> > >
> > > You mean always keep the device in SG mode and provide an option For
> > > simple dma mode if user want to use simple DMA mode??
> > 
> > Yes, why would anyone want to use single if sg is available?

If you have sg mode always enabled, but sg_list is size 1, that its
essentially a single

Btw SPI is a slave case, not a memcpy!

> > > There are few features that are available in the simple DMA mode won't
> > > Available in SG mode like write only DMA , read only DMA mode etc...
> > 
> > Can you explain what these are, how they are used by clients?
> 
> Currently it is not implemented but there are cases like,
> 
> We want to initialize the some region with known value, then write only dma helps
> We want to read dummy data from the fifo, then read only dma helps.

Read will be another transfer, perhpas sg lnegth = 1

> Best case is SPI fifo.

Nope

> 
> > 
> > > > > > > +	chan->config.ratectrl = cfg->ratectrl;
> > > > > > > +	chan->config.src_issue = cfg->src_issue;
> > > > > > > +	chan->config.src_burst_len = cfg->src_burst_len;
> > > > > > > +	chan->config.dst_burst_len = cfg->dst_burst_len;
> > > > > >
> > > > > > can you describe these parameters?
> > > > > ratectl:
> > > > > Rate control can be independently enabled per channel. When rate
> > > > > control is enabled, the DMA channel uses the rate control count to
> > > > > schedule
> > > > successive data read transactions.
> > > >
> > > > And how is this used by client?
> > >
> > > When rate control is enabled, ZDMA channel uses the rate control count
> > > To schedule successive data read transactions I mean kind of flow
> > > control to schedule Transactions at fixed intervals instead of pumping
> > > the transfers without delay or whenever bus is available
> > >
> > > Rate control count register definition (11:0):
> > > Scheduling interval for SRC AXI transaction, only used if rate control
> > > is enabled
> > 
> > Okay, why would anyone want transactions at fixed interval. We are talking
> > about DMA, so please give me transfers without delay or whenever bus is
> > available!
> 
> Could be that there are certain IPs that requires delay in b/w transactions.
> Since IP is providing this feature we are exploring it to the user.

I kind of don't agree to that!

> 
> > 
> > 
> > > > > src_issue:
> > > > > Tells outstanding transaction on SRC.
> > > >
> > > > This should be read only then, right?
> > >
> > > It is a Read/Write register
> > > http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascal
> > > e-registers.html By default it is configured for Max transactions.
> > > If user want to limit it they can limit it using this config option.
> > 
> > And why would they want that?
> 
> Could be that there are certain IPs that my not support burst operations or
> May not support all burst lengths it will be helpful.
> Since IP is providing the feature, we are exploring it to the user.
> 
> > 
> > > > > Burst_len:
> > > > > Configures the burst length of the src and dst transfers...
> > > >
> > > > Hmmm, but you are on memcpy, so that should be programmed for
> > throughput?
> > >
> > > Yes...
> > 
> > So max burst lengths then, why would anyone configure lesser?
> 
> Depends on the destination and source IPs.

Not for memory copy


> 
> > 
> > > > > > How would a client know how to configure them?
> > > > >
> > > > > With the default values of the config parameters driver will work.
> > > >
> > > > But how will client know what is default!
> > >
> > > Default values means IP default state after reset.
> > > If user not aware of the above parameters also still the driver will work for
> > basic functionality.
> > > Do you want me to implement one more API get_config so that Whenever
> > > user will call the get_config he will know the default values Of the
> > > config parameters?
> > 
> > Looking at above I think we do not warrant programming them. Assume defaults
> > in your driver for performance. Like max burst lengths, Max transactions,
> > without delay scheduling.
> > 
> > If you disagree, which is fine, please provide the cases where a client would
> > need to program these to different values.
> 
> As said above there are use cases for SPI and others but currently we didn't tested
> It.
> 
> > 
> > > > > If user has specific requirement to change these parameters they
> > > > > can pass It to the driver using set_config API and all these
> > > > > parameters are Documented in the include/linux/dma/xilinx_dma.h file...
> > > >
> > > > Can you give me an example where user would like to do that
> > >
> > > I am using customized dma test client.
> > > There I am calling this set_config API before triggering memcpy/SG
> > operations.
> > 
> > Well that is precisely a  problem. The generic applications wont know "your"
> > custom API and will not configure that!
> 
> As said above, generic application can work with default values. 
> These are not custom parameters and we can say these are the dma parameters.
> i.e we can generalize these and provide it to user as generic API.

No it doesn't make it generic API. With generic API the IP should be usable
with any generic interface without specfic hoops to go thru. People are
going to test upstream dmatest on your IP and find it not working or
degraded perf, so better stick with generic API.

-- 
~Vinod

[toc] | [prev] | [next] | [standalone]

#1427987

On Tue, Jun 21, 2016 at 04:19:38PM +0000, Punnaiah Choudary Kalluri wrote:
> > > > > > > mode Earlier In the driver this configuration is read from the
> > > > > > > device-tree But as per lars and your suggestion moved it as runtime
> > config
> > > > parameters.
> > > > > >
> > > > > > If sg mode is available why would anyone _not_ want it?
> > > > > >
> > > > > > I do not think there is point to have this
> > > > >
> > > > > You mean always keep the device in SG mode and provide an option
> > For
> > > > > simple dma mode if user want to use simple DMA mode??
> > > >
> > > > Yes, why would anyone want to use single if sg is available?
> >
> > If you have sg mode always enabled, but sg_list is size 1, that its
> > essentially a single
> >
> 
> True. As we said, simple mode ha few additional features like write only
> And read only dma. So, if user want then here is the provision.
> 
> > Btw SPI is a slave case, not a memcpy!
> >
> 
> Correct. We are working on slave dma support and will patch to this driver.

And in slave cases, you can use slave config to pass the values which are
required, so we dont need this custome interface!

> 
> > > > > There are few features that are available in the simple DMA mode
> > won't
> > > > > Available in SG mode like write only DMA , read only DMA mode etc...
> > > >
> > > > Can you explain what these are, how they are used by clients?
> > >
> > > Currently it is not implemented but there are cases like,
> > >
> > > We want to initialize the some region with known value, then write only
> > dma helps
> > > We want to read dummy data from the fifo, then read only dma helps.
> >
> > Read will be another transfer, perhpas sg lnegth = 1
> >
> 
> 
> In sg case, both source and destination locations need to be configured.
> In simple dma and read-only mode, only source address is required. Simple
> Dma just read the data from source location and discard that data. It will save
> Unnecessary write to destination here.
> 
> > > Best case is SPI fifo.
> >
> > Nope
> >
> 
> Why?

beacuse you are messing with APIs. SPI will be slave where we know how to
program the values!

> 
> 
> > >
> > > >
> > > > > > > > > +       chan->config.ratectrl = cfg->ratectrl;
> > > > > > > > > +       chan->config.src_issue = cfg->src_issue;
> > > > > > > > > +       chan->config.src_burst_len = cfg->src_burst_len;
> > > > > > > > > +       chan->config.dst_burst_len = cfg->dst_burst_len;
> > > > > > > >
> > > > > > > > can you describe these parameters?
> > > > > > > ratectl:
> > > > > > > Rate control can be independently enabled per channel. When rate
> > > > > > > control is enabled, the DMA channel uses the rate control count to
> > > > > > > schedule
> > > > > > successive data read transactions.
> > > > > >
> > > > > > And how is this used by client?
> > > > >
> > > > > When rate control is enabled, ZDMA channel uses the rate control
> > count
> > > > > To schedule successive data read transactions I mean kind of flow
> > > > > control to schedule Transactions at fixed intervals instead of pumping
> > > > > the transfers without delay or whenever bus is available
> > > > >
> > > > > Rate control count register definition (11:0):
> > > > > Scheduling interval for SRC AXI transaction, only used if rate control
> > > > > is enabled
> > > >
> > > > Okay, why would anyone want transactions at fixed interval. We are
> > talking
> > > > about DMA, so please give me transfers without delay or whenever bus
> > is
> > > > available!
> > >
> > > Could be that there are certain IPs that requires delay in b/w transactions.
> > > Since IP is providing this feature we are exploring it to the user.
> >
> > I kind of don't agree to that!
> >
> 
> It's a kind of rate control mechanism. We can aslo use this feature to prioritize other
> Channel by deliberately controlling the current channel transfer scheduling.
> 
> > >
> > > >
> > > >
> > > > > > > src_issue:
> > > > > > > Tells outstanding transaction on SRC.
> > > > > >
> > > > > > This should be read only then, right?
> > > > >
> > > > > It is a Read/Write register
> > > > > http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-
> > ultrascal
> > > > > e-registers.html By default it is configured for Max transactions.
> > > > > If user want to limit it they can limit it using this config option.
> > > >
> > > > And why would they want that?
> > >
> > > Could be that there are certain IPs that my not support burst operations or
> > > May not support all burst lengths it will be helpful.
> > > Since IP is providing the feature, we are exploring it to the user.
> > >
> > > >
> > > > > > > Burst_len:
> > > > > > > Configures the burst length of the src and dst transfers...
> > > > > >
> > > > > > Hmmm, but you are on memcpy, so that should be programmed for
> > > > throughput?
> > > > >
> > > > > Yes...
> > > >
> > > > So max burst lengths then, why would anyone configure lesser?
> > >
> > > Depends on the destination and source IPs.
> >
> > Not for memory copy
> >
> 
> Depends on the system and how source and destination IPs are interconnected.
> Sometimes there is a limitation from interconnection also.
> Also some flash controllers providing linear access to NAND or NOR memories may
> Have limitation in burst length but still user can use memory copy with desired burst
> Length.

Some of those cases are treated as slave for obvious reasons.

Please check existing solutions before inventing new ones. Everyone thinks
that their hardware and thereby driver is a novel case, but on closer
inspection that is usually not the case, different falvour yes, novel no!

Okay I am convince now this is not right approach. Please remove this
custom interface and then implement slave for required slave scenarios!

> 
> >
> > >
> > > >
> > > > > > > > How would a client know how to configure them?
> > > > > > >
> > > > > > > With the default values of the config parameters driver will work.
> > > > > >
> > > > > > But how will client know what is default!
> > > > >
> > > > > Default values means IP default state after reset.
> > > > > If user not aware of the above parameters also still the driver will work
> > for
> > > > basic functionality.
> > > > > Do you want me to implement one more API get_config so that
> > Whenever
> > > > > user will call the get_config he will know the default values Of the
> > > > > config parameters?
> > > >
> > > > Looking at above I think we do not warrant programming them. Assume
> > defaults
> > > > in your driver for performance. Like max burst lengths, Max transactions,
> > > > without delay scheduling.
> > > >
> > > > If you disagree, which is fine, please provide the cases where a client
> > would
> > > > need to program these to different values.
> > >
> > > As said above there are use cases for SPI and others but currently we didn't
> > tested
> > > It.
> > >
> > > >
> > > > > > > If user has specific requirement to change these parameters they
> > > > > > > can pass It to the driver using set_config API and all these
> > > > > > > parameters are Documented in the include/linux/dma/xilinx_dma.h
> > file...
> > > > > >
> > > > > > Can you give me an example where user would like to do that
> > > > >
> > > > > I am using customized dma test client.
> > > > > There I am calling this set_config API before triggering memcpy/SG
> > > > operations.
> > > >
> > > > Well that is precisely a  problem. The generic applications wont know
> > "your"
> > > > custom API and will not configure that!
> > >
> > > As said above, generic application can work with default values.
> > > These are not custom parameters and we can say these are the dma
> > parameters.
> > > i.e we can generalize these and provide it to user as generic API.
> >
> > No it doesn't make it generic API. With generic API the IP should be usable
> > with any generic interface without specfic hoops to go thru. People are
> > going to test upstream dmatest on your IP and find it not working or
> > degraded perf, so better stick with generic API.
> >
> 
> By default driver configures the optimized settings and it works with upstream
> Dmatest. Even with customized settings it works with dmatest only thing it might
> Gain/loss performance but that's up to the configuration user may want.
> 
> This dma controller was designed to provide more flexibility to the user by providing
> the all possible dma parameters configurable.
> 
> Regards,
> Punnaiah
> > --
> > ~Vinod
> 
> 
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Really!


-- 
~Vinod

[toc] | [prev] | [next] | [standalone]

#1428017

> On Tue, Jun 21, 2016 at 04:19:38PM +0000, Punnaiah Choudary Kalluri wrote:
> > > > > > > > mode Earlier In the driver this configuration is read from the
> > > > > > > > device-tree But as per lars and your suggestion moved it as
> runtime
> > > config
> > > > > parameters.
> > > > > > >
> > > > > > > If sg mode is available why would anyone _not_ want it?
> > > > > > >
> > > > > > > I do not think there is point to have this
> > > > > >
> > > > > > You mean always keep the device in SG mode and provide an
> option
> > > For
> > > > > > simple dma mode if user want to use simple DMA mode??
> > > > >
> > > > > Yes, why would anyone want to use single if sg is available?
> > >
> > > If you have sg mode always enabled, but sg_list is size 1, that its
> > > essentially a single
> > >
> >
> > True. As we said, simple mode ha few additional features like write only
> > And read only dma. So, if user want then here is the provision.
> >
> > > Btw SPI is a slave case, not a memcpy!
> > >
> >
> > Correct. We are working on slave dma support and will patch to this driver.
> 
> And in slave cases, you can use slave config to pass the values which are
> required, so we dont need this custome interface!
> 

Ok agree with you for the scenario that I have mentioned above.

Other simple dma mode feature that I missed to explain is configuring the 
Dma descriptors. It provides a register interface for configuring the dma transaction.
So, no need to maintain the descriptors in memory and it will be useful for the system 
that are in crunch of memory.  

How do you want us to handle this case?

> > > >
> > > > >
> > > > >
> > > > > > > > src_issue:
> > > > > > > > Tells outstanding transaction on SRC.
> > > > > > >
> > > > > > > This should be read only then, right?
> > > > > >
> > > > > > It is a Read/Write register
> > > > > > http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-
> > > ultrascal
> > > > > > e-registers.html By default it is configured for Max transactions.
> > > > > > If user want to limit it they can limit it using this config option.
> > > > >
> > > > > And why would they want that?
> > > >
> > > > Could be that there are certain IPs that my not support burst operations
> or
> > > > May not support all burst lengths it will be helpful.
> > > > Since IP is providing the feature, we are exploring it to the user.
> > > >
> > > > >
> > > > > > > > Burst_len:
> > > > > > > > Configures the burst length of the src and dst transfers...
> > > > > > >
> > > > > > > Hmmm, but you are on memcpy, so that should be programmed
> for
> > > > > throughput?
> > > > > >
> > > > > > Yes...
> > > > >
> > > > > So max burst lengths then, why would anyone configure lesser?
> > > >
> > > > Depends on the destination and source IPs.
> > >
> > > Not for memory copy
> > >
> >
> > Depends on the system and how source and destination IPs are
> interconnected.
> > Sometimes there is a limitation from interconnection also.
> > Also some flash controllers providing linear access to NAND or NOR
> memories may
> > Have limitation in burst length but still user can use memory copy with
> desired burst
> > Length.
> 
> Some of those cases are treated as slave for obvious reasons.
> 
> Please check existing solutions before inventing new ones. Everyone thinks
> that their hardware and thereby driver is a novel case, but on closer
> inspection that is usually not the case, different falvour yes, novel no!
> 
> Okay I am convince now this is not right approach. Please remove this
> custom interface and then implement slave for required slave scenarios!
>

Assume controller is having 8 channels and four of them are used for slave
Dma and others are for memcpy.
Controller didn't have the per channel priority control but providing the rate control
Mechanism. 

So, I need some interface for configuring the rate control per channel at run time irrespective
Of whether the channel is allocated for slave dma or memcpy dma.

Is it wrong having the configurable dma parameters for dma memcpy operation? We are exposing the
Hw capabilities to the user for better dma transaction management.

> >
> >
> > This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any
> attachments. Delete this email message and any attachments immediately.
> 
> Really!
> 

My apologies :)

Thanks,
Punnaiah
> 
> --
> ~Vinod

[toc] | [prev] | [next] | [standalone]

#1428023

Hi Vinod,

> -----Original Message-----
> From: Vinod Koul [mailto:vinod.koul@intel.com]
> Sent: Tuesday, June 21, 2016 9:11 PM
> To: Appana Durga Kedareswara Rao <appanad@xilinx.com>
> Cc: robh+dt@kernel.org; pawel.moll@arm.com; mark.rutland@arm.com;
> ijc+devicetree@hellion.org.uk; galak@codeaurora.org; Michal Simek
> <michals@xilinx.com>; Soren Brinkmann <sorenb@xilinx.com>;
> dan.j.williams@intel.com; moritz.fischer@ettus.com;
> laurent.pinchart@ideasonboard.com; luis@debethencourt.com; Srikanth
> Vemula <svemula@xilinx.com>; Anirudha Sarangi <anirudh@xilinx.com>;
> Punnaiah Choudary Kalluri <punnaia@xilinx.com>;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; dmaengine@vger.kernel.org
> Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine
> driver support
>
> On Thu, Jun 16, 2016 at 07:19:38AM +0000, Appana Durga Kedareswara Rao
> wrote:
> > Hi Vinod,
> >
> >     Thanks for the review...
> >
> > >
> > > On Tue, Jun 14, 2016 at 08:18:09AM +0000, Appana Durga Kedareswara
> Rao
> > > wrote:
> > > > > > Yes it is HW capability. It can be either in simple mode or SG
> > > > > > mode Earlier In the driver this configuration is read from the
> > > > > > device-tree But as per lars and your suggestion moved it as runtime
> config
> > > parameters.
> > > > >
> > > > > If sg mode is available why would anyone _not_ want it?
> > > > >
> > > > > I do not think there is point to have this
> > > >
> > > > You mean always keep the device in SG mode and provide an option
> For
> > > > simple dma mode if user want to use simple DMA mode??
> > >
> > > Yes, why would anyone want to use single if sg is available?
>
> If you have sg mode always enabled, but sg_list is size 1, that its
> essentially a single
>

True. As we said, simple mode ha few additional features like write only
And read only dma. So, if user want then here is the provision.

> Btw SPI is a slave case, not a memcpy!
>

Correct. We are working on slave dma support and will patch to this driver.

> > > > There are few features that are available in the simple DMA mode
> won't
> > > > Available in SG mode like write only DMA , read only DMA mode etc...
> > >
> > > Can you explain what these are, how they are used by clients?
> >
> > Currently it is not implemented but there are cases like,
> >
> > We want to initialize the some region with known value, then write only
> dma helps
> > We want to read dummy data from the fifo, then read only dma helps.
>
> Read will be another transfer, perhpas sg lnegth = 1
>


In sg case, both source and destination locations need to be configured.
In simple dma and read-only mode, only source address is required. Simple
Dma just read the data from source location and discard that data. It will save
Unnecessary write to destination here.

> > Best case is SPI fifo.
>
> Nope
>

Why?


> >
> > >
> > > > > > > > +       chan->config.ratectrl = cfg->ratectrl;
> > > > > > > > +       chan->config.src_issue = cfg->src_issue;
> > > > > > > > +       chan->config.src_burst_len = cfg->src_burst_len;
> > > > > > > > +       chan->config.dst_burst_len = cfg->dst_burst_len;
> > > > > > >
> > > > > > > can you describe these parameters?
> > > > > > ratectl:
> > > > > > Rate control can be independently enabled per channel. When rate
> > > > > > control is enabled, the DMA channel uses the rate control count to
> > > > > > schedule
> > > > > successive data read transactions.
> > > > >
> > > > > And how is this used by client?
> > > >
> > > > When rate control is enabled, ZDMA channel uses the rate control
> count
> > > > To schedule successive data read transactions I mean kind of flow
> > > > control to schedule Transactions at fixed intervals instead of pumping
> > > > the transfers without delay or whenever bus is available
> > > >
> > > > Rate control count register definition (11:0):
> > > > Scheduling interval for SRC AXI transaction, only used if rate control
> > > > is enabled
> > >
> > > Okay, why would anyone want transactions at fixed interval. We are
> talking
> > > about DMA, so please give me transfers without delay or whenever bus
> is
> > > available!
> >
> > Could be that there are certain IPs that requires delay in b/w transactions.
> > Since IP is providing this feature we are exploring it to the user.
>
> I kind of don't agree to that!
>

It's a kind of rate control mechanism. We can aslo use this feature to prioritize other
Channel by deliberately controlling the current channel transfer scheduling.

> >
> > >
> > >
> > > > > > src_issue:
> > > > > > Tells outstanding transaction on SRC.
> > > > >
> > > > > This should be read only then, right?
> > > >
> > > > It is a Read/Write register
> > > > http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-
> ultrascal
> > > > e-registers.html By default it is configured for Max transactions.
> > > > If user want to limit it they can limit it using this config option.
> > >
> > > And why would they want that?
> >
> > Could be that there are certain IPs that my not support burst operations or
> > May not support all burst lengths it will be helpful.
> > Since IP is providing the feature, we are exploring it to the user.
> >
> > >
> > > > > > Burst_len:
> > > > > > Configures the burst length of the src and dst transfers...
> > > > >
> > > > > Hmmm, but you are on memcpy, so that should be programmed for
> > > throughput?
> > > >
> > > > Yes...
> > >
> > > So max burst lengths then, why would anyone configure lesser?
> >
> > Depends on the destination and source IPs.
>
> Not for memory copy
>

Depends on the system and how source and destination IPs are interconnected.
Sometimes there is a limitation from interconnection also.
Also some flash controllers providing linear access to NAND or NOR memories may
Have limitation in burst length but still user can use memory copy with desired burst
Length.

>
> >
> > >
> > > > > > > How would a client know how to configure them?
> > > > > >
> > > > > > With the default values of the config parameters driver will work.
> > > > >
> > > > > But how will client know what is default!
> > > >
> > > > Default values means IP default state after reset.
> > > > If user not aware of the above parameters also still the driver will work
> for
> > > basic functionality.
> > > > Do you want me to implement one more API get_config so that
> Whenever
> > > > user will call the get_config he will know the default values Of the
> > > > config parameters?
> > >
> > > Looking at above I think we do not warrant programming them. Assume
> defaults
> > > in your driver for performance. Like max burst lengths, Max transactions,
> > > without delay scheduling.
> > >
> > > If you disagree, which is fine, please provide the cases where a client
> would
> > > need to program these to different values.
> >
> > As said above there are use cases for SPI and others but currently we didn't
> tested
> > It.
> >
> > >
> > > > > > If user has specific requirement to change these parameters they
> > > > > > can pass It to the driver using set_config API and all these
> > > > > > parameters are Documented in the include/linux/dma/xilinx_dma.h
> file...
> > > > >
> > > > > Can you give me an example where user would like to do that
> > > >
> > > > I am using customized dma test client.
> > > > There I am calling this set_config API before triggering memcpy/SG
> > > operations.
> > >
> > > Well that is precisely a  problem. The generic applications wont know
> "your"
> > > custom API and will not configure that!
> >
> > As said above, generic application can work with default values.
> > These are not custom parameters and we can say these are the dma
> parameters.
> > i.e we can generalize these and provide it to user as generic API.
>
> No it doesn't make it generic API. With generic API the IP should be usable
> with any generic interface without specfic hoops to go thru. People are
> going to test upstream dmatest on your IP and find it not working or
> degraded perf, so better stick with generic API.
>

By default driver configures the optimized settings and it works with upstream
Dmatest. Even with customized settings it works with dmatest only thing it might
Gain/loss performance but that's up to the configuration user may want.

This dma controller was designed to provide more flexibility to the user by providing
the all possible dma parameters configurable.

Regards,
Punnaiah
> --
> ~Vinod


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web