Re: [PATCH 1/4] soundwire: sdw_slave: add new fields to track probe status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 11/9/19 5:12 AM, Vinod Koul wrote:
On 08-11-19, 08:55, Pierre-Louis Bossart wrote:


On 11/7/19 10:29 PM, Vinod Koul wrote:
On 04-11-19, 08:32, Pierre-Louis Bossart wrote:


On 11/2/19 11:56 PM, Vinod Koul wrote:
On 23-10-19, 16:06, Pierre-Louis Bossart wrote:
Changes to the sdw_slave structure needed to solve race conditions on
driver probe.

Can you please explain the race you have observed, it would be a very
useful to document it as well

the races are explained in the [PATCH 00/18] soundwire: code hardening and
suspend-resume support series.

It would make sense to explain it here as well to give details to
reviewers, there is nothing wrong with too much detail!


The functionality is added in the next patch.

which one..?

[PATCH 00/18] soundwire: code hardening and suspend-resume support

Yeah great! let me play detective with 18 patch series. I asked for a
patch and got a series!

Again, please help the maintainer to help you. We would love to see this
merged as well, but please step up and give more details in cover
letter and changelogs. I shouldn't need to do guesswork and scan through the
inbox to find the context!

We are clearly not going anywhere.

Correct as you don't seem to provide clear answers, I am asking again
which patch implements the new fields added here, how difficult is it to
provide the *specific* patch which implements this so that I can compare
the implementation and see why this is needed and apply if fine!

But no you will not provide a clear answer and start ranting!

I partitioned the patches to make your maintainer life easier and help the
integration of SoundWire across two trees. All I get is negative feedback,
grand-standing, and zero comments on actual changes.

No you get asked specific question which you do not like and start off
on a tangent!

For the record, I am mindful of reviewer/maintainer workload, and I did
contact you in September to check your availability and provided a pointer
to initial code changes. I did send a first version a week prior to your
travel/vacation, I resend another version when you were back and waited yet
another two weeks to resend a second version. I also contacted Takashi, Mark
and you to suggest this code partition, and did not get any pushback. It's
not like I am pushing stuff down your throat, I have been patient and
considerate.

Please start with the patches "soundwire: code hardening and suspend-resume
support" and come back to this interface description when you have reviewed
these changes. It's not detective work, it's working around the consequences
of having separate trees for Audio and SoundWire.

Again, which patch in the series does implement these new members!

It's really straightforward...here is the match between headers and functionality:

[PATCH v2 1/5] soundwire: sdw_slave: add new fields to track probe status
[PATCH v2 02/19] soundwire: fix race between driver probe and update_status callback

[PATCH v2 2/5] soundwire: add enumeration_complete structure
[PATCH v2 12/19] soundwire: add enumeration_complete signaling

[PATCH v2 3/5] soundwire: add initialization_complete definition
[PATCH v2 13/19] soundwire: bus: add initialization_complete signaling

[PATCH v2 4/5] soundwire: intel: update interfaces between ASoC and SoundWire [PATCH v2 5/5] soundwire: intel: update stream callbacks for hwparams/free stream operations
[PATCH v2 13/14] soundwire: intel: free all resources on hw_free()

I suggested an approach that you didn't comment on, and now I am not sure what to make of the heated wording and exclamation marks. You did not answer to Liam's question on links between ASoC/SoundWire - despite the fact that drivers/soundwire cannot be an isolated subsystem, both the Intel and Qualcomm solutions have a big fat 'depends on SND_SOC'.

At this point I am formally asking for your view and guidance on how we are going to do the SoundWire/ASoC integration. It's now your time to make suggestions on what the flow should be between you and Mark/Takashi. If you don't want this initial change to the header files, then what is your proposal?


_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux