On 20-06-18, 10:53, Srinivas Kandagatla wrote:
> On 20/06/18 10:31, Vinod wrote:
> > > Here clock will be enabled twice but disable will be called only once when
> > > count = 0.
> > >
> > > This will make the clock always enabled. So, I think we should
On 29-05-18, 21:13, Robert Jarzmik wrote:
> Vinod writes:
>
> > On 26-05-18, 11:54, Robert Jarzmik wrote:
> >> @@ -762,6 +762,8 @@ static void pxad_free_chan_resources(struct dma_chan
> >> *dchan)
> >>dma_pool_destroy(chan->desc_pool);
> >
; This patch has dependency on https://lkml.org/lkml/2018/5/17/251
Looks good to me know, FWIW:
Reviewed-by: Vinod Koul
--
~Vinod
e fixed it by adding this and pushed out.
--
~Vinod
if (dma_caps.cmd_pause)
> + if (dma_caps.cmd_pause && dma_caps.cmd_resume)
> hw.info |= SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME;
> if (dma_caps.residue_granularity <=
> DMA_RESIDUE_GRANULARITY_SEGMENT)
> hw.info |= SNDRV_PCM_INFO_BATCH;
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
~Vinod
Hi Stephen,
On 05-07-18, 12:47, Stephen Rothwell wrote:
> On Wed, 4 Jul 2018 09:50:17 +0530 Vinod wrote:
> > On 04-07-18, 13:30, Stephen Rothwell wrote:
> > >
> > > After merging the slave-dma tree, today's linux-next build (x86_64
> > > allmodconfig) pr
t; [3.583423] device=eth0, hwaddr=00:14:2d:2c:a1:2e,
> ipaddr=192.168.10.17, mask=255.255.255.0, gw=192.168.10.1
> [3.593813] host=192.168.10.17, domain=, nis-domain=(none)
> [3.599833] bootserver=192.168.10.1, rootserver=192.168.10.1,
> rootpath=/srv/nfs/colibri_vf,v4,tcp
> [3.599854] nameserver0=192.168.10.1
> [3.676511] VFS: Mounted root (nfs4 filesystem) on device 0:13.
> [3.684257] devtmpfs: mounted
> [3.693865] Freeing unused kernel memory: 1024K
> [3.700956] random: fast init done
> [4.950401] systemd[1]: System time before build time, advancing clock.
> [5.136393] random: systemd: uninitialized urandom read (16 bytes read)
> [5.186057] systemd[1]: systemd 232 running in system mode. (-PAM -AUDIT
> -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS
> +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN)
> [5.206664] systemd[1]: Detected architecture arm.
>
--
~Vinod
On 04-07-18, 18:10, Randy Dunlap wrote:
> On 07/04/18 01:54, Krzysztof Kozlowski wrote:
>
> BTW, there is also this warning in linux-next:
> WARNING: modpost: missing MODULE_LICENSE() in drivers/dma/fsl-edma-common.o
That has been fixed.
--
~Vinod
gt; 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
~Vinod
("%s(): invalid bus width %u\n", __func__, width);
> + /* fall through */
Hmm this looks okay but am not able to trigger this warning..(used W=1) Did you
see this warning on your build, if so what options?
--
~Vinod
er
> 'period_len' not described in 'sdma_desc'
> drivers/dma/imx-sdma.c:326: warning: Function parameter or member
> 'chn_real_count' not described in 'sdma_desc'
> drivers/dma/imx-sdma.c:326: warning: Function parameter or member 'chn_count'
> not described in 'sdma_desc
Applied, thanks
--
~Vinod
On 04-07-18, 13:38, Andy Shevchenko wrote:
> On Wed, Jul 4, 2018 at 10:00 AM, Vinod wrote:
> > Hi Marek,
> >
> > On 02-07-18, 15:08, Marek Szyprowski wrote:
> >> 'cmd_pause' DMA channel capability means that respective DMA engine
> >> supports bot
On 05-07-18, 18:23, Angelo Dureghello wrote:
> Hi Stafan,
>
> On Thu, Jul 05, 2018 at 05:55:31PM +0200, Stefan Agner wrote:
> > Hi Vinod, Hi Angelo,
> >
> > On 05.07.2018 14:45, Angelo Dureghello wrote:
> > > Hi Vinod,
> > >
> > > On Th
On 06-07-18, 11:05, Guodong Xu wrote:
> On Thu, Jun 28, 2018 at 2:02 PM Vinod wrote:
> >
> > On 22-06-18, 11:24, Guodong Xu wrote:
> > > From: Li Yu
> > >
> > > On k3 series of SoC, DMA controller reserves some channels for
> > > other on-c
or alsa-devel and ack Intel patches as necessary.
Yeah somehow never added this, thanks for getting this done. This is the right
this going fwd.
Acked-By: Vinod Koul
--
~Vinod
signature.asc
Description: PGP signature
dst_step = SPRD_DMA_NONE_STEP;
> + } else {
> + src = slave_cfg->cfg.src_addr;
> + dst = sg_dma_address(sg);
> + src_step = SPRD_DMA_NONE_STEP;
> + dst_step =
> sprd_dma_get_step(slave_cfg->cfg.dst_addr_width);
> + }
> + }
> +
> + sprd_dma_fill_config(slave_cfg, src_step, dst_step, len, flags);
> +
> + ret = sprd_dma_config(chan, sdesc, src, dst, slave_cfg);
> + if (ret) {
> + kfree(sdesc);
> + return NULL;
> + }
Am more intrigued here, the above call fills you config struct but you do not
use it.. so what is the use of that.
--
~Vinod
}
}
thus making clear in code that we do calls only when it is enabled. Also you can
add a local macro for this code and use that rather than copy pasting :)
--
~Vinod
On 17-05-18, 14:02, Baolin Wang wrote:
> Hi Vinod,
>
> On 17 May 2018 at 13:14, Vinod wrote:
> > On 11-05-18, 21:06, Baolin Wang wrote:
> >> +struct sprd_dma_config {
> >> + struct dma_slave_config cfg;
> >> + u32 block_len;
> >>
; +static int bam_pm_runtime_get_sync(struct device *dev)
> +{
> + if (pm_runtime_enabled(dev))
> + return pm_runtime_get_sync(dev);
> +
> + return 0;
> +}
This makes it look lot neater :)
Applied, thanks
--
~Vinod
On 17-05-18, 11:53, Srinivas Kandagatla wrote:
>
>
> On 17/05/18 11:50, Vinod Koul wrote:
> > On 17-05-18, 10:59, Srinivas Kandagatla wrote:
> > > diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> > > index 4a828c18099a..a05fff8a1447 10
'chan'
> not described in 'bam_dma_terminate_all'
> bam_dma.c:697: warning: Excess function parameter 'bchan'
> description in 'bam_dma_terminate_all'
> bam_dma.c:964: warning: Function parameter or member 'bchan'
> not described in 'bam_start_dma'
>
> Fix these!.
Applied both, thanks
--
~Vinod
sferring the full number of bytes initially
> requested. So the proper resolution is the 8250 serial driver needs
> to remove rx dma support, because they are just trying to do something
> that is not supported.
>
> On Thu, May 17, 2018 at 12:19 AM, Vinod Koul wrote:
> >> &
On 18-05-18, 08:28, Marek Szyprowski wrote:
> Hi Vinod,
>
> Okay, I see that in theory, there are some tricky bits in implementing DMA
> support in UART drivers. On the other hand there are already drivers
> with seems
> to be working fine. This discussion is about rev
+
> + /* Turn on L1, L2, ETB and JU memories 1 at a time */
> + val = readl(qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
> + for (i = 19; i >= 0; i--) {
where is the magic number 19 coming from?
--
~Vinod
msecs_to_jiffies(5000));
> + if (ret == 0) {
> + dev_err(qproc->dev, "timed out on wait\n");
> + return -ETIMEDOUT;
> + }
> +
> + qcom_smem_state_update_bits(qproc->state, BIT(qproc->stop_bit), 0);
> +
> + ret = q6v5_wcss_powerdown(qproc);
> + if (ret)
> + return ret;
> +
> + /* Q6 Power down */
> + ret = q6v5_q6_powerdown(qproc);
> + if (ret)
> + return ret;
> +
> + return 0;
this could be optimized to:
return q6v5_q6_powerdown()
--
~Vinod
dmaengine: imx-sdma: add SDMA_BD_MAX_CNT to replace '0x'
dmaengine: imx-sdma: add memcpy interface
Sascha Hauer (1):
dmaengine: imx-sdma: factor out a struct sdma_desc from struct
sdma_channel
Vinod Koul (17):
dmaengine: imx-sdma: Fix some typos
dmaengine: imx-sdma:
gt; why do we need this as a property?
>
> In some UC, we need more than 4KiB in case of chaining for better
> performances.
> Chaining has to be enabled by client if performance is at sacks.
Okay if that is the case why is the user not taking care of this?
Creating DMA txn and chaining them up and starting the chain? Why would
dmaengine driver need to do that?
--
~Vinod
On 09-10-18, 10:40, Pierre Yves MORDRET wrote:
>
>
> On 10/07/2018 06:00 PM, Vinod wrote:
> > On 28-09-18, 15:01, Pierre-Yves MORDRET wrote:
> >> This patch adds support of DMA/MDMA chaining support.
> >> It introduces an intermediate transfer between per
On 16-10-18, 00:10, Amit Kucheria wrote:
> Add support for the Qualcomm QCS404 platform that contains v1 of the TSENS
> IP. Introduce a fallback binding to handle "v1" functionality.
Reviewed-by: Vinod Koul
Tested-by: Vinod Koul
--
~Vinod
handling
> dmaengine: stm32-dma: fix max items per transfer
> dmaengine: stm32-dma: properly mask irq bits
It would be good to only cherry pick fixes for this. I do not feel that
some of them which are adding or enhancing driver belong to stable.
Thanks
--
~Vinod
On 12-10-18, 01:27, Masahiro Yamada wrote:
> On Sun, Oct 7, 2018 at 1:23 AM Vinod wrote:
> > > > > +static int uniphier_mdmac_probe(struct platform_device *pdev)
> > > > > +{
> > > > > + struct device *dev = &pdev->
q' not
> described in 'owl_dma'
>
> Fix this by adding comments for relevant struct members to appear in
> kernel-doc.
>
> Fixes: d64e1b3f5cce ("dmaengine: owl: Add Slave and Cyclic mode support for
> Actions Semi Owl S900 SoC")
>
This empty l
On 10-10-18, 09:02, Pierre Yves MORDRET wrote:
>
>
> On 10/10/2018 06:03 AM, Vinod wrote:
> > On 09-10-18, 10:40, Pierre Yves MORDRET wrote:
> >>
> >>
> >> On 10/07/2018 06:00 PM, Vinod wrote:
> >>> On 28-09-18, 15:01, Pierre-Yves MOR
On 16-10-18, 11:19, Pierre Yves MORDRET wrote:
>
>
> On 10/15/18 7:14 PM, Vinod wrote:
> > On 10-10-18, 09:02, Pierre Yves MORDRET wrote:
> >>
> >>
> >> On 10/10/2018 06:03 AM, Vinod wrote:
> >>> On 09-10-18, 10:40, Pierre Yves MORDRET wro
*2. 2018/08/25 sudheer.veliseti modified
we dont use this log in kernel. I do not see s-o-b by Shivah, that
should be added. I think he should be author and you need to list
changes you did..
--
~Vinod
On 11-10-18, 00:19, Stephen Boyd wrote:
> Quoting Vinod (2018-10-07 20:51:44)
> > On 07-10-18, 19:38, Stephen Boyd wrote:
> > > Quoting Vinod (2018-10-02 23:21:03)
> > > > Hi Stephen,
> > > >
> > > > Thanks for the comments,
&
Hi Stephen,
On 04-10-18, 15:44, Stephen Rothwell wrote:
> Hi Vinod,
>
> After merging the slave-dma tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/dma/fsl-edma.c:67: warning: "EDMA_SEEI_SEEI" redefined
> #define ED
t; + struct snd_compr_runtime *runtime = substream->runtime;
> +
> + runtime->dma_buffer_p = bufp;
> +}
> +
> int snd_compr_stop_error(struct snd_compr_stream *stream,
>snd_pcm_state_t state);
>
> --
> 2.19.0
--
~Vinod
gt; @@ -39,11 +51,22 @@ enum stream_state {
>
> struct q6asm_dai_rtd {
> struct snd_pcm_substream *substream;
> + struct snd_compr_stream *cstream;
> + struct snd_compr_params codec_param;
> + struct snd_dma_buffer dma_buffer;
> +
> phys_addr_t phys;
> + spinlock_t lock;
why would we need a lock for compress case?
--
~Vinod
return PTR_ERR(mdev->clk);
> + }
> +
> + ret = clk_prepare_enable(mdev->clk);
> + if (ret)
> + return ret;
> +
> + ddev = &mdev->ddev;
> + ddev->dev = dev;
> + dma_cap_set(DMA_PRIVATE, ddev->cap_mask);
> + ddev->src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED);
> + ddev->dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED);
undefined?
> +static int uniphier_mdmac_remove(struct platform_device *pdev)
> +{
> + struct uniphier_mdmac_device *mdev = platform_get_drvdata(pdev);
> +
> + of_dma_controller_free(pdev->dev.of_node);
> + dma_async_device_unregister(&mdev->ddev);
> + clk_disable_unprepare(mdev->clk);
at this point your irq is registered and can be fired, the tasklets are
not killed :(
--
~Vinod
Applied after adding driver tag, thanks
--
~Vinod
On 06-10-18, 04:11, Masahiro Yamada wrote:
> On Fri, Oct 5, 2018 at 11:57 PM Vinod wrote:
> >
> > On 13-09-18, 09:51, Masahiro Yamada wrote:
> >
> > > +#define UNIPHIER_MDMAC_CH_IRQ_STAT 0x010 // current hw status (RO)
> > > +#define UNIPHIER_MDMAC_CH_
user space?
Wouldn't it be better to make it sysfs rather than debugfs knob?
--
~Vinod
> > +#define GCC_USB_30_BCR 7
> > > > +#define GCC_USB3PHY_PHY_BCR 8
> > > > +#define GCC_PCIE_0_BCR 9
> > > > +#define GCC_PCIE_0_PHY_BCR 10
> > > > +#define GCC_PCIE_0_LINK_DOWN_BCR 11
> > > > +#define GCC_PCIEPHY_0_PHY_BCR 12
> > > > +#define GCC_EMAC_BCR 13
> > >
> > > No GDSCs? Ok.
> >
> > Downstream doesn't seem to have one, will recheck specs.
> >
>
> Downstream uses different way to handle GDSC, there are 2 GDSCs which have
> to be added 1 for MDSS and 1 OXILI_GX.
Okay will check and add
--
~Vinod
107
> > +#define PCIE_0_AUX_CLK_SRC 108
> > +#define PCIE_0_PIPE_CLK_SRC109
> > +#define PCLK0_CLK_SRC 110
> > +#define PDM2_CLK_SRC 111
> > +#define SDCC1_APPS_CLK_SRC 112
> > +#define SDCC1_ICE_CORE_CLK_SRC 113
> > +#define SDCC2_APPS_CLK_SRC 114
> > +#define USB20_MOCK_UTMI_CLK_SRC115
> > +#define USB30_MASTER_CLK_SRC 116
> > +#define USB30_MOCK_UTMI_CLK_SRC117
> > +#define USB3_PHY_AUX_CLK_SRC 118
> > +#define USB_HS_SYSTEM_CLK_SRC 119
> > +#define GPLL0_AO_CLK_SRC 120
> > +#define WCNSS_M_CLK121
>
> Please remove WCNSS_M_CLK.
And the reason for that?
--
~Vinod
MDMA used to generate an intermediate M2M transfer.
> + -bit 3-4: indicated SRAM Buffer size in (2^order)*PAGE_SIZE.
> + PAGE_SIZE is given by Linux at 4KiB: include/asm-generic/page.h.
> + Order is given by those 2 bits starting at 0.
> + Valid only whether Intermediate M2M transfer is set.
why do we need this as a property?
> + For cyclic, whether Intermediate M2M transfer is chosen, any value can
> + be set: SRAM buffer size will rely on period size and not on this DT
> + value.
>
> Example:
>
> --
> 2.7.4
--
~Vinod
; +-Second is DMA channel configuration
> +-Third is a 32bit bitfield
please separate out formatting changes and actual change proposed..
> For more details about the three cells, please see
> stm32-dma.txt documentation binding file
> - dma-masters: Phandle pointing to the DMA controllers.
> --
> 2.7.4
--
~Vinod
is used by the MDMA client
> +6. A bitfield value specifying if the MDMA client wants to generate M2M
> + transfer with HW trigger (1) or not (0). This bitfield should be only
> + enabled for M2M transfer triggered by STM32 DMA client. The memory devices
> + involved in this kind of transfer are SRAM and DDR.
>
> Example:
>
> --
> 2.7.4
--
~Vinod
nate current MDMA to initiate a new one */
> + dmaengine_terminate_all(mchan->chan);
> +
> + /* Double buffer management */
> + src_buf = mchan->sram_buf +
> + ((mdma_wrote / mchan->sram_period) & 0x1) *
> + mchan->sram_period;
> + dst_buf = sg_dma_address(&sg_req->stm32_sgl_req) + mdma_wrote;
> +
> + desc = ddev->device_prep_dma_memcpy(mchan->chan,
> + dst_buf, src_buf,
> + dma_to_write,
> + DMA_PREP_INTERRUPT);
why would you do that?
If at all you need to create anothe txn, I think it would be good to
prepare a new descriptor and chain it, not call the dmaengine APIs..
--
~Vinod
On 07-10-18, 19:38, Stephen Boyd wrote:
> Quoting Vinod (2018-10-02 23:21:03)
> > Hi Stephen,
> >
> > Thanks for the comments,
> >
> > On 01-10-18, 10:19, Stephen Boyd wrote:
> > > Quoting Vinod Koul (2018-09-21 11:59:36)
> > > > From: Shef
On 19-09-18, 18:49, Bjorn Andersson wrote:
> From: Vinod Koul
>
> Update the binding and driver for pms405 pwrkey.
Rob, Dmitry
Gentle reminder for this patch...
> Signed-off-by: Vinod Koul
> Signed-off-by: Bjorn Andersson
> ---
> Documentation/devicetree/bindi
On 17-10-18, 19:56, Benjamin Herrenschmidt wrote:
> On Wed, 2018-10-17 at 11:35 +0530, Vinod wrote:
> > On 17-10-18, 09:41, sudheer.v wrote:
> >
> > Please add the change log describing the driver and its features
> >
> > > Signed-off-by: sudheer.v
>
On 18-10-18, 17:01, Dmitry Torokhov wrote:
> On Thu, Oct 18, 2018 at 10:54:37AM +0530, Vinod wrote:
> > On 19-09-18, 18:49, Bjorn Andersson wrote:
> > > From: Vinod Koul
> > >
> > > Update the binding and driver for pms405 pwrkey.
> >
> > Rob
On 19-10-18, 12:41, sudheer.v wrote:
> On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> > >
> > > > It's not a dmaengine driver. It's a serial UART driver that happe
On 18-10-18, 17:29, Baolin Wang wrote:
> Hi Vinod,
>
> On 29 September 2018 at 13:48, Baolin Wang wrote:
> > This patchset removes the direction usage from struct dma_slave_config,
> > and add one new field to save the direction. It also fixes some issues
> > for l
king sure it is less than the hw limit
> */
> - copy = xilinx_dma_calc_copysize(sg_dma_len(sg),
> + copy = xilinx_dma_calc_copysize(chan, sg_dma_len(sg),
why not keep chan in patch 1 and add only handling in patch 2, seems
less churn to me..
--
~Vinod
+968,7 @@ static int xilinx_dma_calc_copysize(struct
> xilinx_dma_chan *chan,
> int size, int done)
> {
> size_t copy = min_t(size_t, size - done,
> - XILINX_DMA_MAX_TRANS_LEN);
> + chan->xdev->max_buffer_len);
hmm why not add max_buffer_len in patch 1 again, and then use default
len as XILINX_DMA_MAX_TRANS_LEN and add multiple lengths here :)
-
~Vinod
orts and update the values accordingly. That way new
uses can be added w/o requiring change in dmaengine driver
--
~Vinod
lock that manages its synchronization.
> Setting the IOAT_CHAN_DOWN bit should prevent other CPUs from
> trying to use that device anyway, there is probably no need to call
> del_timer_sync() while holding the prep_lock. So the del_timer_sync()
> call is now moved outside of the prep_lock critical section to prevent
> the circular lock dependency.
Applied, thanks
--
~Vinod
Hi Mani,
On 18-09-18, 15:52, Manivannan Sadhasivam wrote:
> On Tue, Sep 18, 2018 at 09:35:12AM -0700, Vinod wrote:
> > On 01-09-18, 22:12, Manivannan Sadhasivam wrote:
> >
> > > @@ -364,6 +372,26 @@ static inline int owl_dma_cfg_lli(struct
&g
On 16-07-18, 15:33, Rob Herring wrote:
> On Mon, Jul 09, 2018 at 10:42:26PM +0530, Vinod wrote:
> > On 03-07-18, 14:32, Paul Cercueil wrote:
> >
> > > enum jz_version {
> > > + ID_JZ4740,
> > > ID_JZ4770,
> > > ID_JZ4780,
> > > }
On 17-07-18, 11:40, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 9:34 AM Vinod wrote:
> >
> > On 16-07-18, 15:33, Rob Herring wrote:
> > > On Mon, Jul 09, 2018 at 10:42:26PM +0530, Vinod wrote:
> > > > On 03-07-18, 14:32, Paul Cercueil wrote
On 22-05-18, 10:27, Frank Mori Hess wrote:
> On Mon, May 21, 2018 at 11:37 PM, Vinod Koul wrote:
> >
> > Well looks like even adding support for sync_pause doesn't solve your issue
> > on
> > pl330. Do you want to move this to PIO mode then..?
The issue for w
e + QDSP6SS_XO_CBCR);
As commented on previous patch, it would help IMO to add a modify() wrapper
here which would perform read, modify and write.
Looking at the patch, few other comments would be applicable too, so would be
great if you/Sricharan can update this
--
~Vinod
static int qcom_pcie_host_init(struct pcie_port *pp)
> phy_power_off(pcie->phy);
> err_deinit:
> pcie->ops->deinit(pcie);
> + pm_runtime_put_sync(pci->dev);
Wondering if there is a reason for sync put here?
--
~Vinod
On 22-05-18, 23:58, Bjorn Andersson wrote:
> On Tue 22 May 23:05 PDT 2018, Vinod wrote:
>
> > On 22-05-18, 22:20, Bjorn Andersson wrote:
> >
> > > +static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
> > > +{
> > > + int ret;
> > > + u32 val;
On 23-05-18, 11:10, Srinivas Kandagatla wrote:
>
>
> On 23/05/18 07:15, Vinod wrote:
> > On 18-05-18, 00:07, Bjorn Andersson wrote:
> >
> > > diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> > > index 5897af7d3355..3f35098b71b1
nnel *sdmac)
> +{
> + struct virt_dma_desc *vd = vchan_next_desc(&sdmac->vc);
> + struct sdma_desc *desc;
> + struct sdma_engine *sdma = sdmac->sdma;
> + int channel = sdmac->channel;
> +
> + if (!vd) {
> + sdmac->desc = NULL;
> + return;
> + }
> + sdmac->desc = desc = to_sdma_desc(&vd->tx);
> + /*
> + * Do not delete the node in desc_issued list in cyclic mode, otherwise
> + * the desc alloced will never be freed in vchan_dma_desc_free_list
alloced .. you mean allocated?
--
~Vinod
> it and it may not be possible due to reasons I haven't seen, but please
> at least give it a try.
That is something would help me as well. I have reviewed the patch and am not
sure I fully understand the changes, so breaking up stuff would definitely help
in the review..
--
~Vinod
te the usage counter so that the runtime pm does not suspend
> the clks or power domain associated with the bus driver.
FWIW:
Reviewed-by: Vinod Koul
--
~Vinod
on via:
> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace
>
> Miscellanea:
>
> o Wrapped one multi-line call to a single line
>
> Signed-off-by: Joe Perches
> ---
> sound/core/compress_offload.c | 2 +-
Acked-By: Vinod Koul
--
~Vinod
On 29-05-18, 07:17, Marek Szyprowski wrote:
> Hi Vinod,
>
> On 2018-05-18 09:21, Vinod wrote:
> > On 18-05-18, 08:28, Marek Szyprowski wrote:
> >> Hi Vinod,
> >>
> >> Okay, I see that in theory, there are some tricky bits in implementing DMA
> >&g
On 26-05-18, 11:54, Robert Jarzmik wrote:
> @@ -762,6 +762,8 @@ static void pxad_free_chan_resources(struct dma_chan
> *dchan)
> dma_pool_destroy(chan->desc_pool);
> chan->desc_pool = NULL;
>
> + chan->drcmr = (u32)-1;
why not use U32_MAX for this?
--
~Vinod
5_wcss_halt_axi_port(wcss, wcss->halt_map, wcss->halt_wcss);
> +
> + /* 2 - Enable WCSSAON_CONFIG */
> + val = readl(wcss->rmb_base + SSCAON_CONFIG);
> + val |= SSCAON_ENABLE;
> + writel(val, wcss->rmb_base + SSCAON_CONFIG);
> +
> + /* 3 - Set SSCAON_CONFIG */
> + val |= BIT(15);
> + val &= ~BIT(16);
> + val &= ~BIT(17);
> + val &= ~BIT(18);
wouldn't it be nice to define these bits?
> +static int q6v5_q6_powerdown(struct q6v5_wcss *wcss)
> +{
> + int ret;
> + u32 val;
> + int i;
int ret, i;
--
~Vinod
on (RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)) ||
> >> (RPMSG_QCOM_GLINK_SMEM || (COMPILE_TEST && RPMSG_QCOM_GLINK_SMEM=n))
> >
> > that doesnt really sound good :(
>
> Hmm, but i was thinking it should functionally depend on either SMD or GLINK
> and not both.
If you are depedent upon a symbol provided by a module you should say
depends on. If a machine is not supposed to have both SMD or GLINK then
the driver will not get probed.
--
~Vinod
On 06-06-18, 09:17, Bjorn Andersson wrote:
> On Tue 05 Jun 05:56 PDT 2018, Sricharan R wrote:
>
> > Hi Vinod,
> >
> > On 6/5/2018 11:49 AM, Vinod wrote:
> > > On 05-06-18, 11:12, Sricharan R wrote:
> > >
> > >> +config QCOM_Q6V5_WCSS
On 06-06-18, 21:24, Bjorn Andersson wrote:
> On Wed 06 Jun 21:11 PDT 2018, Vinod wrote:
>
> > So, wouldn't Kconfig syntax something like where we say:
> > M if RPMSG_QCOM_GLINK_SMEM=m
> > bool if RPMSG_QCOM_GLINK_SMEM=y
> >
>
> If we ign
he data which still sits in the
> >>>> DMA engine fifo when transfer is paused/terminated. This means that
> >>>> the serial driver should set maxburst = 1 if it is interested in
> >>>> getting exact number of bytes received/sent. With maxburst = 1 there
>
On 15-05-18, 14:24, Marek Szyprowski wrote:
> Hi Vinod,
>
> On 2018-05-15 08:21, Vinod wrote:
> > On 11-05-18, 14:57, Marek Szyprowski wrote:
> >> On 2018-05-10 18:04, Frank Mori Hess wrote:
> >>> On Thu, May 10, 2018 at 4:31 AM, Marek Szyprowski
> >&g
cy HD-audio driver
> > is that we allocate usually with MSI, so the irq is isolated.
> >
> > Any reason that Intel SKL driver doesn't use MST?
>
> This I'm not sure. Vinod might have answer to it, according to
> https://patchwork.kernel.org/patch/6375831/#13796611
IIRC (seemed quite some time back) we faced issues with using MSI on SKL
and didnt try afterwards. If Intel folks can try it and check. Pierre is
out, maybe Liam can help..?
--
~Vinod
On 12-09-18, 12:01, Masahiro Yamada wrote:
> Hi Vinod,
>
>
> 2018-09-11 16:00 GMT+09:00 Vinod :
> > On 24-08-18, 10:41, Masahiro Yamada wrote:
> >
> >> +/* mc->vc.lock must be held by caller */
> >> +static u32 __uniphier_mdmac_get_residue(struct un
On 12-09-18, 14:25, Masahiro Yamada wrote:
> 2018-09-12 13:35 GMT+09:00 Vinod :
> > On 12-09-18, 12:01, Masahiro Yamada wrote:
> >> Hi Vinod,
> >>
> >>
> >> 2018-09-11 16:00 GMT+09:00 Vinod :
> >> > On 24-08-18, 10:41, Masahiro Yamada wro
On 12-09-18, 09:29, Greg KH wrote:
> On Wed, Aug 08, 2018 at 09:58:50PM +0530, Vinod wrote:
> > Hey Greg,
> >
> > Please PULL to receive the soundwire update for v4.19-rc1 with a signed
> > tag as you requested last time and the norm :-)
> >
>
bus lock twice during master release
Shreyas NC (2):
soundwire: Fix duplicate stream state assignment
soundwire: Fix incorrect exit after configuring stream
drivers/soundwire/stream.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
--
~Vinod
Huang Shijie (1):
dmaengine: mic_x100_dma: use devm_kzalloc to fix an issue
drivers/dma/mic_x100_dma.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Thanks
--
~Vinod
signature.asc
Description: PGP signature
ome of the dais might only
> support capture/playback depending on the board level wiring.
>
> These two new dt properties will allow such flexibilty at board level dts.
Reviewed-by: Vinod Koul
--
~Vinod
;
> + codec->descriptor[0].num_sample_rates =
> + sizeof(supported_sample_rates)/sizeof(unsigned int);
> + codec->descriptor[0].bit_rate[0] = 320; /* 320kbps */
> + codec->descriptor[0].bit_rate[1] = 128;
> + codec->descriptor[0].num_bitrates = 2;
> + codec->descriptor[0].profiles = 0;
> + codec->descriptor[0].modes = SND_AUDIOCHANMODE_MP3_STEREO;
> + codec->descriptor[0].formats = 0;
since we are static here, how about using a table based approach and
use that here
--
~Vinod
icate assignment
Vinod Koul (3):
soundwire: Handle multiple master instances in a stream
soundwire: intel: Fix uninitialized adev deref
MAINTAINERS: Update Vinod's email
Documentation/driver-api/soundwire/stream.rst | 36 ++
MAINTAINERS
eration type 'enum dma_transfer_direction' to different enumeration
> type 'enum dma_data_direction' [-Wenum-conversion]
> td_desc->desc_list_len, DMA_MEM_TO_DEV);
> ^~~~~~
> 1 warning generated.
Applied, thanks
--
~Vinod
dma-ep93xx.h:88:10: warning: implicit
> conversion from enumeration type 'enum dma_data_direction' to different
> enumeration type 'enum dma_transfer_direction' [-Wenum-conversion]
> return DMA_NONE;
> ~~ ^~~~
> 1 warning generated.
Applied, thanks
--
~Vinod
On 28-09-18, 08:53, Andrea Merello wrote:
> On Tue, Sep 18, 2018 at 6:25 PM Vinod wrote:
> > > @@ -964,7 +968,7 @@ static int xilinx_dma_calc_copysize(struct
> > > xilinx_dma_chan *chan,
> > > int size, int done)
> > > {
On 28-09-18, 09:11, Andrea Merello wrote:
> On Tue, Sep 18, 2018 at 6:21 PM Vinod wrote:
> > > @@ -1804,7 +1817,7 @@ static struct dma_async_tx_descriptor
> > > *xilinx_dma_prep_slave_sg(
> > >* Calculate the maximum numb
d
> any parameters whether awkward.
Applied, thanks
--
~Vinod
Hi Stephen,
Thanks for the comments,
On 01-10-18, 10:19, Stephen Boyd wrote:
> Quoting Vinod Koul (2018-09-21 11:59:36)
> > From: Shefali Jain
> >
> > Add the clocks supported in global clock controller which clock the
> > peripherals like BLSPs, SDCC, USB, MDSS e
engine: Add transfer termination synchronization
> support")
> Signed-off-by: Andy Shevchenko
> Signed-off-by: Vinod Koul
> Signed-off-by: Sasha Levin
> ---
> drivers/dma/hsu/hsu.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/dma/hsu/hsu.c b
t; device_synchronize() callback to allow proper synchronization when stopping
> a channel.
Same for this patch as well. Adding optional call should not be stable
material
> Fixes: b36f09c3c441 ("dmaengine: Add transfer termination synchronization
> support")
> Signed-off-
On 19-09-18, 18:44, Bjorn Andersson wrote:
> Add support for the QCS404 APPS Global block with IPC register at offset
> 8.
>
> Signed-off-by: Bjorn Andersson
Reviewed-by: Vinod Koul
> ---
> .../devicetree/bindings/mailbox/qcom,apcs-kpss-global.txt| 1 +
> driv
On 19-09-18, 18:40, Bjorn Andersson wrote:
> The PMS405 provdies 5 SMPS regulators and 13 LDOs, add these to the RPM
> regulator driver.
Reviewed-by: Vinod Koul
>
> Signed-off-by: Bjorn Andersson
> ---
> .../regulator/qcom,smd-rpm-regulator.txt | 23 ++
> drive
On 19-09-18, 18:45, Bjorn Andersson wrote:
> Signed-off-by: Bjorn Andersson
Reviewed-by: Vinod Koul
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt | 1 +
> drivers/soc/qcom/smd-rpm.c | 1 +
> 2 files changed, 2 insertio
TO_DEV) | BIT(DMA_DEV_TO_MEM);
> + ddev->residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
> + ddev->device_prep_slave_sg = uniphier_mdmac_prep_slave_sg;
> + ddev->device_terminate_all = uniphier_mdmac_terminate_all;
> + ddev->device_synchronize = uniphier_mdmac_synchronize;
> + ddev->device_tx_status = uniphier_mdmac_tx_status;
> + ddev->device_issue_pending = uniphier_mdmac_issue_pending;
No device_config?
--
~Vinod
101 - 200 of 3854 matches
Mail list logo
