Re: [PATCH v2 8/9] ALSA: virtio: introduce PCM channel map support

On Sun, 24 Jan 2021, Anton Yakovlev wrote: Enumerate all available PCM channel maps and create ALSA controls. Signed-off-by: Anton Yakovlev --- sound/virtio/Makefile | 1 + sound/virtio/virtio_card.c | 15 +++ sound/virtio/virtio_card.h | 8 ++ sound/virtio/virtio_chmap.c | 237

Re: [PATCH v2 7/9] ALSA: virtio: introduce jack support

On Sun, 24 Jan 2021, Anton Yakovlev wrote: Enumerate all available jacks and create ALSA controls. At the moment jacks have a simple implementation and can only be used to receive notifications about a plugged in/out device. Signed-off-by: Anton Yakovlev --- sound/virtio/Makefile |

Re: [PATCH v2 6/9] ALSA: virtio: PCM substream operators

One more thing I missed yesterday: On Mon, 25 Jan 2021, Guennadi Liakhovetski wrote: On Sun, 24 Jan 2021, Anton Yakovlev wrote: Introduce the operators required for the operation of substreams. Signed-off-by: Anton Yakovlev --- sound/virtio/Makefile | 3 +- sound/virtio

Re: [PATCH v2 3/9] ALSA: virtio: handling control messages

I think the use of (devm_)kmalloc() and friends needs some refinement in several patches in the series. On Sun, 24 Jan 2021, Anton Yakovlev wrote: The control queue can be used by different parts of the driver to send commands to the device. Control messages can be either synchronous or

Re: [PATCH v2 2/9] ALSA: virtio: add virtio sound driver

Hi Anton, A couple of mostly cosmetic comments inline. On Sun, 24 Jan 2021, Anton Yakovlev wrote: Introduce skeleton of the virtio sound driver. The driver implements the virtio sound device specification, which has become part of the virtio standard. Initial initialization of the device,

Re: [PATCH v2 4/9] ALSA: virtio: build PCM devices and substream hardware descriptors

On Sun, 24 Jan 2021, Anton Yakovlev wrote: Like the HDA specification, the virtio sound device specification links PCM substreams, jacks and PCM channel maps into functional groups. For each discovered group, a PCM device is created, the number of which coincides with the group number.

Re: [PATCH v2 6/9] ALSA: virtio: PCM substream operators

On Sun, 24 Jan 2021, Anton Yakovlev wrote: Introduce the operators required for the operation of substreams. Signed-off-by: Anton Yakovlev --- sound/virtio/Makefile | 3 +- sound/virtio/virtio_pcm.c | 5 +- sound/virtio/virtio_pcm.h | 2 + sound/virtio/virtio_pcm_ops.c |

Re: [PATCH v2 5/9] ALSA: virtio: handling control and I/O messages for the PCM device

On Sun, 24 Jan 2021, Anton Yakovlev wrote: The driver implements a message-based transport for I/O substream operations. Before the start of the substream, the hardware buffer is sliced into I/O messages, the number of which is equal to the current number of periods. The size of each message

