* Re: [PATCH] ARM: dts: armada-{370,xp}: drop "marvell,orion-spi" from SPI controllers
From: Uwe Kleine-König @ 2016-12-07 15:41 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87eg1jhi4l.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello Gregory,
On Wed, Dec 07, 2016 at 04:30:02PM +0100, Gregory CLEMENT wrote:
> On mer., déc. 07 2016, Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org> wrote:
>
> > From: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >
> > The SPI controllers on Armada 370 and XP differ from the original Orion
> > SPI controllers (at least) in the configuration of the baud rate. So
> > it's wrong to claim compatibility which results in bogus baud rates.
>
> Until two years ago with the commits
> df59fa7f4bca9658b75f0f5fee225b3a057475c5 and
> 4dacccfac69494ba70248b134352f299171c41b7
> we used "marvell,orion-spi" compatible on Armada XP and Armada 370
> without any problem.
>
> The new compatible "marvell,armada-xp-spi" and "marvell,armada-xp-spi"
> allows to have more choice for the baudrate for a given clock but it is
> not true that Armada 370 and Armada XP are not compatible with
> "marvell,orion-spi".
The issue I was faced with that made me create this patch is that in
barebox no special case for 370/XP was active. The result was that a
device that could be operated at 60 MHz only got a clock of 11 MHz and
the driver assumed it configured 41.666 MHz. I didn't check if the same
can happen in the opposite direction (or if there are other important
incompatibilities) but still I'd say this is a bug with my patch being
the obvious fix.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] crypto: brcm: DT documentation for Broadcom SPU driver
From: Rob (William) Rice @ 2016-12-07 15:46 UTC (permalink / raw)
To: Mark Rutland
Cc: Herbert Xu, David S. Miller, Rob Herring, linux-crypto,
devicetree, linux-kernel, Ray Jui, Scott Branden, Jon Mason,
bcm-kernel-feedback-list, Catalin Marinas, Will Deacon,
linux-arm-kernel, Steve Lin
In-Reply-To: <20161206140607.GB24177@leverpostej>
Mark,
Thanks for your comments. Replies below.
Rob
On 12/6/2016 9:06 AM, Mark Rutland wrote:
> On Wed, Nov 30, 2016 at 03:07:31PM -0500, Rob Rice wrote:
>> Device tree documentation for Broadcom Secure Processing Unit
>> (SPU) crypto driver.
>>
>> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
>> Signed-off-by: Rob Rice <rob.rice@broadcom.com>
>> ---
>> .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 ++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>> new file mode 100644
>> index 0000000..e5fe942
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>> @@ -0,0 +1,25 @@
>> +The Broadcom Secure Processing Unit (SPU) driver supports symmetric
>> +cryptographic offload for Broadcom SoCs with SPU hardware. A SoC may have
>> +multiple SPU hardware blocks.
> Bindings shound describe *hardware*, not *drivers*. Please drop mention
> of the driver, and just decribe the hardware.
Makes sense. I'll change it.
>
>> +Required properties:
>> +- compatible : Should be "brcm,spum-crypto" for devices with SPU-M hardware
>> + (e.g., Northstar2) or "brcm,spum-nsp-crypto" for the Northstar Plus variant
>> + of the SPU-M hardware.
>> +
>> +- reg: Should contain SPU registers location and length.
>> +- mboxes: A list of mailbox channels to be used by the kernel driver. Mailbox
>> +channels correspond to DMA rings on the device.
>> +
>> +Example:
>> + spu-crypto@612d0000 {
>> + compatible = "brcm,spum-crypto";
>> + reg = <0 0x612d0000 0 0x900>, /* SPU 0 control regs */
>> + <0 0x612f0000 0 0x900>, /* SPU 1 control regs */
>> + <0 0x61310000 0 0x900>, /* SPU 2 control regs */
>> + <0 0x61330000 0 0x900>; /* SPU 3 control regs */
> The above didn't mention there were several register sets, and the
> comment beside each makes them sound like they're separate SPU
> instances, so I don't think it makes sense to group them as one node.
>
> What's going on here?
That's right. For the SoC I used as the example, there are four SPU
hardware blocks. The driver round robins crypto requests to the hardware
blocks to handle requests in parallel and increase throughput. I want
one instance of the SPU driver that registers algos once with the crypto
API and manages all the mailbox channels. Maybe I can achieve that with
separate device tree entries for each SPU block, I'm not sure. I'll look
into it.
>
>> + mboxes = <&pdc0 0>,
>> + <&pdc1 0>,
>> + <&pdc2 0>,
>> + <&pdc3 0>;
> Does each mbox correspond to one of the SPUs above? Or is there a shared
> pool?
Yes, each of these mailbox channels corresponds to a different SPU. PDC
is a DMA ring manager for DMAs to the SPUs.
>
> Thanks,
> Mark.
^ permalink raw reply
* Re: [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Laurent Pinchart @ 2016-12-07 15:47 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil, Sakari Ailus,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sekhar Nori,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m237i1gfz1.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Kevin,
On Tuesday 06 Dec 2016 08:49:38 Kevin Hilman wrote:
> Laurent Pinchart writes:
> > On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote:
> >> Video capture subdevs may be over I2C and may sleep during xfer, so we
> >> cannot do IRQ-disabled locking when calling the subdev.
> >>
> >> Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >> ---
> >> drivers/media/platform/davinci/vpif_capture.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> >> b/drivers/media/platform/davinci/vpif_capture.c index
> >> 5104cc0ee40e..9f8f41c0f251 100644
> >> --- a/drivers/media/platform/davinci/vpif_capture.c
> >> +++ b/drivers/media/platform/davinci/vpif_capture.c
> >> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue
> >> *vq, unsigned int count)
> >> }
> >> }
> >>
> >> + spin_unlock_irqrestore(&common->irqlock, flags);
> >> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
> >> + spin_lock_irqsave(&common->irqlock, flags);
> >
> > I always get anxious when I see a spinlock being released randomly with an
> > operation in the middle of a protected section. Looking at the code it
> > looks like the spinlock is abused here. irqlock should only protect the
> > dma_queue and should thus only be taken around the following code:
> >
> > spin_lock_irqsave(&common->irqlock, flags);
> > /* Get the next frame from the buffer queue */
> > common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
> > struct vpif_cap_buffer, list);
> >
> > /* Remove buffer from the buffer queue */
> > list_del(&common->cur_frm->list);
> > spin_unlock_irqrestore(&common->irqlock, flags);
>
> Yes, that looks correct. Will update.
>
> > The code that is currently protected by the lock in the start and stop
> > streaming functions should be protected by a mutex instead.
>
> I tried taking the mutex here, but lockdep pointed out a deadlock. I
> may not be fully understanding the V4L2 internals here, but it seems
> that the ioctl is already taking a mutex, so taking it again in
> start/stop streaming is a deadlock. Unless you think the locking should
> be nested here, it seems to me that the mutex isn't needed.
The V4L2 core can lock all ioctls using struct video_device::lock. For buffer-
related ioctls, it can optionally use a separate lock from struct
vb2_queue::lock. See v4l2_ioctl_get_lock() in drivers/media/v4l2-core/v4l2-
ioctl.c.
The vpif-capture driver sets both the video_device and vb2_queue locks to the
same lock (which would have the same effect as leaving the vb2_queue lock
NULL). All ioctls are thus serialized. You would only need to handle locking
in start_streaming and stop_streaming manually if you didn't rely on the core
serializing the ioctls.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver
From: Rob (William) Rice @ 2016-12-07 15:49 UTC (permalink / raw)
To: Mark Rutland
Cc: Herbert Xu, David S. Miller, Rob Herring, linux-crypto,
devicetree, linux-kernel, Ray Jui, Scott Branden, Jon Mason,
bcm-kernel-feedback-list, Catalin Marinas, Will Deacon,
linux-arm-kernel, Steve Lin
In-Reply-To: <20161206141826.GC24177@leverpostej>
Mark,
Thanks for the comments. Replies below.
Rob
On 12/6/2016 9:18 AM, Mark Rutland wrote:
> On Wed, Nov 30, 2016 at 03:07:32PM -0500, Rob Rice wrote:
>> +static const struct of_device_id bcm_spu_dt_ids[] = {
>> + {
>> + .compatible = "brcm,spum-crypto",
>> + .data = &spum_ns2_types,
>> + },
>> + {
>> + .compatible = "brcm,spum-nsp-crypto",
>> + .data = &spum_nsp_types,
>> + },
>> + {
>> + .compatible = "brcm,spu2-crypto",
>> + .data = &spu2_types,
>> + },
>> + {
>> + .compatible = "brcm,spu2-v2-crypto",
>> + .data = &spu2_v2_types,
>> + },
> These last two weren't in the binding document.
yes, I'll add them.
>
>> + { /* sentinel */ }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, bcm_spu_dt_ids);
>> +
>> +static int spu_dt_read(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct spu_hw *spu = &iproc_priv.spu;
>> + struct device_node *dn = pdev->dev.of_node;
>> + struct resource *spu_ctrl_regs;
>> + const struct of_device_id *match;
>> + struct spu_type_subtype *matched_spu_type;
>> + void __iomem *spu_reg_vbase[MAX_SPUS];
>> + int i;
>> + int err;
>> +
>> + if (!of_device_is_available(dn)) {
>> + dev_crit(dev, "SPU device not available");
>> + return -ENODEV;
>> + }
> How can this happen?
You are correct. This is unnecessary. I will remove.
>
>> + /* Count number of mailbox channels */
>> + spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
>> + dev_dbg(dev, "Device has %d SPU channels", spu->num_chan);
>> +
>> + match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
>> + matched_spu_type = (struct spu_type_subtype *)match->data;
> This cast usn't necessary.
Ok, will remove.
>
>> + spu->spu_type = matched_spu_type->type;
>> + spu->spu_subtype = matched_spu_type->subtype;
>> +
>> + /* Read registers and count number of SPUs */
>> + i = 0;
>> + while ((i < MAX_SPUS) && ((spu_ctrl_regs =
>> + platform_get_resource(pdev, IORESOURCE_MEM, i)) != NULL)) {
>> + dev_dbg(dev,
>> + "SPU %d control register region res.start = %#x, res.end = %#x",
>> + i,
>> + (unsigned int)spu_ctrl_regs->start,
>> + (unsigned int)spu_ctrl_regs->end);
>> +
>> + spu_reg_vbase[i] = devm_ioremap_resource(dev, spu_ctrl_regs);
>> + if (IS_ERR(spu_reg_vbase[i])) {
>> + err = PTR_ERR(spu_reg_vbase[i]);
>> + dev_err(&pdev->dev, "Failed to map registers: %d\n",
>> + err);
>> + spu_reg_vbase[i] = NULL;
>> + return err;
>> + }
>> + i++;
>> + }
> These *really* sound like independent devices. There are no shared
> registers, and each has its own mbox.
>
> Why do we group them like this?
As I said in the previous email, I want one instance of the driver to
register crypto algos once with the crypto API and to distribute crypto
requests among all available SPU hw blocks.
>
> Thanks,
> Mark.
^ permalink raw reply
* Re: [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Kevin Hilman @ 2016-12-07 16:06 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil, Sakari Ailus,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sekhar Nori,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4999781.kd7ueUSsQd@avalon>
Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> writes:
> Hi Kevin,
>
> On Tuesday 06 Dec 2016 08:49:38 Kevin Hilman wrote:
>> Laurent Pinchart writes:
>> > On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote:
>> >> Video capture subdevs may be over I2C and may sleep during xfer, so we
>> >> cannot do IRQ-disabled locking when calling the subdev.
>> >>
>> >> Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> >> ---
>> >> drivers/media/platform/davinci/vpif_capture.c | 3 +++
>> >> 1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c
>> >> b/drivers/media/platform/davinci/vpif_capture.c index
>> >> 5104cc0ee40e..9f8f41c0f251 100644
>> >> --- a/drivers/media/platform/davinci/vpif_capture.c
>> >> +++ b/drivers/media/platform/davinci/vpif_capture.c
>> >> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue
>> >> *vq, unsigned int count)
>> >> }
>> >> }
>> >>
>> >> + spin_unlock_irqrestore(&common->irqlock, flags);
>> >> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
>> >> + spin_lock_irqsave(&common->irqlock, flags);
>> >
>> > I always get anxious when I see a spinlock being released randomly with an
>> > operation in the middle of a protected section. Looking at the code it
>> > looks like the spinlock is abused here. irqlock should only protect the
>> > dma_queue and should thus only be taken around the following code:
>> >
>> > spin_lock_irqsave(&common->irqlock, flags);
>> > /* Get the next frame from the buffer queue */
>> > common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
>> > struct vpif_cap_buffer, list);
>> >
>> > /* Remove buffer from the buffer queue */
>> > list_del(&common->cur_frm->list);
>> > spin_unlock_irqrestore(&common->irqlock, flags);
>>
>> Yes, that looks correct. Will update.
>>
>> > The code that is currently protected by the lock in the start and stop
>> > streaming functions should be protected by a mutex instead.
>>
>> I tried taking the mutex here, but lockdep pointed out a deadlock. I
>> may not be fully understanding the V4L2 internals here, but it seems
>> that the ioctl is already taking a mutex, so taking it again in
>> start/stop streaming is a deadlock. Unless you think the locking should
>> be nested here, it seems to me that the mutex isn't needed.
>
> The V4L2 core can lock all ioctls using struct video_device::lock. For buffer-
> related ioctls, it can optionally use a separate lock from struct
> vb2_queue::lock. See v4l2_ioctl_get_lock() in drivers/media/v4l2-core/v4l2-
> ioctl.c.
>
> The vpif-capture driver sets both the video_device and vb2_queue locks to the
> same lock (which would have the same effect as leaving the vb2_queue lock
> NULL). All ioctls are thus serialized. You would only need to handle locking
> in start_streaming and stop_streaming manually if you didn't rely on the core
> serializing the ioctls.
OK, thanks for clarifying how that works.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 00/13] net: ethernet: ti: cpts: update and fixes
From: David Miller @ 2016-12-07 16:14 UTC (permalink / raw)
To: grygorii.strashko
Cc: netdev, mugunthanvnm, richardcochran, nsekhar, linux-kernel,
linux-omap, devicetree, m-karicheri2, w-kwok2, tglx
In-Reply-To: <20161207000045.28333-1-grygorii.strashko@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Tue, 6 Dec 2016 18:00:32 -0600
> It is preparation series intended to clean up and optimize TI CPTS driver to
> facilitate further integration with other TI's SoCs like Keystone 2.
...
Series applied.
^ permalink raw reply
* Re: [PATCH v3 2/5] spi: armada-3700: Add support for the FIFO mode
From: Romain Perier @ 2016-12-07 16:19 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20161205133728.sza2pt4tfkywu35k-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hello,
Le 05/12/2016 à 14:37, Mark Brown a écrit :
> On Thu, Dec 01, 2016 at 11:27:16AM +0100, Romain Perier wrote:
>
>> Changes in v3:
>> - Don't enable the fifo mode based on the compatible string, we introduce
>> a module parameter "pio_mode". By default this option is set to zero, so
>> the fifo mode is enabled. Pass pio_mode=1 to the driver enables the PIO
>> mode.
>
> Why? If the hardware supports a more efficient mode of operation it
> doesn't seem sensible not to use it.
That's just that our customer want to keep both modes, this is why I
decided to use the more efficient mode by default and disable it via a
module parameter. Previously the more efficient mode was always enabled,
based on the "compatible string" of the DT (the PIO mode was simply
useless in this case and dead code)
>
>> - int i;
>> + int i, ret = 0;
>
> Coding style - don't combine initialized and non-initalized variables on
> one line.
Ok
>
>> static int a3700_spi_transfer_one(struct spi_master *master,
>> struct spi_device *spi,
>> struct spi_transfer *xfer)
>> {
>> struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
>> - int ret = 0;
>> + int ret;
>>
>> a3700_spi_transfer_setup(spi, xfer);
>>
>> @@ -505,6 +737,151 @@ static int a3700_spi_transfer_one(struct spi_master *master,
>> return ret;
>> }
>
> This appears to be a random unrelated change, should probably be part of
> the initial driver commit.
Good catch
>
>> +static int a3700_spi_fifo_transfer_one(struct spi_master *master,
>> + struct spi_device *spi,
>> + struct spi_transfer *xfer)
>> +{
>> + struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
>> + int ret = 0, timeout = A3700_SPI_TIMEOUT;
>> + unsigned int nbits = 0;
>> + u32 val;
>> +
>> + a3700_spi_transfer_setup(spi, xfer);
>> +
>> + a3700_spi->tx_buf = xfer->tx_buf;
>> + a3700_spi->rx_buf = xfer->rx_buf;
>> + a3700_spi->buf_len = xfer->len;
>> +
>> + /* SPI transfer headers */
>> + a3700_spi_header_set(a3700_spi);
>> +
>> + if (xfer->tx_buf)
>> + nbits = xfer->tx_nbits;
>> + else if (xfer->rx_buf)
>> + nbits = xfer->rx_nbits;
>> +
>> + a3700_spi_pin_mode_set(a3700_spi, nbits);
>> +
>> + if (xfer->rx_buf) {
>> + /* Set read data length */
>> + spireg_write(a3700_spi, A3700_SPI_IF_DIN_CNT_REG,
>> + a3700_spi->buf_len);
>> + /* Start READ transfer */
>> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
>> + val &= ~A3700_SPI_RW_EN;
>> + val |= A3700_SPI_XFER_START;
>> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
>> + } else if (xfer->tx_buf) {
>> + /* Start Write transfer */
>
> So this only supports single duplex transfers but there doesn't seem to
> be anything that enforces this.
>
A flag or a capability, typically? I will investigate
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] i2c: rk3x: keep i2c irq ON in suspend
From: Grygorii Strashko @ 2016-12-07 16:27 UTC (permalink / raw)
To: David.Wu, Doug Anderson
Cc: Heiko Stuebner, Wolfram Sang,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list:ARM/Rockchip SoC...,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <a6694d7d-6fca-e5ef-7bbd-9956562132a2-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On 12/06/2016 09:37 PM, David.Wu wrote:
> Hi Doug,
>
> 在 2016/12/7 0:31, Doug Anderson 写道:
>> Hi,
>>
>> On Tue, Dec 6, 2016 at 12:12 AM, David.Wu <david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> wrote:
>>> Hi Heiko,
>>>
>>> 在 2016/12/5 18:54, Heiko Stuebner 写道:
>>>>
>>>> Hi David,
>>>>
>>>> Am Montag, 5. Dezember 2016, 16:02:59 CET schrieb David Wu:
>>>>>
>>>>> During suspend there may still be some i2c access happening.
>>>>> And if we don't keep i2c irq ON, there may be i2c access timeout if
>>>>> i2c is in irq mode of operation.
>>>>
>>>>
>>>> can you describe the issue you're trying to fix a bit more please?
>>>
>>>
>>> Sometimes we could see the i2c timeout errors during suspend/resume,
>>> which
>>> makes the duration of suspend/resume too longer.
>>>
>>> [ 484.171541] CPU4: Booted secondary processor [410fd082]
>>> [ 485.172777] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>>> [ 486.172760] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>>> [ 487.172759] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>>> [ 487.172840] cpu cpu4: _set_opp_voltage: failed to set voltage (800000
>>> 800000 800000 mV): -110
>>> [ 487.172874] cpu cpu4: failed to set volt 800000
>>>
>>>>
>>>> I.e. I'd think the i2c-core does suspend i2c-client devices first,
>>>> so that
>>>> these should be able to finish up their ongoing transfers and not start
>>>> any
>>>> new ones instead?
>>>>
>>>> Your irq can still happen slightly after the system started going to
>>>> actually
>>>> sleep, so to me it looks like you just widened the window where irqs
>>>> can
>>>> be
>>>> handled. Especially as your irq could also just simply stem from the
>>>> start
>>>> state, so you cannot even be sure if your transaction actually is
>>>> finished.
>>>
>>>
>>> Okay, you are right. I want to give it a double insurance at first,
>>> but it
>>> may hide the unhappend issue.
>>>
>>>>
>>>> So to me it looks like the i2c-connected device driver should be fixed
>>>> instead?
>>>
>>>
>>> I tell them to fix it in rk808 driver.
>>
>> To me it seems like perhaps cpufreq should not be changing frequencies
>> until it is resumed properly. Presumably if all the ordering is done
>> right then cpufreq should be resumed _after_ the i2c regulator so you
>> should be OK. ...or am I somehow confused about that?
>
> yes，the cpufreq and regulator should start i2c job after they resume
> properly.
>
>>
>> Also note that previous i2c busses I worked with simply returned -EIO
>> in the case where they were called when suspended. See
>> "i2c-exynos5.c" and "i2c-s3c2410.c".
>
> In "i2c-exynos5.c", it seems that using the "i2c->suspended" to protect
> i2c transfer works most of the time. Of course it could prevent the next
> new i2c transfer to start. But in one case, if the current i2c job was
> not finished until the i2c irq was disabled by system suspend, the i2c
> timeout error would also happen, as the current i2c job may have a large
> data to transfer and it lasts from a long time.
And this means you have bug in some of I2C client drivers which do not stop
their activities during suspend properly (most usual case - driver uses work
and this work still active during suspend and can run on one CPU while suspend
runs on another).
At the moment .suspend_noirq() callback is called there should be no active
I2C transactions in general.
>
> So is it necessary to add a mutex lock to wait the current job to be
> finished before the "i2c->suspended" is changed in i2c_suspend_noirq()?
>
You need to catch and fix all driver who will try to access I2C after your
I2C bus driver passes suspend_noirq stage. Smth, like [1], uses i2c_lock_adapter().
[1] https://git.ti.com/android-sdk/kernel-omap/commit/125ef8f7016e7b205886f93862288a45a312b1d8
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/5] spi: armada-3700: Add support for the FIFO mode
From: Mark Brown @ 2016-12-07 16:34 UTC (permalink / raw)
To: Romain Perier
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <a9b86043-b631-8154-edc8-5abe49e47114-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
On Wed, Dec 07, 2016 at 05:19:57PM +0100, Romain Perier wrote:
> Le 05/12/2016 à 14:37, Mark Brown a écrit :
> > Why? If the hardware supports a more efficient mode of operation it
> > doesn't seem sensible not to use it.
> That's just that our customer want to keep both modes, this is why I decided
> to use the more efficient mode by default and disable it via a module
> parameter. Previously the more efficient mode was always enabled, based on
> the "compatible string" of the DT (the PIO mode was simply useless in this
> case and dead code)
Keep that out of tree, if the user wants to do silly things then let
them pay the cost.
> > > + if (xfer->rx_buf) {
> > > + /* Set read data length */
> > > + spireg_write(a3700_spi, A3700_SPI_IF_DIN_CNT_REG,
> > > + a3700_spi->buf_len);
> > > + /* Start READ transfer */
> > > + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> > > + val &= ~A3700_SPI_RW_EN;
> > > + val |= A3700_SPI_XFER_START;
> > > + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> > > + } else if (xfer->tx_buf) {
> > > + /* Start Write transfer */
> > So this only supports single duplex transfers but there doesn't seem to
> > be anything that enforces this.
> A flag or a capability, typically? I will investigate
SPI_MASTER_HALF_DUPLEX.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2] dsa:mv88e6xxx: dispose irq mapping for chip->irq
From: Volodymyr Bendiuga @ 2016-12-07 16:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
volodymyr.bendiuga-Re5JQEeQqe8AvxtiuMwx3w, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161207141144.GJ18817-g2DYL2Zd6BY@public.gmane.org>
Yes, most of the users of of_irq_get() do not use irq_dispose_mapping().
But some of them do (some irq chips), and I believe the correct way of
doing this is to
dispose irq mapping, as the description for this function says that it
unmaps
the irq, which is mapped by of_irq_parse_and_map(). Not disposing irq
might not make
any affect on most drivers, but some, that get EPROBE_DEFER error do
need to dispose.
This is what I get when I run the code.
of_irq_put() could be implemented, and it would be a wrapper for
irq_dispose_mapping()
as I can see it. Should I do it this way?
On 2016-12-07 15:11, Andrew Lunn wrote:
> On Wed, Dec 07, 2016 at 11:35:07AM +0100, Volodymyr Bendiuga wrote:
>> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga-qeDNsGSBLoYwFerOooGFRg@public.gmane.org>
> You need some text in the Change log. Say why this change is needed,
> etc.
>
> Looking through other users of of_irq_get(), i don't see any disposing
> of the mapping. It is not obvious you need to do this. The name does
> not give any hint.
>
> Maybe we should add an of_irq_put() which would clean up the mapping?
>
> Andrew
>
>
>> ---
>> drivers/net/dsa/mv88e6xxx/chip.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>> index 173ea97..0c3271d 100644
>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
>> @@ -4483,7 +4483,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
>> mutex_unlock(&chip->reg_lock);
>>
>> if (err)
>> - goto out;
>> + goto out_dispose;
>>
>> if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_G2_INT)) {
>> err = mv88e6xxx_g2_irq_setup(chip);
>> @@ -4513,6 +4513,9 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
>> mv88e6xxx_g1_irq_free(chip);
>> mutex_unlock(&chip->reg_lock);
>> }
>> +
>> +out_dispose:
>> + irq_dispose_mapping(chip->irq);
>> out:
>> return err;
>> }
>> @@ -4530,6 +4533,7 @@ static void mv88e6xxx_remove(struct mdio_device *mdiodev)
>> if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_G2_INT))
>> mv88e6xxx_g2_irq_free(chip);
>> mv88e6xxx_g1_irq_free(chip);
>> + irq_dispose_mapping(chip->irq);
>> }
>> }
>>
>> --
>> 2.7.4
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru
From: Heiko Stuebner @ 2016-12-07 16:48 UTC (permalink / raw)
To: Brian Norris
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Doug Anderson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Chris Zhong, Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Caesar Wang
In-Reply-To: <1480645653-36943-9-git-send-email-briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Hi Brian,
Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
> We need to add regulators to the CPU nodes, so cpufreq doesn't think it
> can crank up the clock speed without changing the voltage. However, we
> don't yet have the DT bindings to fully describe the Over Voltage
> Protection (OVP) circuits on these boards. Without that description, we
> might end up changing the voltage too much, too fast.
>
> Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
> them disabled.
>
> Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
is there a specific reason for keeping this change separate?
While it is nice for documentation reasons, as it stands now the previous
patch introduces a regression (cpufreq trying to scale without regulators) and
immediately fixes it here.
So if you're ok with it, I'd like to merge this one back into the previous
patch when applying.
Heiko
^ permalink raw reply
* [PATCH v2 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters
From: Anurup M @ 2016-12-07 16:50 UTC (permalink / raw)
To: robh+dt, gregkh, catalin.marinas, arnd, geert+renesas, davem,
akpm, corbet, mark.rutland, will.deacon
Cc: linux-kernel, devicetree, linux-arm-kernel, anurup.m,
zhangshaokun, tanxiaojun, xuwei5, sanil.kumar, john.garry,
gabriele.paoloni, shiju.jose, wangkefeng.wang, linuxarm, shyju.pv,
anurupvasu
From: John Garry <john.garry@huawei.com>
Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters.
The Hisilicon SoC HiP0x series has many uncore or non-CPU performance
events and counters units.
This patch series is implemented refering to arm-cci, Intel/AMD uncore and
also the cavium thunderX and xgene uncore pmu patches.
This v2 version has addressed the review comments of v1 version.
Support for Hisilicon L3 cache(L3C) and Misclennaneous nodes(MN) hardware
events and counters are added in this implementation.
The Hisilicon uncore PMUs can be found under /sys/bus/event_source/devices.
The counters are exported via sysfs in the corresponding events files
under the PMU directory so the perf tool can list the event names.
ToDo:
1) The counter overflow handling is currently unsupported in this
patch series.
2) ACPI support.
Version history
---------------
v2
--
- Fix review comments of v2 version.
- Move djtag driver to drivers/perf/hisilicon.
- Have separate PMU instance for each L3 cache banks.
- Modify device properties in DTS as per review comments.
- Handle hardware version difference.
- Change compatible names of djtag so use prefix hisi-
and remove chip version as driver only depend on djtag
hw version.
- use devm_kzalloc.
- Remove DDRC changes in this series. As the DDRC PMU doesnot
depend on djtag it will be send separately.
v1
--
-Initial version with support for L3C, MN and DDRC event counters
-Djtag driver is used to access registers of L3 cache and MN.
Anurup M (7):
arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support
dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event
counting.
perf: hisi: Update Kconfig for Hisilicon PMU support
perf: hisi: Add support for Hisilicon SoC event counters
perf: hisi: Add sysfs attributes for L3 cache(L3C) PMU
dts: arm64: hip06: Add Hisilicon SoC PMU support
Shaokun Zhang (1):
perf: hisi: Miscellanous node(MN) event counting in perf
Tan Xiaojun (2):
dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
drivers: perf: hisi: Add support for Hisilicon Djtag driver
.../devicetree/bindings/arm/hisilicon/djtag.txt | 66 ++
.../devicetree/bindings/arm/hisilicon/pmu.txt | 98 +++
Documentation/perf/hisi-pmu.txt | 75 +++
MAINTAINERS | 9 +
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 78 +++
drivers/perf/Kconfig | 8 +
drivers/perf/Makefile | 1 +
drivers/perf/hisilicon/Makefile | 1 +
drivers/perf/hisilicon/djtag.c | 729 +++++++++++++++++++++
drivers/perf/hisilicon/djtag.h | 39 ++
drivers/perf/hisilicon/hisi_uncore_l3c.c | 629 ++++++++++++++++++
drivers/perf/hisilicon/hisi_uncore_mn.c | 516 +++++++++++++++
drivers/perf/hisilicon/hisi_uncore_pmu.c | 365 +++++++++++
drivers/perf/hisilicon/hisi_uncore_pmu.h | 128 ++++
14 files changed, 2742 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
create mode 100644 Documentation/perf/hisi-pmu.txt
create mode 100644 drivers/perf/hisilicon/Makefile
create mode 100644 drivers/perf/hisilicon/djtag.c
create mode 100644 drivers/perf/hisilicon/djtag.h
create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h
--
2.1.4
^ permalink raw reply
* [PATCH v4 0/5] Add support for the STM32F4 I2C
From: M'boumba Cedric Madianga @ 2016-12-07 16:51 UTC (permalink / raw)
To: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.
Changes since v3 after Wolfram's review:
- Add COMPILE_TEST flag in Kconfig
- Use correct driver name in Kconfig i.e i2c-stm32f4 instead of i2c-st
- Use more comprehensible name stm32f4_i2c_msg for client specific data
- Don't store reset control node as just needed in probe
- Use clamp() function to test value between 2 ranges
- Use new "i2c_8bit_addr_from_msg() function to build I2C address
- Don't write error messages for timeout
- Remove error message when i2c_add_adapter() fails as it is already handled by
the i2c core driver
M'boumba Cedric Madianga (5):
dt-bindings: Document the STM32 I2C bindings
i2c: Add STM32F4 I2C driver
ARM: dts: Add I2C1 support for STM32F429 SoC
ARM: dts: Add I2C1 support for STM32429 eval board
ARM: configs: Add I2C support for STM32 defconfig
.../devicetree/bindings/i2c/i2c-stm32.txt | 33 +
arch/arm/boot/dts/stm32429i-eval.dts | 6 +
arch/arm/boot/dts/stm32f429.dtsi | 23 +
arch/arm/configs/stm32_defconfig | 3 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-stm32f4.c | 857 +++++++++++++++++++++
7 files changed, 933 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
create mode 100644 drivers/i2c/busses/i2c-stm32f4.c
--
1.9.1
^ permalink raw reply
* [PATCH v4 1/5] dt-bindings: Document the STM32 I2C bindings
From: M'boumba Cedric Madianga @ 2016-12-07 16:51 UTC (permalink / raw)
To: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: M'boumba Cedric Madianga
In-Reply-To: <1481129492-26600-1-git-send-email-cedric.madianga@gmail.com>
This patch adds documentation of device tree bindings for the STM32 I2C
controller.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/i2c/i2c-stm32.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 0000000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+ interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+ operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 100000 and 400000.
+
+Example :
+
+ i2c@40005400 {
+ compatible = "st,stm32f4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x40005400 0x400>;
+ interrupts = <31>,
+ <32>;
+ resets = <&rcc 277>;
+ clocks = <&rcc 0 149>;
+ pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+ pinctrl-names = "default";
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v4 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-12-07 16:51 UTC (permalink / raw)
To: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: M'boumba Cedric Madianga
In-Reply-To: <1481129492-26600-1-git-send-email-cedric.madianga@gmail.com>
This patch adds support for the STM32F4 I2C controller.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-stm32f4.c | 857 +++++++++++++++++++++++++++++++++++++++
3 files changed, 868 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-stm32f4.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 8e43914..584e0d7 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -886,6 +886,16 @@ config I2C_ST
This driver can also be built as module. If so, the module
will be called i2c-st.
+config I2C_STM32F4
+ tristate "STMicroelectronics STM32F4 I2C support"
+ depends on ARCH_STM32 || COMPILE_TEST
+ help
+ Enable this option to add support for STM32 I2C controller embedded
+ in STM32F4 SoCs.
+
+ This driver can also be built as module. If so, the module
+ will be called i2c-stm32f4.
+
config I2C_STU300
tristate "ST Microelectronics DDC I2C interface"
depends on MACH_U300
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 1c1bac8..a2c6ff5 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_I2C_SH_MOBILE) += i2c-sh_mobile.o
obj-$(CONFIG_I2C_SIMTEC) += i2c-simtec.o
obj-$(CONFIG_I2C_SIRF) += i2c-sirf.o
obj-$(CONFIG_I2C_ST) += i2c-st.o
+obj-$(CONFIG_I2C_STM32F4) += i2c-stm32f4.o
obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o
obj-$(CONFIG_I2C_TEGRA) += i2c-tegra.o
diff --git a/drivers/i2c/busses/i2c-stm32f4.c b/drivers/i2c/busses/i2c-stm32f4.c
new file mode 100644
index 0000000..faf12fd
--- /dev/null
+++ b/drivers/i2c/busses/i2c-stm32f4.c
@@ -0,0 +1,857 @@
+/*
+ * Driver for STMicroelectronics STM32 I2C controller
+ *
+ * Copyright (C) M'boumba Cedric Madianga 2015
+ * Author: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
+ *
+ * This driver is based on i2c-st.c
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+/* STM32F4 I2C offset registers */
+#define STM32F4_I2C_CR1 0x00
+#define STM32F4_I2C_CR2 0x04
+#define STM32F4_I2C_DR 0x10
+#define STM32F4_I2C_SR1 0x14
+#define STM32F4_I2C_SR2 0x18
+#define STM32F4_I2C_CCR 0x1C
+#define STM32F4_I2C_TRISE 0x20
+#define STM32F4_I2C_FLTR 0x24
+
+/* STM32F4 I2C control 1*/
+#define STM32F4_I2C_CR1_SWRST BIT(15)
+#define STM32F4_I2C_CR1_POS BIT(11)
+#define STM32F4_I2C_CR1_ACK BIT(10)
+#define STM32F4_I2C_CR1_STOP BIT(9)
+#define STM32F4_I2C_CR1_START BIT(8)
+#define STM32F4_I2C_CR1_PE BIT(0)
+
+/* STM32F4 I2C control 2 */
+#define STM32F4_I2C_CR2_FREQ_MASK GENMASK(5, 0)
+#define STM32F4_I2C_CR2_FREQ(n) ((n & STM32F4_I2C_CR2_FREQ_MASK))
+#define STM32F4_I2C_CR2_ITBUFEN BIT(10)
+#define STM32F4_I2C_CR2_ITEVTEN BIT(9)
+#define STM32F4_I2C_CR2_ITERREN BIT(8)
+#define STM32F4_I2C_CR2_IRQ_MASK (STM32F4_I2C_CR2_ITBUFEN \
+ | STM32F4_I2C_CR2_ITEVTEN \
+ | STM32F4_I2C_CR2_ITERREN)
+
+/* STM32F4 I2C Status 1 */
+#define STM32F4_I2C_SR1_AF BIT(10)
+#define STM32F4_I2C_SR1_ARLO BIT(9)
+#define STM32F4_I2C_SR1_BERR BIT(8)
+#define STM32F4_I2C_SR1_TXE BIT(7)
+#define STM32F4_I2C_SR1_RXNE BIT(6)
+#define STM32F4_I2C_SR1_BTF BIT(2)
+#define STM32F4_I2C_SR1_ADDR BIT(1)
+#define STM32F4_I2C_SR1_SB BIT(0)
+#define STM32F4_I2C_SR1_ITEVTEN_MASK (STM32F4_I2C_SR1_BTF \
+ | STM32F4_I2C_SR1_ADDR \
+ | STM32F4_I2C_SR1_SB)
+#define STM32F4_I2C_SR1_ITBUFEN_MASK (STM32F4_I2C_SR1_TXE \
+ | STM32F4_I2C_SR1_RXNE)
+#define STM32F4_I2C_SR1_ITERREN_MASK (STM32F4_I2C_SR1_AF \
+ | STM32F4_I2C_SR1_ARLO \
+ | STM32F4_I2C_SR1_BERR)
+
+/* STM32F4 I2C Status 2 */
+#define STM32F4_I2C_SR2_BUSY BIT(1)
+
+/* STM32F4 I2C Control Clock */
+#define STM32F4_I2C_CCR_CCR_MASK GENMASK(11, 0)
+#define STM32F4_I2C_CCR_CCR(n) ((n & STM32F4_I2C_CCR_CCR_MASK))
+#define STM32F4_I2C_CCR_FS BIT(15)
+#define STM32F4_I2C_CCR_DUTY BIT(14)
+
+/* STM32F4 I2C Trise */
+#define STM32F4_I2C_TRISE_VALUE_MASK GENMASK(5, 0)
+#define STM32F4_I2C_TRISE_VALUE(n) ((n & STM32F4_I2C_TRISE_VALUE_MASK))
+
+/* STM32F4 I2C Filter */
+#define STM32F4_I2C_FLTR_DNF_MASK GENMASK(3, 0)
+#define STM32F4_I2C_FLTR_DNF(n) ((n & STM32F4_I2C_FLTR_DNF_MASK))
+#define STM32F4_I2C_FLTR_ANOFF BIT(4)
+
+#define STM32F4_I2C_MIN_FREQ 2
+#define STM32F4_I2C_MAX_FREQ 42
+#define FAST_MODE_MAX_RISE_TIME 1000
+#define STD_MODE_MAX_RISE_TIME 300
+#define MHZ_TO_HZ 1000000
+
+enum stm32f4_i2c_speed {
+ STM32F4_I2C_SPEED_STANDARD, /* 100 kHz */
+ STM32F4_I2C_SPEED_FAST, /* 400 kHz */
+ STM32F4_I2C_SPEED_END,
+};
+
+/**
+ * struct stm32f4_i2c_timings - per-Mode tuning parameters
+ * @duty: Fast mode duty cycle
+ * @mul_ccr: Value to be multiplied to CCR to reach 100Khz/400Khz SCL frequency
+ * @min_ccr: Minimum clock ctrl reg value to reach 100Khz/400Khz SCL frequency
+ */
+struct stm32f4_i2c_timings {
+ u32 rate;
+ u32 duty;
+ u32 mul_ccr;
+ u32 min_ccr;
+};
+
+/**
+ * struct stm32f4_i2c_msg - client specific data
+ * @addr: 8-bit slave addr, including r/w bit
+ * @count: number of bytes to be transferred
+ * @buf: data buffer
+ * @result: result of the transfer
+ * @stop: last I2C msg to be sent, i.e. STOP to be generated
+ */
+struct stm32f4_i2c_msg {
+ u8 addr;
+ u32 count;
+ u8 *buf;
+ int result;
+ bool stop;
+};
+
+/**
+ * struct stm32f4_i2c_dev - private data of the controller
+ * @adap: I2C adapter for this controller
+ * @dev: device for this controller
+ * @base: virtual memory area
+ * @complete: completion of I2C message
+ * @irq_event: interrupt event line for the controller
+ * @irq_error: interrupt error line for the controller
+ * @clk: hw i2c clock
+ * speed: I2C clock frequency of the controller. Standard or Fast only supported
+ * @msg: I2C transfer information
+ */
+struct stm32f4_i2c_dev {
+ struct i2c_adapter adap;
+ struct device *dev;
+ void __iomem *base;
+ struct completion complete;
+ int irq_event;
+ int irq_error;
+ struct clk *clk;
+ int speed;
+ struct stm32f4_i2c_msg msg;
+};
+
+static struct stm32f4_i2c_timings i2c_timings[] = {
+ [STM32F4_I2C_SPEED_STANDARD] = {
+ .mul_ccr = 1,
+ .min_ccr = 4,
+ .duty = 0,
+ },
+ [STM32F4_I2C_SPEED_FAST] = {
+ .mul_ccr = 16,
+ .min_ccr = 1,
+ .duty = 1,
+ },
+};
+
+static inline void stm32f4_i2c_set_bits(void __iomem *reg, u32 mask)
+{
+ writel_relaxed(readl_relaxed(reg) | mask, reg);
+}
+
+static inline void stm32f4_i2c_clr_bits(void __iomem *reg, u32 mask)
+{
+ writel_relaxed(readl_relaxed(reg) & ~mask, reg);
+}
+
+static void stm32f4_i2c_soft_reset(struct stm32f4_i2c_dev *i2c_dev)
+{
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
+
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_SWRST);
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_SWRST);
+}
+
+static void stm32f4_i2c_disable_it(struct stm32f4_i2c_dev *i2c_dev)
+{
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_IRQ_MASK);
+}
+
+static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
+{
+ u32 clk_rate, cr2, freq;
+
+ cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
+ cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
+
+ clk_rate = clk_get_rate(i2c_dev->clk);
+ freq = clk_rate / MHZ_TO_HZ;
+
+ if (freq > STM32F4_I2C_MAX_FREQ)
+ freq = STM32F4_I2C_MAX_FREQ;
+ else if (freq < STM32F4_I2C_MIN_FREQ)
+ freq = STM32F4_I2C_MIN_FREQ;
+
+ cr2 |= STM32F4_I2C_CR2_FREQ(freq);
+ writel_relaxed(cr2, i2c_dev->base + STM32F4_I2C_CR2);
+}
+
+static void stm32f4_i2c_set_rise_time(struct stm32f4_i2c_dev *i2c_dev)
+{
+ u32 trise, freq, cr2, val;
+
+ cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
+ freq = cr2 & STM32F4_I2C_CR2_FREQ_MASK;
+
+ trise = readl_relaxed(i2c_dev->base + STM32F4_I2C_TRISE);
+ trise &= ~STM32F4_I2C_TRISE_VALUE_MASK;
+
+ /* Maximum rise time computation */
+ if (i2c_dev->speed == STM32F4_I2C_SPEED_STANDARD) {
+ trise |= STM32F4_I2C_TRISE_VALUE((freq + 1));
+ } else {
+ val = freq * FAST_MODE_MAX_RISE_TIME / STD_MODE_MAX_RISE_TIME;
+ trise |= STM32F4_I2C_TRISE_VALUE((val + 1));
+ }
+
+ writel_relaxed(trise, i2c_dev->base + STM32F4_I2C_TRISE);
+}
+
+static void stm32f4_i2c_set_speed_mode(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_timings *t = &i2c_timings[i2c_dev->speed];
+ u32 ccr, clk_rate;
+ int val;
+
+ ccr = readl_relaxed(i2c_dev->base + STM32F4_I2C_CCR);
+ ccr &= ~(STM32F4_I2C_CCR_FS | STM32F4_I2C_CCR_DUTY |
+ STM32F4_I2C_CCR_CCR_MASK);
+
+ clk_rate = clk_get_rate(i2c_dev->clk);
+ val = clk_rate / MHZ_TO_HZ * t->mul_ccr;
+ if (val < t->min_ccr)
+ val = t->min_ccr;
+ ccr |= STM32F4_I2C_CCR_CCR(val);
+
+ if (t->duty)
+ ccr |= STM32F4_I2C_CCR_FS | STM32F4_I2C_CCR_DUTY;
+
+ writel_relaxed(ccr, i2c_dev->base + STM32F4_I2C_CCR);
+}
+
+static void stm32f4_i2c_set_filter(struct stm32f4_i2c_dev *i2c_dev)
+{
+ u32 filter;
+
+ /* Enable analog noise filter and disable digital noise filter */
+ filter = readl_relaxed(i2c_dev->base + STM32F4_I2C_FLTR);
+ filter &= ~(STM32F4_I2C_FLTR_ANOFF | STM32F4_I2C_FLTR_DNF_MASK);
+ writel_relaxed(filter, i2c_dev->base + STM32F4_I2C_FLTR);
+}
+
+/**
+ * stm32f4_i2c_hw_config() - Prepare I2C block
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_hw_config(struct stm32f4_i2c_dev *i2c_dev)
+{
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
+
+ /* Disable I2C */
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_PE);
+
+ stm32f4_i2c_set_periph_clk_freq(i2c_dev);
+
+ stm32f4_i2c_set_rise_time(i2c_dev);
+
+ stm32f4_i2c_set_speed_mode(i2c_dev);
+
+ stm32f4_i2c_set_filter(i2c_dev);
+
+ /* Enable I2C */
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_PE);
+}
+
+static int stm32f4_i2c_wait_free_bus(struct stm32f4_i2c_dev *i2c_dev)
+{
+ u32 status;
+ int ret;
+
+ ret = readl_relaxed_poll_timeout(i2c_dev->base + STM32F4_I2C_SR2,
+ status,
+ !(status & STM32F4_I2C_SR2_BUSY),
+ 10, 1000);
+ if (ret) {
+ dev_err(i2c_dev->dev, "bus not free\n");
+ ret = -EBUSY;
+ }
+
+ return ret;
+}
+
+/**
+ * stm32f4_i2c_write_ byte() - Write a byte in the data register
+ * @i2c_dev: Controller's private data
+ * @byte: Data to write in the register
+ */
+static void stm32f4_i2c_write_byte(struct stm32f4_i2c_dev *i2c_dev, u8 byte)
+{
+ writel_relaxed(byte, i2c_dev->base + STM32F4_I2C_DR);
+}
+
+/**
+ * stm32f4_i2c_write_msg() - Fill the data register in write mode
+ * @i2c_dev: Controller's private data
+ *
+ * This function fills the data register with I2C transfer buffer
+ */
+static void stm32f4_i2c_write_msg(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+
+ stm32f4_i2c_write_byte(i2c_dev, *msg->buf++);
+ msg->count--;
+}
+
+static void stm32f4_i2c_read_msg(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ u32 rbuf;
+
+ rbuf = readl_relaxed(i2c_dev->base + STM32F4_I2C_DR);
+ *msg->buf++ = (u8)rbuf & 0xff;
+ msg->count--;
+}
+
+static void stm32f4_i2c_terminate_xfer(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+
+ stm32f4_i2c_disable_it(i2c_dev);
+
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ if (msg->stop)
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
+ else
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
+
+ complete(&i2c_dev->complete);
+}
+
+/**
+ * stm32f4_i2c_handle_write() - Handle FIFO empty interrupt in case of write
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_handle_write(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+
+ if (msg->count) {
+ stm32f4_i2c_write_msg(i2c_dev);
+ if (!msg->count) {
+ /* Disable BUF interrupt */
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
+ }
+ } else {
+ stm32f4_i2c_terminate_xfer(i2c_dev);
+ }
+}
+
+/**
+ * stm32f4_i2c_handle_read() - Handle FIFO empty interrupt in case of read
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_handle_read(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR2;
+
+ switch (msg->count) {
+ case 1:
+ stm32f4_i2c_disable_it(i2c_dev);
+ stm32f4_i2c_read_msg(i2c_dev);
+ complete(&i2c_dev->complete);
+ break;
+ case 2:
+ case 3:
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
+ break;
+ default:
+ stm32f4_i2c_read_msg(i2c_dev);
+ }
+}
+
+/**
+ * stm32f4_i2c_handle_rx_btf() - Handle byte transfer finished interrupt
+ * in case of read
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_handle_rx_btf(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg;
+ u32 mask;
+ int i;
+
+ switch (msg->count) {
+ case 2:
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ /* Generate STOP or REPSTART */
+ if (msg->stop)
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
+ else
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
+
+ /* Read two last data bytes */
+ for (i = 2; i > 0; i--)
+ stm32f4_i2c_read_msg(i2c_dev);
+
+ /* Disable EVT and ERR interrupt */
+ reg = i2c_dev->base + STM32F4_I2C_CR2;
+ mask = STM32F4_I2C_CR2_ITEVTEN | STM32F4_I2C_CR2_ITERREN;
+ stm32f4_i2c_clr_bits(reg, mask);
+
+ complete(&i2c_dev->complete);
+ break;
+ case 3:
+ /* Enable ACK and read data */
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
+ stm32f4_i2c_read_msg(i2c_dev);
+ break;
+ default:
+ stm32f4_i2c_read_msg(i2c_dev);
+ }
+}
+
+/**
+ * stm32f4_i2c_handle_rx_addr() - Handle address matched interrupt in case of
+ * master receiver
+ * @i2c_dev: Controller's private data
+ */
+static void stm32f4_i2c_handle_rx_addr(struct stm32f4_i2c_dev *i2c_dev)
+{
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg;
+ u32 sr2;
+
+ switch (msg->count) {
+ case 0:
+ stm32f4_i2c_terminate_xfer(i2c_dev);
+ /* Clear ADDR flag */
+ sr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+ break;
+ case 1:
+ /*
+ * Single byte reception:
+ * Enable NACK, clear ADDR flag and generate STOP or RepSTART
+ */
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
+ sr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+ if (msg->stop)
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
+ else
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
+ break;
+ case 2:
+ /*
+ * 2-byte reception:
+ * Enable NACK and PEC Position Ack and clear ADDR flag
+ */
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK);
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_POS);
+ sr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+ break;
+
+ default:
+ /* N-byte reception: Enable ACK and clear ADDR flag */
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_ACK);
+ sr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+ break;
+ }
+}
+
+/**
+ * stm32f4_i2c_isr_event() - Interrupt routine for I2C bus event
+ * @irq: interrupt number
+ * @data: Controller's private data
+ */
+static irqreturn_t stm32f4_i2c_isr_event(int irq, void *data)
+{
+ struct stm32f4_i2c_dev *i2c_dev = data;
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg;
+ u32 real_status, possible_status, ien, sr2;
+ int flag;
+
+ ien = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
+ ien &= STM32F4_I2C_CR2_IRQ_MASK;
+ possible_status = 0;
+
+ /* Check possible status combinations */
+ if (ien & STM32F4_I2C_CR2_ITEVTEN) {
+ possible_status = STM32F4_I2C_SR1_ITEVTEN_MASK;
+ if (ien & STM32F4_I2C_CR2_ITBUFEN)
+ possible_status |= STM32F4_I2C_SR1_ITBUFEN_MASK;
+ }
+
+ real_status = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR1);
+
+ if (!(real_status & possible_status)) {
+ dev_dbg(i2c_dev->dev,
+ "spurious evt it (status=0x%08x, ien=0x%08x)\n",
+ real_status, ien);
+ return IRQ_NONE;
+ }
+
+ /* Use __fls() to check error bits first */
+ flag = __fls(real_status & possible_status);
+
+ switch (1 << flag) {
+ case STM32F4_I2C_SR1_SB:
+ stm32f4_i2c_write_byte(i2c_dev, msg->addr);
+ break;
+
+ case STM32F4_I2C_SR1_ADDR:
+ if (msg->addr & I2C_M_RD)
+ stm32f4_i2c_handle_rx_addr(i2c_dev);
+ else
+ sr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR2);
+
+ /* Enable ITBUF interrupts */
+ reg = i2c_dev->base + STM32F4_I2C_CR2;
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR2_ITBUFEN);
+ break;
+
+ case STM32F4_I2C_SR1_BTF:
+ if (msg->addr & I2C_M_RD)
+ stm32f4_i2c_handle_rx_btf(i2c_dev);
+ else
+ stm32f4_i2c_handle_write(i2c_dev);
+ break;
+
+ case STM32F4_I2C_SR1_TXE:
+ stm32f4_i2c_handle_write(i2c_dev);
+ break;
+
+ case STM32F4_I2C_SR1_RXNE:
+ stm32f4_i2c_handle_read(i2c_dev);
+ break;
+
+ default:
+ dev_err(i2c_dev->dev,
+ "evt it unhandled: status=0x%08x)\n", real_status);
+ return IRQ_NONE;
+ }
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * stm32f4_i2c_isr_error() - Interrupt routine for I2C bus error
+ * @irq: interrupt number
+ * @data: Controller's private data
+ */
+static irqreturn_t stm32f4_i2c_isr_error(int irq, void *data)
+{
+ struct stm32f4_i2c_dev *i2c_dev = data;
+ struct stm32f4_i2c_msg *msg = &i2c_dev->msg;
+ void __iomem *reg;
+ u32 real_status, possible_status, ien;
+ int flag;
+
+ ien = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
+ ien &= STM32F4_I2C_CR2_IRQ_MASK;
+ possible_status = 0;
+
+ /* Check possible status combinations */
+ if (ien & STM32F4_I2C_CR2_ITERREN)
+ possible_status = STM32F4_I2C_SR1_ITERREN_MASK;
+
+ real_status = readl_relaxed(i2c_dev->base + STM32F4_I2C_SR1);
+
+ if (!(real_status & possible_status)) {
+ dev_dbg(i2c_dev->dev,
+ "spurious err it (status=0x%08x, ien=0x%08x)\n",
+ real_status, ien);
+ return IRQ_NONE;
+ }
+
+ /* Use __fls() to check error bits first */
+ flag = __fls(real_status & possible_status);
+
+ switch (1 << flag) {
+ case STM32F4_I2C_SR1_BERR:
+ reg = i2c_dev->base + STM32F4_I2C_SR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_SR1_BERR);
+ msg->result = -EIO;
+ break;
+
+ case STM32F4_I2C_SR1_ARLO:
+ reg = i2c_dev->base + STM32F4_I2C_SR1;
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_SR1_ARLO);
+ msg->result = -EAGAIN;
+ break;
+
+ case STM32F4_I2C_SR1_AF:
+ reg = i2c_dev->base + STM32F4_I2C_CR1;
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_STOP);
+ msg->result = -EIO;
+ break;
+
+ default:
+ dev_err(i2c_dev->dev,
+ "err it unhandled: status=0x%08x)\n", real_status);
+ return IRQ_NONE;
+ }
+
+ stm32f4_i2c_soft_reset(i2c_dev);
+ stm32f4_i2c_disable_it(i2c_dev);
+ complete(&i2c_dev->complete);
+
+ return IRQ_HANDLED;
+}
+
+/**
+ * stm32f4_i2c_xfer_msg() - Transfer a single I2C message
+ * @i2c_dev: Controller's private data
+ * @msg: I2C message to transfer
+ * @is_first: first message of the sequence
+ * @is_last: last message of the sequence
+ */
+static int stm32f4_i2c_xfer_msg(struct stm32f4_i2c_dev *i2c_dev,
+ struct i2c_msg *msg, bool is_first,
+ bool is_last)
+{
+ struct stm32f4_i2c_msg *f4_msg = &i2c_dev->msg;
+ void __iomem *reg = i2c_dev->base + STM32F4_I2C_CR1;
+ unsigned long timeout;
+ u32 mask;
+ int ret;
+
+ f4_msg->addr = i2c_8bit_addr_from_msg(msg);
+ f4_msg->buf = msg->buf;
+ f4_msg->count = msg->len;
+ f4_msg->result = 0;
+ f4_msg->stop = is_last;
+
+ reinit_completion(&i2c_dev->complete);
+
+ /* Enable ITEVT and ITERR interrupts */
+ mask = STM32F4_I2C_CR2_ITEVTEN | STM32F4_I2C_CR2_ITERREN;
+ stm32f4_i2c_set_bits(i2c_dev->base + STM32F4_I2C_CR2, mask);
+
+ if (is_first) {
+ ret = stm32f4_i2c_wait_free_bus(i2c_dev);
+ if (ret)
+ return ret;
+
+ /* START generation */
+ stm32f4_i2c_set_bits(reg, STM32F4_I2C_CR1_START);
+ }
+
+ timeout = wait_for_completion_timeout(&i2c_dev->complete,
+ i2c_dev->adap.timeout);
+ ret = f4_msg->result;
+
+ /* Disable PEC position Ack */
+ stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_POS);
+
+ if (!timeout)
+ ret = -ETIMEDOUT;
+
+ return ret;
+}
+
+/**
+ * stm32f4_i2c_xfer() - Transfer combined I2C message
+ * @i2c_adap: Adapter pointer to the controller
+ * @msgs: Pointer to data to be written.
+ * @num: Number of messages to be executed
+ */
+static int stm32f4_i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[],
+ int num)
+{
+ struct stm32f4_i2c_dev *i2c_dev = i2c_get_adapdata(i2c_adap);
+ int ret, i;
+
+ ret = clk_enable(i2c_dev->clk);
+ if (ret) {
+ dev_err(i2c_dev->dev, "Failed to enable clock\n");
+ return ret;
+ }
+
+ stm32f4_i2c_hw_config(i2c_dev);
+
+ for (i = 0; i < num && !ret; i++)
+ ret = stm32f4_i2c_xfer_msg(i2c_dev, &msgs[i], i == 0,
+ i == num - 1);
+
+ clk_disable(i2c_dev->clk);
+
+ return (ret < 0) ? ret : i;
+}
+
+static u32 stm32f4_i2c_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static struct i2c_algorithm stm32f4_i2c_algo = {
+ .master_xfer = stm32f4_i2c_xfer,
+ .functionality = stm32f4_i2c_func,
+};
+
+static int stm32f4_i2c_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct stm32f4_i2c_dev *i2c_dev;
+ struct resource *res;
+ u32 clk_rate;
+ struct i2c_adapter *adap;
+ struct reset_control *rst;
+ int ret;
+
+ i2c_dev = devm_kzalloc(&pdev->dev, sizeof(*i2c_dev), GFP_KERNEL);
+ if (!i2c_dev)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ i2c_dev->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(i2c_dev->base))
+ return PTR_ERR(i2c_dev->base);
+
+ i2c_dev->irq_event = irq_of_parse_and_map(np, 0);
+ if (!i2c_dev->irq_event) {
+ dev_err(&pdev->dev, "IRQ missing or invalid\n");
+ return -EINVAL;
+ }
+
+ i2c_dev->irq_error = irq_of_parse_and_map(np, 1);
+ if (!i2c_dev->irq_error) {
+ dev_err(&pdev->dev, "IRQ missing or invalid\n");
+ return -EINVAL;
+ }
+
+ i2c_dev->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(i2c_dev->clk)) {
+ dev_err(&pdev->dev, "Error: Missing controller clock\n");
+ return PTR_ERR(i2c_dev->clk);
+ }
+ ret = clk_prepare(i2c_dev->clk);
+ if (ret) {
+ dev_err(i2c_dev->dev, "Failed to prepare clock\n");
+ return ret;
+ }
+
+ rst = devm_reset_control_get(&pdev->dev, NULL);
+ if (IS_ERR(rst)) {
+ dev_err(&pdev->dev, "Error: Missing controller reset\n");
+ ret = PTR_ERR(rst);
+ goto clk_free;
+ }
+ reset_control_assert(rst);
+ udelay(2);
+ reset_control_deassert(rst);
+
+ i2c_dev->speed = STM32F4_I2C_SPEED_STANDARD;
+ ret = of_property_read_u32(np, "clock-frequency", &clk_rate);
+ if ((!ret) && (clk_rate == 400000))
+ i2c_dev->speed = STM32F4_I2C_SPEED_FAST;
+
+ i2c_dev->dev = &pdev->dev;
+
+ ret = devm_request_threaded_irq(&pdev->dev, i2c_dev->irq_event,
+ NULL, stm32f4_i2c_isr_event,
+ IRQF_ONESHOT, pdev->name, i2c_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request irq %i\n",
+ i2c_dev->irq_error);
+ goto clk_free;
+ }
+
+ ret = devm_request_threaded_irq(&pdev->dev, i2c_dev->irq_error,
+ NULL, stm32f4_i2c_isr_error,
+ IRQF_ONESHOT, pdev->name, i2c_dev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to request irq %i\n",
+ i2c_dev->irq_error);
+ goto clk_free;
+ }
+
+ adap = &i2c_dev->adap;
+ i2c_set_adapdata(adap, i2c_dev);
+ snprintf(adap->name, sizeof(adap->name), "STM32 I2C(%pa)", &res->start);
+ adap->owner = THIS_MODULE;
+ adap->timeout = 2 * HZ;
+ adap->retries = 0;
+ adap->algo = &stm32f4_i2c_algo;
+ adap->dev.parent = &pdev->dev;
+ adap->dev.of_node = pdev->dev.of_node;
+
+ init_completion(&i2c_dev->complete);
+
+ ret = i2c_add_adapter(adap);
+ if (ret)
+ goto clk_free;
+
+ platform_set_drvdata(pdev, i2c_dev);
+
+ dev_info(i2c_dev->dev, "STM32F4 I2C driver initialized\n");
+
+ return 0;
+
+clk_free:
+ clk_unprepare(i2c_dev->clk);
+ return ret;
+}
+
+static int stm32f4_i2c_remove(struct platform_device *pdev)
+{
+ struct stm32f4_i2c_dev *i2c_dev = platform_get_drvdata(pdev);
+
+ i2c_del_adapter(&i2c_dev->adap);
+
+ clk_unprepare(i2c_dev->clk);
+
+ return 0;
+}
+
+static const struct of_device_id stm32f4_i2c_match[] = {
+ { .compatible = "st,stm32f4-i2c", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, stm32f4_i2c_match);
+
+static struct platform_driver stm32f4_i2c_driver = {
+ .driver = {
+ .name = "stm32f4-i2c",
+ .of_match_table = stm32f4_i2c_match,
+ },
+ .probe = stm32f4_i2c_probe,
+ .remove = stm32f4_i2c_remove,
+};
+
+module_platform_driver(stm32f4_i2c_driver);
+
+MODULE_AUTHOR("M'boumba Cedric Madianga <cedric.madianga@gmail.com>");
+MODULE_DESCRIPTION("STMicroelectronics STM32F4 I2C driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v4 3/5] ARM: dts: Add I2C1 support for STM32F429 SoC
From: M'boumba Cedric Madianga @ 2016-12-07 16:51 UTC (permalink / raw)
To: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: M'boumba Cedric Madianga
In-Reply-To: <1481129492-26600-1-git-send-email-cedric.madianga@gmail.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 7de52ee..cbdece7 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -48,6 +48,7 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
+#include <dt-bindings/mfd/stm32f4-rcc.h>
/ {
clocks {
@@ -337,6 +338,16 @@
slew-rate = <2>;
};
};
+
+ i2c1_pins_b: i2c1@0 {
+ pins1 {
+ pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
+ drive-open-drain;
+ };
+ pins2 {
+ pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
+ };
+ };
};
rcc: rcc@40023810 {
@@ -409,6 +420,18 @@
interrupts = <80>;
clocks = <&rcc 0 38>;
};
+
+ i2c1: i2c@40005400 {
+ compatible = "st,stm32f4-i2c";
+ reg = <0x40005400 0x400>;
+ interrupts = <31>,
+ <32>;
+ resets = <&rcc STM32F4_APB1_RESET(I2C1)>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(I2C1)>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH v4 4/5] ARM: dts: Add I2C1 support for STM32429 eval board
From: M'boumba Cedric Madianga @ 2016-12-07 16:51 UTC (permalink / raw)
To: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: M'boumba Cedric Madianga
In-Reply-To: <1481129492-26600-1-git-send-email-cedric.madianga@gmail.com>
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
arch/arm/boot/dts/stm32429i-eval.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index afb90bc..74e0045 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -141,3 +141,9 @@
pinctrl-names = "default";
status = "okay";
};
+
+&i2c1 {
+ pinctrl-0 = <&i2c1_pins_b>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH v4 5/5] ARM: configs: Add I2C support for STM32 defconfig
From: M'boumba Cedric Madianga @ 2016-12-07 16:51 UTC (permalink / raw)
To: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: M'boumba Cedric Madianga
In-Reply-To: <1481129492-26600-1-git-send-email-cedric.madianga@gmail.com>
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
arch/arm/configs/stm32_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index e7b56d4..9494eaf 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -52,6 +52,9 @@ CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_STM32=y
CONFIG_SERIAL_STM32_CONSOLE=y
# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_STM32F4=y
# CONFIG_HWMON is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_NEW_LEDS=y
--
1.9.1
^ permalink raw reply related
* [PATCH v2 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters
From: Anurup M @ 2016-12-07 16:53 UTC (permalink / raw)
To: robh+dt, gregkh, catalin.marinas, arnd, geert+renesas, davem,
akpm, corbet, mark.rutland, will.deacon
Cc: linux-kernel, devicetree, linux-arm-kernel, anurup.m,
zhangshaokun, tanxiaojun, xuwei5, sanil.kumar, john.garry,
gabriele.paoloni, shiju.jose, wangkefeng.wang, linuxarm, shyju.pv,
anurupvasu
Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters.
The Hisilicon SoC HiP0x series has many uncore or non-CPU performance
events and counters units.
This patch series is implemented refering to arm-cci, Intel/AMD uncore and
also the cavium thunderX and xgene uncore pmu patches.
This v2 version has addressed the review comments of v1 version.
Support for Hisilicon L3 cache(L3C) and Misclennaneous nodes(MN) hardware
events and counters are added in this implementation.
The Hisilicon uncore PMUs can be found under /sys/bus/event_source/devices.
The counters are exported via sysfs in the corresponding events files
under the PMU directory so the perf tool can list the event names.
ToDo:
1) The counter overflow handling is currently unsupported in this
patch series.
2) ACPI support.
Version history
---------------
v2
--
- Fix review comments of v2 version.
- Move djtag driver to drivers/perf/hisilicon.
- Have separate PMU instance for each L3 cache banks.
- Modify device properties in DTS as per review comments.
- Handle hardware version difference.
- Change compatible names of djtag so use prefix hisi-
and remove chip version as driver only depend on djtag
hw version.
- use devm_kzalloc.
- Remove DDRC changes in this series. As the DDRC PMU doesnot
depend on djtag it will be send separately.
v1
--
-Initial version with support for L3C, MN and DDRC event counters
-Djtag driver is used to access registers of L3 cache and MN.
Anurup M (7):
arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support
dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event
counting.
perf: hisi: Update Kconfig for Hisilicon PMU support
perf: hisi: Add support for Hisilicon SoC event counters
perf: hisi: Add sysfs attributes for L3 cache(L3C) PMU
dts: arm64: hip06: Add Hisilicon SoC PMU support
Shaokun Zhang (1):
perf: hisi: Miscellanous node(MN) event counting in perf
Tan Xiaojun (2):
dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
drivers: perf: hisi: Add support for Hisilicon Djtag driver
.../devicetree/bindings/arm/hisilicon/djtag.txt | 66 ++
.../devicetree/bindings/arm/hisilicon/pmu.txt | 98 +++
Documentation/perf/hisi-pmu.txt | 75 +++
MAINTAINERS | 9 +
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 78 +++
drivers/perf/Kconfig | 8 +
drivers/perf/Makefile | 1 +
drivers/perf/hisilicon/Makefile | 1 +
drivers/perf/hisilicon/djtag.c | 729 +++++++++++++++++++++
drivers/perf/hisilicon/djtag.h | 39 ++
drivers/perf/hisilicon/hisi_uncore_l3c.c | 629 ++++++++++++++++++
drivers/perf/hisilicon/hisi_uncore_mn.c | 516 +++++++++++++++
drivers/perf/hisilicon/hisi_uncore_pmu.c | 365 +++++++++++
drivers/perf/hisilicon/hisi_uncore_pmu.h | 128 ++++
14 files changed, 2742 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
create mode 100644 Documentation/perf/hisi-pmu.txt
create mode 100644 drivers/perf/hisilicon/Makefile
create mode 100644 drivers/perf/hisilicon/djtag.c
create mode 100644 drivers/perf/hisilicon/djtag.h
create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h
--
2.1.4
^ permalink raw reply
* Re: [PATCH] arm: dts: rockchip: add qos node for rk3288
From: Heiko Stuebner @ 2016-12-07 16:53 UTC (permalink / raw)
To: Elaine Zhang
Cc: wxt-TNX95d0MmH7DzftRWevZcw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
huangtao-TNX95d0MmH7DzftRWevZcw, xxx-TNX95d0MmH7DzftRWevZcw,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481077065-11309-1-git-send-email-zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Mittwoch, 7. Dezember 2016, 10:17:45 CET schrieb Elaine Zhang:
> when pd power on/off, the qos regs need to save and restore.
>
> Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> arch/arm/boot/dts/rk3288.dtsi | 84
> +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 84
> insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 4fad13368a7b..2628edc871fa 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -699,6 +699,76 @@
> reg = <0xff720000 0x1000>;
> };
>
> + qos_gpu_r: qos@ffaa0000 {
> + compatible = "syscon";
> + reg = <0xffaa0000 0x20>;
> + };
applied for 4.11, after moving the qos nodes to their correct place (please
sort according to register address [aka 0xffaa.... behind the hdmi])
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Anurup M @ 2016-12-07 16:55 UTC (permalink / raw)
To: robh+dt, mark.rutland, will.deacon
Cc: linux-kernel, devicetree, linux-arm-kernel, anurup.m,
zhangshaokun, tanxiaojun, xuwei5, sanil.kumar, john.garry,
gabriele.paoloni, shiju.jose, wangkefeng.wang, linuxarm, shyju.pv,
anurupvasu
From: Tan Xiaojun <tanxiaojun@huawei.com>
Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
Signed-off-by: Anurup M <anurup.m@huawei.com>
---
.../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
new file mode 100644
index 0000000..733498e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
@@ -0,0 +1,41 @@
+The Hisilicon Djtag is an independent component which connects with some other
+components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
+in the chip. The djtag controls access to connecting modules of CPU and IO
+dies.
+The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
+are accessed by djtag during real time debugging. In IO die there are connecting
+components like RSA. These components appear as devices atatched to djtag bus.
+
+Hisilicon HiP05/06 djtag for CPU and HiP05 IO die
+Required properties:
+ - compatible : "hisilicon,hisi-djtag-v1"
+ - reg : Register address and size
+ - scl-id : The Super Cluster ID for CPU or IO die
+
+Hisilicon HiP06 djtag for IO die and HiP07 djtag for CPU and IO die
+Required properties:
+ - compatible : "hisilicon,hisi-djtag-v2"
+ - reg : Register address and size
+ - scl-id : The Super Cluster ID for CPU or IO die
+
+Example 1: Djtag for CPU die
+
+ /* for Hisilicon HiP05 djtag for CPU Die */
+ djtag0: djtag@80010000 {
+ compatible = "hisilicon,hisi-djtag-v1";
+ reg = <0x0 0x80010000 0x0 0x10000>;
+ scl-id = <0x02>;
+
+ /* All connecting components will appear as child nodes */
+ };
+
+Example 2: Djtag for IO die
+
+ /* for Hisilicon HiP05 djtag for IO Die */
+ djtag1: djtag@d0000000 {
+ compatible = "hisilicon,hisi-djtag-v1";
+ reg = <0x0 0xd0000000 0x0 0x10000>;
+ scl-id = <0x01>;
+
+ /* All connecting components will appear as child nodes */
+ };
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/9] arm64: dts: rockchip: add rk3399 thermal_zones phandle
From: Heiko Stuebner @ 2016-12-07 16:55 UTC (permalink / raw)
To: Brian Norris
Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
Chris Zhong
In-Reply-To: <1480645653-36943-3-git-send-email-briannorris@chromium.org>
Am Donnerstag, 1. Dezember 2016, 18:27:26 CET schrieb Brian Norris:
> We're going to need to amend this table in board files.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
applied for 4.11
Thanks
Heiko
^ permalink raw reply
* [PATCH v2 03/10] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Anurup M @ 2016-12-07 16:55 UTC (permalink / raw)
To: robh+dt, mark.rutland, will.deacon
Cc: linux-kernel, devicetree, linux-arm-kernel, anurup.m,
zhangshaokun, tanxiaojun, xuwei5, sanil.kumar, john.garry,
gabriele.paoloni, shiju.jose, wangkefeng.wang, linuxarm, shyju.pv,
anurupvasu
1) Device tree bindings for Hisilicon SoC PMU.
2) Add example for Hisilicon L3 cache and MN PMU.
3) Add child nodes of L3C and MN in djtag bindings example.
Signed-off-by: Anurup M <anurup.m@huawei.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
---
.../devicetree/bindings/arm/hisilicon/djtag.txt | 25 ++++++
.../devicetree/bindings/arm/hisilicon/pmu.txt | 98 ++++++++++++++++++++++
2 files changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
index 733498e..c885507 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
@@ -27,6 +27,31 @@ Example 1: Djtag for CPU die
scl-id = <0x02>;
/* All connecting components will appear as child nodes */
+
+ pmul3c0 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x02>;
+ };
+
+ pmul3c1 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x04>;
+ };
+
+ pmul3c2 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x01>;
+ };
+
+ pmul3c3 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x08>;
+ };
+
+ pmumn0 {
+ compatible = "hisilicon,hisi-pmu-mn-v1";
+ module-id = <0x0b>;
+ };
};
Example 2: Djtag for IO die
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
new file mode 100644
index 0000000..e2160ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
@@ -0,0 +1,98 @@
+Hisilicon SoC HiP05/06/07 ARMv8 PMU
+===================================
+
+The Hisilicon SoC chips like HiP05/06/07 etc. consist of various independent
+system device PMUs such as L3 cache (L3C) and Miscellaneous Nodes(MN). These
+PMU devices are independent and have hardware logic to gather statistics and
+performance information.
+
+HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
+is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
+in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which includes
+4 cpu-cores each.
+e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
+The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
+
+The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
+For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
+the parent node will be the djtag node of the corresponding CPU die (SCCL).
+
+L3 cache
+---------
+The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips have 4
+L3 cache banks. Each L3 cache bank have separate DT nodes.
+
+Required properties:
+
+ - compatible : This value should be as follows
+ (a) "hisilicon,hisi-pmu-l3c-v1" for v1 hw in HiP05/06 chips
+ (b) "hisilicon,hisi-pmu-l3c-v2" for v2 hw in HiP07 chip
+
+ - module-id : This property is a combination of two values in the below order.
+ a) Module ID: The module identifier for djtag.
+ b) Instance or Bank ID: This will identify the L3 cache bank
+ or instance.
+
+Optional properties:
+
+ - interrupt-parent : A phandle indicating which interrupt controller
+ this PMU signals interrupts to.
+
+ - interrupts : Interrupt lines used by this L3 cache bank.
+
+ *The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
+
+Miscellaneous Node
+------------------
+The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
+for each SCCL.
+
+Required properties:
+
+ - compatible : This value should be as follows
+ (a) "hisilicon,hisi-pmu-mn-v1" for v1 hw in HiP05/06 chips
+ (b) "hisilicon,hisi-pmu-mn-v2" for v2 hw in HiP07 chip
+
+ - module-id : Module ID to input for djtag.
+
+Optional properties:
+
+ - interrupt-parent : A phandle indicating which interrupt controller
+ this PMU signals interrupts to.
+
+ - interrupts : Interrupt lines used by this PMU.
+
+ *The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
+
+Example:
+
+ djtag0: djtag@80010000 {
+ compatible = "hisilicon,hisi-djtag-v1";
+ reg = <0x0 0x80010000 0x0 0x10000>;
+ scl-id = <0x02>;
+
+ pmul3c0 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x02>;
+ };
+
+ pmul3c1 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x04>;
+ };
+
+ pmul3c2 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x01>;
+ };
+
+ pmul3c3 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x08>;
+ };
+
+ pmumn0 {
+ compatible = "hisilicon,hisi-pmu-mn-v1";
+ module-id = <0x0b>;
+ };
+ };
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 3/9] arm64: dts: rockchip: add rk3399 eDP HPD pinctrl
From: Heiko Stuebner @ 2016-12-07 16:56 UTC (permalink / raw)
To: Brian Norris
Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
Chris Zhong
In-Reply-To: <1480645653-36943-4-git-send-email-briannorris@chromium.org>
Am Donnerstag, 1. Dezember 2016, 18:27:27 CET schrieb Brian Norris:
> We haven't enabled eDP support yet, but we might as well describe the
> pin now.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
applied for 4.11
Thanks
Heiko
^ permalink raw reply
* [PATCH v2 10/10] dts: arm64: hip06: Add Hisilicon SoC PMU support
From: Anurup M @ 2016-12-07 16:58 UTC (permalink / raw)
To: mark.rutland, will.deacon, robh+dt, xuwei5, catalin.marinas
Cc: devicetree, linux-kernel, linux-arm-kernel, anurup.m,
zhangshaokun, tanxiaojun, sanil.kumar, john.garry,
gabriele.paoloni, shiju.jose, linuxarm, shyju.pv, anurupvasu
1. Add nodes for hip06 L3 cache to support uncore events.
2. Add nodes for hip06 MN to support uncore events.
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Anurup M <anurup.m@huawei.com>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 78 ++++++++++++++++++++++++++++++++
1 file changed, 78 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index e861698..309b974 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -963,6 +963,84 @@
status = "disabled";
};
+ djtag0: djtag@60010000 {
+ compatible = "hisilicon,hisi-djtag-v1";
+ reg = <0x0 0x60010000 0x0 0x10000>;
+ scl-id = <0x02>;
+
+ /* L3 cache bank 0 for socket0 CPU die scl#2 */
+ pmul3c0 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x02>;
+ };
+
+ /* L3 cache bank 1 for socket0 CPU die scl#2 */
+ pmul3c1 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x04>;
+ };
+
+ /* L3 cache bank 2 for socket0 CPU die scl#2 */
+ pmul3c2 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x01>;
+ };
+
+ /* L3 cache bank 3 for socket0 CPU die scl#2 */
+ pmul3c3 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x08>;
+ };
+
+ /*
+ * Miscellaneous node for socket0
+ * CPU die scl#2
+ */
+ pmumn0 {
+ compatible = "hisilicon,hisi-pmu-mn-v1";
+ module-id = <0x0b>;
+ };
+ };
+
+ djtag1: djtag@40010000 {
+ compatible = "hisilicon,hisi-djtag-v1";
+ reg = <0x0 0x40010000 0x0 0x10000>;
+ scl-id = <0x01>;
+
+ /* L3 cache bank 0 for socket0 CPU die scl#1 */
+ pmul3c0 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x02>;
+ };
+
+ /* L3 cache bank 1 for socket0 CPU die scl#1 */
+ pmul3c1 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x04>;
+ };
+
+ /* L3 cache bank 2 for socket0 CPU die scl#1 */
+ pmul3c2 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x01>;
+ };
+
+ /* L3 cache bank 3 for socket0 CPU die scl#1 */
+ pmul3c3 {
+ compatible = "hisilicon,hisi-pmu-l3c-v1";
+ module-id = <0x04 0x08>;
+ };
+
+ /*
+ * Miscellaneous node for socket0
+ * CPU die scl#1
+ */
+ pmumn1 {
+ compatible = "hisilicon,hisi-pmu-mn-v1";
+ module-id = <0x0b>;
+ };
+ };
+
sas1: sas@a2000000 {
compatible = "hisilicon,hip06-sas-v2";
reg = <0 0xa2000000 0 0x10000>;
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox