From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ezequiel Garcia Subject: Re: [PATCH] drm: Change link order to load modules first Date: Fri, 27 Jun 2014 10:54:37 -0300 Message-ID: <20140627135437.GA4736@arch.cereza> References: <1403486076-1397-1-git-send-email-ezequiel@vanguardiasur.com.ar> <20140623145809.GC16725@ulmo> <20140623152909.GA16870@arch.cereza> <20140627051438.GA9258@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) by gabe.freedesktop.org (Postfix) with ESMTP id AEC226E75F for ; Fri, 27 Jun 2014 06:55:25 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id 9so2859189ykp.40 for ; Fri, 27 Jun 2014 06:55:25 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140627051438.GA9258@ulmo> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 27 Jun 07:14 AM, Thierry Reding wrote: > On Mon, Jun 23, 2014 at 12:29:09PM -0300, Ezequiel Garcia wrote: > > > > > > No. We don't need to change the link order. > > > > Could you clarify why? I guess you have some case in mind where changing > > the link order breaks things or makes something mis-behave. > > I said we don't need to change the link order because there is a better > mechanism in the kernel to handle this type of situation. Saying "we > need to change" makes it sound like there's a bug that needs to be fixed > by changing the link order. That's not so. If link order breaks some > drivers then its those drivers that are broken. > Ah, OK. I understand your point now. On a second read, my commit log isn't too clear explaining why I want to change the order. > > > What we need to do is make > > > sure that modules deal properly with situations where their resources > > > aren't available yet (i.e. EPROBE_DEFER). There are factors other than > > > link order that influence probe ordering. > > > > > > > While I understand defering is more robust, it would be systematically > > defering the probe when the DRM driver needs an I2C encoder. > > > > Just to name one example, the tilcdc, armada and others requiring TDA998x > > encoder will always defered the probe of the DRM, and then re-probe() once > > the encoder is ready. > > > > So, unless we have a good reason not to do this, it sounds a bit silly > > to me. > > The problem that I have with working around this issue by changing the > link order is that it hides bugs in drivers. It's not like probe > deferral is a very expensive operation, so I very much prefer this as a > way of forcing drivers to be fixed rather than optimizing for a few > microseconds of boot time. > That's true. However, in this particular case, I'm not worried about the extra microseconds wasted in the defered operation, but about the unneeded delay introduced in the DRM probe. I know that relying in some particular order is very fragile, but I don't agree with knowingly and even explicitly have a sub-optimal order of the drivers. Or maybe it's just that I dislike deferals a lot. Anyway, thanks for feedback. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar