* [PATCH 0/5] ARM: qcom_defconfig: Add configs required for IFC6410
From: Olof Johansson @ 2017-01-04 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483536933-21503-1-git-send-email-srinivas.kandagatla@linaro.org>
Hi,
On Wed, Jan 4, 2017 at 5:35 AM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> This patchset adds configs required to get USB, SATA, PCIE, and tsens work on
> top of mainline on APQ8064 based IFC6410 and SD-600EVAL board.
Stop sending patches to arm at kernel.org. We won't apply them directly from you.
You should send these to the Qualcomm maintainer, who you haven't even
cc:d here.
Please talk to your coworkers in Linaro how to send code to
maintainers if you need further assistance.
Thanks,
-Olof
^ permalink raw reply
* [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64
From: Florian Fainelli @ 2017-01-04 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104114449.GA18193@arm.com>
On 01/04/2017 03:44 AM, Will Deacon wrote:
> On Tue, Jan 03, 2017 at 03:25:53PM -0800, Laura Abbott wrote:
>> On 01/03/2017 02:56 PM, Florian Fainelli wrote:
>>> On 01/03/2017 09:21 AM, Laura Abbott wrote:
>>>> Happy New Year!
>>>>
>>>> This is a very minor rebase from v5. It only moves a few headers around.
>>>> I think this series should be ready to be queued up for 4.11.
>>>
>>> FWIW:
>>>
>>> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
>>>
>>
>> Thanks!
>>
>>> How do we get this series included? I would like to get the ARM 32-bit
>>> counterpart included as well (will resubmit rebased shortly), but I have
>>> no clue which tree this should be going through.
>>>
>>
>> I was assuming this would go through the arm64 tree unless Catalin/Will
>> have an objection to that.
>
> Yup, I was planning to pick it up for 4.11.
>
> Florian -- does your series depend on this? If so, then I'll need to
> co-ordinate with Russell (probably via a shared branch that we both pull)
> if you're aiming for 4.11 too.
Yes, pretty much everything in Laura's patch series is relevant, except
the arm64 bits.
I will get v6 out now addressing Laura's and Hartley's feedback and
then, if you could holler when and where you have applied these, I can
coordinate with Russell about how to get these included.
Thanks and happy new year!
--
Florian
^ permalink raw reply
* [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Dave Gerlach @ 2017-01-04 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6fc7a6cb-1856-1377-b00c-8166dbb23ea2@oracle.com>
Santosh,
On 01/04/2017 03:54 PM, Santosh Shilimkar wrote:
> On 1/4/2017 12:55 PM, Dave Gerlach wrote:
>> Hi,
>> This is v3 of the series to add support for TI-SCI Generic PM Domains.
>> Previous versions can be found here:
>>
>> v2: https://www.spinics.net/lists/kernel/msg2364612.html
>> v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
>>
>> This version is rebased on v4.10-rc2 but is the same as v2 with the
>> exception of patch 2 in which the devicetree binding documentation
>> needed to be updated to show the k2g_pds node should be a child of
>> the pmmc node. Apart from that, the acks provided by Ulf were added
>> to patches 1 and 3.
>>
>> Now that the TI-SCI series has been merged [1] this series will be ready
>> to go in with an ack on the DT binding. Rob had raised some questions on
>> the necessity ti,sci-id property but I believe these were properly
>> addressed during the discussion of v2 so hopefully an ack is in order
>> now.
>>
> How do you plan to merge this series with below patch ?
>
>> PM / Domains: Add generic data pointer to genpd data struct
> I think this one goes via Rafael's tree. If you want me to merge this
> along with other patches then will need his ack.
>
> Other way is to get that merged first via Rafael's tree and then
> the remainder series.
I'd be happy with it going in through your tree with an ack to avoid any
delay but I'd say it's Rafael's call as it is a patch to the genpd core,
even though at this point I am the only user.
Regards,
Dave
>
> Regards,
> Santosh
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: keystone: Add "ti, da830-uart" compatible string
From: Santosh Shilimkar @ 2017-01-04 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483561814-21953-5-git-send-email-david@lechnology.com>
On 1/4/2017 12:30 PM, David Lechner wrote:
> The TI Keystone SoCs have extra UART registers beyond the standard 8250
> registers, so we need a new compatible string to indicate this. Also, at
> least one of these registers uses the full 32 bits, so we need to specify
> reg-io-width in addition to reg-shift.
>
> "ns16550a" is left in the compatible specification since it does work as
> long as the bootloader configures the SoC UART power management registers.
>
NAK!!
We can't break the booting boards with existing boot loaders.
I suggest you to first get the driver updated to take care of
the UART PM register and then enable the support for it.
^ permalink raw reply
* [PATCH v1 1/4] dt-bindings: Document Broadcom iProc mailbox controller driver
From: Jonathan Richardson @ 2017-01-04 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY2-M29qkrctNZfV1eJJzOguKkTTn5KfhdAHQ2aixCyU_A@mail.gmail.com>
On 16-11-16 07:13 PM, Jassi Brar wrote:
> On Wed, Oct 19, 2016 at 12:30 AM, Jonathan Richardson
> <jonathan.richardson@broadcom.com> wrote:
>
>> Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>> Reviewed-by: Vikram Prakash <vikram.prakash@broadcom.com>
>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>> Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar@broadcom.com>
>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>> ---
> Wow, heavily endorsed! :) Some log explaining the node, would have
> been nice. Especially how mailbox acts as an interrupt controller.
>
I agree. I'll add it to the binding for the suggested new mailbox irq
controller driver.
> Thanks.
>
^ permalink raw reply
* [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Santosh Shilimkar @ 2017-01-04 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104205536.15963-1-d-gerlach@ti.com>
On 1/4/2017 12:55 PM, Dave Gerlach wrote:
> Hi,
> This is v3 of the series to add support for TI-SCI Generic PM Domains.
> Previous versions can be found here:
>
> v2: https://www.spinics.net/lists/kernel/msg2364612.html
> v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
>
> This version is rebased on v4.10-rc2 but is the same as v2 with the
> exception of patch 2 in which the devicetree binding documentation
> needed to be updated to show the k2g_pds node should be a child of
> the pmmc node. Apart from that, the acks provided by Ulf were added
> to patches 1 and 3.
>
> Now that the TI-SCI series has been merged [1] this series will be ready
> to go in with an ack on the DT binding. Rob had raised some questions on
> the necessity ti,sci-id property but I believe these were properly
> addressed during the discussion of v2 so hopefully an ack is in order now.
>
How do you plan to merge this series with below patch ?
> PM / Domains: Add generic data pointer to genpd data struct
I think this one goes via Rafael's tree. If you want me to merge this
along with other patches then will need his ack.
Other way is to get that merged first via Rafael's tree and then
the remainder series.
Regards,
Santosh
^ permalink raw reply
* [PATCH] rtc: armada38x: add __ro_after_init to armada38x_rtc_ops
From: Kees Cook @ 2017-01-04 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104130628.GQ14217@n2100.armlinux.org.uk>
On Wed, Jan 4, 2017 at 5:06 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Jan 04, 2017 at 01:23:41PM +0100, Julia Lawall wrote:
>> Basically, the strategy of the patch is that one may consider it
>> preferable to duplicate the structure for the different alternatives,
>> rather than use __ro_after_init. Perhaps if the structure were larger,
>> then __ro_after_init would be a better choice?
>
> It depends on not just the size, but how many members need to be
> modified, and obviously whether there are likely to be more than one
> user of the structure as well.
>
> So I'd say __ro_after_init rarely makes sense for an operations
> structure - the only case I can see is:
>
> - a large structure
> - only a small number of elements need to be modified
> - it is only single-use
>
> which is probably quite rare - this one falls into two out of those
> three.
>
> There's another consideration (imho) too - we may wish, at a later
> date, to make .text and .rodata both read-only from the start of the
> kernel to harden the kernel against possibly init-time exploitation.
> (Think about a buggy built-in driver with emulated hardware - much the
> same problem that Kees is trying to address in one of his recent patch
> sets but with hotplugged hardware while a screen-saver is active.)
> Having function pointers in .rodata rather than the ro-after-init
> section would provide better protection.
Agreed: I'd much prefer things just be const. :) As to my confusing
question, I hadn't looked at how where the pointers to the structure
was being stored, so I was just asking if it, too, could be const,
which it can't, and that's fine here.
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH v1 2/4] mailbox: Add iProc mailbox controller driver
From: Jonathan Richardson @ 2017-01-04 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABb+yY3ga7CgZaRi_5Qu4UXNjGdhuLHM0gZjrwusFSLfCuc5cQ@mail.gmail.com>
On 16-11-16 07:40 PM, Jassi Brar wrote:
> Hi Jonathan,
Hi Jassi. Thanks for the review. I was away so sorry for the slow reply.
>
> On Wed, Oct 19, 2016 at 12:30 AM, Jonathan Richardson
> <jonathan.richardson@broadcom.com> wrote:
>> The Broadcom iProc mailbox controller handles all communication with a
>> Cortex-M0 MCU processor that provides support for power, clock, and
>> reset management.
>>
>> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>> Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>> Reviewed-by: Vikram Prakash <vikram.prakash@broadcom.com>
>> Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar@broadcom.com>
>> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
>> ---
>> drivers/mailbox/Kconfig | 10 +
>> drivers/mailbox/Makefile | 2 +
>> drivers/mailbox/bcm-iproc-mailbox.c | 422 ++++++++++++++++++++++++++++++++++++
>> include/linux/bcm_iproc_mailbox.h | 32 +++
>>
> This should be include/linux/mailbox/bcm_iproc_mailbox.h
I'll move it.
>
>
>> +++ b/drivers/mailbox/bcm-iproc-mailbox.c
>> @@ -0,0 +1,422 @@
>> +/*
>> + * Copyright (C) 2016 Broadcom.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation version 2.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/slab.h>
>> +#include <linux/module.h>
>> +#include <linux/irq.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/irqchip/chained_irq.h>
>> +#include <linux/notifier.h>
>> +#include <linux/reboot.h>
>> +#include <linux/mailbox_controller.h>
>> +#include <linux/mailbox_client.h>
>>
> Need of mailbox_controller.h & client.h is a bad sign.
The controller is using this only for the tx_tout value from the client
to determine a reasonable timeout period. We could use a fixed value in
the controller instead.
>
>> +
>> +static int iproc_mbox_send_data_m0_imp(struct iproc_mbox *mbox,
>> + struct iproc_mbox_msg *msg, int max_retries, int poll_period_us)
>> +{
>> + unsigned long flags;
>> + u32 val;
>> + int err = 0;
>> + int retries;
>> +
>> + spin_lock_irqsave(&mbox->lock, flags);
>> +
>> + dev_dbg(mbox->dev, "Send msg to M0: cmd=0x%x, param=0x%x, wait_ack=%d\n",
>> + msg->cmd, msg->param, msg->wait_ack);
>> +
>> + writel(msg->cmd, mbox->base + IPROC_CRMU_MAILBOX0_OFFSET);
>> + writel(msg->param, mbox->base + IPROC_CRMU_MAILBOX1_OFFSET);
>> +
>> + if (msg->wait_ack) {
>> + err = msg->reply_code = -ETIMEDOUT;
>> + for (retries = 0; retries < max_retries; retries++) {
>> + val = readl(mbox->base + IPROC_CRMU_MAILBOX0_OFFSET);
>> + if (val & M0_IPC_CMD_DONE_MASK) {
>> + /*
>> + * M0 replied - save reply code and
>> + * clear error.
>> + */
>> + msg->reply_code = (val &
>> + M0_IPC_CMD_REPLY_MASK) >>
>> + M0_IPC_CMD_REPLY_SHIFT;
>> + err = 0;
>> + break;
>> + }
>> + udelay(poll_period_us);
>> + }
>> + }
>> +
>> + spin_unlock_irqrestore(&mbox->lock, flags);
>> +
>> + return err;
>> +}
>> +
> OK, so this is the real message passing voodoo.
>
>> +static void iproc_mbox_aon_gpio_forwarding_enable(struct iproc_mbox *mbox,
>> + bool en)
>> +{
>> + struct iproc_mbox_msg msg;
>> + const int max_retries = 5;
>> + const int poll_period_us = 200;
>> +
>> + msg.cmd = M0_IPC_M0_CMD_AON_GPIO_FORWARDING_ENABLE;
>> + msg.param = en ? 1 : 0;
>> + msg.wait_ack = true;
>> +
>> + iproc_mbox_send_data_m0_imp(mbox, &msg, max_retries, poll_period_us);
>> +}
>> +
>> +static void iproc_mbox_irq_unmask(struct irq_data *d)
>> +{
>> + struct iproc_mbox *iproc_mbox = irq_data_get_irq_chip_data(d);
>> +
>> + iproc_mbox_aon_gpio_forwarding_enable(iproc_mbox, true);
>> +}
>> +
>> +static void iproc_mbox_irq_mask(struct irq_data *d)
>> +{
>> + /* Do nothing - Mask callback is not required, since upon GPIO event,
>> + * M0 disables GPIO forwarding to A9. Hence, GPIO forwarding is already
>> + * disabled when in mbox irq handler, and no other mbox events from M0
>> + * to A9 are expected until GPIO forwarding is enabled following
>> + * iproc_mbox_irq_unmask()
>> + */
>> +}
>> +
>> +static struct irq_chip iproc_mbox_irq_chip = {
>> + .name = "bcm-iproc-mbox",
>> + .irq_mask = iproc_mbox_irq_mask,
>> + .irq_unmask = iproc_mbox_irq_unmask,
>> +};
>> +
> .... these are simply using the mailbox controllers directly. So you
> are actually clubbing a mailbox client (interrupt controller) with the
> provider (mailbox) here.
>
> I think you need move the IRQ controller part under drivers/irqchip/
> that uses the mailbox api to manage its 'irq lines'.
>
Should be straight forward to change.
Thanks.
> Thanks.
>
^ permalink raw reply
* [PATCH 4/4] watchdog: tangox: Use watchdog core to install restart handler
From: Guenter Roeck @ 2017-01-04 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483565318-25578-1-git-send-email-linux@roeck-us.net>
Use the infrastructure provided by the watchdog core to install
the restart handler.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/watchdog/tangox_wdt.c | 32 +++++++++++---------------------
1 file changed, 11 insertions(+), 21 deletions(-)
diff --git a/drivers/watchdog/tangox_wdt.c b/drivers/watchdog/tangox_wdt.c
index 202c4b9cc921..49e6e805db7c 100644
--- a/drivers/watchdog/tangox_wdt.c
+++ b/drivers/watchdog/tangox_wdt.c
@@ -15,9 +15,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
-#include <linux/notifier.h>
#include <linux/platform_device.h>
-#include <linux/reboot.h>
#include <linux/watchdog.h>
#define DEFAULT_TIMEOUT 30
@@ -47,7 +45,6 @@ struct tangox_wdt_device {
void __iomem *base;
unsigned long clk_rate;
struct clk *clk;
- struct notifier_block restart;
};
static int tangox_wdt_set_timeout(struct watchdog_device *wdt,
@@ -96,24 +93,24 @@ static const struct watchdog_info tangox_wdt_info = {
.identity = "tangox watchdog",
};
+static int tangox_wdt_restart(struct watchdog_device *wdt,
+ unsigned long action, void *data)
+{
+ struct tangox_wdt_device *dev = watchdog_get_drvdata(wdt);
+
+ writel(1, dev->base + WD_COUNTER);
+
+ return 0;
+}
+
static const struct watchdog_ops tangox_wdt_ops = {
.start = tangox_wdt_start,
.stop = tangox_wdt_stop,
.set_timeout = tangox_wdt_set_timeout,
.get_timeleft = tangox_wdt_get_timeleft,
+ .restart = tangox_wdt_restart,
};
-static int tangox_wdt_restart(struct notifier_block *nb, unsigned long action,
- void *data)
-{
- struct tangox_wdt_device *dev =
- container_of(nb, struct tangox_wdt_device, restart);
-
- writel(1, dev->base + WD_COUNTER);
-
- return NOTIFY_DONE;
-}
-
static int tangox_wdt_probe(struct platform_device *pdev)
{
struct tangox_wdt_device *dev;
@@ -180,12 +177,6 @@ static int tangox_wdt_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dev);
- dev->restart.notifier_call = tangox_wdt_restart;
- dev->restart.priority = 128;
- err = register_restart_handler(&dev->restart);
- if (err)
- dev_warn(&pdev->dev, "failed to register restart handler\n");
-
dev_info(&pdev->dev, "SMP86xx/SMP87xx watchdog registered\n");
return 0;
@@ -202,7 +193,6 @@ static int tangox_wdt_remove(struct platform_device *pdev)
tangox_wdt_stop(&dev->wdt);
clk_disable_unprepare(dev->clk);
- unregister_restart_handler(&dev->restart);
watchdog_unregister_device(&dev->wdt);
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] watchdog: bcm2835_wdt: Use watchdog core to install restart handler
From: Guenter Roeck @ 2017-01-04 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483565318-25578-1-git-send-email-linux@roeck-us.net>
Use the infrastructure provided by the watchdog core to install
the restart handler.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/watchdog/bcm2835_wdt.c | 54 +++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
index c32c45bd8b09..2bc7d195f0a4 100644
--- a/drivers/watchdog/bcm2835_wdt.c
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -14,7 +14,6 @@
*/
#include <linux/delay.h>
-#include <linux/reboot.h>
#include <linux/types.h>
#include <linux/module.h>
#include <linux/io.h>
@@ -49,7 +48,6 @@
struct bcm2835_wdt {
void __iomem *base;
spinlock_t lock;
- struct notifier_block restart_handler;
};
static unsigned int heartbeat;
@@ -99,11 +97,37 @@ static unsigned int bcm2835_wdt_get_timeleft(struct watchdog_device *wdog)
return WDOG_TICKS_TO_SECS(ret & PM_WDOG_TIME_SET);
}
+static void __bcm2835_restart(struct bcm2835_wdt *wdt)
+{
+ u32 val;
+
+ /* use a timeout of 10 ticks (~150us) */
+ writel_relaxed(10 | PM_PASSWORD, wdt->base + PM_WDOG);
+ val = readl_relaxed(wdt->base + PM_RSTC);
+ val &= PM_RSTC_WRCFG_CLR;
+ val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
+ writel_relaxed(val, wdt->base + PM_RSTC);
+
+ /* No sleeping, possibly atomic. */
+ mdelay(1);
+}
+
+static int bcm2835_restart(struct watchdog_device *wdog,
+ unsigned long action, void *data)
+{
+ struct bcm2835_wdt *wdt = watchdog_get_drvdata(wdog);
+
+ __bcm2835_restart(wdt);
+
+ return 0;
+}
+
static const struct watchdog_ops bcm2835_wdt_ops = {
.owner = THIS_MODULE,
.start = bcm2835_wdt_start,
.stop = bcm2835_wdt_stop,
.get_timeleft = bcm2835_wdt_get_timeleft,
+ .restart = bcm2835_restart,
};
static const struct watchdog_info bcm2835_wdt_info = {
@@ -120,26 +144,6 @@ static struct watchdog_device bcm2835_wdt_wdd = {
.timeout = WDOG_TICKS_TO_SECS(PM_WDOG_TIME_SET),
};
-static int
-bcm2835_restart(struct notifier_block *this, unsigned long mode, void *cmd)
-{
- struct bcm2835_wdt *wdt = container_of(this, struct bcm2835_wdt,
- restart_handler);
- u32 val;
-
- /* use a timeout of 10 ticks (~150us) */
- writel_relaxed(10 | PM_PASSWORD, wdt->base + PM_WDOG);
- val = readl_relaxed(wdt->base + PM_RSTC);
- val &= PM_RSTC_WRCFG_CLR;
- val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
- writel_relaxed(val, wdt->base + PM_RSTC);
-
- /* No sleeping, possibly atomic. */
- mdelay(1);
-
- return 0;
-}
-
/*
* We can't really power off, but if we do the normal reset scheme, and
* indicate to bootcode.bin not to reboot, then most of the chip will be
@@ -163,7 +167,7 @@ static void bcm2835_power_off(void)
writel_relaxed(val, wdt->base + PM_RSTS);
/* Continue with normal reset mechanism */
- bcm2835_restart(&wdt->restart_handler, REBOOT_HARD, NULL);
+ __bcm2835_restart(wdt);
}
static int bcm2835_wdt_probe(struct platform_device *pdev)
@@ -208,9 +212,6 @@ static int bcm2835_wdt_probe(struct platform_device *pdev)
return err;
}
- wdt->restart_handler.notifier_call = bcm2835_restart;
- wdt->restart_handler.priority = 128;
- register_restart_handler(&wdt->restart_handler);
if (pm_power_off == NULL)
pm_power_off = bcm2835_power_off;
@@ -222,7 +223,6 @@ static int bcm2835_wdt_remove(struct platform_device *pdev)
{
struct bcm2835_wdt *wdt = platform_get_drvdata(pdev);
- unregister_restart_handler(&wdt->restart_handler);
if (pm_power_off == bcm2835_power_off)
pm_power_off = NULL;
watchdog_unregister_device(&bcm2835_wdt_wdd);
--
2.7.4
^ permalink raw reply related
* [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Doug Anderson @ 2017-01-04 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229141707.qjrtjz7dik6a7l5s@kozik-lap>
Hi,
On Thu, Dec 29, 2016 at 6:17 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Dec 15, 2016 at 04:54:30PM -0800, Doug Anderson wrote:
>> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
>> > ===================================================================
>> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
>> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
>> > @@ -24,6 +24,16 @@
>> > };
>> >
>> > &cluster_a15_opp_table {
>> > + opp at 2000000000 {
>> > + opp-hz = /bits/ 64 <2000000000>;
>> > + opp-microvolt = <1250000>;
>> > + clock-latency-ns = <140000>;
>> > + };
>> > + opp at 1900000000 {
>> > + opp-hz = /bits/ 64 <1900000000>;
>> > + opp-microvolt = <1250000>;
>> > + clock-latency-ns = <140000>;
>> > + };
>>
>> I don't think the voltages you listed are high enough for all peach pi
>> boards for A15 at 1.9 GHz and 2.0 GHz, at least based on the research
>> I did. See my response to v1.
>
> I wanted to apply this but saw this remaining issue. Javier tested it
> on Peach Pi so is this concern still valid?
I'm not sure. It's been years since I did anything with exynos, so I
won't stand in the way if everyone else agrees that this patch is
good, but I will point out that testing on a single Peach Pi board is
not really enough given the massive difference in voltage needed
between the highest ASV group and the lowest (a whopping 112.5 mV from
looking in the Chrome OS source tree).
-Doug
^ permalink raw reply
* [PATCH v3 4/4] ARM: keystone: Drop PM domain support for k2g
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104205536.15963-1-d-gerlach@ti.com>
K2G will use a different power domain driver than the rest of the
keystone family in order to make use of the TI SCI protocol so prevent
the standard keystone pm_domain code from registering itself in
preparation for a new driver.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/mach-keystone/pm_domain.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-keystone/pm_domain.c b/arch/arm/mach-keystone/pm_domain.c
index 8cbb35765a19..fe57e2692629 100644
--- a/arch/arm/mach-keystone/pm_domain.c
+++ b/arch/arm/mach-keystone/pm_domain.c
@@ -32,7 +32,9 @@ static struct pm_clk_notifier_block platform_domain_notifier = {
};
static const struct of_device_id of_keystone_table[] = {
- {.compatible = "ti,keystone"},
+ {.compatible = "ti,k2hk"},
+ {.compatible = "ti,k2e"},
+ {.compatible = "ti,k2l"},
{ /* end of list */ },
};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104205536.15963-1-d-gerlach@ti.com>
Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider
to allow each device to attach and associate it's ti-sci-id so that it can
be controlled through the TI SCI protocol.
This driver implements a simple genpd where each device node has
a phandle to the power domain node and also must provide an index which
represents the ID to be passed with TI SCI representing the device using a
ti,sci-id property. Through this interface the genpd dev_ops start and
stop hooks will use TI SCI to turn on and off each device as determined
by pm_runtime usage.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
MAINTAINERS | 1 +
arch/arm/mach-keystone/Kconfig | 1 +
drivers/soc/ti/Kconfig | 12 +++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti_sci_pm_domains.c | 198 +++++++++++++++++++++++++++++++++++++
5 files changed, 213 insertions(+)
create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7e68af170dae..39d05f92bfcb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12146,6 +12146,7 @@ F: drivers/firmware/ti_sci*
F: include/linux/soc/ti/ti_sci_protocol.h
F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
F: include/dt-bindings/genpd/k2g.h
+F: drivers/soc/ti/ti_sci_pm_domains.c
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 24bd64dabdfc..18d49465cafb 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -9,6 +9,7 @@ config ARCH_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
select ZONE_DMA if ARM_LPAE
select PINCTRL
+ select PM_GENERIC_DOMAINS if PM
help
Support for boards based on the Texas Instruments Keystone family of
SoCs.
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 3557c5e32a93..39e152abe6b9 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -38,4 +38,16 @@ config WKUP_M3_IPC
to communicate and use the Wakeup M3 for PM features like suspend
resume and boots it using wkup_m3_rproc driver.
+config TI_SCI_PM_DOMAINS
+ tristate "TI SCI PM Domains Driver"
+ depends on TI_SCI_PROTOCOL
+ depends on PM_GENERIC_DOMAINS
+ help
+ Generic power domain implementation for TI device implementing
+ the TI SCI protocol.
+
+ To compile this as a module, choose M here. The module will be
+ called ti_sci_pm_domains. Note this is needed early in boot before
+ rootfs may be available.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index 48ff3a79634f..7d572736c86e 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
+obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
diff --git a/drivers/soc/ti/ti_sci_pm_domains.c b/drivers/soc/ti/ti_sci_pm_domains.c
new file mode 100644
index 000000000000..ec76215d64c7
--- /dev/null
+++ b/drivers/soc/ti/ti_sci_pm_domains.c
@@ -0,0 +1,198 @@
+/*
+ * TI SCI Generic Power Domain Driver
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ * J Keerthy <j-keerthy@ti.com>
+ * Dave Gerlach <d-gerlach@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/slab.h>
+#include <linux/soc/ti/ti_sci_protocol.h>
+
+/**
+ * struct ti_sci_genpd_dev_data: holds data needed for every device attached
+ * to this genpd
+ * @idx: index of the device that identifies it with the system
+ * control processor.
+ */
+struct ti_sci_genpd_dev_data {
+ int idx;
+};
+
+/**
+ * struct ti_sci_pm_domain: TI specific data needed for power domain
+ * @ti_sci: handle to TI SCI protocol driver that provides ops to
+ * communicate with system control processor.
+ * @dev: pointer to dev for the driver for devm allocs
+ * @pd: generic_pm_domain for use with the genpd framework
+ */
+struct ti_sci_pm_domain {
+ const struct ti_sci_handle *ti_sci;
+ struct device *dev;
+ struct generic_pm_domain pd;
+};
+
+#define genpd_to_ti_sci_pd(gpd) container_of(gpd, struct ti_sci_pm_domain, pd)
+
+/**
+ * ti_sci_dev_id(): get prepopulated ti_sci id from struct dev
+ * @dev: pointer to device associated with this genpd
+ *
+ * Returns device_id stored from ti,sci_id property
+ */
+static int ti_sci_dev_id(struct device *dev)
+{
+ struct generic_pm_domain_data *genpd_data = dev_gpd_data(dev);
+ struct ti_sci_genpd_dev_data *sci_dev_data = genpd_data->data;
+
+ return sci_dev_data->idx;
+}
+
+/**
+ * ti_sci_dev_to_sci_handle(): get pointer to ti_sci_handle
+ * @dev: pointer to device associated with this genpd
+ *
+ * Returns ti_sci_handle to be used to communicate with system
+ * control processor.
+ */
+static const struct ti_sci_handle *ti_sci_dev_to_sci_handle(struct device *dev)
+{
+ struct generic_pm_domain *pd = pd_to_genpd(dev->pm_domain);
+ struct ti_sci_pm_domain *ti_sci_genpd = genpd_to_ti_sci_pd(pd);
+
+ return ti_sci_genpd->ti_sci;
+}
+
+/**
+ * ti_sci_dev_start(): genpd device start hook called to turn device on
+ * @dev: pointer to device associated with this genpd to be powered on
+ */
+static int ti_sci_dev_start(struct device *dev)
+{
+ const struct ti_sci_handle *ti_sci = ti_sci_dev_to_sci_handle(dev);
+ int idx = ti_sci_dev_id(dev);
+
+ return ti_sci->ops.dev_ops.get_device(ti_sci, idx);
+}
+
+/**
+ * ti_sci_dev_stop(): genpd device stop hook called to turn device off
+ * @dev: pointer to device associated with this genpd to be powered off
+ */
+static int ti_sci_dev_stop(struct device *dev)
+{
+ const struct ti_sci_handle *ti_sci = ti_sci_dev_to_sci_handle(dev);
+ int idx = ti_sci_dev_id(dev);
+
+ return ti_sci->ops.dev_ops.put_device(ti_sci, idx);
+}
+
+static int ti_sci_pd_attach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct ti_sci_pm_domain *ti_sci_genpd = genpd_to_ti_sci_pd(domain);
+ const struct ti_sci_handle *ti_sci = ti_sci_genpd->ti_sci;
+ struct ti_sci_genpd_dev_data *sci_dev_data;
+ struct generic_pm_domain_data *genpd_data;
+ int idx, ret = 0;
+
+ ret = of_property_read_u32(np, "ti,sci-id", &idx);
+ if (ret) {
+ dev_err(ti_sci_genpd->dev, "Cannot find ti,sci-id for %s\n",
+ dev_name(dev));
+ return -ENODEV;
+ }
+
+ /*
+ * Check the validity of the requested idx, if the index is not valid
+ * the PMMC will return a NAK here and we will not allocate it.
+ */
+ ret = ti_sci->ops.dev_ops.is_valid(ti_sci, idx);
+ if (ret)
+ return -EINVAL;
+
+ sci_dev_data = kzalloc(sizeof(*sci_dev_data), GFP_KERNEL);
+ if (!sci_dev_data)
+ return -ENOMEM;
+
+ sci_dev_data->idx = idx;
+
+ genpd_data = dev_gpd_data(dev);
+ genpd_data->data = sci_dev_data;
+
+ return 0;
+}
+
+static void ti_sci_pd_detach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct generic_pm_domain_data *genpd_data = dev_gpd_data(dev);
+ struct ti_sci_genpd_dev_data *sci_dev_data = genpd_data->data;
+
+ kfree(sci_dev_data);
+ genpd_data->data = NULL;
+}
+
+static const struct of_device_id ti_sci_pm_domain_matches[] = {
+ { .compatible = "ti,sci-pm-domain", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ti_sci_pm_domain_matches);
+
+static int ti_sci_pm_domain_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct ti_sci_pm_domain *ti_sci_pd;
+ int ret;
+
+ ti_sci_pd = devm_kzalloc(dev, sizeof(*ti_sci_pd), GFP_KERNEL);
+ if (!ti_sci_pd)
+ return -ENOMEM;
+
+ ti_sci_pd->ti_sci = devm_ti_sci_get_handle(dev);
+ if (IS_ERR(ti_sci_pd->ti_sci))
+ return PTR_ERR(ti_sci_pd->ti_sci);
+
+ ti_sci_pd->dev = dev;
+
+ ti_sci_pd->pd.attach_dev = ti_sci_pd_attach_dev;
+ ti_sci_pd->pd.detach_dev = ti_sci_pd_detach_dev;
+
+ ti_sci_pd->pd.dev_ops.start = ti_sci_dev_start;
+ ti_sci_pd->pd.dev_ops.stop = ti_sci_dev_stop;
+
+ pm_genpd_init(&ti_sci_pd->pd, NULL, true);
+
+ ret = of_genpd_add_provider_simple(np, &ti_sci_pd->pd);
+
+ return ret;
+}
+
+static struct platform_driver ti_sci_pm_domains_driver = {
+ .probe = ti_sci_pm_domain_probe,
+ .driver = {
+ .name = "ti_sci_pm_domains",
+ .of_match_table = ti_sci_pm_domain_matches,
+ },
+};
+module_platform_driver(ti_sci_pm_domains_driver);
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("TI System Control Interface (SCI) Power Domain driver");
+MODULE_AUTHOR("Dave Gerlach");
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104205536.15963-1-d-gerlach@ti.com>
Add a generic power domain implementation, TI SCI PM Domains, that
will hook into the genpd framework and allow the TI SCI protocol to
control device power states.
Also, provide macros representing each device index as understood
by TI SCI to be used in the device node power-domain references.
These are identifiers for the K2G devices managed by the PMMC.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v2->v3:
Update k2g_pds node docs to show it should be a child of pmmc node.
In early versions a phandle was used to point to pmmc and docs still
incorrectly showed this.
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++++++++++
MAINTAINERS | 2 +
include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
3 files changed, 151 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 include/dt-bindings/genpd/k2g.h
diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
new file mode 100644
index 000000000000..4c9064e512cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
@@ -0,0 +1,59 @@
+Texas Instruments TI-SCI Generic Power Domain
+---------------------------------------------
+
+Some TI SoCs contain a system controller (like the PMMC, etc...) that is
+responsible for controlling the state of the IPs that are present.
+Communication between the host processor running an OS and the system
+controller happens through a protocol known as TI-SCI [1]. This pm domain
+implementation plugs into the generic pm domain framework and makes use of
+the TI SCI protocol power on and off each device when needed.
+
+[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+PM Domain Node
+==============
+The PM domain node represents the global PM domain managed by the PMMC,
+which in this case is the single implementation as documented by the generic
+PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
+Because this relies on the TI SCI protocol to communicate with the PMMC it
+must be a child of the pmmc node.
+
+Required Properties:
+--------------------
+- compatible: should be "ti,sci-pm-domain"
+- #power-domain-cells: Must be 0.
+
+Example (K2G):
+-------------
+ pmmc: pmmc {
+ compatible = "ti,k2g-sci";
+ ...
+
+ k2g_pds: k2g_pds {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <0>;
+ };
+ };
+
+PM Domain Consumers
+===================
+Hardware blocks that require SCI control over their state must provide
+a reference to the sci-pm-domain they are part of and a unique device
+specific ID that identifies the device.
+
+Required Properties:
+--------------------
+- power-domains: phandle pointing to the corresponding PM domain node.
+- ti,sci-id: index representing the device id to be passed oevr SCI to
+ be used for device control.
+
+See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
+
+Example (K2G):
+--------------------
+ uart0: serial at 02530c00 {
+ compatible = "ns16550a";
+ ...
+ power-domains = <&k2g_pds>;
+ ti,sci-id = <K2G_DEV_UART0>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index cfff2c9e3d94..7e68af170dae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12144,6 +12144,8 @@ S: Maintained
F: Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
F: drivers/firmware/ti_sci*
F: include/linux/soc/ti/ti_sci_protocol.h
+F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+F: include/dt-bindings/genpd/k2g.h
THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
M: Hans Verkuil <hverkuil@xs4all.nl>
diff --git a/include/dt-bindings/genpd/k2g.h b/include/dt-bindings/genpd/k2g.h
new file mode 100644
index 000000000000..91ad827e0ca1
--- /dev/null
+++ b/include/dt-bindings/genpd/k2g.h
@@ -0,0 +1,90 @@
+/*
+ * TI K2G SoC Device definitions
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_GENPD_K2G_H
+#define _DT_BINDINGS_GENPD_K2G_H
+
+/* Documented in http://processors.wiki.ti.com/index.php/TISCI */
+
+#define K2G_DEV_PMMC0 0x0000
+#define K2G_DEV_MLB0 0x0001
+#define K2G_DEV_DSS0 0x0002
+#define K2G_DEV_MCBSP0 0x0003
+#define K2G_DEV_MCASP0 0x0004
+#define K2G_DEV_MCASP1 0x0005
+#define K2G_DEV_MCASP2 0x0006
+#define K2G_DEV_DCAN0 0x0008
+#define K2G_DEV_DCAN1 0x0009
+#define K2G_DEV_EMIF0 0x000a
+#define K2G_DEV_MMCHS0 0x000b
+#define K2G_DEV_MMCHS1 0x000c
+#define K2G_DEV_GPMC0 0x000d
+#define K2G_DEV_ELM0 0x000e
+#define K2G_DEV_SPI0 0x0010
+#define K2G_DEV_SPI1 0x0011
+#define K2G_DEV_SPI2 0x0012
+#define K2G_DEV_SPI3 0x0013
+#define K2G_DEV_ICSS0 0x0014
+#define K2G_DEV_ICSS1 0x0015
+#define K2G_DEV_USB0 0x0016
+#define K2G_DEV_USB1 0x0017
+#define K2G_DEV_NSS0 0x0018
+#define K2G_DEV_PCIE0 0x0019
+#define K2G_DEV_GPIO0 0x001b
+#define K2G_DEV_GPIO1 0x001c
+#define K2G_DEV_TIMER64_0 0x001d
+#define K2G_DEV_TIMER64_1 0x001e
+#define K2G_DEV_TIMER64_2 0x001f
+#define K2G_DEV_TIMER64_3 0x0020
+#define K2G_DEV_TIMER64_4 0x0021
+#define K2G_DEV_TIMER64_5 0x0022
+#define K2G_DEV_TIMER64_6 0x0023
+#define K2G_DEV_MSGMGR0 0x0025
+#define K2G_DEV_BOOTCFG0 0x0026
+#define K2G_DEV_ARM_BOOTROM0 0x0027
+#define K2G_DEV_DSP_BOOTROM0 0x0029
+#define K2G_DEV_DEBUGSS0 0x002b
+#define K2G_DEV_UART0 0x002c
+#define K2G_DEV_UART1 0x002d
+#define K2G_DEV_UART2 0x002e
+#define K2G_DEV_EHRPWM0 0x002f
+#define K2G_DEV_EHRPWM1 0x0030
+#define K2G_DEV_EHRPWM2 0x0031
+#define K2G_DEV_EHRPWM3 0x0032
+#define K2G_DEV_EHRPWM4 0x0033
+#define K2G_DEV_EHRPWM5 0x0034
+#define K2G_DEV_EQEP0 0x0035
+#define K2G_DEV_EQEP1 0x0036
+#define K2G_DEV_EQEP2 0x0037
+#define K2G_DEV_ECAP0 0x0038
+#define K2G_DEV_ECAP1 0x0039
+#define K2G_DEV_I2C0 0x003a
+#define K2G_DEV_I2C1 0x003b
+#define K2G_DEV_I2C2 0x003c
+#define K2G_DEV_EDMA0 0x003f
+#define K2G_DEV_SEMAPHORE0 0x0040
+#define K2G_DEV_INTC0 0x0041
+#define K2G_DEV_GIC0 0x0042
+#define K2G_DEV_QSPI0 0x0043
+#define K2G_DEV_ARM_64B_COUNTER0 0x0044
+#define K2G_DEV_TETRIS0 0x0045
+#define K2G_DEV_CGEM0 0x0046
+#define K2G_DEV_MSMC0 0x0047
+#define K2G_DEV_CBASS0 0x0049
+#define K2G_DEV_BOARD0 0x004c
+#define K2G_DEV_EDMA1 0x004f
+
+#endif
--
2.11.0
^ permalink raw reply related
* [PATCH v3 1/4] PM / Domains: Add generic data pointer to genpd data struct
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104205536.15963-1-d-gerlach@ti.com>
Add a void *data pointer to struct generic_pm_domain_data. Because this
exists for each device associated with a genpd it will allow us to
assign per-device data if needed on a platform for control of that
specific device.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
include/linux/pm_domain.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 81ece61075df..73c9dba5cfcc 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -117,6 +117,7 @@ struct generic_pm_domain_data {
struct pm_domain_data base;
struct gpd_timing_data td;
struct notifier_block nb;
+ void *data;
};
#ifdef CONFIG_PM_GENERIC_DOMAINS
--
2.11.0
^ permalink raw reply related
* [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is v3 of the series to add support for TI-SCI Generic PM Domains.
Previous versions can be found here:
v2: https://www.spinics.net/lists/kernel/msg2364612.html
v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
This version is rebased on v4.10-rc2 but is the same as v2 with the
exception of patch 2 in which the devicetree binding documentation
needed to be updated to show the k2g_pds node should be a child of
the pmmc node. Apart from that, the acks provided by Ulf were added
to patches 1 and 3.
Now that the TI-SCI series has been merged [1] this series will be ready
to go in with an ack on the DT binding. Rob had raised some questions on
the necessity ti,sci-id property but I believe these were properly
addressed during the discussion of v2 so hopefully an ack is in order now.
Regards,
Dave
[1] http://www.spinics.net/lists/arm-kernel/msg536851.html
Dave Gerlach (4):
PM / Domains: Add generic data pointer to genpd data struct
dt-bindings: Add TI SCI PM Domains
soc: ti: Add ti_sci_pm_domains driver
ARM: keystone: Drop PM domain support for k2g
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++
MAINTAINERS | 3 +
arch/arm/mach-keystone/Kconfig | 1 +
arch/arm/mach-keystone/pm_domain.c | 4 +-
drivers/soc/ti/Kconfig | 12 ++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti_sci_pm_domains.c | 198 +++++++++++++++++++++
include/dt-bindings/genpd/k2g.h | 90 ++++++++++
include/linux/pm_domain.h | 1 +
9 files changed, 368 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
create mode 100644 include/dt-bindings/genpd/k2g.h
--
2.11.0
^ permalink raw reply
* [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Rob Herring @ 2017-01-04 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <529b-586c3500-5-5e05b080@98620974>
On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin
<peter.senna@collabora.co.uk> wrote:
> Hi Rob,
>
> Thank you for the review.
>
> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
>
>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
>> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++
>> > display bridge.
>> >
>> > Cc: Martyn Welch <martyn.welch@collabora.co.uk>
>> > Cc: Martin Donnelly <martin.donnelly@ge.com>
>> > Cc: Javier Martinez Canillas <javier@dowhile0.org>
>> > Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> > Cc: Philipp Zabel <p.zabel@pengutronix.de>
>> > Cc: Rob Herring <robh@kernel.org>
>> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> > Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
>> > ---
>> > There was an Acked-by from Rob Herring <robh@kernel.org> for V6, but I changed
>> > the bindings to use i2c_new_secondary_device() so I removed it from the commit
>> > message.
>> >
>> > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++++++++++
>>
>> Generally, bindings are not organized by vendor. Put in
>> bindings/display/bridge/... instead.
>
> Will change that.
>
>>
>> > 1 file changed, 39 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> > new file mode 100644
>> > index 0000000..1bc6ebf
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> > @@ -0,0 +1,39 @@
>> > +Driver for GE B850v3 LVDS/DP++ display bridge
>> > +
>> > +Required properties:
>> > + - compatible : should be "ge,b850v3-lvds-dp".
>>
>> Isn't '-lvds-dp' redundant? The part# should be enough.
>
> b850v3 is the name of the product, this is why the proposed name. What about, b850v3-dp2 dp2 indicating the second DP output?
Humm, b850v3 is the board name? This node should be the name of the bridge chip.
Rob
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: keystone: Add "ti, da830-uart" compatible string
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
The TI Keystone SoCs have extra UART registers beyond the standard 8250
registers, so we need a new compatible string to indicate this. Also, at
least one of these registers uses the full 32 bits, so we need to specify
reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work as
long as the bootloader configures the SoC UART power management registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v2 changes:
* This is a new patch in v2
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 63c7cf0c..7d7b9a8 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -90,7 +90,7 @@
};
uart0: serial at 02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index 0c5e74e..e91633f 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -35,7 +35,7 @@
/include/ "keystone-k2l-clocks.dtsi"
uart2: serial at 02348400 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -45,7 +45,7 @@
};
uart3: serial at 02348800 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba..9152610 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -98,7 +98,7 @@
/include/ "keystone-clocks.dtsi"
uart0: serial at 02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -108,7 +108,7 @@
};
uart1: serial at 02531000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] ARM: da850: Add ti, da830-uart compatible for serial ports
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond
the standard 8250 registers, so we need a new compatible string to
indicate this. Also, at least one of these registers uses the full 32
bits, so we need to specify reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work
as long as the bootloader configures the SoC UART power management
registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v2 changes:
* None
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..f6cd212 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -266,22 +266,25 @@
interrupt-names = "edm3_tcerrint";
};
serial0: serial at 42000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x42000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <25>;
status = "disabled";
};
serial1: serial at 10c000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10c000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <53>;
status = "disabled";
};
serial2: serial at 10d000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10d000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <61>;
status = "disabled";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/4] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x.
These SoCs have standard 8250 registers plus some extra non-standard
registers.
The UART will not function unless the non-standard Power and Emulation
Management Register (PWREMU_MGMT) is configured correctly. This is
currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
boards. Making this part of the UART driver will allow UART to work on
device-tree boards as well and the mach code can eventually be removed.
Signed-off-by: David Lechner <david@lechnology.com>
---
v2 changes:
* Added C66x to list of SoCs
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index d25ab1c..5281252 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_platform_serial_table[] = {
.data = (void *)PORT_ALTR_16550_F128, },
{ .compatible = "mrvl,mmp-uart",
.data = (void *)PORT_XSCALE, },
+ { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
{ /* end of list */ },
};
MODULE_DEVICE_TABLE(of, of_platform_serial_table);
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fe4399b..61dd806 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -273,6 +273,15 @@ static const struct serial8250_config uart_config[] = {
.rxtrig_bytes = {1, 4, 8, 14},
.flags = UART_CAP_FIFO,
},
+ [PORT_DA830] = {
+ .name = "TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
+ UART_FCR_R_TRIG_10,
+ .rxtrig_bytes = {1, 4, 8, 14},
+ .flags = UART_CAP_FIFO | UART_CAP_AFE,
+ },
};
/* Uart divisor latch read */
@@ -2118,6 +2127,19 @@ int serial8250_do_startup(struct uart_port *port)
serial_port_out(port, UART_LCR, 0);
}
+ if (port->type == PORT_DA830) {
+ /* Reset the port */
+ serial_port_out(port, UART_IER, 0);
+ serial_port_out(port, UART_DA830_PWREMU_MGMT, 0);
+ mdelay(10);
+
+ /* Enable Tx, Rx and free run mode */
+ serial_port_out(port, UART_DA830_PWREMU_MGMT,
+ UART_DA830_PWREMU_MGMT_UTRST |
+ UART_DA830_PWREMU_MGMT_URRST |
+ UART_DA830_PWREMU_MGMT_FREE);
+ }
+
#ifdef CONFIG_SERIAL_8250_RSA
/*
* If this is an RSA port, see if we can kick it up to the
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 99dbed8..1265918 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -56,7 +56,8 @@
#define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
#define PORT_RT2880 29 /* Ralink RT2880 internal UART */
#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
-#define PORT_MAX_8250 30 /* max port ID */
+#define PORT_DA830 31 /* TI DA8xx/OMAP13x/AM17xx/AM18xx/C66x */
+#define PORT_MAX_8250 31 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index b4c0484..84606d8 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -327,6 +327,14 @@
#define SERIAL_RSA_BAUD_BASE (921600)
#define SERIAL_RSA_BAUD_BASE_LO (SERIAL_RSA_BAUD_BASE / 8)
+/* Extra registers for TI DA8xx/OMAP13x/AM17xx/AM18xx/C66x */
+#define UART_DA830_PWREMU_MGMT 12
+
+/* PWREMU_MGMT register bits */
+#define UART_DA830_PWREMU_MGMT_FREE (1 << 0) /* Free-running mode */
+#define UART_DA830_PWREMU_MGMT_URRST (1 << 13) /* Receiver reset/enable */
+#define UART_DA830_PWREMU_MGMT_UTRST (1 << 14) /* Transmitter reset/enable */
+
/*
* Extra serial register definitions for the internal UARTs
* in TI OMAP processors.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/4] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v2 changes:
* picked up Acked-by:
Documentation/devicetree/bindings/serial/8250.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index f86bb06..10276a4 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -19,6 +19,7 @@ Required properties:
- "altr,16550-FIFO128"
- "fsl,16550-FIFO64"
- "fsl,ns16550"
+ - "ti,da830-uart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/4] TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x UART
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: linux-arm-kernel
This series adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
UART. This SoCs have a non-standard register for UART power management that
needs special handling in the UART driver.
v2 changes:
* Added references to C66x SoC in various places, which I assume is an OK
shorthand for TI Keystone processors.
* New patch for Keystone device tree. This is untested as I don't have any
Keystone boards.
David Lechner (4):
doc: DT: Add ti,da830-uart to serial/8250 bindings
serial: 8250: Add new port type for TI
DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
ARM: da850: Add ti,da830-uart compatible for serial ports
ARM: dts: keystone: Add "ti,da830-uart" compatible string
Documentation/devicetree/bindings/serial/8250.txt | 1 +
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
9 files changed, 45 insertions(+), 9 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v6 05/14] ACPI: platform-msi: retrieve dev id from IORT
From: Lorenzo Pieralisi @ 2017-01-04 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483363905-2806-6-git-send-email-hanjun.guo@linaro.org>
On Mon, Jan 02, 2017 at 09:31:36PM +0800, Hanjun Guo wrote:
> For devices connecting to ITS, it needs dev id to identify
> itself, and this dev id is represented in the IORT table in
> named componant node [1] for platform devices, so in this
> patch we will scan the IORT to retrieve device's dev id.
>
> Introduce iort_pmsi_get_dev_id() with pointer dev passed
> in for that purpose.
>
> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Tested-by: Majun <majun258@huawei.com>
> Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/acpi/arm64/iort.c | 26 ++++++++++++++++++++++++++
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +++-
> include/linux/acpi_iort.h | 8 ++++++++
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 174e983..ab7bae7 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -444,6 +444,32 @@ u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> }
>
> /**
> + * iort_pmsi_get_dev_id() - Get the device id for a device
> + * @dev: The device for which the mapping is to be done.
> + * @dev_id: The device ID found.
> + *
> + * Returns: 0 for successful find a dev id, errors otherwise
> + */
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + struct acpi_iort_node *node;
> +
> + if (!iort_table)
> + return -ENODEV;
> +
> + node = iort_find_dev_node(dev);
> + if (!node) {
> + dev_err(dev, "can't find related IORT node\n");
> + return -ENODEV;
> + }
> +
> + if(!iort_node_get_id(node, dev_id, IORT_MSI_TYPE, 0))
I disagree with this approach. For named components we know that
there are always two steps involved (second optional):
(1) Retrieve the initial id (this may well provide the final mapping)
(2) Map the id (optional if (1) represents the map type we need)
That's the reason why I kept iort_node_get_id() and iort_node_map_rid()
separated.
Now, what we can do is to create an iort_node_map_id() function that is
PCI agnostic (ie rename rid to id :)), whose rid_in is either a PCI RID
or the outcome of a previous call to iort_node_get_id() for named
components, that's in my opinion cleaner.
It would be even cleaner if you passed a type_mask (or write a
wrapper function for that) that is:
(IORT_MSI_TYPE | IORT_IOMMU_TYPE)
and we just use the returned parent pointer to check if the mapping
providing the initial id correspond to the type we are looking for (eg
ITS) or we need to map the retrieved initial id any further, with
iort_node_map_id(), to get to the final identifier.
Thoughts ?
Thanks,
Lorenzo
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> +/**
> * iort_dev_find_its_id() - Find the ITS identifier for a device
> * @dev: The device.
> * @req_id: Device's Requster ID
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 3c94278..16587a9 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -15,6 +15,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi_iort.h>
> #include <linux/device.h>
> #include <linux/msi.h>
> #include <linux/of.h>
> @@ -56,7 +57,8 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
>
> msi_info = msi_get_domain_info(domain->parent);
>
> - ret = of_pmsi_get_dev_id(domain, dev, &dev_id);
> + ret = dev->of_node ? of_pmsi_get_dev_id(domain, dev, &dev_id) :
> + iort_pmsi_get_dev_id(dev, &dev_id);
> if (ret)
> return ret;
>
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 77e0809..ef99fd52 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -33,6 +33,7 @@
> void acpi_iort_init(void);
> bool iort_node_match(u8 type);
> u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> +int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id);
> struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> @@ -42,9 +43,16 @@ static inline void acpi_iort_init(void) { }
> static inline bool iort_node_match(u8 type) { return false; }
> static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> { return req_id; }
> +
> static inline struct irq_domain *iort_get_device_domain(struct device *dev,
> u32 req_id)
> { return NULL; }
> +
> +static inline int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
> +{
> + return -ENODEV;
> +}
> +
> /* IOMMU interface */
> static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
> --
> 1.9.1
>
^ permalink raw reply
* [RFC PATCH 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Will Deacon @ 2017-01-04 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104103713.GH25813@worktop.programming.kicks-ass.net>
Hi Peter,
On Wed, Jan 04, 2017 at 11:37:13AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 03, 2017 at 06:10:26PM +0000, Will Deacon wrote:
> > The ARMv8.2 architecture introduces the Statistical Profiling Extension
> > (SPE). SPE provides a way to configure and collect profiling samples
> > from the CPU in the form of a trace buffer, which can be mapped directly
> > into userspace using the perf AUX buffer infrastructure.
> >
> > This patch adds support for SPE in the form of a new perf driver.
> >
>
> Can you give a little high level overview of what exactly SPE is?
Sure, I can try, although there is no public documentation yet so it's a
bit fiddly.
SPE can be used to profile a population of operations in the CPU pipeline
after instruction decode. These are either architected instructions (i.e.
a dynamic instruction trace) or CPU-specific uops and the choice is fixed
statically in the hardware and advertised to userspace via caps/. Sampling
is controlled using a sampling interval, similar to a regular PMU counter,
but also with an optional random perturbation to avoid falling into patterns
where you continuously profile the same instruction in a hot loop.
After each operation is decoded, the interval counter is decremented. When
it hits zero, an operation is chosen for profiling and tracked within the
pipeline until it retires. Along the way, information such as TLB lookups,
cache misses, time spent to issue etc is captured in the form of a sample.
The sample is then filtered according to certain criteria (e.g. load
latency) that can be specified in the event config (described under
format/) and, if the sample satisfies the filter, it is written out to
memory as a record, otherwise it is discarded. Only one operation can
be sampled at a time.
The in-memory buffer is linear and virtually addressed, raising an
interrupt when it fills up. The PMU driver handles these interrupts to
give the appearance of a ring buffer, as expected by the AUX code.
The in-memory trace-like format is self-describing (though not parseable
in reverse) and written as a series of records, with each record
corresponding to a sample and consisting of a sequence of packets. These
packets are defined by the architecture, although some have CPU-specific
fields for recording information specific to the microarchitecture.
As a simple example, a record generated for a branch instruction may
consist of the following packets:
0 (Address) : Virtual PC of the branch instruction
1 (Type) : Conditional direct branch
2 (Counter) : Number of cycles taken from Dispatch to Issue
3 (Address) : Virtual branch target + condition flags
4 (Counter) : Number of cycles taken from Dispatch to Complete
5 (Events) : Mispredicted as not-taken
6 (END) : End of record
You can also toggle things like timestamp packets in each record.
Since SPE is an optional extension to the architecture, I'm sure there
will be big.LITTLE systems where only one of the clusters has SPE support,
so the driver is slightly complicated by handling that.
Will
^ permalink raw reply
* [PATCH 2/2] mmc: sdhci-iproc: Increase max_blk_size for bcm2835
From: Scott Branden @ 2017-01-04 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87o9zonhoz.fsf@eliezer.anholt.net>
On 17-01-03 10:04 AM, Eric Anholt wrote:
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
>> According to the BCM2835 datasheet the maximum block size for the
>> eMMC module is restricted to the internal data FIFO which is 1024 byte.
>> But this is still an improvement to the default of 512 byte.
>
> Confirmed that the internal FIFOs are 1k.
>
> Reviewed-by: Eric Anholt <eric@anholt.net>
>
Acked-by: Scott Branden <scott.branden@broadcom.com>
^ permalink raw reply
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