From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>,
linux-i3c@lists.infradead.org, Rob Herring <robh+dt@kernel.org>,
<devicetree@vger.kernel.org>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Rajeev Huralikoppi <rajeev.huralikoppi@silvaco.com>,
linux-kernel@vger.kernel.org,
Conor Culhane <conor.culhane@silvaco.com>,
Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [PATCH v2 3/4] i3c: master: svc: Add Silvaco I3C master driver
Date: Wed, 12 Aug 2020 17:18:02 +0200 [thread overview]
Message-ID: <20200812171802.295b08d8@xps13> (raw)
In-Reply-To: <20200812141312.3331-3-miquel.raynal@bootlin.com>
Hi Conor, Rajeev,
> +static int svc_i3c_master_handle_ibi(struct svc_i3c_master *master,
> + struct i3c_dev_desc *dev)
> +{
> + struct svc_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
> + struct i3c_ibi_slot *slot;
> + unsigned int count;
> + u32 mdatactrl;
> + int ret = 0;
> + u8 *buf;
> +
> + spin_lock(&master->ibi.lock);
> +
> + slot = i3c_generic_ibi_get_free_slot(data->ibi_pool);
> + if (!slot) {
> + ret = -ENOSPC;
> + goto unlock;
> + }
> +
> + slot->len = 0;
> + buf = slot->data;
> + while (readl(master->regs + SVC_I3C_MSTATUS) & SVC_I3C_MINT_RXPEND) {
> + mdatactrl = readl(master->regs + SVC_I3C_MDATACTRL);
> + count = SVC_I3C_MDATACTRL_RXCOUNT(mdatactrl);
> + readsl(master->regs + SVC_I3C_MRDATAB, buf, count);
After discussing with Boris, I have a question about the design: is
there a way to differentiate, from a software point of view, from the
data coming as "IBI" and "regular data"?
Let's say the master initiates a read.
The moment after, an IBI is triggered.
The hanlde_ibi() helper is called to read the IBI payload.
While the IBI interrupted the read operation, it also interrupted the
master dequeuing process of the bytes already in the FIFO. From a
software perspective, we might end up reading a "regular byte" from the
handle_ibi() helper expecting an "IBI byte".
Is there some kind of double queue feature which I missed? Or perhaps a
way to discriminate the origin of the data?
> + slot->len += count;
> + buf += count;
> + }
> +
> + i3c_master_queue_ibi(dev, slot);
> +
> +unlock:
> + spin_unlock(&master->ibi.lock);
> + svc_i3c_master_emit_stop(master);
> + svc_i3c_master_flush_fifo(master);
> +
> + return ret;
> +}
> +
> +static void svc_i3c_master_ack_ibi(struct svc_i3c_master *master,
> + bool mandatory_byte)
> +{
> + unsigned int ibi_ack_nack;
> +
> + ibi_ack_nack = SVC_I3C_MCTRL_REQUEST_IBI_ACKNACK;
> + if (mandatory_byte)
> + ibi_ack_nack |= SVC_I3C_MCTRL_IBIRESP_ACK_WITH_BYTE;
> + else
> + ibi_ack_nack |= SVC_I3C_MCTRL_IBIRESP_ACK_WITHOUT_BYTE;
> +
> + writel(ibi_ack_nack, master->regs + SVC_I3C_MCTRL);
> +}
> +
> +static void svc_i3c_master_nack_ibi(struct svc_i3c_master *master)
> +{
> + writel(SVC_I3C_MCTRL_REQUEST_IBI_ACKNACK |
> + SVC_I3C_MCTRL_IBIRESP_NACK,
> + master->regs + SVC_I3C_MCTRL);
> +}
> +
> +static irqreturn_t svc_i3c_master_irq_handler(int irq, void *dev_id)
> +{
> + struct svc_i3c_master *master = (struct svc_i3c_master *)dev_id;
> + u32 active = readl(master->regs + SVC_I3C_MINTMASKED);
> + u32 status = readl(master->regs + SVC_I3C_MSTATUS);
> + unsigned int ibitype = SVC_I3C_MSTATUS_IBITYPE(status);
> + unsigned int ibiaddr = SVC_I3C_MSTATUS_IBIADDR(status);
> + struct i3c_dev_desc *dev;
> + bool rdata;
> +
> + if (active & SVC_I3C_MINT_SLVSTART) {
> + writel(SVC_I3C_MINT_SLVSTART, master->regs + SVC_I3C_MSTATUS);
> + writel(SVC_I3C_MCTRL_REQUEST_AUTO_IBI |
> + SVC_I3C_MCTRL_IBIRESP_MANUAL,
> + master->regs + SVC_I3C_MCTRL);
> + return IRQ_HANDLED;
> + }
> +
> + if (!(active & SVC_I3C_MINT_IBIWON))
> + return IRQ_NONE;
> +
> + writel(SVC_I3C_MINT_IBIWON, master->regs + SVC_I3C_MSTATUS);
> +
> + switch (ibitype) {
> + case SVC_I3C_MSTATUS_IBITYPE_IBI:
> + dev = svc_i3c_master_dev_from_addr(master, ibiaddr);
> + if (WARN_ON(!dev)) {
> + svc_i3c_master_nack_ibi(master);
> + break;
> + }
> +
> + rdata = dev->info.bcr & I3C_BCR_IBI_PAYLOAD;
> + svc_i3c_master_ack_ibi(master, rdata);
> + if (rdata) {
> + svc_i3c_master_disable_interrupts(master);
> + return IRQ_WAKE_THREAD;
> + }
> +
> + break;
> + case SVC_I3C_MSTATUS_IBITYPE_MASTER_REQUEST:
> + svc_i3c_master_nack_ibi(master);
> + break;
> + case SVC_I3C_MSTATUS_IBITYPE_HOT_JOIN:
> + svc_i3c_master_ack_ibi(master, false);
> + queue_work(master->base.wq, &master->hj_work);
> + break;
> + default:
> + return IRQ_NONE;
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t svc_i3c_master_threaded_handler(int irq, void *dev_id)
> +{
> + struct svc_i3c_master *master = (struct svc_i3c_master *)dev_id;
> + u32 status = readl(master->regs + SVC_I3C_MSTATUS);
> + unsigned int ibiaddr = SVC_I3C_MSTATUS_IBIADDR(status);
> + struct i3c_dev_desc *dev;
> +
> + dev = svc_i3c_master_dev_from_addr(master, ibiaddr);
> + if (WARN_ON(!dev)) {
> + svc_i3c_master_emit_stop(master);
> + svc_i3c_master_flush_fifo(master);
> + return IRQ_HANDLED;
> + }
> +
> + svc_i3c_master_handle_ibi(master, dev);
> + svc_i3c_master_enable_interrupts(master,
> + SVC_I3C_MINT_SLVSTART |
> + SVC_I3C_MINT_IBIWON);
> +
> + return IRQ_HANDLED;
> +}
Thanks,
Miquèl
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2020-08-12 15:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 14:13 [PATCH v2 1/4] dt-bindings: Add vendor prefix for Silvaco Miquel Raynal
2020-08-12 14:13 ` [PATCH v2 2/4] dt-bindings: i3c: Describe Silvaco master binding Miquel Raynal
2020-08-24 23:24 ` Rob Herring
2020-08-12 14:13 ` [PATCH v2 3/4] i3c: master: svc: Add Silvaco I3C master driver Miquel Raynal
2020-08-12 15:18 ` Miquel Raynal [this message]
2020-08-19 9:04 ` Boris Brezillon
2020-12-28 16:04 ` Miquel Raynal
2020-08-12 14:13 ` [PATCH v2 4/4] MAINTAINERS: Add Silvaco I3C master Miquel Raynal
2020-08-12 15:07 ` Miquel Raynal
2020-08-24 23:21 ` [PATCH v2 1/4] dt-bindings: Add vendor prefix for Silvaco Rob Herring
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=20200812171802.295b08d8@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=boris.brezillon@collabora.com \
--cc=conor.culhane@silvaco.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=rajeev.huralikoppi@silvaco.com \
--cc=robh+dt@kernel.org \
--cc=thomas.petazzoni@bootlin.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).