From: Mark Brown <broonie@kernel.org>
To: Sagar Dharia <sdharia@codeaurora.org>
Cc: gregkh@linuxfoundation.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, linux-kernel@vger.kernel.org,
nkaje@codeaurora.org, kheitke@audience.com,
mlocke@codeaurora.org, agross@codeaurora.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH V2 4/6] slim: qcom: Add Qualcomm Slimbus controller driver
Date: Wed, 17 Jun 2015 14:53:13 +0100 [thread overview]
Message-ID: <20150617135313.GH3214@sirena.org.uk> (raw)
In-Reply-To: <1434505564-14333-5-git-send-email-sdharia@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 5972 bytes --]
On Tue, Jun 16, 2015 at 07:46:02PM -0600, Sagar Dharia wrote:
> + - dmaengine, and pipes used to communicate between controller and memory if
> + sps-BAM HW is used
This needs more detail.
> + */
> + mb();
> + if (notify_rx)
> + complete(&dev->rx_msgq_notify);
> + }
> + return IRQ_HANDLED;
This interrupt handler unconditionally returns IRQ_HANDLED regardless of
if that's true or not.
> +static void msm_slim_wait_retry(struct msm_slim_ctrl *dev)
> +{
> + int msec_per_frm = 0;
> + int sfr_per_sec;
> +
> + /* Wait for 1 superframe, or default time and then retry */
> + sfr_per_sec = dev->framer.superfreq /
> + (1 << (SLIM_MAX_CLK_GEAR - dev->ctrl.clkgear));
> + if (sfr_per_sec)
> + msec_per_frm = MSEC_PER_SEC / sfr_per_sec;
> + if (msec_per_frm < DEF_RETRY_MS)
> + msec_per_frm = DEF_RETRY_MS;
> + msleep(msec_per_frm);
> +}
Is this device specific?
> +static void msm_slim_cb(void *ctx, int err)
> +{
> + if (err)
> + pr_err("MSM-slim completion reported err:%d\n", err);
dev_err()?
> + else if (ctx)
> + complete(ctx);
> +}
That's weird, if we get an error we don't signal whatever's waiting -
won't it just time out at best then? Also, what happens if we get
neither an error nor context?
> + if (txn->msg->wbuf)
> + memcpy(puc, txn->msg->wbuf, txn->msg->num_bytes);
> + msm_slim_queue_tx(dev, pbuf, txn->rl, MGR_TX_MSG);
> + timeout = wait_for_completion_timeout(&done,
> + msecs_to_jiffies(txn->rl + 100));
> +
> + if (!timeout)
> + dev_err(dev->dev, "TX timed out:MC:0x%x,mt:0x%x\n", txn->mc,
> + txn->mt);
> +
> + mutex_unlock(&dev->txn_lock);
> + return timeout ? 0 : -ETIMEDOUT;
> +}
Shouldn't we provide a route for error reports here (and might some of
this timeout stuff go into the core)?
> +
> + if ((msm_slim_put_rx(dev, (u8 *)buf)) != -ENODATA) {
> + len = buf[0] & 0x1F;
> + mt = (buf[0] >> 5) & 0x7;
> + mc = buf[1];
> + if (mt == SLIM_MSG_MT_CORE &&
> + mc == SLIM_MSG_MC_REPORT_PRESENT) {
Looks like a switch statement.
> +static int msm_slim_rx_msgq_thread(void *data)
> +{
> + struct msm_slim_ctrl *dev = (struct msm_slim_ctrl *)data;
> + struct completion *notify = &dev->rx_msgq_notify;
> + int ret;
> +
> + while (!kthread_should_stop()) {
> + set_current_state(TASK_INTERRUPTIBLE);
> + ret = wait_for_completion_interruptible(notify);
> +
> + if (ret)
> + dev_err(dev->dev, "rx thread wait error:%d\n", ret);
> + else
> + msm_slim_rxwq(dev);
> + }
> +
> + return 0;
> +}
It's not entirely clear to me why this is a kthread rather than a
workqueue or something. I'm also unclear what happens if more than one
piece of work is queued prior to msm_slim_rxwq() running, it looks like
it only handles a single operation.
> + /* SLEW RATE register for this slimbus */
> + dev->slew_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "slimbus_slew_reg");
> + if (!dev->slew_mem) {
> + dev_err(&pdev->dev, "no slimbus slew resource\n");
> + return;
> + }
Warning not an error isn't it?
> + hclk = clk_get(&pdev->dev, "iface_clk");
> + if (IS_ERR(hclk))
> + return PTR_ERR(hclk);
devm_clk_get()
> + ret = clk_set_rate(rclk, SLIM_ROOT_FREQ);
You're ignoring this error in spite of assigning to ret.
> + slim_mem = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "slimbus_physical");
> + if (!slim_mem) {
> + dev_err(&pdev->dev, "no slimbus physical memory resource\n");
> + ret = ENODEV;
> + goto err_get_mem_failed;
> + }
> + slim_io = request_mem_region(slim_mem->start, resource_size(slim_mem),
> + pdev->name);
> + if (!slim_io) {
> + dev_err(&pdev->dev, "slimbus memory already claimed\n");
> + ret = EBUSY;
> + goto err_get_mem_failed;
> + }
devm_ioremap_resource() and a lot of this starts looking simpler.
> + dev = kzalloc(sizeof(struct msm_slim_ctrl), GFP_KERNEL);
devm_kzalloc()
> + if (pdev->dev.of_node) {
> +
> + ret = of_property_read_u32(pdev->dev.of_node, "cell-index",
> + &dev->ctrl.nr);
Was that in the binding?
> + /* Register with framework before enabling frame, clock */
> + ret = slim_add_numbered_controller(&dev->ctrl);
> + if (ret) {
> + dev_err(dev->dev, "error adding controller\n");
> + goto err_ctrl_failed;
> + }
This is suspicious - why are you adding a numbered controller with DT?
And looking at this interface why is it a separate call to add a
numbered controller, why not just register the controller using the same
API and handle any number that was set when doing that?
> + dev->ver = readl_relaxed(dev->base);
> + /* Version info in 16 MSbits */
> + dev->ver >>= 16;
> + /* Component register initialization */
> + writel_relaxed(1, dev->base + CFG_PORT(COMP_CFG, dev->ver));
> + writel_relaxed((EE_MGR_RSC_GRP | EE_NGD_2 | EE_NGD_1),
> + dev->base + CFG_PORT(COMP_TRUST_CFG, dev->ver));
You've registered the device with the core prior to initialising the
hardware - I'd expect this means the generic code will start trying to
register slaves immediately. The normal pattern would be to initialise
the hardware then register it.
> +#ifdef CONFIG_PM_SLEEP
> +static int msm_slim_suspend(struct device *dev)
> +{
> + return 0;
> +}
> +
> +static int msm_slim_resume(struct device *dev)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_PM_SLEEP */
Omit empty functions.
> +static int msm_slim_init(void)
> +{
> + return platform_driver_register(&msm_slim_driver);
> +}
> +module_init(msm_slim_init);
module_platform_driver().
> +u8 *msm_slim_get_tx(struct msm_slim_ctrl *dev, struct msm_wr_cb *cur)
> +{
> + unsigned long flags;
> + int idx;
> +
> + spin_lock_irqsave(&dev->tx.lock, flags);
> + if (((dev->tx.head + 1) % MSM_TX_MSGS) == dev->tx.tail) {
> + spin_unlock_irqrestore(&dev->tx.lock, flags);
> + return NULL;
> + }
> + idx = dev->tx.tail;
> + dev->tx.tail = (dev->tx.tail + 1) % MSM_TX_MSGS;
> + spin_unlock_irqrestore(&dev->tx.lock, flags);
> + dev->pending_wr[idx] = cur;
> + return dev->tx.base + (idx * SLIM_MSGQ_BUF_LEN);
> +}
Would just using a regular list hurt?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-06-17 13:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 1:45 [PATCH V2 0/6] Introduce framework for SLIMbus device drivers Sagar Dharia
2015-06-17 1:45 ` [PATCH V2 1/6] SLIMbus: Device management on SLIMbus Sagar Dharia
2015-06-17 3:38 ` Joe Perches
2015-06-17 13:16 ` Mark Brown
2015-06-17 17:36 ` Sagar Dharia
2015-06-18 21:39 ` Srinivas Kandagatla
2015-06-19 8:22 ` Daniel Thompson
2015-06-17 1:46 ` [PATCH V2 2/6] of/slimbus: OF helper for SLIMbus Sagar Dharia
2015-06-17 13:09 ` Mark Brown
2015-06-17 17:01 ` Sagar Dharia
2015-06-17 1:46 ` [PATCH V2 3/6] slimbus: Add messaging APIs to slimbus framework Sagar Dharia
2015-06-17 1:46 ` [PATCH V2 4/6] slim: qcom: Add Qualcomm Slimbus controller driver Sagar Dharia
2015-06-17 13:53 ` Mark Brown [this message]
2015-06-28 19:13 ` Sagar Dharia
2015-06-17 1:46 ` [PATCH V2 5/6] slimbus: Add support for 'clock-pause' feature Sagar Dharia
2015-06-17 1:46 ` [PATCH V2 6/6] slim: qcom: Add runtime-pm support using clock-pause feature Sagar Dharia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150617135313.GH3214@sirena.org.uk \
--to=broonie@kernel.org \
--cc=agross@codeaurora.org \
--cc=alan@linux.intel.com \
--cc=andreas.noever@gmail.com \
--cc=bp@suse.de \
--cc=daniel.thompson@linaro.org \
--cc=daniel@ffwll.ch \
--cc=davem@davemloft.net \
--cc=gong.chen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=james.hogan@imgtec.com \
--cc=jkosina@suse.cz \
--cc=joe@perches.com \
--cc=kheitke@audience.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=michael.opdenacker@free-electrons.com \
--cc=mlocke@codeaurora.org \
--cc=nkaje@codeaurora.org \
--cc=oded.gabbay@amd.com \
--cc=poeschel@lemonage.de \
--cc=sdharia@codeaurora.org \
--cc=sharon.dvir1@mail.huji.ac.il \
--cc=treding@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).