Re: [PATCH v2 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas

On Wed, 16 Dec 2020, Rob Herring wrote: > On Wed, Dec 16, 2020 at 11:18:03AM +0100, Guennadi Liakhovetski wrote: > > Hi Rob, > > > > Sorry for the delay! I didn't realise my ack was required for this patch. > > I won't object against the licence change, but please don't

Re: [PATCH v2 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas

R BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/video-interfaces.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common bindings for video receiver and transmitter interface endpoints > + > +maintainers: > +

Re: [PATCH v7 0/8] rpmsg: Make RPMSG name service modular

, 2020 at 01:39:54PM -0700, Mathieu Poirier wrote: > Good day, > > On Wed, Dec 02, 2020 at 12:05:55PM +0100, Guennadi Liakhovetski wrote: > > Hi Mathieu, > > > > I'd like to resume reviewing and begin upstreaming of the next steps of > > my Audio DSP Virtualisati

Re: [PATCH v7 0/8] rpmsg: Make RPMSG name service modular

on, Nov 23, 2020 at 05:06:10PM +0100, Guennadi Liakhovetski wrote: > Hi Mathieu, > > Thanks for bringing all the stuff together and for polishing it! > > For the entire series: > > Tested-by: Guennadi Liakhovetski > Reviewed-by: Guennadi Liakhovetski > > Thanks &g

Re: [PATCH v7 0/8] rpmsg: Make RPMSG name service modular

Hi Mathieu, Thanks for bringing all the stuff together and for polishing it! For the entire series: Tested-by: Guennadi Liakhovetski Reviewed-by: Guennadi Liakhovetski Thanks Guennadi On Fri, Nov 20, 2020 at 02:42:37PM -0700, Mathieu Poirier wrote: > This revision addresses comme

Re: [PATCH v6 8/8] rpmsg: Turn name service into a stand alone driver

Hi Mathieu, I haven't tested it yet, but I've compared it to the previous version and all the changed except the one, mentioned by Arnaud, seem to be there! So, let's just fix this one and should be good to go! Thanks Guennadi On Thu, Nov 19, 2020 at 03:52:50PM +0100, Arnaud POULIQUEN wrote:

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

On Tue, Nov 17, 2020 at 05:06:47PM -0700, Mathieu Poirier wrote: [snip] > I confirm that all this is working as expected - I will send a new revision of > this set tomorrow afternoon. > > Guennadi, can I add a Co-developed-by and Signed-off-by with your name on the > patch? You can add the

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

On Tue, Nov 17, 2020 at 06:30:54PM +0100, Arnaud POULIQUEN wrote: [snip] > It's not a good day for me today... it seems I read your explanation too > quickly > this morning, which is, however, very clear. > My apologies Oh, I did the same to one of your earlier emails one of these days - I

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

On Tue, Nov 17, 2020 at 05:44:05PM +0100, Arnaud POULIQUEN wrote: > > > On 11/17/20 5:03 PM, Guennadi Liakhovetski wrote: > > On Tue, Nov 17, 2020 at 12:42:30PM +0100, Arnaud POULIQUEN wrote: > > > > [snip] > > > >> diff --git a/drivers/rpmsg/rpmsg_

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

On Tue, Nov 17, 2020 at 12:42:30PM +0100, Arnaud POULIQUEN wrote: [snip] > diff --git a/drivers/rpmsg/rpmsg_ns.c b/drivers/rpmsg/rpmsg_ns.c > index 5bda7cb44618..80c2cc23bada 100644 > --- a/drivers/rpmsg/rpmsg_ns.c > +++ b/drivers/rpmsg/rpmsg_ns.c > @@ -55,6 +55,39 @@ static int

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

Hi Mathieu, On Mon, Nov 16, 2020 at 03:40:03PM -0700, Mathieu Poirier wrote: > On Mon, Nov 16, 2020 at 04:51:52PM +0100, Arnaud POULIQUEN wrote: [snip] > > Having said that, does this guarantee the probe, a good question! > > Maybe you or Mathieu have the answer, not me... > > I did a lot of

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

On Mon, Nov 16, 2020 at 04:51:52PM +0100, Arnaud POULIQUEN wrote: > Hi Guennadi, > > On 11/16/20 4:10 PM, Guennadi Liakhovetski wrote: > > Hi Arnaud, > > > > On Mon, Nov 16, 2020 at 03:43:35PM +0100, Arnaud POULIQUEN wrote: > >> Hi Guennadi, Mathie

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

Hi Arnaud, On Mon, Nov 16, 2020 at 03:43:35PM +0100, Arnaud POULIQUEN wrote: > Hi Guennadi, Mathieu, [snip] > I tried the find_module API, it's quite simple and seems to work well. just > need > to be protected by #ifdef MODULE > > I also added a select RMPS_NS in the RPMSG_VIRTIO for

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

Hi Arnaud, On Thu, Nov 12, 2020 at 11:17:54AM +0100, Arnaud POULIQUEN wrote: > Hi Guennadi, > > On 11/11/20 3:49 PM, Guennadi Liakhovetski wrote: > > Hi Arnaud, [snip] > > From: Guennadi Liakhovetski > > Subject: [PATCH] fixup! rpmsg: Turn name service into a stand

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

Hi Arnaud, On Tue, Nov 10, 2020 at 07:18:45PM +0100, Arnaud POULIQUEN wrote: > Hi Mathieu, Guennadi, > > On 11/9/20 6:55 PM, Mathieu Poirier wrote: > > On Mon, Nov 09, 2020 at 11:20:24AM +0100, Guennadi Liakhovetski wrote: > >> Hi Arnaud, > >> > >>

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

Hi Arnaud, On Mon, Nov 09, 2020 at 09:48:37AM +0100, Arnaud POULIQUEN wrote: > Hi Guennadi, Mathieu, > > On 11/6/20 6:53 PM, Mathieu Poirier wrote: > > On Fri, Nov 06, 2020 at 03:00:28PM +0100, Guennadi Liakhovetski wrote: > >> On Fri, Nov 06, 2020 at 02:15:45PM +010

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

On Fri, Nov 06, 2020 at 02:15:45PM +0100, Guennadi Liakhovetski wrote: > Hi Mathieu, Arnaud, > > On Thu, Nov 05, 2020 at 03:50:28PM -0700, Mathieu Poirier wrote: > > From: Arnaud Pouliquen > > > > Make the RPMSG name service announcement a stand alone driver s

Re: [PATCH v5 8/8] rpmsg: Turn name service into a stand alone driver

Hi Mathieu, Arnaud, On Thu, Nov 05, 2020 at 03:50:28PM -0700, Mathieu Poirier wrote: > From: Arnaud Pouliquen > > Make the RPMSG name service announcement a stand alone driver so that it > can be reused by other subsystems. It is also the first step in making the > functionatlity transport

Re: [PATCH v4 8/8] rpmsg: Turn name service into a stand alone driver

On Wed, Nov 04, 2020 at 10:34:24AM -0700, Mathieu Poirier wrote: > On Wed, Nov 04, 2020 at 03:01:44PM +0100, Guennadi Liakhovetski wrote: > > Hi Mathieu, Arnaud, > > > > I've tried the patch set with my VirtIO / vhost audio implementation, > > in general it worked

Re: [PATCH v4 3/8] rpmsg: Move structure rpmsg_ns_msg to header file

A nitpick to this one: On Tue, Oct 27, 2020 at 11:52:13AM -0600, Mathieu Poirier wrote: > Move structure rpmsg_ns_msg to its own header file so that > it can be used by other entities. > > Signed-off-by: Mathieu Poirier > Reviewed-by: Arnaud Pouliquen > --- [snip] > diff --git

Re: [PATCH v4 8/8] rpmsg: Turn name service into a stand alone driver

Hi Mathieu, Arnaud, I've tried the patch set with my VirtIO / vhost audio implementation, in general it worked quite well, but I did need one chamge, which should be improved in this patch: On Tue, Oct 27, 2020 at 11:52:18AM -0600, Mathieu Poirier wrote: > From: Arnaud Pouliquen > > Make the

Re: [PATCH v4 3/8] rpmsg: Move structure rpmsg_ns_msg to header file

Hi Mathieu, On Tue, Oct 27, 2020 at 11:52:13AM -0600, Mathieu Poirier wrote: > Move structure rpmsg_ns_msg to its own header file so that > it can be used by other entities. > > Signed-off-by: Mathieu Poirier > Reviewed-by: Arnaud Pouliquen > --- > drivers/rpmsg/virtio_rpmsg_bus.c | 32

Re: [PATCH v2 0/9] rpmsg: Make RPMSG name service modular

ork that Arnaud > published[1] to make the name service modular. > > Tested on stm32mp157 with the RPMSG client sample application. Applies > cleanly on v5.9. Reviewed-by: Guennadi Liakhovetski Thanks Guennadi > > Thanks, > Mathieu > > [1]. https://patchwork.kernel

Re: [PATCH 10/10] rpmsg: ns: Make Name service module transport agnostic

On Mon, Sep 21, 2020 at 06:10:00PM -0600, Mathieu Poirier wrote: > Make name service module transport agnostic by using the rpmsg > device specific byte conversion routine. > > Signed-off-by: Mathieu Poirier > --- > drivers/rpmsg/rpmsg_ns.c | 10 -- > include/linux/rpmsg_ns.h | 4 ++--

Re: [PATCH 08/10] rpmsg: core: Add RPMSG byte conversion operations

On Mon, Sep 21, 2020 at 06:09:58PM -0600, Mathieu Poirier wrote: > Add RPMSG device specific byte conversion operations as a first > step to separate the RPMSG name space service from the virtIO > transport layer. > > Signed-off-by: Mathieu Poirier > --- > drivers/rpmsg/rpmsg_core.c | 51

Re: [PATCH 06/10] rpmsg: Turn name service into a stand alone driver

On Mon, Sep 21, 2020 at 06:09:56PM -0600, Mathieu Poirier wrote: > From: Arnaud Pouliquen > > Make the RPMSG name service announcement a stand alone driver so that it > can be reused by other subsystems. It is also the first step in making the > functionatlity transport independent, i.e that is

Re: [PATCH 05/10] rpmsg: virtio: Move virtio RPMSG structures to private header

On Mon, Sep 21, 2020 at 06:09:55PM -0600, Mathieu Poirier wrote: > Move structure virtiproc_info and virtio_rpmsg_channel to rpmsg_internal.h > so that they can be used by rpmsg_ns.c > > Signed-off-by: Mathieu Poirier > --- > drivers/rpmsg/rpmsg_internal.h | 62

Re: [PATCH 04/10] rpmsg: Move common structures and defines to headers

On Mon, Sep 21, 2020 at 06:09:54PM -0600, Mathieu Poirier wrote: > From: Guennadi Liakhovetski > > virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and > common defines like the ones, needed for name-space announcements, > internal. Move them to common headers inste

Re: [PATCH 02/10] rpmsg: core: Add channel creation internal API

On Mon, Sep 21, 2020 at 06:09:52PM -0600, Mathieu Poirier wrote: > From: Arnaud Pouliquen > > Add the channel creation API as a first step to be able to define the > name service announcement as a rpmsg driver independent from the RPMsg > virtio bus. > > Signed-off-by: Arnaud Pouliquen > --- >

Re: [PATCH 00/10] rpmsg: Make RPMSG name service modular

Hi Mathieu, On Mon, Sep 28, 2020 at 01:33:08PM -0600, Mathieu Poirier wrote: > Hey Guennadi, > > On Mon, Sep 28, 2020 at 11:49:42AM +0200, Guennadi Liakhovetski wrote: > > (re-sending, mailing list delivery attempts last Friday failed) > > > > I got your emai

Re: [PATCH 00/10] rpmsg: Make RPMSG name service modular

, Mathieu Poirier wrote: > Good day Guennadi, > > On Tue, 22 Sep 2020 at 02:09, Guennadi Liakhovetski > wrote: > > > > Hi Mathieu, > > > > Thanks for the patches. I'm trying to understand the concept of > > this approach and I'm probably failing at that. It see

Re: [PATCH 00/10] rpmsg: Make RPMSG name service modular

; rpmsg: virtio: rename rpmsg_create_channel > rpmsg: core: Add channel creation internal API > rpmsg: virtio: Add rpmsg channel device ops > rpmsg: Turn name service into a stand alone driver > rpmsg: virtio: use rpmsg ns device for the ns announcement > > Guennadi Liakh

Re: [PATCH 01/10] rpmsg: virtio: rename rpmsg_create_channel

On Mon, Sep 21, 2020 at 06:09:51PM -0600, Mathieu Poirier wrote: > From: Arnaud Pouliquen > > Rename the internal function as it is internal, and as > the name will be used in rpmsg_core. > > Signed-off-by: Arnaud Pouliquen > --- > drivers/rpmsg/virtio_rpmsg_bus.c | 7 --- > 1 file

Re: linux-next: build failure after merge of the vhost tree

=bba6f4f52c31af1ce4ebcc063afa08eb063b3d2c doesn't have it? Thanks Guennadi On Tue, Aug 04, 2020 at 07:47:58AM +0200, Guennadi Liakhovetski wrote: > Hi Stephen, > > On Tue, Aug 04, 2020 at 03:11:17PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the vhost tree, to

Re: linux-next: build failure after merge of the vhost tree

Hi Stephen, On Tue, Aug 04, 2020 at 03:11:17PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the vhost tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > drivers/rpmsg/virtio_rpmsg_bus.c:28:10: fatal error: linux/virtio_rpmsg.h: No > such file or

Re: [PATCH v4 1/3] virtio: add dma-buf support for exported objects

Hi David, On Fri, Jun 19, 2020 at 10:57:37AM +0900, David Stevens wrote: > On Thu, Jun 18, 2020 at 9:29 PM Guennadi Liakhovetski > wrote: > > > > Hi Michael, > > > > On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote: > > > On Tue, May 26,

Re: [PATCH v4 1/3] virtio: add dma-buf support for exported objects

Hi Michael, On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote: > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote: > > This change adds a new flavor of dma-bufs that can be used by virtio > > drivers to share exported objects. A virtio dma-buf can be queried by > >

Re: [alsa-devel] [RFC PATCH 0/5] ASoC: SOF: Intel: SoundWire initial integration

Hi Pierre, In patch 4/5 I forgot to mention superfluous braces around dev_err() in sdw_config_stream() and sdw_free_stream(). Otherwise for the series: Reviewed-by: Guennadi Liakhovetski Thanks Guennadi On Wed, Aug 21, 2019 at 03:17:15PM -0500, Pierre-Louis Bossart wrote: > This

Re: [RFC PATCH 4/5] ASoC: SOF: Intel: hda: add SoundWire stream config/free callbacks

On Thu, Aug 22, 2019 at 08:53:06AM -0500, Pierre-Louis Bossart wrote: > Thanks for the review Guennadi > > > > +static int sdw_config_stream(void *arg, void *s, void *dai, > > > + void *params, int link_id, int alh_stream_id) > > > > I realise, that these function prototypes

Re: [RFC PATCH 4/5] ASoC: SOF: Intel: hda: add SoundWire stream config/free callbacks

On Thu, Aug 22, 2019 at 09:18:35AM +0200, Guennadi Liakhovetski wrote: [snip] > > static int hda_sdw_init(struct snd_sof_dev *sdev) > > { > > acpi_handle handle; > > @@ -67,6 +131,8 @@ static int hda_sdw_init(struct snd_sof_dev *sdev) > > res.mmi

Re: [RFC PATCH 4/5] ASoC: SOF: Intel: hda: add SoundWire stream config/free callbacks

Hi Pierre, A couple of comments below On Wed, Aug 21, 2019 at 03:17:19PM -0500, Pierre-Louis Bossart wrote: > These callbacks are invoked when a matching hw_params/hw_free() DAI > operation takes place, and will result in IPC operations with the SOF > firmware. > > Signed-off-by: Pierre-Louis

Re: [alsa-devel] [RFC PATCH 17/40] soundwire: bus: use runtime_pm_get_sync/pm when enabled

On Fri, Jul 26, 2019 at 01:08:57PM -0500, Pierre-Louis Bossart wrote: > This thread became unreadable with interleaved top-posting, allow me restate > the options and ask PM folks what they think > > On 7/25/19 6:40 PM, Pierre-Louis Bossart wrote: > > Not all platforms support runtime_pm for now,

Re: [alsa-devel] [RFC PATCH 38/40] soundwire: cadence_master: make clock stop exit configurable on init

On Thu, Jul 25, 2019 at 06:40:30PM -0500, Pierre-Louis Bossart wrote: > The use of clock stop is not a requirement, the IP can e.g. be > completely power gated and not detect any wakes while in s2idle/deep > sleep. > > Signed-off-by: Pierre-Louis Bossart > --- >

Re: [alsa-devel] [RFC PATCH 36/40] soundwire: intel: disable interrupts on suspend

On Thu, Jul 25, 2019 at 06:40:28PM -0500, Pierre-Louis Bossart wrote: > Signed-off-by: Pierre-Louis Bossart > --- > drivers/soundwire/cadence_master.c | 42 +- > drivers/soundwire/cadence_master.h | 2 +- > drivers/soundwire/intel.c | 6 +++-- > 3 files

Re: [alsa-devel] [RFC PATCH 37/40] soundwire: cadence_master: add hw_reset capability in debugfs

On Thu, Jul 25, 2019 at 06:40:29PM -0500, Pierre-Louis Bossart wrote: > This is to kick devices into reset and see what software does > > Signed-off-by: Pierre-Louis Bossart > --- > drivers/soundwire/cadence_master.c | 22 ++ > 1 file changed, 22 insertions(+) > > diff

Re: [alsa-devel] [RFC PATCH 35/40] soundwire: intel: export helper to exit reset

On Thu, Jul 25, 2019 at 06:40:27PM -0500, Pierre-Louis Bossart wrote: > Signed-off-by: Pierre-Louis Bossart > --- > drivers/soundwire/cadence_master.c | 9 +++-- > drivers/soundwire/cadence_master.h | 1 + > drivers/soundwire/intel.c | 4 > 3 files changed, 12 insertions(+), 2

Re: [alsa-devel] [RFC PATCH 27/40] soundwire: Add Intel resource management algorithm

On Thu, Jul 25, 2019 at 06:40:19PM -0500, Pierre-Louis Bossart wrote: > This algorithm computes bus parameters like clock frequency, frame > shape and port transport parameters based on active stream(s) running > on the bus. > > This implementation is optimal for Intel platforms. Developers can >

Re: [alsa-devel] [RFC PATCH 23/40] soundwire: stream: fix disable sequence

Unrelated to this specific patch, but I looked at _sdw_disable_stream() and I see this there (again, maybe my version is outdated already): struct sdw_master_runtime *m_rt = NULL; struct sdw_bus *bus = NULL; where both those initialisations are redundant. Moreover: On Thu, Jul

Re: [alsa-devel] [RFC PATCH 21/40] soundwire: export helpers to find row and column values

On Thu, Jul 25, 2019 at 06:40:13PM -0500, Pierre-Louis Bossart wrote: > Add a prefix for common tables and export 2 helpers to set the frame > shapes based on row/col values. > > Signed-off-by: Pierre-Louis Bossart > --- > drivers/soundwire/bus.h| 7 +-- > drivers/soundwire/stream.c |

Re: [alsa-devel] [RFC PATCH 17/40] soundwire: bus: use runtime_pm_get_sync/pm when enabled

On Fri, Jul 26, 2019 at 08:33:35AM +, Jan Kotas wrote: > > > > On 26 Jul 2019, at 10:22, Guennadi Liakhovetski > > wrote: > > > > EXTERNAL MAIL > > > > > > Hi Jan, > > > > On Fri, Jul 26, 2019 at 07:47:04AM +, Jan Kotas w

Re: [alsa-devel] [RFC PATCH 17/40] soundwire: bus: use runtime_pm_get_sync/pm when enabled

tly once?..) and it's active and the device is suspended for a system suspend, the function will return 1. I don't understand the logic of this code, but it seems to me it could break the -EACCESS check? Thanks Guennadi > Jan > > > On 26 Jul 2019, at 09:39, Guennadi Liakhovetski >

Re: [alsa-devel] [RFC PATCH 17/40] soundwire: bus: use runtime_pm_get_sync/pm when enabled

Hi Pierre, I might be wrong but this doesn't seem right to me. (Supposedly) all RT-PM functions check for "enabled" internally. The only thing that can happen is that if RT-PM isn't enabled some of those functions will return an error. So, in those cases where the return value of RT-PM functions

Re: [alsa-devel] [RFC PATCH 16/40] soundwire: cadence_master: improve startup sequence with link hw_reset

On Thu, Jul 25, 2019 at 06:40:08PM -0500, Pierre-Louis Bossart wrote: > Enable interrupts first, then engage hardware bus reset with maximum > duration to make sure the Slave(s) correctly detect the reset pattern > and to ensure electrical conflicts can be resolved. > > Without these changes the

Re: [alsa-devel] [RFC PATCH 15/40] soundwire: cadence_master: handle multiple status reports per Slave

On Thu, Jul 25, 2019 at 06:40:07PM -0500, Pierre-Louis Bossart wrote: > When a Slave reports multiple status in the sticky bits, find the > latest configuration from the mirror of the PING frame status and > update the status directly. > > Signed-off-by: Pierre-Louis Bossart > --- >

Re: [alsa-devel] [RFC PATCH 09/40] soundwire: cadence_master: fix usage of CONFIG_UPDATE

On Thu, Jul 25, 2019 at 06:40:01PM -0500, Pierre-Louis Bossart wrote: > Per the hardware documentation, all changes to MCP_CONFIG, > MCP_CONTROL, MCP_CMDCTRL and MCP_PHYCTRL need to be validated with a > self-clearing write to MCP_CONFIG_UPDATE. > > For some reason, the existing code only does

Re: [alsa-devel] [RFC PATCH 01/40] soundwire: add debugfs support

Hi Pierre, A couple of nitpicks: On Thu, Jul 25, 2019 at 06:39:53PM -0500, Pierre-Louis Bossart wrote: > Add base debugfs mechanism for SoundWire bus by creating soundwire > root and master-N and slave-x hierarchy. > > Also add SDW Slave SCP, DP0 and DP-N register debug file. > > Registers not

[PATCH resend] regulator: fix device unlinking

From: Guennadi Liakhovetski Device links are refcounted, device_link_remove() has to be called as many times as device_link_add(). Signed-off-by: Guennadi Liakhovetski --- Resending with the "PATCH" subject line modifier. drivers/regulator/core.c | 10 +- 1 file changed, 1

regulator: fix device unlinking

From: Guennadi Liakhovetski Device links are refcounted, device_link_remove() has to be called as many times as device_link_add(). Signed-off-by: Guennadi Liakhovetski --- drivers/regulator/core.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/regulator

Re: [PATCH] media: uvcvideo: Prevent setting unavailable flags

off-by: Kieran Bingham <kieran.bing...@ideasonboard.com> Tested-by: Guennadi Liakhovetski <guennadi.liakhovet...@intel.com> Thanks Guennadi > --- > drivers/media/usb/uvc/uvc_ctrl.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --gi

Re: [PATCH] media: uvcvideo: Prevent setting unavailable flags

gt; use case, and ensure that the new functionality in uvc_ctrl_get_flags() > will only set flags based on their reported capability from the GET_INFO > call. > > Fixes: 859086ae3636 ("media: uvcvideo: Apply flags from device to actual > properties") > > Signed-of

Re: [RFT PATCH v3 6/6] uvcvideo: Move decode processing to process context

Hi Kieran, On Fri, 12 Jan 2018, Kieran Bingham wrote: > Newer high definition cameras, and cameras with multiple lenses such as > the range of stereo-vision cameras now available have ever increasing > data rates. > > The inclusion of a variable length packet header in URB packets mean > that

Re: [RFT PATCH v3 6/6] uvcvideo: Move decode processing to process context

Hi Kieran, On Fri, 12 Jan 2018, Kieran Bingham wrote: > Newer high definition cameras, and cameras with multiple lenses such as > the range of stereo-vision cameras now available have ever increasing > data rates. > > The inclusion of a variable length packet header in URB packets mean > that

Re: [RFC/RFT PATCH 6/6] uvcvideo: Move decode processing to process context

On Wed, 3 Jan 2018, Kieran Bingham wrote: > From: Kieran Bingham > > Newer high definition cameras, and cameras with multiple lenses such as > the range of stereovision cameras now available have ever increasing > data rates. > > The inclusion of a variable

Re: [RFC/RFT PATCH 6/6] uvcvideo: Move decode processing to process context

On Wed, 3 Jan 2018, Kieran Bingham wrote: > From: Kieran Bingham > > Newer high definition cameras, and cameras with multiple lenses such as > the range of stereovision cameras now available have ever increasing > data rates. > > The inclusion of a variable length packet header in URB packets

Re: [RFC/RFT PATCH 3/6] uvcvideo: Protect queue internals with helper

Hi Kieran, On Wed, 3 Jan 2018, Kieran Bingham wrote: > From: Kieran Bingham > > The URB completion operation obtains the current buffer by reading > directly into the queue internal interface. > > Protect this queue abstraction by providing a helper >

Re: [RFC/RFT PATCH 3/6] uvcvideo: Protect queue internals with helper

Hi Kieran, On Wed, 3 Jan 2018, Kieran Bingham wrote: > From: Kieran Bingham > > The URB completion operation obtains the current buffer by reading > directly into the queue internal interface. > > Protect this queue abstraction by providing a helper > uvc_queue_get_current_buffer() which can

Re: [RFC/RFT PATCH 1/6] uvcvideo: Refactor URB descriptors

Hi Kieran, Just minor suggestions below: On Wed, 3 Jan 2018, Kieran Bingham wrote: > From: Kieran Bingham > > We currently store three separate arrays for each URB reference we hold. > > Objectify the data needed to track URBs into a single uvc_urb structure,

Re: [RFC/RFT PATCH 1/6] uvcvideo: Refactor URB descriptors

Hi Kieran, Just minor suggestions below: On Wed, 3 Jan 2018, Kieran Bingham wrote: > From: Kieran Bingham > > We currently store three separate arrays for each URB reference we hold. > > Objectify the data needed to track URBs into a single uvc_urb structure, > allowing better object

Re: [PATCH resend] [media] uvcvideo: zero seq number when disabling stream

Hi Laurent, On Mon, 16 Oct 2017, Laurent Pinchart wrote: > Hi Hans, > > (CC'ing Guennadi Liakhovetski) > > Thank you for the patch. > > On Friday, 15 September 2017 09:27:51 EEST Hans Yang wrote: > > For bulk-based devices, when disabling the video strea

Re: [PATCH resend] [media] uvcvideo: zero seq number when disabling stream

Hi Laurent, On Mon, 16 Oct 2017, Laurent Pinchart wrote: > Hi Hans, > > (CC'ing Guennadi Liakhovetski) > > Thank you for the patch. > > On Friday, 15 September 2017 09:27:51 EEST Hans Yang wrote: > > For bulk-based devices, when disabling the video strea

Re: [PATCH 03/15] [media] i2c: make device_type const

On Sat, 19 Aug 2017, Bhumika Goyal wrote: > Make this const as it is only stored in the type field of a device > structure, which is const. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal <bhumi...@gmail.com> Acked-by: Guennadi Liakhovetski <g.liakhovet...@

Re: [PATCH 03/15] [media] i2c: make device_type const

On Sat, 19 Aug 2017, Bhumika Goyal wrote: > Make this const as it is only stored in the type field of a device > structure, which is const. > Done using Coccinelle. > > Signed-off-by: Bhumika Goyal Acked-by: Guennadi Liakhovetski Thanks Guennadi > --- > drivers/media/i

Re: [PATCH 1/3] [media] soc-camera: ov5642: Add OF device ID table

device ID and > that the MODALIAS reported will always be of the form i2c:. > > But this could change in the future so the correct approach is to have an > OF device ID table if the devices are registered via OF. > > Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> Acked-by: G

Re: [PATCH 1/3] [media] soc-camera: ov5642: Add OF device ID table

device ID and > that the MODALIAS reported will always be of the form i2c:. > > But this could change in the future so the correct approach is to have an > OF device ID table if the devices are registered via OF. > > Signed-off-by: Javier Martinez Canillas Acked-by: Guennadi Liakhovetski &g

Re: [PATCH v5 01/13] media: mt9m111: make a standalone v4l2 subdevice

mentioned in my reply to your other patch, maybe good to join this with #3. Otherwise and with that in mind > Signed-off-by: Robert Jarzmik <robert.jarz...@free.fr> Acked-by: Guennadi Liakhovetski <g.liakhovet...@gmx.de> Thanks Guennadi > --- > drivers

Re: [PATCH v5 01/13] media: mt9m111: make a standalone v4l2 subdevice

mentioned in my reply to your other patch, maybe good to join this with #3. Otherwise and with that in mind > Signed-off-by: Robert Jarzmik Acked-by: Guennadi Liakhovetski Thanks Guennadi > --- > drivers/media/i2c/soc_camera/mt9m111.c | 51 > ++ >

Re: [PATCH v5 03/13] media: mt9m111: move mt9m111 out of soc_camera

Hi Robert, You could use "git format-patch -M" to make this patch much smaller and to make it simple to verify, what actually changed in mt9m111.c, if anything. Actually it might even be good to merge this patch with patch #1. Thanks Guennadi On Mon, 29 Aug 2016, Robert Jarzmik wrote: > As

Re: [PATCH v5 03/13] media: mt9m111: move mt9m111 out of soc_camera

Hi Robert, You could use "git format-patch -M" to make this patch much smaller and to make it simple to verify, what actually changed in mt9m111.c, if anything. Actually it might even be good to merge this patch with patch #1. Thanks Guennadi On Mon, 29 Aug 2016, Robert Jarzmik wrote: > As

Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

Hi Robert, Not sure I understand, what should the purpose of this patch be? Why do you want to move some function(s) from one file to another? And you aren't even calling the new soc_mbus_build_fmts_xlate() function, and you aren't replacing the currently used analogous

Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

Hi Robert, Not sure I understand, what should the purpose of this patch be? Why do you want to move some function(s) from one file to another? And you aren't even calling the new soc_mbus_build_fmts_xlate() function, and you aren't replacing the currently used analogous

Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path

On Mon, 8 Feb 2016, Robert Jarzmik wrote: > Guennadi Liakhovetski <g.liakhovet...@gmx.de> writes: > > > Hi Robert, > > > > On Tue, 27 Oct 2015, Robert Jarzmik wrote: > > > >> Guennadi Liakhovetski <g.liakhovet...@gmx.de> writes: > >> &

Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path

On Mon, 8 Feb 2016, Robert Jarzmik wrote: > Guennadi Liakhovetski writes: > > > Hi Robert, > > > > On Tue, 27 Oct 2015, Robert Jarzmik wrote: > > > >> Guennadi Liakhovetski writes: > >> > >> > Hi Robert, > >> > > &g

Re: [PATCH v5 3/4] media: pxa_camera: trivial move of dma irq functions

Hi Robert, On Sun, 6 Sep 2015, Robert Jarzmik wrote: > This moves the dma irq handling functions up in the source file, so that > they are available before DMA preparation functions. It prepares the > conversion to DMA engine, where the descriptors are populated with these > functions as

Re: [PATCH v5 3/4] media: pxa_camera: trivial move of dma irq functions

Hi Robert, On Sun, 6 Sep 2015, Robert Jarzmik wrote: > This moves the dma irq handling functions up in the source file, so that > they are available before DMA preparation functions. It prepares the > conversion to DMA engine, where the descriptors are populated with these > functions as

Re: [PATCH 4/7] atmel-isi: fix IS_ERR_VALUE usage

Hi Andrzej, On Mon, 15 Feb 2016, Andrzej Hajda wrote: > IS_ERR_VALUE macro should be used only with unsigned long type. > For signed types comparison 'ret < 0' should be used. > > The patch follows conclusion from discussion on LKML [1][2]. > > [1]:

Re: [PATCH 4/7] atmel-isi: fix IS_ERR_VALUE usage

Hi Andrzej, On Mon, 15 Feb 2016, Andrzej Hajda wrote: > IS_ERR_VALUE macro should be used only with unsigned long type. > For signed types comparison 'ret < 0' should be used. > > The patch follows conclusion from discussion on LKML [1][2]. > > [1]:

Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path

On Sun, 21 Feb 2016, Robert Jarzmik wrote: > Guennadi Liakhovetski <g.liakhovet...@gmx.de> writes: > > >> Okay Guennadi, I retested this version on top of v4.5-rc2, still good to > >> go. There is a minor conflict in the includes since this submission, and I &

Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path

On Sun, 21 Feb 2016, Robert Jarzmik wrote: > Guennadi Liakhovetski writes: > > >> Okay Guennadi, I retested this version on top of v4.5-rc2, still good to > >> go. There is a minor conflict in the includes since this submission, and I > >> can > >> re

Re: [PATCH v5 3/4] media: pxa_camera: trivial move of dma irq functions

On Sun, 21 Feb 2016, Guennadi Liakhovetski wrote: > Hi Robert, > > On Sun, 6 Sep 2015, Robert Jarzmik wrote: > > > This moves the dma irq handling functions up in the source file, so that > > they are available before DMA preparation functions. It prepares the >

Re: [PATCH v5 3/4] media: pxa_camera: trivial move of dma irq functions

On Sun, 21 Feb 2016, Guennadi Liakhovetski wrote: > Hi Robert, > > On Sun, 6 Sep 2015, Robert Jarzmik wrote: > > > This moves the dma irq handling functions up in the source file, so that > > they are available before DMA preparation functions. It prepares the >

Re: [PATCH] net: smc911x: convert pxa dma to dmaengine

Hi, On Sat, 20 Feb 2016, Hitoshi Mitake wrote: > > Hi Robert, > > At Sat, 06 Feb 2016 10:05:51 +0100, > Robert Jarzmik wrote: > > > > David Miller writes: > > > > > From: Robert Jarzmik > > > Date: Fri, 05 Feb 2016 22:44:56 +0100 > > > > > >>

Re: [PATCH] net: smc911x: convert pxa dma to dmaengine

Hi, On Sat, 20 Feb 2016, Hitoshi Mitake wrote: > > Hi Robert, > > At Sat, 06 Feb 2016 10:05:51 +0100, > Robert Jarzmik wrote: > > > > David Miller writes: > > > > > From: Robert Jarzmik > > > Date: Fri, 05 Feb 2016 22:44:56 +0100 > > > > > >> Apart from Alberto who answered he cannot test

  1   2   3   4   5   6   7   8   9   10   >