[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAA+D8AMTyxcz2nXEDemuWRwtORSfRoBRZO03WyX+XpuiOD0XiA@mail.gmail.com>
Date: Sun, 7 Feb 2021 17:50:35 +0800
From: Shengjiu Wang <shengjiu.wang@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Shengjiu Wang <shengjiu.wang@....com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, alsa-devel@...a-project.org,
Timur Tabi <timur@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
linuxppc-dev@...ts.ozlabs.org, Xiubo Li <Xiubo.Lee@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Takashi Iwai <tiwai@...e.com>,
Nicolin Chen <nicoleotsuka@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Fabio Estevam <festevam@...il.com>
Subject: Re: [PATCH 5/7] ASoC: imx-pcm-rpmsg: Add platform driver for audio
base on rpmsg
On Fri, Feb 5, 2021 at 11:00 PM Mark Brown <broonie@...nel.org> wrote:
>
> On Fri, Feb 05, 2021 at 02:57:28PM +0800, Shengjiu Wang wrote:
>
> > + if (params_format(params) == SNDRV_PCM_FORMAT_S16_LE)
> > + msg->s_msg.param.format = RPMSG_S16_LE;
> > + else if (params_format(params) == SNDRV_PCM_FORMAT_S24_LE)
>
> Again this should be a switch statement.
>
> > + if (params_channels(params) == 1)
> > + msg->s_msg.param.channels = RPMSG_CH_LEFT;
> > + else
> > + msg->s_msg.param.channels = RPMSG_CH_STEREO;
>
> Shouldn't this be reporting an error if the number of channels is more
> than 2?
>
> > + /*
> > + * if the data in the buffer is less than one period
> > + * send message immediately.
> > + * if there is more than one period data, delay one
> > + * period (timer) to send the message.
> > + */
> > + if ((avail - writen_num * period_size) <= period_size) {
> > + imx_rpmsg_insert_workqueue(substream, msg, info);
> > + } else if (rpmsg->force_lpa && !timer_pending(timer)) {
> > + int time_msec;
> > +
> > + time_msec = (int)(runtime->period_size * 1000 / runtime->rate);
> > + mod_timer(timer, jiffies + msecs_to_jiffies(time_msec));
> > + }
>
> The comment here is at least confusing - why would we not send a full
> buffer immediately if we have one? This sounds like it's the opposite
> way round to what we'd do if we were trying to cut down the number of
> messages. It might help to say which buffer and where?
>
> > + /**
> > + * Every work in the work queue, first we check if there
>
> /** comments are only for kerneldoc.
Thanks Mark, I will update them.
Best regards
wang shengjiu
Powered by blists - more mailing lists