From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: Stefan Wahren <stefan.wahren@i2se.com>,
Dave Stevenson <dave.stevenson@raspberrypi.org>,
Peter Robinson <pbrobinson@gmail.com>
Cc: devel@driverdev.osuosl.org, Arnd Bergmann <arnd@arndb.de>,
tiwai@suse.de, Greg KH <gregkh@linuxfoundation.org>,
mikebrady@eircom.net, Eric Anholt <eric@anholt.net>,
"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE"
<linux-rpi-kernel@lists.infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload
Date: Wed, 09 Jan 2019 12:58:39 +0100 [thread overview]
Message-ID: <64799d4495a4cbc43c3a8f61afda17a0ae70c2fc.camel@suse.de> (raw)
In-Reply-To: <537778454.382280.1547022816273@email.ionos.de>
[-- Attachment #1.1: Type: text/plain, Size: 669 bytes --]
Hi Stefan,
On Wed, 2019-01-09 at 09:33 +0100, Stefan Wahren wrote:
>
> But i noticed a regression introduced in 5.0-rc1, which might be
> related. I
> tried to run "vchiq_test -f 1" and it never completes. After
> reverting commit
> 852b2876a8a8 ("staging: vchiq: rework remove_event handling")
> vchiq_test [1]
> works as expected again.
I had a look at that one, it seems that it's due to the fact that vchiq
relies on completions only sleeping whenever their internal count
reaches 0 (it's incremented on every complete()). As opposed to
wait_queues, which will wait until an event is triggered regardless of
previous state.
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-09 11:59 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-25 15:29 [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 01/11] staging: bcm2835-camera: Abort probe if there is no camera Stefan Wahren
2018-12-19 8:07 ` Peter Robinson
2018-10-25 15:29 ` [PATCH RFC 02/11] staging: bcm2835-camera: fix module autoloading Stefan Wahren
2018-12-19 7:54 ` Peter Robinson
2018-10-25 15:29 ` [PATCH RFC 03/11] staging: bcm2835-camera: Move module info to the end Stefan Wahren
2018-12-19 7:53 ` Peter Robinson
2018-10-25 15:29 ` [PATCH RFC 04/11] staging: vchiq_arm: Fix platform device unregistration Stefan Wahren
2018-10-26 8:07 ` Dan Carpenter
2018-10-25 15:29 ` [PATCH RFC 05/11] staging: vchiq_arm: Fix camera device registration Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 06/11] staging: vchiq_arm: Register a platform device for audio Stefan Wahren
2018-10-26 8:09 ` Dan Carpenter
2018-10-26 8:18 ` Dan Carpenter
2018-10-25 15:29 ` [PATCH RFC 07/11] staging: bcm2835-audio: Enable compile test Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 08/11] staging: bcm2835-audio: use module_platform_driver() macro Stefan Wahren
2018-10-25 15:29 ` [PATCH RFX 09/11] staging: bcm2835-audio: Drop DT dependency Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 10/11] staging: bcm2835-camera: Provide more specific probe error messages Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 11/11] staging: bcm2835-camera: Add hint about possible faulty config Stefan Wahren
2018-10-26 10:55 ` Nicolas Saenz Julienne
2018-10-26 11:06 ` [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload Nicolas Saenz Julienne
2018-10-28 20:10 ` Stefan Wahren
2019-01-08 7:21 ` Peter Robinson
2019-01-08 8:48 ` Stefan Wahren
2019-01-08 8:56 ` Peter Robinson
2019-01-08 10:20 ` Stefan Wahren
2019-01-10 5:09 ` Peter Robinson
2019-01-10 6:24 ` Stefan Wahren
2019-01-10 6:34 ` Peter Robinson
2019-01-10 18:48 ` Stefan Wahren
2019-01-11 6:10 ` Peter Robinson
2019-01-11 16:43 ` Dave Stevenson
2019-01-12 5:26 ` Peter Robinson
2019-01-10 7:05 ` Peter Robinson
2019-01-08 17:10 ` Dave Stevenson
2019-01-09 8:33 ` Stefan Wahren
2019-01-09 11:58 ` Nicolas Saenz Julienne [this message]
2019-01-10 5:22 ` Peter Robinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64799d4495a4cbc43c3a8f61afda17a0ae70c2fc.camel@suse.de \
--to=nsaenzjulienne@suse.de \
--cc=arnd@arndb.de \
--cc=dave.stevenson@raspberrypi.org \
--cc=devel@driverdev.osuosl.org \
--cc=eric@anholt.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=mikebrady@eircom.net \
--cc=pbrobinson@gmail.com \
--cc=stefan.wahren@i2se.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.