From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Anderson Subject: Re: [PATCH v8 09/10] drivers: qcom: rpmh: add support for batch RPMH request Date: Tue, 15 May 2018 08:52:47 -0700 Message-ID: References: <20180509170159.29682-1-ilina@codeaurora.org> <20180509170159.29682-10-ilina@codeaurora.org> <20180514195929.GA22950@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20180514195929.GA22950@codeaurora.org> Sender: linux-kernel-owner@vger.kernel.org To: Lina Iyer Cc: Andy Gross , David Brown , linux-arm-msm@vger.kernel.org, "open list:ARM/QUALCOMM SUPPORT" , Rajendra Nayak , Bjorn Andersson , LKML , Stephen Boyd , Evan Green , Matthias Kaehlcke , rplsssn@codeaurora.org List-Id: linux-arm-msm@vger.kernel.org Hi, On Mon, May 14, 2018 at 12:59 PM, Lina Iyer wrote: >>> /** >>> @@ -77,12 +82,14 @@ struct rpmh_request { >>> * @cache: the list of cached requests >>> * @lock: synchronize access to the controller data >>> * @dirty: was the cache updated since flush >>> + * @batch_cache: Cache sleep and wake requests sent as batch >>> */ >>> struct rpmh_ctrlr { >>> struct rsc_drv *drv; >>> struct list_head cache; >>> spinlock_t lock; >>> bool dirty; >>> + const struct rpmh_request *batch_cache[RPMH_MAX_BATCH_CACHE]; >> >> >> I'm pretty confused about why the "batch_cache" is separate from the >> normal cache. As far as I can tell the purpose of the two is the same >> but you have two totally separate code paths and data structures. >> > Due to a hardware limitation, requests made by bus drivers must be set > up in the sleep and wake TCS first before setting up the requests from > other drivers. Bus drivers use batch mode for any and all RPMH > communication. Hence their request are the only ones in the batch_cache. This is totally not obvious and not commented. Why not rename to "priority" instead of "batch"? If the only requirement is that these come first, that's still no reason to use totally separate code paths and mechanisms. These requests can still use the same data structures / functions and just be ordered to come first, can't they? ...or given a boolean "priority" and you can do two passes through your queue: one to do the priority ones and one to do the secondary ones. >>> + spin_unlock_irqrestore(&ctrlr->lock, flags); >>> + >>> + return ret; >>> +} >> >> >> As part of my overall confusion about why the batch cache is different >> than the normal one: for the normal use case you still call >> rpmh_rsc_write_ctrl_data() for things you put in your cache, but you >> don't for the batch cache. I still haven't totally figured out what >> rpmh_rsc_write_ctrl_data() does, but it seems strange that you don't >> do it for the batch cache but you do for the other one. >> >> > flush_batch does write to the controller using > rpmh_rsc_write_ctrl_data() My confusion is that they happen at different times. As I understand it: * For the normal case, you immediately calls rpmh_rsc_write_ctrl_data() and then later do the rest of the work. * For the batch case, you call both later. Is there a good reason for this, or is it just an arbitrary difference? If there's a good reason, it should be documented. -Doug