From: Vinod Koul <vkoul@kernel.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
<dmaengine@vger.kernel.org>, DTML <devicetree@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Jassi Brar <jaswinder.singh@linaro.org>,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: [v2,2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver
Date: Wed, 12 Sep 2018 10:05:30 +0530 [thread overview]
Message-ID: <20180912043530.GE2766@vkoul-mobl> (raw)
On 12-09-18, 12:01, Masahiro Yamada wrote:
> Hi Vinod,
>
>
> 2018-09-11 16:00 GMT+09:00 Vinod <vkoul@kernel.org>:
> > On 24-08-18, 10:41, Masahiro Yamada wrote:
> >
> >> +/* mc->vc.lock must be held by caller */
> >> +static u32 __uniphier_mdmac_get_residue(struct uniphier_mdmac_desc *md)
> >> +{
> >> + u32 residue = 0;
> >> + int i;
> >> +
> >> + for (i = md->sg_cur; i < md->sg_len; i++)
> >> + residue += sg_dma_len(&md->sgl[i]);
> >
> > so if the descriptor is submitted to hardware, we return the descriptor
> > length, which is not correct.
> >
> > Two cases are required to be handled:
> > 1. Descriptor is in queue (IMO above logic is fine for that, but it can
> > be calculated at descriptor submit and looked up here)
>
> Where do you want it to be calculated?
where is it calculated now?
> This hardware provides only simple registers (address and size)
> for one-shot transfer instead of descriptors.
>
> So, I used sgl as-is because I did not see a good reason
> to transform sgl to another data structure.
> > this seems missing stuff. Where do you do register calculation for the
> > descriptor and where is slave_config here, how do you know where to
> > send/receive data form/to (peripheral)
>
>
> This dmac is really simple, and un-flexible.
>
> The peripheral address to send/receive data from/to is hard-weird.
> cfg->{src_addr,dst_addr} is not configurable.
>
> Look at __uniphier_mdmac_handle().
> 'dest_addr' and 'src_addr' must be set to 0 for the peripheral.
Fair enough, what about other values like addr_width and maxburst?
WARNING: multiple messages have this Message-ID (diff)
From: Vinod <vkoul@kernel.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
<dmaengine@vger.kernel.org>, DTML <devicetree@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Jassi Brar <jaswinder.singh@linaro.org>,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver
Date: Wed, 12 Sep 2018 10:05:30 +0530 [thread overview]
Message-ID: <20180912043530.GE2766@vkoul-mobl> (raw)
In-Reply-To: <CAK7LNASMhKfQT-Hqv48=HqOPRx3OVMtdNBEe=c7dE-B_5_Nuyw@mail.gmail.com>
On 12-09-18, 12:01, Masahiro Yamada wrote:
> Hi Vinod,
>
>
> 2018-09-11 16:00 GMT+09:00 Vinod <vkoul@kernel.org>:
> > On 24-08-18, 10:41, Masahiro Yamada wrote:
> >
> >> +/* mc->vc.lock must be held by caller */
> >> +static u32 __uniphier_mdmac_get_residue(struct uniphier_mdmac_desc *md)
> >> +{
> >> + u32 residue = 0;
> >> + int i;
> >> +
> >> + for (i = md->sg_cur; i < md->sg_len; i++)
> >> + residue += sg_dma_len(&md->sgl[i]);
> >
> > so if the descriptor is submitted to hardware, we return the descriptor
> > length, which is not correct.
> >
> > Two cases are required to be handled:
> > 1. Descriptor is in queue (IMO above logic is fine for that, but it can
> > be calculated at descriptor submit and looked up here)
>
> Where do you want it to be calculated?
where is it calculated now?
> This hardware provides only simple registers (address and size)
> for one-shot transfer instead of descriptors.
>
> So, I used sgl as-is because I did not see a good reason
> to transform sgl to another data structure.
> > this seems missing stuff. Where do you do register calculation for the
> > descriptor and where is slave_config here, how do you know where to
> > send/receive data form/to (peripheral)
>
>
> This dmac is really simple, and un-flexible.
>
> The peripheral address to send/receive data from/to is hard-weird.
> cfg->{src_addr,dst_addr} is not configurable.
>
> Look at __uniphier_mdmac_handle().
> 'dest_addr' and 'src_addr' must be set to 0 for the peripheral.
Fair enough, what about other values like addr_width and maxburst?
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: Vinod <vkoul@kernel.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM"
<dmaengine@vger.kernel.org>, DTML <devicetree@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Jassi Brar <jaswinder.singh@linaro.org>,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver
Date: Wed, 12 Sep 2018 10:05:30 +0530 [thread overview]
Message-ID: <20180912043530.GE2766@vkoul-mobl> (raw)
In-Reply-To: <CAK7LNASMhKfQT-Hqv48=HqOPRx3OVMtdNBEe=c7dE-B_5_Nuyw@mail.gmail.com>
On 12-09-18, 12:01, Masahiro Yamada wrote:
> Hi Vinod,
>
>
> 2018-09-11 16:00 GMT+09:00 Vinod <vkoul@kernel.org>:
> > On 24-08-18, 10:41, Masahiro Yamada wrote:
> >
> >> +/* mc->vc.lock must be held by caller */
> >> +static u32 __uniphier_mdmac_get_residue(struct uniphier_mdmac_desc *md)
> >> +{
> >> + u32 residue = 0;
> >> + int i;
> >> +
> >> + for (i = md->sg_cur; i < md->sg_len; i++)
> >> + residue += sg_dma_len(&md->sgl[i]);
> >
> > so if the descriptor is submitted to hardware, we return the descriptor
> > length, which is not correct.
> >
> > Two cases are required to be handled:
> > 1. Descriptor is in queue (IMO above logic is fine for that, but it can
> > be calculated at descriptor submit and looked up here)
>
> Where do you want it to be calculated?
where is it calculated now?
> This hardware provides only simple registers (address and size)
> for one-shot transfer instead of descriptors.
>
> So, I used sgl as-is because I did not see a good reason
> to transform sgl to another data structure.
> > this seems missing stuff. Where do you do register calculation for the
> > descriptor and where is slave_config here, how do you know where to
> > send/receive data form/to (peripheral)
>
>
> This dmac is really simple, and un-flexible.
>
> The peripheral address to send/receive data from/to is hard-weird.
> cfg->{src_addr,dst_addr} is not configurable.
>
> Look at __uniphier_mdmac_handle().
> 'dest_addr' and 'src_addr' must be set to 0 for the peripheral.
Fair enough, what about other values like addr_width and maxburst?
--
~Vinod
WARNING: multiple messages have this Message-ID (diff)
From: vkoul@kernel.org (Vinod)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver
Date: Wed, 12 Sep 2018 10:05:30 +0530 [thread overview]
Message-ID: <20180912043530.GE2766@vkoul-mobl> (raw)
In-Reply-To: <CAK7LNASMhKfQT-Hqv48=HqOPRx3OVMtdNBEe=c7dE-B_5_Nuyw@mail.gmail.com>
On 12-09-18, 12:01, Masahiro Yamada wrote:
> Hi Vinod,
>
>
> 2018-09-11 16:00 GMT+09:00 Vinod <vkoul@kernel.org>:
> > On 24-08-18, 10:41, Masahiro Yamada wrote:
> >
> >> +/* mc->vc.lock must be held by caller */
> >> +static u32 __uniphier_mdmac_get_residue(struct uniphier_mdmac_desc *md)
> >> +{
> >> + u32 residue = 0;
> >> + int i;
> >> +
> >> + for (i = md->sg_cur; i < md->sg_len; i++)
> >> + residue += sg_dma_len(&md->sgl[i]);
> >
> > so if the descriptor is submitted to hardware, we return the descriptor
> > length, which is not correct.
> >
> > Two cases are required to be handled:
> > 1. Descriptor is in queue (IMO above logic is fine for that, but it can
> > be calculated at descriptor submit and looked up here)
>
> Where do you want it to be calculated?
where is it calculated now?
> This hardware provides only simple registers (address and size)
> for one-shot transfer instead of descriptors.
>
> So, I used sgl as-is because I did not see a good reason
> to transform sgl to another data structure.
> > this seems missing stuff. Where do you do register calculation for the
> > descriptor and where is slave_config here, how do you know where to
> > send/receive data form/to (peripheral)
>
>
> This dmac is really simple, and un-flexible.
>
> The peripheral address to send/receive data from/to is hard-weird.
> cfg->{src_addr,dst_addr} is not configurable.
>
> Look at __uniphier_mdmac_handle().
> 'dest_addr' and 'src_addr' must be set to 0 for the peripheral.
Fair enough, what about other values like addr_width and maxburst?
--
~Vinod
next reply other threads:[~2018-09-12 4:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-12 4:35 Vinod Koul [this message]
2018-09-12 4:35 ` [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver Vinod
2018-09-12 4:35 ` Vinod
2018-09-12 4:35 ` Vinod
-- strict thread matches above, loose matches on Subject: below --
2018-09-12 7:31 [v2,2/2] " Masahiro Yamada
2018-09-12 7:31 ` [PATCH v2 2/2] " Masahiro Yamada
2018-09-12 7:31 ` Masahiro Yamada
2018-09-12 7:31 ` Masahiro Yamada
2018-09-12 7:26 [v2,2/2] " Vinod Koul
2018-09-12 7:26 ` [PATCH v2 2/2] " Vinod
2018-09-12 7:26 ` Vinod
2018-09-12 7:26 ` Vinod
2018-09-12 5:25 [v2,2/2] " Masahiro Yamada
2018-09-12 5:25 ` [PATCH v2 2/2] " Masahiro Yamada
2018-09-12 5:25 ` Masahiro Yamada
2018-09-12 5:25 ` Masahiro Yamada
2018-09-12 3:01 [v2,2/2] " Masahiro Yamada
2018-09-12 3:01 ` [PATCH v2 2/2] " Masahiro Yamada
2018-09-12 3:01 ` Masahiro Yamada
2018-09-12 3:01 ` Masahiro Yamada
2018-09-11 7:00 [v2,2/2] " Vinod Koul
2018-09-11 7:00 ` [PATCH v2 2/2] " Vinod
2018-09-11 7:00 ` Vinod
2018-08-29 0:36 [v2,1/2] dt-bindings: dmaengine: add DT binding for UniPhier MIO DMAC Rob Herring
2018-08-29 0:36 ` [PATCH v2 1/2] " Rob Herring
2018-08-29 0:36 ` Rob Herring
2018-08-24 1:41 [v2,2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver Masahiro Yamada
2018-08-24 1:41 ` [PATCH v2 2/2] " Masahiro Yamada
2018-08-24 1:41 ` Masahiro Yamada
2018-08-24 1:41 [v2,1/2] dt-bindings: dmaengine: add DT binding for UniPhier MIO DMAC Masahiro Yamada
2018-08-24 1:41 ` [PATCH v2 1/2] " Masahiro Yamada
2018-08-24 1:41 ` Masahiro Yamada
2018-08-24 1:41 [PATCH v2 0/2] dmaengine: add UniPhier MIO DMAC driver Masahiro Yamada
2018-08-24 1:41 ` Masahiro Yamada
2018-08-24 1:41 ` Masahiro Yamada
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=20180912043530.GE2766@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=jaswinder.singh@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=robh+dt@kernel.org \
--cc=yamada.masahiro@socionext.com \
/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.