From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73D6EC7EE23 for ; Fri, 26 May 2023 06:21:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235137AbjEZGVN (ORCPT ); Fri, 26 May 2023 02:21:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231495AbjEZGVM (ORCPT ); Fri, 26 May 2023 02:21:12 -0400 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1C01813D for ; Thu, 25 May 2023 23:21:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 42DAB8107; Fri, 26 May 2023 06:21:10 +0000 (UTC) Date: Fri, 26 May 2023 09:21:09 +0300 From: Tony Lindgren To: "H. Nikolaus Schaller" Cc: =?utf-8?B?UMOpdGVy?= Ujfalusi , linux-omap@vger.kernel.org, Letux-kernel@openphoenux.org Subject: Re: OMAP4/5 AESS on v6.4 Message-ID: <20230526062109.GC14287@atomide.com> References: <20230525045340.GA14287@atomide.com> <85922330-D19F-474A-9F23-F12CCAC68491@goldelico.com> <20230526050917.GB14287@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230526050917.GB14287@atomide.com> Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org * Tony Lindgren [230526 05:09]: > * H. Nikolaus Schaller [230525 08:34]: > > > Am 25.05.2023 um 06:53 schrieb Tony Lindgren : > > > You could also check some driver registers for > > > context lost status in the driver as the context lost registers are outside > > > the driver IO range. And after that, using reset framework for context lost > > > status could be done, maybe by adding support to drivers/soc/ti/omap_prm.c. > > > > Ok. I'll look into that. > > So reset_control_status() could maybe return -EIO error if context was lost. > Or maybe something like reset_control_context_lost() could be implemented. > Needs to be discussed on the related mailing lists of course. Then omap_prm.c > just needs the context lost registers mapped, and consumer drivers can check > context lost status from the reset framework. Oh looking at the dts files, we're not passing the register offset to the prm reset controller instance. So the binding #reset-cells = <2> would be needed where the first one is reset controller offset and second one is the bit in the context register. Seems doable though if we want to make reset framework support hardware triggered reset status. Regards, Tony