From: Brad Campbell Subject: Re: Radeon regression fix Date: Fri, 30 Sep 2011 13:14:56 +0800 Message-ID: <4E855050.8080403@fnarfbargle.com> References: <4E847ED4.5090703@fnarfbargle.com> <4E848CDE.1020707@fnarfbargle.com> <4E850BE6.2050306@fnarfbargle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from fnarfbargle.com (unknown [93.93.131.224]) by gabe.freedesktop.org (Postfix) with ESMTP id DC3069F308 for ; Thu, 29 Sep 2011 22:15:08 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alex Deucher Cc: airlied@redhat.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 30/09/11 12:59, Alex Deucher wrote: > On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell >> Looking at it with a nights sleep, it's obvious the code path in >> aux_native_write is ok. Is this a bit cleaner than the last patch? > > Looks pretty good. I was thinking of something more like this (sorry > for the lack of a patch, I'm away from my source trees at the moment): > > while (1) { > ret = radeon_process_aux_ch(dig_connector->dp_i2c_bus, > msg, msg_bytes, recv, recv_bytes, delay,&ack); > > if (ret< 0) > return ret; > if ((ack& AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_ACK) > return ret; > else if ((ack& AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_DEFER) > udelay(400); > else if (ret == 0) > return -EPROTO; > else > return -EIO; > } Yep, that looks cleaner. My only thought was the pre-3.0 code had a limit to the number of retries. Was that for a specific reason or is it ok to attempt to retry indefinitely if we receive a DEFER ? > > Thanks for tracking this down. No worries. I learned quite a bit about some kernel internals and more than a few quirks about apple hardware while muddling around.