On Tue, Jan 10, 2023 at 01:46:37PM +0100, Andrzej Hajda wrote:
> On 10.01.2023 12:07, Andy Shevchenko wrote:
> > On Tue, Jan 10, 2023 at 11:53:06AM +0100, Andrzej Hajda wrote:
...
> > > + return __xchg(_chain->p_prod_elem,
> > > + (void
return __xchg(_chain->p_prod_elem,
> + (void *)(((u8 *)p_chain->p_prod_elem) +
> p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
> }
...
Btw, is it done by coccinelle? If no, why not pr
IW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Andrzej Hajda
> ---
> include/linux/non-atomic/xchg.h | 19 +++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/linux/non-atomic/xchg.h
>
> diff --git a/include/linux/non-atomic/xchg.h b/include/l
a device described, then there is or will be a
> driver for it. The result is you can't use new DTs (if they add
> providers) with older kernels.
>
> We've ended up with a timeout because no one has come up with a better
> way t
for all serial drivers that at DT based. This way,
> fw_devlink will know not to delay the probing of the consoles past
> kernel boot.
Same question, do you think only serial drivers need that?
--
With Best Regards,
Andy Shevchenko
gt; probe times back to how they were before the deferred_probe_timeout
> clean up series[2].
Are you sure it's only limited to the serial drivers?
(just asking, I don't know myself the answer)
--
With Best Regards,
Andy Shevchenko
___
linux-snp
erpc/kernel/setup-common.c | 3 ++
> arch/riscv/kernel/setup.c | 2 +
> arch/sh/kernel/setup.c | 3 ++
> arch/xtensa/kernel/setup.c | 2 +
Isn't x86 missed? Is it on purpose?
Would be nice to have this in the commit message or f
ned-off-by: Andrey Abramov
> Reviewed by: George Spelvin
FWIW,
Reviewed-by: Andy Shevchenko
> ---
> arch/x86/kernel/unwind_orc.c | 2 +-
> include/linux/sort.h | 2 +-
> kernel/jump_label.c | 2 +-
> lib/extable.c| 2 +-
> lib/sort.c
On Mon, Apr 01, 2019 at 09:56:07AM +, George Spelvin wrote:
> On Mon, 1 Apr 2019 at 12:35:55 +0300, Andy Shevchenko wrote:
> > Hmm... If (*swap)() is called recursively it means the change might increase
> > stack usage on 64-bit platforms.
> >
> > Am I missing
ifs: find.c: replace swap function with built-in one
> Lib: sort.h: replace int size with size_t size in the swap function
You have to do something about Cc list.
50 people is complete overkill. Seems as your series is a set of
independent fixes. Why not to split a
tty/serial/qcom_geni_serial.c | 10 --
> include/linux/kgdb.h| 9 ++---
> include/linux/serial_core.h | 38 -
> kernel/debug/debug_core.c | 2 +-
> kernel/smp.c| 4
ce *dev, size_t size,
> void *kvaddr;
> int need_coh = 1, need_kvaddr = 0;
>
> - page = alloc_pages(gfp, order);
> + page = alloc_pages(gfp | __GFP_ZERO, order);
>
> if (!page)
> return NULL;
> ->8---
usage
> of DIV_ROUND_UP when we may only compile stuff on a very few arches.
>
> Lets cast this multiply to u64 type which prevents overflow.
>
FWIW,
Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com>
> Tested-by: Vineet Gupta <vineet.gup...@synopsys.com>
> Reporte
On Tue, Feb 27, 2018 at 5:52 AM, Jisheng Zhang
<jisheng.zh...@synaptics.com> wrote:
> On Mon, 26 Feb 2018 20:27:22 + Alexey Brodkin wrote:
>> On Mon, 2018-02-26 at 20:30 +0200, Andy Shevchenko wrote:
>> > On Mon, Feb 26, 2018 at 7:14 PM, Evgeniy Didin
>> > &
On Mon, Feb 26, 2018 at 7:14 PM, Evgeniy Didin
<evgeniy.di...@synopsys.com> wrote:
> On Mon, 2018-02-26 at 18:53 +0200, Andy Shevchenko wrote:
>> On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
>> <evgeniy.di...@synopsys.com> wrote:
>> > On Mon, 2018-02-26 a
On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
<evgeniy.di...@synopsys.com> wrote:
> On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
>> On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
>> <evgeniy.di...@synopsys.com> wrote:
>> > In commit 4c2357f57dd
clk_prepare_enable(chip->core_clk);
Each of them may fail. Is it okay?
> +static const struct dev_pm_ops dw_axi_dma_pm_ops = {
> + SET_RUNTIME_PM_OPS(axi_dma_runtime_suspend, axi_dma_runtime_resume,
> NULL)
> +};
No system suspend?
> +/*
> + * Synopsys DesignWare AXI DMA Controller driver.
> + *
> + * Copyright (C) 2017-2018 Synopsys, Inc. (www.synopsys.com)
> + * Author: Eugeniy Paltsev <eugeniy.palt...@synopsys.com>
> + *
> + * SPDX-License-Identifier:GPL-2.0
First line, but C style of the comment.
> + */
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
> host->bus_hz);
IIRC, someone commented on this or similar, i.e.
DIV_ROUND_UP_ULL() ?
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
t; + drto_ms = DIV_ROUND_UP((uint64_t)MSEC_PER_SEC * drto_clks * drto_div,
> host->bus_hz);
Does the driver use uint64_t elsewhere?
Or simple u64?
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
+ do {
> + if (axi_chan_irq_read(chan) & DWAXIDMAC_IRQ_SUSPENDED) {
> + ret = 0;
> + break;
> + }
> + udelay(2);
> + } while (timeout--);
Off-by-one. You will have 21 tries here.
ionale behind why one needs such a combination of parameters?
P.S. For doulble output ask Sergey and Petr (they are quite concerned
about it). Actually strange I didn't see their names in Cc list for
console related stuff,
--
With Best Regards,
Andy Shevchenko
___
On Thu, 2017-04-27 at 13:21 +, Eugeniy Paltsev wrote:
> On Wed, 2017-04-26 at 18:04 +0300, Andy Shevchenko wrote:
> > On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote:
> > > On Tue, 2017-04-25 at 15:16 +, Eugeniy Paltsev wrote:
> > > > On Mon, 2
On Tue, 2017-04-25 at 21:12 +0300, Andy Shevchenko wrote:
> On Tue, 2017-04-25 at 15:16 +, Eugeniy Paltsev wrote:
> > On Mon, 2017-04-24 at 19:56 +0300, Andy Shevchenko wrote:
> > > On Mon, 2017-04-24 at 15:55 +, Eugeniy Paltsev wrote:
> > > Descriptor is
On Fri, 2017-04-21 at 14:29 +, 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.
> > >
> > > +#incl
MAC_IRQ_LLI_WR_SLV_ERR: LLI write slave error
> + * @DWAXIDMAC_IRQ_INVALID_ERR: LLI invalide error or Shadow register
> error
> + * @DWAXIDMAC_IRQ_MULTIBLKTYPE_ERR: Slave Interface Multiblock type
> error
> + * @DWAXIDMAC_IRQ_DEC_ERR: Slave Interface decode error
> + * @DWAXIDMAC_IRQ_WR2RO_ERR: Slave
expect more then 100+ LOC reduction when
> > switched to virt-dma API. Can you double check that you are using it
> > effectively?
>
> There is a simple explanation: I switched to virt-dma API (and it
> cause
> LOC reduction) and I implemented some TODOs (and it cause LOC
> increase).
Ah, that explains, indeed.
> Also about previous comment, which I missed before:
> > > +static u32 axi_chan_get_xfer_width(struct axi_dma_chan *chan,
> > > dma_addr_t src, dma_addr_t dst, size_t len)
> > > +{
> > > + u32 width;
> > > + dma_addr_t sdl = (src | dst | len);
> > > + u32 max_width = chan->chip->dw->hdata->m_data_width;
> >
> >
> > Use reverse tree.
> >
> > dma_addr_t use above is wrong. (size_t might be bigger in some
> > cases)
>
> What do you mean by the phrase "Use reverse tree" ?
Just convenient pattern: longest first.
On top of that logical groups of definitions:
a) assignments based on parameters;
b) other variables;
c) return variable last;
d) flags for spin lock -> depends.
Thus:
u32 max_width = chan->chip->dw->hdata->m_data_width;
dma_addr_t sdl = (src | dst | len);
u32 width;
But pay attention to your sdl, which is always nonzero.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
paused).
The trick allows to make code cleaner.
> + ret = device_property_read_u32_array(dev, "priority", carr,
I'm not sure you will have a use case for that. Have you?
> + ret = devm_request_irq(chip->dev, chip->irq,
> dw_axi_dma_intretupt,
> +
ers/dma/axi_dma_platform_reg.h | 189
> 6 files changed, 1415 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/snps,axi-dw-
> dmac.txt
> create mode 100644 drivers/dma/axi_dma_platform.c
> create mode 100644 drivers/dma/axi_dma_platfor
On Fri, Jan 20, 2017 at 8:21 PM, Eugeniy Paltsev
<eugeniy.palt...@synopsys.com> wrote:
> Hi Andy,
> thanks for respond.
>
> I'm agree with most of the comments.
> My comments below.
So my answers!
> On Fri, 2017-01-20 at 15:38 +0200, Andy Shevchenko wrote:
>> On
On Fri, Jan 6, 2017 at 11:43 AM, Nicolas Dichtel
<nicolas.dich...@6wind.com> wrote:
> This header file is exported, thus move it to uapi.
Just hint for the future:
-M (move)
-C (copy)
-D (delete) [though this is NOT for applying]
--
With Best Regards,
Andy S
On Fri, 2016-11-25 at 11:40 +, Eugeniy Paltsev wrote:
> On Thu, 2016-11-24 at 17:58 +0200, Andy Shevchenko wrote:
> > On Thu, 2016-11-24 at 17:52 +0200, Andy Shevchenko wrote:
> > >
> > > On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote:
> > > &g
On Thu, 2016-11-24 at 17:52 +0200, Andy Shevchenko wrote:
> On Thu, 2016-11-24 at 18:04 +0300, Eugeniy Paltsev wrote:
> > Several versions of DW DMAC have multi block transfers hardware
> > support. Hardware support of multi block transfers is disabled
> > by default if we use
ave you tested this? How?
In case of positive property you have to update DTS. By the way, I'm
pretty sure that spare13xx boards has auto configuration enabled, though
it has to be checked with vendor (I assume you may have fast response
from them).
> }
> }
>
--
A
tion, support
> + * memory-to-memory transfers. So enable it by default.
> + */
> + pdata->is_memcpy = true;
> +
> if (!of_property_read_u32(np, "chan_allocation_order", ))
> pdata->chan_allocation_order = (unsigned char)tmp;
>
--
Andy Shevchenko <
dings/dma/snps-dma.txt | 2 ++
> drivers/dma/dw/core.c | 2 +-
> drivers/dma/dw/platform.c | 11 +++
> drivers/tty/serial/8250/8250_lpss.c| 2 +-
> include/linux/platform_data/dma-dw.h | 4 +
On Fri, 2016-11-18 at 19:53 +0300, Eugeniy Paltsev wrote:
> All known devices, which use DT for configuration, support
> memory-to-memory transfers. So enable it by default, if we read
> configuration from DT.
>
Acked-by: Andy Shevchenko <andriy.shevche...@linux.intel.com
0 /* zero to seven */
> #define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero
> */
> unsigned char chan_allocation_order;
> @@ -62,6 +61,7 @@ struct dw_dma_platform_data {
> unsigned intblock_size;
> unsigned char nr_masters;
> unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
> + unsigned char multi_block[DW_DMA_MAX_NR_MASTERS];
> };
>
> #endif /* _PLATFORM_DATA_DMA_DW_H */
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Wed, 2016-11-16 at 17:01 +, Eugeniy Paltsev wrote:
> On Wed, 2016-11-16 at 17:10 +0200, Andy Shevchenko wrote:
> > Overall, since we are going to expose some properties to the Device
> > Tree
> > I would really think twice about naming. Better if we reuse
> > som
ee/bindings/dma/snps-dma.txt | 10 --
> drivers/dma/dw/core.c | 2 +-
> drivers/dma/dw/platform.c | 10 ++
> include/linux/platform_data/dma-dw.h | 4 ++--
> 4 files changed, 21 insertions(+), 5 deletion
is_memcpy;
> - boolis_nollp;
> #define CHAN_ALLOCATION_ASCENDING0 /* zero to seven */
> #define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero
> */
> unsigned char chan_allocation_order;
> @@ -62,6 +61,7 @@ struct dw_dma_platform_data {
>
> if (!of_property_read_u32(np, "chan_allocation_order", ))
> pdata->chan_allocation_order = (unsigned char)tmp;
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu, Nov 10, 2016 at 6:28 PM, Eugeniy Paltsev
<eugeniy.palt...@synopsys.com> wrote:
> On Tue, 2016-11-08 at 15:36 +0200, Andy Shevchenko wrote:
>> On Tue, 2016-11-08 at 12:22 +, Eugeniy Paltsev wrote:
>> > On Mon, 2016-11-07 at 15:55 +0200, Andy Shevchenko wrote:
On Tue, 2016-11-08 at 12:22 +, Eugeniy Paltsev wrote:
> On Mon, 2016-11-07 at 15:55 +0200, Andy Shevchenko wrote:
> > > + * @only_quirks_used: Only read quirks (like "is_private" or
> > > "is_memcpy") from
> > > + * platform data
" to "dwc->flags"
>
> drivers/dma/dw/core.c| 34 +--
> drivers/dma/dw/platform.c| 53 +++--
> ---
> drivers/dma/dw/regs.h| 2 +-
> include/linux/platform_data/dma-dw.h | 5
> 4 files change
gt; * @chan_priority: Set channel priority increasing from 0 to 7 or 7
> to 0.
> @@ -52,6 +55,7 @@ struct dw_dma_platform_data {
> unsigned intnr_channels;
> boolis_private;
> boolis_memcpy;
> + boolonly_quirks_used;
Perhaps add if at the end of quirk list and name just
> boolis_nollp;
...here
bool use_quirks;
> #define CHAN_ALLOCATION_ASCENDING0 /* zero to seven */
> #define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero
> */
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu, 2016-10-20 at 13:16 +, Eugeniy Paltsev wrote:
> On Thu, 2016-10-20 at 13:48 +0300, Andy Shevchenko wrote:
> > On Thu, 2016-09-15 at 16:14 +0300, Eugeniy Paltsev wrote:
> > >
> > > This patch is to address a proposal by Andy in this thread:
> > > ht
7
> * @chan_priority: Set channel priority increasing from 0 to 7 or 7
> to 0.
> * @block_size: Maximum block size supported by the controller
> @@ -50,9 +47,18 @@ struct dw_dma_slave {
> */
> struct dw_dma_platform_data {
> unsigned intnr_channels;
> - bool
On Wed, 2016-10-05 at 15:14 +, Eugeniy Paltsev wrote:
> Hi Andy,
> what do you think about these changes?
I was off for few weeks, will look at this next week.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
__
able "is_memcpy" in this board .dts
> file.
> Am I wrong?
Some of the properties are set or unset due to support in the driver and
/ or issues of the hardware _related_ to the driver in question.
Though if anyone has different opinion I would appreciate to listen to.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Tue, 2016-08-16 at 11:32 +, Eugeniy Paltsev wrote:
> On Mon, 2016-08-15 at 15:41 +0300, Andy Shevchenko wrote:
> > On Mon, 2016-08-15 at 11:10 +, Eugeniy Paltsev wrote:
> > Consider to review
> > http://www.spinics.net/lists/dmaengine/msg10682.html
> Looks
On Mon, 2016-08-15 at 11:10 +, Eugeniy Paltsev wrote:
> On Fri, 2016-08-12 at 17:08 +0300, Andy Shevchenko wrote:
> >
> > > > > "nollp" parameter defines if DW DMAC channel supports multi
> > > > > block
> > > > > tr
On Fri, 2016-08-12 at 13:36 +, Eugeniy Paltsev wrote:
> On Fri, 2016-08-12 at 13:59 +0300, Andy Shevchenko wrote:
> >
> > On Fri, 2016-08-12 at 08:03 +, Eugeniy Paltsev wrote:
> > >
> > >
> > > Hi,
> > >
> > > "
is_private" or "is_memcpu"
> fields)
Yeah, perhaps we can remove that trick since we need this flag to be set
on Intel Quark which might have the same issue as your case [1].
[1] http://www.spinics.net/lists/linux-serial/msg22948.html
--
Andy Shevchenko <andriy.shevche...@linu
em worth doing to me.
The big issue with DT, you know, is hanging around names. This moves
name to be de facto standard for similar in the other drivers.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
___
linux-s
On Mon, 2016-01-25 at 07:32 +, Vineet Gupta wrote:
> On Monday 25 January 2016 12:55 AM, Mans Rullgard wrote:
> > From: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> >
> > There are several changes are done here:
> >
> > - Convert the proper
On Sun, 2016-01-24 at 19:21 +, Mans Rullgard wrote:
> From: Andy Shevchenko <andriy.shevche...@linux.intel.com>
>
> There are several changes are done here:
>
> - Convert the property to be in bytes
>
> Much more convenient than keeping encoded value.
>
On Mon, 2016-01-25 at 10:31 +, Måns Rullgård wrote:
> Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
>
> > On Mon, 2016-01-25 at 07:32 +, Vineet Gupta wrote:
> > > On Monday 25 January 2016 12:55 AM, Mans Rullgard wrote:
> > > > ---
57 matches
Mail list logo
