Message-ID: <74042758-0c28-227b-1362-ed410c74d115@amd.com>
Date:   Wed, 15 Feb 2023 03:48:28 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: [PATCH V2 5/8] soundwire: amd: add soundwire manager interrupt
 handling
Content-Language: en-US
To:     Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
        vkoul@kernel.org
Cc:     amadeuszx.slawinski@linux.intel.com, Mario.Limonciello@amd.com,
        Sunil-kumar.Dommati@amd.com, Basavaraj.Hiregoudar@amd.com,
        Mastan.Katragadda@amd.com, Arungopal.kondaveeti@amd.com,
        Bard Liao <yung-chuan.liao@linux.intel.com>,
        Sanyog Kale <sanyog.r.kale@intel.com>,
        "moderated list:SOUNDWIRE SUBSYSTEM" <alsa-devel@alsa-project.org>,
        open list <linux-kernel@vger.kernel.org>
References: <20230213094031.2231058-1-Vijendar.Mukunda@amd.com>
 <20230213094031.2231058-6-Vijendar.Mukunda@amd.com>
 <9505941e-73a1-249b-08c2-83b86e7ef5c6@linux.intel.com>
 <2fc1191d-e57d-4b76-1c9c-088e33f2ad45@amd.com>
 <f739053c-d19b-f773-cead-77abad53feec@amd.com>
 <b632ba86-767f-2813-ad2d-4a3424e6b02e@linux.intel.com>
