[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5ef9a07-73df-c2b6-3e03-001f53700c5b@linux.intel.com>
Date: Mon, 1 Feb 2021 10:29:44 -0600
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Vinod Koul <vkoul@...nel.org>,
Bard Liao <yung-chuan.liao@...ux.intel.com>
Cc: alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
gregkh@...uxfoundation.org, jank@...ence.com,
srinivas.kandagatla@...aro.org, rander.wang@...ux.intel.com,
ranjani.sridharan@...ux.intel.com, hui.wang@...onical.com,
sanyog.r.kale@...el.com, bard.liao@...el.com
Subject: Re: [PATCH 3/3] soundwire: bus: clear parity interrupt before the
mask is enabled
>> * Set SCP_INT1_MASK register, typically bus clash and
>> diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c
>> index f7ba1a77a1df..c1fdc85d0a74 100644
>> --- a/drivers/soundwire/intel.c
>> +++ b/drivers/soundwire/intel.c
>> @@ -1286,7 +1286,8 @@ static int sdw_master_read_intel_prop(struct sdw_bus *bus)
>> if (quirk_mask & SDW_INTEL_QUIRK_MASK_BUS_DISABLE)
>> prop->hw_disabled = true;
>>
>> - prop->quirks = SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH;
>> + prop->quirks = SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH |
>> + SDW_MASTER_QUIRKS_CLEAR_INITIAL_PARITY;
>
> move this to intel patch please..
>
>>
>> return 0;
>> }
>> diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
>> index a2766c3b603d..30415354d419 100644
>> --- a/include/linux/soundwire/sdw.h
>> +++ b/include/linux/soundwire/sdw.h
>> @@ -426,6 +426,7 @@ struct sdw_master_prop {
>> };
>>
>> #define SDW_MASTER_QUIRKS_CLEAR_INITIAL_CLASH BIT(0)
>> +#define SDW_MASTER_QUIRKS_CLEAR_INITIAL_PARITY BIT(1)
>
> Why not add this quirk in patch 1..?
There is an element of history here. We first found out about the bus
clash on multiple devices and dealt with a specific bug number. Then we
spend weeks on the parity issue on a new platform and ultimately showed
we needed a similar work-around.
All these problems are not typical from a user perspective; they appear
when loading/unloading modules in loops, at some point it seems some
hardware devices don't always reset properly or there's something
problematic in power delivery.
I don't think it's an issue if we refactor the code to add the quirks
first, and add the intel.c patches later. We probably want 2 intel
changes to keep the references to the bugs though and the detailed
explanations.
> Also add comments about each quirk, hopefully it wont be a big table
Sounds fine.
Powered by blists - more mailing lists