From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752725AbbC0NOd (ORCPT ); Fri, 27 Mar 2015 09:14:33 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:50849 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752214AbbC0NOb (ORCPT ); Fri, 27 Mar 2015 09:14:31 -0400 Message-ID: <551557B4.5000504@roeck-us.net> Date: Fri, 27 Mar 2015 06:14:28 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Wolfram Sang CC: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters References: <20150216120951.GA2840@katana> <20150317042049.GA6765@roeck-us.net> <20150318132707.GD3580@katana> <550A4162.8000009@roeck-us.net> <20150319081612.GA900@katana> <20150319174314.GA17329@roeck-us.net> <20150319213937.GA899@katana> <5512C213.7030705@roeck-us.net> <20150327080947.GA900@katana> <5515523F.9010609@roeck-us.net> <20150327130108.GA19151@katana> In-Reply-To: <20150327130108.GA19151@katana> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-CTCH-PVer: 0000001 X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: 0 X-CTCH-RefID: str=0001.0A020202.551557B6.01BF,ss=1,re=0.001,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-CTCH-Score: 0.001 X-CTCH-ScoreCust: 0.000 X-CTCH-Rules: C_4847, X-CTCH-SenderID: linux@roeck-us.net X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-TotalRecipients: 0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from get_relayhosts_entry X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/27/2015 06:01 AM, Wolfram Sang wrote: > On Fri, Mar 27, 2015 at 05:51:11AM -0700, Guenter Roeck wrote: >> On 03/27/2015 01:09 AM, Wolfram Sang wrote: >>> >>>> just to give you an update: I do have some code, but it is a bit messy, >>>> and it doesn't work well for ds2482 (the chip behind it still hangs up >>>> if I access it in parallel through i2c-dev). On top of that, it causes >>>> pretty significant slow-downs when accessing other devices on the same >>>> bus at the same time. Not surprising, I guess, since it expands the scope >>>> of the bus lock significantly. >>> >>> Just to get a better idea: Did you try taking the adapter_lock before >>> the two SMBus command which needed to be concatenated (and use >>> smbus_xfer directly)? >>> >> I did. I didn't use smbus_xfer directly, though, but introduced lockless >> versions of the various smbus commands, and kept using those. > > And then the chip still hangs? Or was that the performance penalty here? > Parallel access to a second eeprom chip on the same bus was much slower than before. Also, the new code did not solve the problem for ds2482 (completely unrelated to the at24 driver of course). Even with proper locking, the chip ended up hanging after some parallel accesses through i2c-dev. Granted, ds2482 is a difficult beast, but it is still annoying how access through i2c-dev can mess it up. The latter is what bothered me more: What is the point of all this if we still can not ensure correct operation ? Guenter