Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1314934pxu; Sat, 12 Dec 2020 08:42:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJxbeObkMJs63uBzsp8uQPTmI2y+kaMXa/mg80toG7RO+2Krw2ETLNuizxO9k6Q2x0iqTzM8 X-Received: by 2002:aa7:dc5a:: with SMTP id g26mr17370008edu.35.1607791370755; Sat, 12 Dec 2020 08:42:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607791370; cv=none; d=google.com; s=arc-20160816; b=P/4fZma0+SsWZDb48gGnElQhwU9ZV/wX7jbDP3g+MGiIDizjBabQTeWvvjcaXp2za7 jecLDwies/lxM9V4Oww51gqlqfIRvwmaoro/U9WI86353G4S5khkHnf3ay0aXyyipwr+ 1LtN+kVWbqr6MdctlpkXN3vL7S2//bErDybNOHciFZ2CWas4EXCPaXbTYeCvYBSjAmGO EraDjvCxTIMS2tWos+nkNgUZInMxZrGCWTJnz3zYxnoReEWNVgoHF1G8LGo0eG02ooxU +B/OHcpOYueDtnWFfiMWR+8gxRLAdZm3kT8vSIofM8qencl+CzesjyATGHMjS/fyXfWo 5D4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=4bksxVXyraVeH/vaukciGlNCembplpca28pml2zwvZo=; b=hxCf9GmvIFLEZaupl4wMEhrDRsvSKVOjflQKHFdC5LMUmOID1NQlLnIu7Eb8H/5NPn 8hTY8AyacLgEB6AiSLakGQsF0EoJUx2Kosvo7iZ9TYfN+4XOaO/L1MbLcYKzDdXHtCXH iR3QJ/sVTeeaS6BFeYmHvIBJexDG9uAJ+KhKJigY5aFGz1KOLBkQyBWvRRFkvrzni17U VPD+hDwzdqYdzOtmNVuUT/jeb7Iry2AW1gZ+rfRA6X4V37Af0q8mv9lOYmb18sLKI09c R8++hTX5Ac5W/G/+v6iL7X/UyrAMWAhRD5Tr3tQ+XQScsVuqz0/rHajFInNFQ+yYXVP/ t+zQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@platinasystems-com.20150623.gappssmtp.com header.s=20150623 header.b=fOEanG0S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id nt21si6508372ejb.739.2020.12.12.08.42.28; Sat, 12 Dec 2020 08:42:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@platinasystems-com.20150623.gappssmtp.com header.s=20150623 header.b=fOEanG0S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395321AbgLKR6e (ORCPT + 99 others); Fri, 11 Dec 2020 12:58:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392619AbgLKR6N (ORCPT ); Fri, 11 Dec 2020 12:58:13 -0500 Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF73CC0613CF for ; Fri, 11 Dec 2020 09:57:32 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id x4so5234853vsp.7 for ; Fri, 11 Dec 2020 09:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=platinasystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4bksxVXyraVeH/vaukciGlNCembplpca28pml2zwvZo=; b=fOEanG0Sqt1amxqrOs795KMLdoMfZhTniz2AFwOzAmU1PZIPBxfG+oOrFOtGmEmUtx SaUeF47rGnO0/gITECyEVdU7oLXOvUBu/Xyk03x+VsNeSvI/6GclCYg29MPUFjHhVfao Mq72T0F3ZbIHN5NUBNxNQwDKA/ZQ64+8ENJd90SHNDE4l2UPhbur5HIWCFqkhOwQ7EZR ApkpWfd8GQiLl+mIxMyFhYNjMk9mIGDydvOttxtqA7DpARxHGplGCwjSTLFRwS6JVe97 HBlWJ6IbZz9QxF9FRRQy8nfXP6PMIHMuZFxHh9XGmQ9ZQmq0cs8VVu1dklOwvrKiyqe8 Z6ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4bksxVXyraVeH/vaukciGlNCembplpca28pml2zwvZo=; b=umMcmxqJsFH7e6Bj0YmLTQDjAJ+ZLdu3VNv3rR3jjn4V67EzO5D+9cZcfzy9QfsB24 RfNnDvk0kff7Jl5kRypFLxzs65dSmZQYc0GkurKikEZWQW9IHLlb5ussQFpBYoFoNbNB +MpI8L+BBjQAHA7WHNAlhU1dC2LgW5eARaZ7NBIsMpLbOQCBfgZiOY4rYvyt4nhLKNia fvKImYqPv2h0509wUD5YGQWtY8Ww8711cKWrZDgDzZSZ7Sg3KurZ+wVXddAnm6cRRkz2 rAVO/DKYoGicrz0JRkl0Kf6+KuH+PJgt89Bryg/vnQoWszVWCMNfFKv19s7GgkTbHuIQ KqLQ== X-Gm-Message-State: AOAM533I+O63pBy6j5uDznAK8BVUUEAeOptJiL1IYsnyNRUTU8/K5S3x hR2lHiOiB27sJaV9UY/GQAt0wtqrTUEVoTpzukxL5g== X-Received: by 2002:a05:6102:66a:: with SMTP id z10mr14819634vsf.53.1607709451615; Fri, 11 Dec 2020 09:57:31 -0800 (PST) MIME-Version: 1.0 References: <20201111113255.28710-1-biwen.li@oss.nxp.com> <20201202151033.GC874@kunai> <20201209170948.GA2249@kunai> In-Reply-To: From: Kevin Herbert Date: Fri, 11 Dec 2020 09:57:19 -0800 Message-ID: Subject: Re: [EXT] Re: [v10] i2c: imx: support slave mode for imx I2C driver To: Biwen Li Cc: Wolfram Sang , "Biwen Li (OSS)" , Leo Li , "linux@rempel-privat.de" , "kernel@pengutronix.de" , "shawnguo@kernel.org" , "s.hauer@pengutronix.de" , "festevam@gmail.com" , Aisheng Dong , Clark Wang , "o.rempel@pengutronix.de" , "linux-i2c@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Jiafei Pan , Xiaobo Xie , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for the tip. I attempted to see if the register was implemented on the i.mx6, and it doesn't appear to be. I'll reach out to my FAE. I found the datasheet and the register definitely isn't documented there. I was thinking of a patch that would keep track of state, and synthesize the I2C_SLAVE_STOP on the next interrupt if it was a new transaction. Does this seem too hacky to you? What are your thoughts? Thanks, Kevin Thanks, Kevin On Wed, Dec 9, 2020 at 6:16 PM Biwen Li wrote: > > Hi Kevin, > > > > After enabling idle interrupts, the i2c register will generate an idle in= terrupts(whatever read or write) when i2c bus enter idle status. Then get I= 2C_SLAVE_STOP event. > > But don=E2=80=99t have the IBIC register(Maybe it=E2=80=99s a hidden regi= ster) in imx. You can query about the AE of imx about this. > > static void i2c_imx_enable_bus_idle(struct imx_i2c_struct *i2c_imx) > > { > > if (is_vf610_i2c(i2c_imx)) { > > unsigned int temp; > > > > temp =3D imx_i2c_read_reg(i2c_imx, IMX_I2C_IBIC); > > temp |=3D IBIC_BIIE; > > imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_IBIC); > > } > > } > > > > Best Regards, > > Biwen Li > > From: Kevin Herbert > Sent: 2020=E5=B9=B412=E6=9C=8810=E6=97=A5 1:18 > To: Wolfram Sang ; Kevin Herbert ; Biwen Li (OSS) ; Leo Li ; li= nux@rempel-privat.de; kernel@pengutronix.de; shawnguo@kernel.org; s.hauer@p= engutronix.de; festevam@gmail.com; Aisheng Dong ; Cla= rk Wang ; o.rempel@pengutronix.de; linux-i2c@vger.ke= rnel.org; linux-kernel@vger.kernel.org; Jiafei Pan ; Xi= aobo Xie ; linux-arm-kernel@lists.infradead.org; Biwen = Li > Subject: [EXT] Re: [v10] i2c: imx: support slave mode for imx I2C driver > > > > Caution: EXT Email > > Even on an operation like writing a byte, I get I2C_SLAVE_WRITE_REQUESTED= followed by I2C_SLAVE_WRITE_RECEIVED, but no I2C_SLAVE_STOP. If I do a I2C= write of multiple bytes, I get I2c_SLAVE_WRITE_REQUESTED followed by multi= ple I2C_SLAVE_WRITE_RECEIVED. > > > > Kevin > > > > On Wed, Dec 9, 2020 at 9:10 AM Wolfram Sang wrote: > > On Wed, Dec 09, 2020 at 09:03:50AM -0800, Kevin Herbert wrote: > > What is the protocol for the I2C_SLAVE_STOP event? I am working on my o= wn > > backend, and I've only tried it with this i.mx driver, and I do not rec= eive > > I2C_SLAVE_STOP at the end of every I2C transaction. It was my expectati= on > > I'd receive this event at the end of every frame. In my testing, I've n= ever > > received this event at all. > > > > Where are the I2C registers on the i.mx documented? My board is an i.mx= 6sx. > > Hmm, from a glimpse, it looks the STOP event is only sent after a write > and not after a read? Does this match your findings?