From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A54A1B0406 for ; Tue, 28 Jan 2025 16:43:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738082614; cv=none; b=kI6fl1Ai+gIxDhRi6ZGmxluG+qWZ/PvBVXMOXgq4DGkqDabkp3X2pd4QL1jducdJuL6Lv1cU4cskjs3oGyc1xNOAEgrDmm+9SqK1sDNb4qpmh53tp6U/yjHHUnQ+F3G6+mMMg7oZQ8qBh+A/RDMqBgPwYd3oq9k8DEiZNL5Lzrk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738082614; c=relaxed/simple; bh=D64twa18YWTbFCeP+NDxcL/MlTZI7Ggll+Li/4x7fbo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=srbNKTxTiSrwjqtZWxP8LDoNGkeCQ8VuwO+jv0IXH+QAQd1A5OaTNiZkX34SY8VXi1TE5xi3MG5g8Ps5LEFsaIRcdLY3DUep1l710+fPcAKwYjWxPZZZFXEgv7z5/o8UGF+1kGQUZL2P2nFWT4dwPHoULvH7a0NTkYLBEUV9WQg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=l6ItAYV+; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="l6ItAYV+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738082612; x=1769618612; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=D64twa18YWTbFCeP+NDxcL/MlTZI7Ggll+Li/4x7fbo=; b=l6ItAYV+In7Ib9B8JBXUOK0xLzE9xzk4QXEeNOOlyX/ffhNG43zP2pz9 Slhkgnly3YSOSfyNOm/mMnHbmXC/QAUBKpctUfmznZIM8v+AztKqQBNHq opzlNKAV1J5XMHsG4IMsn2xf8SftTdo6GhbgWlp7OjexDKHku19oWwk+4 kPk9sn1ZmNphG3zdsk4otazgIjOTauV2F2uQFEBeedsiTtatWYwMjpp1G YwJfaRBua8/uqYblllmAKD3E8NBSEHb7gKIsDrwv6qCoI0fx5vhM6U2kL oJehpjLy/B/oR/MrRPxNqvbe4/X2CuyyoUIBBXwqG1IUYbT8xZdYZ4g22 Q==; X-CSE-ConnectionGUID: vlrO/d/JQf224PyuX0xNkA== X-CSE-MsgGUID: MtxFz86BT7OYPwmVm1F7xQ== X-IronPort-AV: E=McAfee;i="6700,10204,11329"; a="49163653" X-IronPort-AV: E=Sophos;i="6.13,241,1732608000"; d="scan'208";a="49163653" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jan 2025 08:43:32 -0800 X-CSE-ConnectionGUID: n4WohlxIS7GprOK67OL+9A== X-CSE-MsgGUID: GNEgHlFgS2G19cR74yvIDQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,241,1732608000"; d="scan'208";a="113784616" Received: from smile.fi.intel.com ([10.237.72.58]) by fmviesa004.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jan 2025 08:43:29 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1tcogQ-000000067pQ-3oqe; Tue, 28 Jan 2025 18:43:26 +0200 Date: Tue, 28 Jan 2025 18:43:26 +0200 From: Andy Shevchenko To: Marek Szyprowski Cc: Mark Brown , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Dmitry Baryshkov , DRI mailing list Subject: Re: [PATCH v3 1/1] regmap: Synchronize cache for the page selector Message-ID: References: <20250116124303.3941583-1-andriy.shevchenko@linux.intel.com> <8a7581e4-6422-4d77-8027-02df0d7da489@samsung.com> <42fe4488-0ff2-4b92-ae11-cce1664a7176@samsung.com> <6b4cba29-786c-4999-ac1d-27b3e4cea6f8@samsung.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6b4cba29-786c-4999-ac1d-27b3e4cea6f8@samsung.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Tue, Jan 28, 2025 at 05:08:08PM +0100, Marek Szyprowski wrote: > On 21.01.2025 14:29, Andy Shevchenko wrote: > > On Tue, Jan 21, 2025 at 08:33:09AM +0100, Marek Szyprowski wrote: > >> On 17.01.2025 18:28, Andy Shevchenko wrote: > >>> On Fri, Jan 17, 2025 at 05:05:42PM +0100, Marek Szyprowski wrote: > >>> > >>> Does it fail in the same way? > >> Yes, the hw revision is reported as zero in this case: LT9611 revision: > >> 0x00.00.00 > > Hmm... This is very interesting! It means that the page selector is a bit > > magical there. Dmitry, can you chime in and perhaps shed some light on this? > > > >>>> Does it mean that there is really a bug in the driver? > >>> Without looking at the datasheet it's hard to say. At least what I found so far > >>> is one page of the I²C traffic dump on Windows as an example how to use their > >>> evaluation board and software, but it doesn't unveil the bigger picture. At > >>> least what I think is going on here is that the programming is not so easy as > >>> just paging. Something is more complicated there. > >>> > >>> But at least (and as Mark said) the most of the regmap based drivers got > >>> the ranges wrong (so, at least there is one bug in the driver). > >> I can do more experiments if this helps. Do you need a dump of all > >> regmap accesses or i2c traffic from this driver? > > It would be helpful! Traces from the failed and non-failed cases > > till the firmware revision and chip ID reading would be enough to > > start with. > > I'm sorry for the delay, I was a bit busy with other stuff. No problem and thanks for sharing. > Here are logs (all values are in hex): > > next-20250128 (probe broken): > root@target:~# dmesg | grep regmap > [   14.817604] regmap_write reg 80ee <- 1 > [   14.823036] regmap_read reg 8100 -> 0 > [   14.827631] regmap_read reg 8101 -> 0 > [   14.832130] regmap_read reg 8102 -> 0 > next-20250128 + 1fd60ed1700c reverted (probe okay): > root@target:~# dmesg | grep regmap > [   13.565920] regmap_write reg 80ee <- 1 > [   13.567509] regmap_read reg 8100 -> 17 > [   13.568219] regmap_read reg 8101 -> 4 > [   13.568909] regmap_read reg 8102 -> 93 Something is missing here. Like we have an identical start and an immediate failure. If you did it via printk() approach, it's probably wrong as my patch uses internal regmap function. Most likely you need to enable trace events for regmap and collect those for let's say 2 seconds: echo 1 > ...trace events... modprobe ... sleep 2 echo 0 > ...trace events... and dump the buffer to a file. It might have though more than needed as some other devices might also use regmap at the same time. I don't remember if the trace events for regmap have a device instance name field which can be used as a filter. Alternatively you may also try to add a printk() into regmap core, but I don't think it's more practical than trace events. -- With Best Regards, Andy Shevchenko