From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sagar Dharia Subject: Re: [PATCH 1/3] SLIMbus: Device management on SLIMbus Date: Wed, 17 Jun 2015 11:10:09 -0600 Message-ID: <5581A9F1.6010301@codeaurora.org> References: <1434260958-13732-1-git-send-email-sdharia@codeaurora.org> <1434260958-13732-2-git-send-email-sdharia@codeaurora.org> <20150615105424.GJ18309@sirena.org.uk> <55803F37.9050809@codeaurora.org> <20150617114501.GB3214@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:43095 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754519AbbFQRKO (ORCPT ); Wed, 17 Jun 2015 13:10:14 -0400 In-Reply-To: <20150617114501.GB3214@sirena.org.uk> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Mark Brown Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, bp@suse.de, poeschel@lemonage.de, treding@nvidia.com, gong.chen@linux.intel.com, andreas.noever@gmail.com, alan@linux.intel.com, mathieu.poirier@linaro.org, daniel@ffwll.ch, oded.gabbay@amd.com, jkosina@suse.cz, sharon.dvir1@mail.huji.ac.il, joe@perches.com, davem@davemloft.net, james.hogan@imgtec.com, michael.opdenacker@free-electrons.com, daniel.thompson@linaro.org, nkaje@codeaurora.org, kheitke@audience.com, mlocke@codeaurora.org, agross@codeaurora.org, linux-arm-msm@vger.kernel.org On 6/17/2015 5:45 AM, Mark Brown wrote: > On Tue, Jun 16, 2015 at 09:22:31AM -0600, Sagar Dharia wrote: >> On 6/15/2015 4:54 AM, Mark Brown wrote: >>> On Sat, Jun 13, 2015 at 11:49:16PM -0600, Sagar Dharia wrote: >>>> +void slim_ctrl_add_boarddevs(struct slim_controller *ctrl) >>>> +{ >>> Why are these operations split? >> Some slaves may choose to do expensive operations in their probes (or wait >> for logical address assignment). That will delay/block controller >> registration and further HW initialization of the controller. >> I did not see any downside/side-effect in splitting them. I am open however >> to have them combined if that's the preferred way. > How does this resolve the issue? As far as I can see it just shuffles > it around so any delay happens later (and possibly not at a convenient > time), possibly not helping if there's multiple controllers. If devices > are doing excessively expensive things in their probe that seems like > something that we should fix in the drivers. For LA assignment > shouldn't we be addressing that by having a callback when the LA is > assigned? That will avoid single threading effects and is more like the > pattern for other buses. Slimbus isn't particularly unique in this > regard. I agree that using the 'device_up' callback (it's called when the device has LA assignment) will make sure slaves can keep their probes non-blocking. I was just trying to accommodate that blocking call by slaves and did not realize the downside you now mentioned about multiple-controllers I will combine these in next patchset. Thanks Sagar > > Greg, the LA assignment thing here is an example of the issue is an > example of the pattern I raised a while ago (but never got round to > coding up handling of) where we have devices on an enumerable bus with > static registrations. LA assignment is the end of the hotplug process > for a Slimbus device but most devices will need something doing to power > them up so they enumerate. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation