diff for duplicates of <1493052970.24567.168.camel@linux.intel.com> diff --git a/a/1.txt b/N1/1.txt index 7808a39..6c0c079 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,11 +1,11 @@ -On Mon, 2017-04-24@15:55 +0000, Eugeniy Paltsev wrote: +On Mon, 2017-04-24 at 15:55 +0000, Eugeniy Paltsev wrote: > Hi, -> On Fri, 2017-04-21@18:13 +0300, Andy Shevchenko wrote: -> > On Fri, 2017-04-21@14:29 +0000, Eugeniy Paltsev wrote: -> > > On Tue, 2017-04-18@15:31 +0300, Andy Shevchenko wrote: -> > > > On Fri, 2017-04-07@17:04 +0300, Eugeniy Paltsev wrote: +> On Fri, 2017-04-21 at 18:13 +0300, Andy Shevchenko wrote: +> > On Fri, 2017-04-21 at 14:29 +0000, Eugeniy Paltsev wrote: +> > > On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote: +> > > > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote: > > > > > This patch adds support for the DW AXI DMAC controller. -> > > > > +#define AXI_DMA_BUSWIDTHS ??\ +> > > > > +#define AXI_DMA_BUSWIDTHS \ > > > > > + (DMA_SLAVE_BUSWIDTH_1_BYTE | \ > > > > > + DMA_SLAVE_BUSWIDTH_2_BYTES | \ > > > > > + DMA_SLAVE_BUSWIDTH_4_BYTES | \ @@ -27,7 +27,7 @@ On Mon, 2017-04-24@15:55 +0000, Eugeniy Paltsev wrote: > > Strange. AFAIK they are representing bits (which is not the best > > idea) in the resulting u64 field. So, anything bigger than 63 > > doesn't -> > ?make sense. +> > make sense. > > They are u32 fields! @@ -36,8 +36,8 @@ Even "better"! > From dmaengine.h : > struct dma_device { > ... -> ????u32 src_addr_widths; -> ????u32 dst_addr_widths; +> u32 src_addr_widths; +> u32 dst_addr_widths; > }; > > > In drivers where they are not bits quite likely a bug is hidden. @@ -201,12 +201,12 @@ no user or solve non-existing problem. See below. > I checked hsu/hsu.c dma driver implementation: -> ? vdma descriptor is deleted from desc_issued list when transfer -> ? starts. When descriptor marked as error descriptor -> ? vchan_cookie_complete isn't called for this descriptor. And this -> ? descriptor isn't placed in any list. So error descriptors *never* -> ? will be freed. -> ? I don't actually like this approach. +> vdma descriptor is deleted from desc_issued list when transfer +> starts. When descriptor marked as error descriptor +> vchan_cookie_complete isn't called for this descriptor. And this +> descriptor isn't placed in any list. So error descriptors *never* +> will be freed. +> I don't actually like this approach. Descriptor is active until terminate_all() is called or new descriptor is supplied. So, the caller has a quite time to check on it. @@ -317,5 +317,5 @@ some that are using former, and number of plain driver.c variant is bigger. -- -Andy Shevchenko <andriy.shevchenko at linux.intel.com> +Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy diff --git a/a/content_digest b/N1/content_digest index 524f37d..3926998 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,20 +4,28 @@ "ref\01492784977.16657.6.camel@synopsys.com\0" "ref\01492787583.24567.120.camel@linux.intel.com\0" "ref\01493049305.25985.4.camel@synopsys.com\0" - "From\0andriy.shevchenko@linux.intel.com (Andy Shevchenko)\0" - "Subject\0[PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver\0" + "From\0Andy Shevchenko <andriy.shevchenko@linux.intel.com>\0" + "Subject\0Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver\0" "Date\0Mon, 24 Apr 2017 19:56:10 +0300\0" - "To\0linux-snps-arc@lists.infradead.org\0" + "To\0Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>\0" + "Cc\0vinod.koul@intel.com <vinod.koul@intel.com>" + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + robh+dt@kernel.org <robh+dt@kernel.org> + Alexey.Brodkin@synopsys.com <Alexey.Brodkin@synopsys.com> + devicetree@vger.kernel.org <devicetree@vger.kernel.org> + linux-snps-arc@lists.infradead.org <linux-snps-arc@lists.infradead.org> + dan.j.williams@intel.com <dan.j.williams@intel.com> + " dmaengine@vger.kernel.org <dmaengine@vger.kernel.org>\0" "\00:1\0" "b\0" - "On Mon, 2017-04-24@15:55 +0000, Eugeniy Paltsev wrote:\n" + "On Mon, 2017-04-24 at 15:55 +0000, Eugeniy Paltsev wrote:\n" "> Hi,\n" - "> On Fri, 2017-04-21@18:13 +0300, Andy Shevchenko wrote:\n" - "> > On Fri, 2017-04-21@14:29 +0000, Eugeniy Paltsev wrote:\n" - "> > > On Tue, 2017-04-18@15:31 +0300, Andy Shevchenko wrote:\n" - "> > > > On Fri, 2017-04-07@17:04 +0300, Eugeniy Paltsev wrote:\n" + "> On Fri, 2017-04-21 at 18:13 +0300, Andy Shevchenko wrote:\n" + "> > On Fri, 2017-04-21 at 14:29 +0000, Eugeniy Paltsev wrote:\n" + "> > > On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote:\n" + "> > > > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote:\n" "> > > > > This patch adds support for the DW AXI DMAC controller.\n" - "> > > > > +#define AXI_DMA_BUSWIDTHS\t\t??\\\n" + "> > > > > +#define AXI_DMA_BUSWIDTHS\t\t\302\240\302\240\\\n" "> > > > > +\t(DMA_SLAVE_BUSWIDTH_1_BYTE\t| \\\n" "> > > > > +\tDMA_SLAVE_BUSWIDTH_2_BYTES\t| \\\n" "> > > > > +\tDMA_SLAVE_BUSWIDTH_4_BYTES\t| \\\n" @@ -39,7 +47,7 @@ "> > Strange. AFAIK they are representing bits (which is not the best\n" "> > idea) in the resulting u64 field. So, anything bigger than 63\n" "> > doesn't\n" - "> > ?make sense.\n" + "> > \302\240make sense.\n" "> \n" "> They are u32 fields!\n" "\n" @@ -48,8 +56,8 @@ "> From dmaengine.h :\n" "> struct dma_device {\n" "> ...\n" - "> ????u32 src_addr_widths;\n" - "> ????u32 dst_addr_widths;\n" + "> \302\240\302\240\302\240\302\240u32 src_addr_widths;\n" + "> \302\240\302\240\302\240\302\240u32 dst_addr_widths;\n" "> };\n" "> \n" "> > In drivers where they are not bits quite likely a bug is hidden.\n" @@ -213,12 +221,12 @@ "See below.\n" "\n" "> I checked hsu/hsu.c dma driver implementation:\n" - "> ? vdma descriptor is deleted from desc_issued list when transfer\n" - "> ? starts. When descriptor marked as error descriptor\n" - "> ? vchan_cookie_complete isn't called for this descriptor. And this\n" - "> ? descriptor isn't placed in any list. So error descriptors *never*\n" - "> ? will be freed.\n" - "> ? I don't actually like this approach.\n" + "> \302\240 vdma descriptor is deleted from desc_issued list when transfer\n" + "> \302\240 starts. When descriptor marked as error descriptor\n" + "> \302\240 vchan_cookie_complete isn't called for this descriptor. And this\n" + "> \302\240 descriptor isn't placed in any list. So error descriptors *never*\n" + "> \302\240 will be freed.\n" + "> \302\240 I don't actually like this approach.\n" "\n" "Descriptor is active until terminate_all() is called or new descriptor\n" "is supplied. So, the caller has a quite time to check on it.\n" @@ -329,7 +337,7 @@ "bigger.\n" "\n" "-- \n" - "Andy Shevchenko <andriy.shevchenko at linux.intel.com>\n" + "Andy Shevchenko <andriy.shevchenko@linux.intel.com>\n" Intel Finland Oy -7fa92f8adf45dbfafe63aea05ec2e622fb4f1ec439ebfeb5a701b266a4230a45 +2082463df79eb0159ebd79967b9cac5222e65f01e2dc66e452679fae05f228e6
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.