From:   "Mukunda,Vijendar" <vijendar.mukunda@amd.com>
In-Reply-To: <b632ba86-767f-2813-ad2d-4a3424e6b02e@linux.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NDBEeGRNM09xM3duZFlMSnl1UFIxVTFOVCtFZFFzdkMrTzk1YzJVbWs4QUdZ?=
 =?utf-8?B?ZjR1Q3UvdXNxcVNGSy9YSTJhN09VTnVDbFg2Y3FtaTF1UmtpNzNGby9jU2wy?=
 =?utf-8?B?NmtsQTVRaWhHWFU5ZGdZZitBVm1BYUpNUmloNW8rSUJUU0NxQkYxNitZN0h6?=
 =?utf-8?B?dGhNTjh2T2I2aUpXOEM0NWlBUU1MbFN0UytHQlQzQklHdStmbGZyWDd2VmJn?=
 =?utf-8?B?SjFRdGdjdDRWWEh4Vld1L0hIZWc5TW5sc09xTHBacThiWW9zenJRcDdUbVFm?=
 =?utf-8?B?WEQzVldjQ1llakFnZ2Jrd292MHp5M0NCaUVSNndQNmxrM0J6ZUw0WDgyYXE3?=
 =?utf-8?B?YVU0emJmUHFsUGxtQSt5WEdGK0VyTUN0aEFibk9kYkhXSkJhSlg2LzlVeFJ6?=
 =?utf-8?B?MGJCMkMrdnBTU2JiakxvTWFpYXJyWEVJNDdnV1V6cVk1bDU5NDRobHVDWUQv?=
 =?utf-8?B?ZEFwaXF3emFLaWdta2lwUE1hVEVpOWhyUm5oUzQ2SlFESGtBS3c0c0FkR2J4?=
 =?utf-8?B?OTBwWUNKVmNXeW9zMjBVa0tTdDNXa2V4ZEpleGVOVFFxT3JrcDFTK1VvbVh4?=
 =?utf-8?B?Z04xcDRnUEVqQS9WRGVhN3VsRndjS3JDREVmRHpSbXVDVCtja1hDL1NUY3Bh?=
 =?utf-8?B?WEIwNWxoZUoxTFI0U1p3R3hQZnpSTUkyNVI3SFVYU0tMLzhvRG41K3hOc3RO?=
 =?utf-8?B?bHNUN0syOHN6V1UvQkUvSmV1VzFnNCtlZlo5ejVuSkN1aCtaNWYyaG9WK3Ir?=
 =?utf-8?B?SGI5cjhGeHVEQVAvNHNtRnB5cjdTaHJKT3ZxcVQ1Y3dJZk5NRkZYT251bHZI?=
 =?utf-8?B?UXlNZWY2cEJiZThTQkdSYnBxc2lSWkVYc09WaWtPVjN5eTU2dVlEemRIb3lD?=
 =?utf-8?B?Um1YVXJOMHJieUMzVTdDN2p0R1hKQWFFUm5QVWkvbTVTSW5Vc1VxN1JVOXBL?=
 =?utf-8?B?UUxablpEQ3NiOFJ3VUxKTVhsUG1Wd0lHa2JnZjQ0WjFRb1diUDc1L2NUeW40?=
 =?utf-8?B?T3NQMUFMc2o2V1NxaElMT2F0YjM1Rmx0bExmZm0xalZBOWFaRlBpK0JLRlB5?=
 =?utf-8?B?VVBEZUJDMjR1QS91SGVPdW5nM2xnV1J0L3pyeWJLVmhHVUpMajFTT08raTNj?=
 =?utf-8?B?WGp1Y3l3MnEwOWlRS005Zy96NU9ERUs5RE80SlpDUzhwaTlsY25qZGkrODMr?=
 =?utf-8?B?aVdpbmVEYmUxVG5ZZ3d1Z2JZVERMeXJJR3Q0TUs2NUFkNnhKbWdjdE9yQ3NG?=
 =?utf-8?B?ZW1VdDRUR2xNZTNpci9LOFRPTlhHWW4yb1lON2hGVDNhNDJseVdRY0M4NXdM?=
 =?utf-8?B?d3JnM2ZTUGtRZGd2L205cjJiREh4dzVrYXA4RzVRdU1IYXA5aXFMRm9FWEtB?=
 =?utf-8?B?b1BQaVRCSGMwL2ljeSt2L2g2ajk1SGZaa3JoWlU0MVRrMjJGamY2YkZsUFdl?=
 =?utf-8?B?SWRDandhTll3VEplbGdWbFVuWXpKaGFZMStFRDRxTjgxNFJNdFMzeTRsMUd4?=
 =?utf-8?B?WnV0bVluQjBhbDBVaWtGNHhwbVpiN2ZiUTZad3hiYno2aEFJdFVUTGkvc3Ji?=
 =?utf-8?B?MXhwQ01uYXBMVFBqd0FFOGJ5amloR1l0Mysva0dubU5WeFBHdW9wdmRtT1I3?=
 =?utf-8?B?eFpXQ2k3dGN0YXJ0Vk9jZG1QQVoycE1qakh1UHdxSm9lNVlmVUdwTVBzSVVi?=
 =?utf-8?B?Rzl4dVFpK0czWVpIalhsOHFVMERxaFB3WXEvL0ZVYi9POEpEbjBvQjlJTFVi?=
 =?utf-8?B?SjRDdE1GVmdqVGh5dFZFYlc4Smx3eEkrRXYzOWxUVENtc05tRVpFL0Q1Ylhp?=
 =?utf-8?B?S0pDRCtURmFMWGIyRWNjdGZ3dXUyQk5NeE5hUm1tTzlVYUFmSWdpOTJkVkpl?=
 =?utf-8?B?MTB1WEhwMWo3TUw2S2xPdTJHUGZKbCttWmhZQmZrNlArZUdwaVl5dy9zR3VF?=
 =?utf-8?B?N1RYdzNiaEpnc1g4ZU8yU1FGQVBDQkprMUNYT2pmM3ZGdURsMGlHcncwczNv?=
 =?utf-8?B?MEYwSDZaQmx0aExNYlFYbVhoOGZjTWQ0cU82NEFMYkFYenBCcTU1T0Y4dTZz?=
 =?utf-8?B?MDZuUnQxcU5remVOSC9TSGNDUVZwRW1zdmhSOXN6TldTWm93RURocHEwemNQ?=
 =?utf-8?Q?bIlnu0iiMX/1A1AYLZhA/9qK2?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d7fb3de-e778-4633-fed5-08db0ed8feba
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB4123.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2023 22:15:35.6355
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: c5FQeAcaApk+TwaUvBH6SisRtHn2F6azTvsCi7WGhqcL9418E7viTDMB38aWUYsrBO1yJER+KM5PvsO0rWqrGA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR12MB5164
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 14/02/23 18:58, Pierre-Louis Bossart wrote:
>>>>> +update_status:
>>>>> +	sdw_handle_slave_status(&amd_manager->bus, amd_manager->status);
>>>>> +	if (amd_manager->status[0] == SDW_SLAVE_ATTACHED) {
>>>>> +		if (retry_count++ < SDW_MAX_DEVICES) {
>>>>> +			acp_reg_writel(AMD_SDW_IRQ_MASK_0TO7, amd_manager->mmio +
>>>>> +				       ACP_SW_STATE_CHANGE_STATUS_MASK_0TO7);
>>>>> +			acp_reg_writel(AMD_SDW_IRQ_MASK_8TO11,
>>>>> +				       amd_manager->mmio + ACP_SW_STATE_CHANGE_STATUS_MASK_8TO11);
>>>>> +			amd_sdw_read_and_process_ping_status(amd_manager);
>>>>> +			goto update_status;
>>>>> +		} else {
>>>>> +			dev_err_ratelimited(amd_manager->dev,
>>>>> +					    "Device0 detected after %d iterations\n",
>>>>> +					    retry_count);
>>>>> +		}
>>>>> +	}
>>>> this seems rather inspired by the Cadence code, but is there really a
>>>> case where you need to re-check for devices? In the Cadence case, this
>>>> was added because we have a logical OR and new devices would not be handled.
>>> As mentioned in V1 set, we have corner cases during enumeration sequence.
>>> We observed device alerts are missing during peripheral enumeration sequence
>>> when multiple peripheral devices are connected over the same link.
>>> This is not inspired by Intel code.
>>>
>>> As per V1 version review comment, we have included retry_count logic to address
>>> faulty case.
>>>
>>> We forgot to include comment. we will fix it.
>> Slight correction in the explanation.
>>
>> During the peripheral enumeration sequence, the soundwire peripheral interrupts
>> are masked.
>> If soundwire interrupts are not masked, it will cause side effects when multiple
>> peripheral devices connected over the same link.
>> As interrupts are masked, during device slot programming for each peripheral,
>> soundwire manager driver won't receive any interrupts.
>>
>> Once the device number programming is done for all peripherals, the soundwire
>> interrupts will be unmasked. Read the peripheral device status from ping command
>> and process the response, which will invoke the peripheral device initialization sequence.
>> This sequence will ensure all peripheral devices enumerated and initialized
>> properly.
> Humm, the explanation is difficult to follow, it's not clear on which
> side the interrupts are masked. Are you talking about the peripheral
> being prevented from generating interrupts, or about the manager not
> detecting peripheral state changes with an interrupt-based mechanism?
>
> I am not sure what 'side effects' can happen, during enumeration all
> devices show up as device0 and the SoundWire bus provides a mechanism to
> enumerate without conflicts.
I am talking about manager side detecting peripheral state changes
with interrupt-based mechanism.
We are referring to the scenario where multiple peripheral devices are
connected over the same link.
Till peripheral devices enumeration gets completed, we are masking
manager side interrupts, and later we are unmasking the manager side
interrupts.