* [PATCH v4 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Rob Herring @ 2016-11-14 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109115715.2557-4-romain.perier@free-electrons.com>
On Wed, Nov 09, 2016 at 12:57:15PM +0100, Romain Perier wrote:
> This commit documents the compatible string to have the compatibility for
> the I2C unit found in the Armada 3700.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
>
> Changes in v2:
> - Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
> and not "marvell,armada-3700".
>
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM64: configs: Activate Internal PHY for Meson GXL
From: Kevin Hilman @ 2016-11-14 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114094250.25059-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/configs/defconfig | 3 +++
> 1 file changed, 3 insertions(+)
Appled to v4.10/defconfig,
Kevin
^ permalink raw reply
* [PATCH 0/2] ARM: da850: enable the MSTPRI and DDR2/mDDR drivers
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
This is a follow-up for my previous series:
ARM: da850: new drivers for better LCDC support
from which the new drivers were merged, while the patch adding the
panel node was nacked and has been dropped.
The first patch in this series enables the new drivers in da850.dtsi.
It has been changed since the last iteration to not disable the added
nodes. Also: the patch enabling the nodes in da850-lcdk.dts has been
dropped too.
The second patch updates the davinci defconfig.
Bartosz Golaszewski (2):
ARM: dts: da850: add the mstpri and ddrctl nodes
ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
arch/arm/boot/dts/da850.dtsi | 9 +++++++++
arch/arm/configs/davinci_all_defconfig | 2 ++
2 files changed, 11 insertions(+)
--
2.9.3
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479144724-14231-1-git-send-email-bgolaszewski@baylibre.com>
Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
controller drivers to da850.dtsi.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1bb1f6d..1635218 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -440,6 +440,11 @@
interrupts = <52>;
status = "disabled";
};
+
+ mstpri: mstpri at 14110 {
+ compatible = "ti,da850-mstpri";
+ reg = <0x14110 0x0c>;
+ };
};
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
@@ -451,4 +456,8 @@
1 0 0x68000000 0x00008000>;
status = "disabled";
};
+ ddrctl: ddrctl at b0000000 {
+ compatible = "ti,da850-ddr-controller";
+ reg = <0xb0000000 0xe8>;
+ };
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479144724-14231-1-git-send-email-bgolaszewski@baylibre.com>
With the da8xx memory controller and master peripheral priority
drivers merged and corresponding device tree changes in place we can
now enable appropriate options by default.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978f..f814f01 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -56,6 +56,7 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_FW_LOADER is not set
+CONFIG_DA8XX_MSTPRI=y
CONFIG_MTD=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_CFI=m
@@ -187,6 +188,7 @@ CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
+CONFIG_DA8XX_DDRCTL=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_XFS_FS=m
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: apq8064: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108191343.GP25787@tuxbot>
Thanks Bjorn for review comments.
On 08/11/16 19:13, Bjorn Andersson wrote:
> On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote:
>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> arch/arm/boot/dts/qcom-apq8064.dtsi | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
>> index 1dbe697..fde006c 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
>> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
>> @@ -627,6 +627,34 @@
>> clock-names = "core";
>> };
>>
>> + qcom,ssbi at c00000 {
>
> No "qcom," in the node name.
Will fix it in next version, I agree with rest of the comments too.
All of them will be fixed in next version.
>
>> + compatible = "qcom,ssbi";
>> + reg = <0x00c00000 0x1000>;
>> + qcom,controller-type = "pmic-arbiter";
>> +
>> + pmicintc2: pmic at 1 {
>
> I think we should follow Linus' lead and label this "pm8821".
>
>> + compatible = "qcom,pm8821";
>> + interrupt-parent = <&tlmm_pinmux>;
>> + interrupts = <76 8>;
>
> Please spell out IRQ_TYPE_LEVEL_LOW.
>
> And interrupts-extended = <&tlmm_pinmux 76 IRQ_TYPE_LEVEL_LOW> combines
> the two lines nicely.
>
>> + #interrupt-cells = <2>;
>> + interrupt-controller;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + pm8821_mpps: mpps at 50 {
>> +
>
> Extra newline.
>
>> + compatible = "qcom,pm8821-mpp", "qcom,ssbi-mpp";
>> + reg = <0x50>;
>> +
>> + interrupts = <24 1>, <25 1>, <26 1>,
>> + <27 1>;
>
> I think these should be IRQ_TYPE_NONE per the discussion on how to share
> interrupts between the gpio/mpp driver and other clients.
>
> On the other hand, per the pm8821 driver we only support LEVEL_LOW
> (high?).
>
>> +
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> + };
>> + };
>> +
>
> Regards,
> Bjorn
>
^ permalink raw reply
* [PATCH] arm64: dts: juno: fix cluster sleep state entry latency on all SoC versions
From: Liviu Dudau @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479137189-15378-1-git-send-email-sudeep.holla@arm.com>
On Mon, Nov 14, 2016 at 03:26:29PM +0000, Sudeep Holla wrote:
> The core and the cluster sleep state entry latencies can't be same as
> cluster sleep involves more work compared to core level e.g. shared
> cache maintenance.
>
> Experiments have shown on an average about 100us more latency for the
> cluster sleep state compared to the core level sleep. This patch fixes
> the entry latency for the cluster sleep state.
>
> Fixes: 28e10a8f3a03 ("arm64: dts: juno: Add idle-states to device tree")
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: "Jon Medhurst (Tixy)" <tixy@linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Looks sensible to me.
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-r1.dts | 2 +-
> arch/arm64/boot/dts/arm/juno-r2.dts | 2 +-
> arch/arm64/boot/dts/arm/juno.dts | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> Hi,
>
> This was found recently when I found that core sleep was chosen when
> entering suspend-to-idle state on Juno. Since the wakeup(entry+exit)
> latency matched for the both states, cpu sleep state was chosen to enter
> in suspend-to-idle.
>
> Regards,
> Sudeep
>
> diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts b/arch/arm64/boot/dts/arm/juno-r1.dts
> index 3be8a3ef671c..eec37feee8fc 100644
> --- a/arch/arm64/boot/dts/arm/juno-r1.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r1.dts
> @@ -76,7 +76,7 @@
> compatible = "arm,idle-state";
> arm,psci-suspend-param = <0x1010000>;
> local-timer-stop;
> - entry-latency-us = <300>;
> + entry-latency-us = <400>;
> exit-latency-us = <1200>;
> min-residency-us = <2500>;
> };
> diff --git a/arch/arm64/boot/dts/arm/juno-r2.dts b/arch/arm64/boot/dts/arm/juno-r2.dts
> index 614fc9227943..28f40ec44090 100644
> --- a/arch/arm64/boot/dts/arm/juno-r2.dts
> +++ b/arch/arm64/boot/dts/arm/juno-r2.dts
> @@ -76,7 +76,7 @@
> compatible = "arm,idle-state";
> arm,psci-suspend-param = <0x1010000>;
> local-timer-stop;
> - entry-latency-us = <300>;
> + entry-latency-us = <400>;
> exit-latency-us = <1200>;
> min-residency-us = <2500>;
> };
> diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
> index 6b4135e9cfe5..ac5ceb73f45f 100644
> --- a/arch/arm64/boot/dts/arm/juno.dts
> +++ b/arch/arm64/boot/dts/arm/juno.dts
> @@ -76,7 +76,7 @@
> compatible = "arm,idle-state";
> arm,psci-suspend-param = <0x1010000>;
> local-timer-stop;
> - entry-latency-us = <300>;
> + entry-latency-us = <400>;
> exit-latency-us = <1200>;
> min-residency-us = <2500>;
> };
> --
> 2.7.4
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH 0/5] net: thunderx: Miscellaneous fixes
From: David Miller @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2948c47d-0f15-8153-440b-7a2c753b7251@suse.com>
From: Matthias Brugger <mbrugger@suse.com>
Date: Mon, 14 Nov 2016 13:01:25 +0100
>
>
> On 14/11/16 11:54, sunil.kovvuri at gmail.com wrote:
>> From: Sunil Goutham <sgoutham@cavium.com>
>>
>> This patchset includes fixes for incorrect LMAC credits,
>> unreliable driver statistics, memory leak upon interface
>> down e.t.c
>>
>
> Are these fixes relevant to for older kernels as well?
> If so, please add "Cc: stable at vger.kernel.org" to the Sigend-off list.
This is not appropriate for networking patches.
People instead explicitly request -stable inclusion when the
submit networking changes to me, and I queue them up for
later submission.
^ permalink raw reply
* [PATCH 1/2] mfd: pm8921: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108190751.GO25787@tuxbot>
Thanks Bjorn for review comments.
On 08/11/16 19:07, Bjorn Andersson wrote:
> On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote:
>
>> This patch adds support to PM8821 PMIC and interrupt support.
>> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>>
>
> Linus Walleij has a patch out for renaming a lot of things in this file,
> so we should probably make sure that lands and then rebase this ontop.
>
Yep, Will rebase on top of it.
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> Tested this patch for MPP and IRQ functionality on IFC6410 and SD600 EVAL
>> board with mpps PM8821 and PM8921.
>>
>> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
>> drivers/mfd/pm8921-core.c | 368 +++++++++++++++++++--
>> 2 files changed, 340 insertions(+), 29 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> index 37a088f..8f1b4ec 100644
>> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
>> Definition: must be one of:
>> "qcom,pm8058"
>> "qcom,pm8921"
>> + "qcom,pm8821"
>>
>> - #address-cells:
>> Usage: required
>> diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c
>> index 0e3a2ea..28c2470 100644
>> --- a/drivers/mfd/pm8921-core.c
>> +++ b/drivers/mfd/pm8921-core.c
>> @@ -28,16 +28,26 @@
>> #include <linux/mfd/core.h>
>>
>> #define SSBI_REG_ADDR_IRQ_BASE 0x1BB
>> -
>> -#define SSBI_REG_ADDR_IRQ_ROOT (SSBI_REG_ADDR_IRQ_BASE + 0)
>> -#define SSBI_REG_ADDR_IRQ_M_STATUS1 (SSBI_REG_ADDR_IRQ_BASE + 1)
>> -#define SSBI_REG_ADDR_IRQ_M_STATUS2 (SSBI_REG_ADDR_IRQ_BASE + 2)
>> -#define SSBI_REG_ADDR_IRQ_M_STATUS3 (SSBI_REG_ADDR_IRQ_BASE + 3)
>> -#define SSBI_REG_ADDR_IRQ_M_STATUS4 (SSBI_REG_ADDR_IRQ_BASE + 4)
>> -#define SSBI_REG_ADDR_IRQ_BLK_SEL (SSBI_REG_ADDR_IRQ_BASE + 5)
>> -#define SSBI_REG_ADDR_IRQ_IT_STATUS (SSBI_REG_ADDR_IRQ_BASE + 6)
>> -#define SSBI_REG_ADDR_IRQ_CONFIG (SSBI_REG_ADDR_IRQ_BASE + 7)
>> -#define SSBI_REG_ADDR_IRQ_RT_STATUS (SSBI_REG_ADDR_IRQ_BASE + 8)
>
> Keep these (per argumentation that follows), but try to name them
> appropriately.
>
Yes, I agree, I will address all the comments related to register
defines in next version.
...
>
>>
>> #define PM_IRQF_LVL_SEL 0x01 /* level select */
>> #define PM_IRQF_MASK_FE 0x02 /* mask falling edge */
>> @@ -54,30 +64,41 @@
>> #define REG_HWREV_2 0x0E8 /* PMIC4 revision 2 */
>>
>> #define PM8921_NR_IRQS 256
>> +#define PM8821_NR_IRQS 112
>>
>> struct pm_irq_chip {
>> struct regmap *regmap;
>> spinlock_t pm_irq_lock;
>> struct irq_domain *irqdomain;
>> + unsigned int irq_reg_base;
>> unsigned int num_irqs;
>> unsigned int num_blocks;
>> unsigned int num_masters;
>> u8 config[0];
>> };
>>
>> +struct pm8xxx_data {
>> + int num_irqs;
>> + unsigned int irq_reg_base;
>
> As far as I can see this is always SSBI_PM8821_REG_ADDR_IRQ_BASE in the
> 8821 functions and SSBI_REG_ADDR_IRQ_BASE in the pm8xxx functions. If
> you have disjunct code paths I think it's better to not obscure this
> with a variable.
>
> Try renaming the constants appropriately instead. This also has the
> benefit of reducing the size of the patch slightly.
>
Yep, will remove reg_base variable.
>>
...
>>
>> +static int pm8821_read_master_irq(const struct pm_irq_chip *chip,
>> + int m, unsigned int *master)
>> +{
>
> I think you should inline this, as you already have the calls unrolled
> in pm8821_irq_handler().
We can just call regmap_read directly from the caller function, and get
rid of this function all together.
>
>> + unsigned int base;
>> +
>> + if (!m)
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
>> + else
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
>> +
>> + return regmap_read(chip->regmap, base, master);
>> +}
>> +
>> +static int pm8821_read_block_irq(struct pm_irq_chip *chip, int master,
>> + u8 block, unsigned int *bits)
>> +{
>> + int rc;
>> +
>> + unsigned int base;
>
> Odd empty line between rc and base. (And btw, sorting your local
> variables in descending length make things pretty).
Yep, will fix it in next version.
>
>> +
>> + if (!master)
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
>> + else
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
>> +
>> + spin_lock(&chip->pm_irq_lock);
>
> The reason why this is done under a lock in the other case is because
> the status register is paged, so you shouldn't need it here.
>
Thanks for the info, will remove it.
> With this updated I think you can favorably inline this into
> pm8821_irq_block_handler().
>
>> +
>> + rc = regmap_read(chip->regmap, base + block, bits);
>> + if (rc)
>> + pr_err("Failed Reading Status rc=%d\n", rc);
>> +
>> + spin_unlock(&chip->pm_irq_lock);
>> + return rc;
>> +}
>> +
>> +static int pm8821_irq_block_handler(struct pm_irq_chip *chip,
>> + int master_number, int block)
>> +{
>> + int pmirq, irq, i, ret;
>> + unsigned int bits;
>> +
>> + ret = pm8821_read_block_irq(chip, master_number, block, &bits);
>> + if (ret) {
>> + pr_err("Failed reading %d block ret=%d", block, ret);
>> + return ret;
>> + }
>> + if (!bits) {
>> + pr_err("block bit set in master but no irqs: %d", block);
>> + return 0;
>> + }
>> +
>> + /* Convert block offset to global block number */
>> + block += (master_number * PM8821_BLOCKS_PER_MASTER) - 1;
>
> So this is block -= 1 for master 0 and block += 6 for master 1, is the
> latter correct?
>
Yes, both of them are correct.
for master 0 which has block numbers from 1-7 should translate to 0-6 in
linear space.
for master 1 which has block numbers from 1-7 should translate to 7-13
in linear space.
so for master0 it is -=1 and and for master1 it is +=6 seems correct.
>> +
>> + /* Check IRQ bits */
>> + for (i = 0; i < 8; i++) {
>> + if (bits & BIT(i)) {
>> + pmirq = block * 8 + i;
>> + irq = irq_find_mapping(chip->irqdomain, pmirq);
>> + generic_handle_irq(irq);
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int pm8821_irq_read_master(struct pm_irq_chip *chip,
>> + int master_number, u8 master_val)
>
> This isn't so much a matter of "reading master X" as "handle master X".
>
Agreed, it would be more consistent with pm8xxx too.
> Also, you don't care about the return value, so no need to return one...
>
Yep will fix it.
>> +{
>> + int ret = 0;
>> + int block;
>> +
>> + for (block = 1; block < 8; block++) {
>> + if (master_val & BIT(block)) {
>> + ret |= pm8821_irq_block_handler(chip,
>> + master_number, block);
>> + }
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + int ret;
>> + unsigned int master;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + /* check master 0 */
>> + ret = pm8821_read_master_irq(chip, 0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
>> + return;
>> + }
>> +
>> + if (master & ~PM8821_IRQ_MASTER1_SET)
>
> Rather than having a define for MASTER1_SET use BIT(0) here and write a
> comment like:
>
Yep, I will add some comments in this area.
> "bits 1 through 7 marks the first 7 blocks"
>
>> + pm8821_irq_read_master(chip, 0, master);
>> +
>
> and then
>
> "bit 0 is set if second master contains any bits"
>
> Or just skip this optimization and check the two masters unconditionally
> in a loop.
>
>> + /* check master 1 */
>> + if (!(master & PM8821_IRQ_MASTER1_SET))
>> + goto done;
>> +
>> + ret = pm8821_read_master_irq(chip, 1, &master);
>> + if (ret) {
>> + pr_err("Failed to read master 1 ret=%d\n", ret);
>> + return;
>> + }
>> +
>> + pm8821_irq_read_master(chip, 1, master);
>> +
>> +done:
>> + chained_irq_exit(irq_chip, desc);
>> +}
>> +
>> static void pm8xxx_irq_mask_ack(struct irq_data *d)
>> {
>> struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> @@ -254,13 +394,15 @@ static int pm8xxx_irq_get_irqchip_state(struct irq_data *d,
>> irq_bit = pmirq % 8;
>>
>> spin_lock(&chip->pm_irq_lock);
>> - rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_BLK_SEL, block);
>> + rc = regmap_write(chip->regmap, chip->irq_reg_base +
>> + SSBI_REG_ADDR_IRQ_BLK_SEL, block);
>> if (rc) {
>> pr_err("Failed Selecting Block %d rc=%d\n", block, rc);
>> goto bail;
>> }
>>
>> - rc = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_RT_STATUS, &bits);
>> + rc = regmap_read(chip->regmap, chip->irq_reg_base +
>> + SSBI_REG_ADDR_IRQ_RT_STATUS, &bits);
>> if (rc) {
>> pr_err("Failed Reading Status rc=%d\n", rc);
>> goto bail;
>> @@ -299,6 +441,151 @@ static const struct irq_domain_ops pm8xxx_irq_domain_ops = {
>> .map = pm8xxx_irq_domain_map,
>> };
>>
>> +static void pm8821_irq_mask_ack(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int base, pmirq = irqd_to_hwirq(d);
>> + u8 block, master;
>> + int irq_bit, rc;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>
> You can deobfuscate this somewhat by instead of testing for !master
> below you just do:
>
> if (block < PM8821_BLOCKS_PER_MASTER) {
> base =
> } else {
> base =
> block -= PM8821_BLOCKS_PER_MASTER;
> }
>
Done some cleanup in register defines which avoids this totally.
>> +
>> + if (!master)
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
>> + else
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
>> +
>> + spin_lock(&chip->pm_irq_lock);
>
> The irqchip code grabs a lock on the irq_desc, so this can't race with
> unmask - and the regmap_update_bits() is internally protecting the
> read/write cycle.
>
> So you shouldn't need to lock around this section.
>
Yep.
>> + rc = regmap_update_bits(chip->regmap,
>> + base + PM8821_IRQ_MASK_REG_OFFSET + block,
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>> + if (rc) {
>> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
>> + goto fail;
>> + }
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + base + PM8821_IRQ_CLEAR_OFFSET + block,
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>> + if (rc) {
>> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
>> + pmirq, rc);
>> + }
>> +
>> +fail:
>> + spin_unlock(&chip->pm_irq_lock);
>> +}
>> +
>> +static void pm8821_irq_unmask(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int base, pmirq = irqd_to_hwirq(d);
>> + int irq_bit, rc;
>> + u8 block, master;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>
> As mask().
>
>> +
>> + if (!master)
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
>> + else
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
>> +
>> + spin_lock(&chip->pm_irq_lock);
>
> As mask().
>
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + base + PM8821_IRQ_MASK_REG_OFFSET + block,
>> + BIT(irq_bit), ~BIT(irq_bit));
>> +
>> + if (rc)
>> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
>> +
>> + spin_unlock(&chip->pm_irq_lock);
>> +}
>> +
>> +static int pm8821_irq_set_type(struct irq_data *d, unsigned int flow_type)
>> +{
>> +
>> + /*
>> + * PM8821 IRQ controller does not have explicit software support for
>> + * IRQ flow type.
>> + */
>
> Is returning "success" here the right thing to do? Shouldn't we just
> omit the function? Or did you perhaps hit some clients that wouldn't
> deal with that?
>
Will remove this totally.
>> + return 0;
>> +}
>> +
>> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
>> + enum irqchip_irq_state which,
>> + bool *state)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + int pmirq, rc;
>> + u8 block, irq_bit, master;
>> + unsigned int bits;
>> + unsigned int base;
>> + unsigned long flags;
>> +
>> + pmirq = irqd_to_hwirq(d);
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>
> Simplify as in mask().
taken care by new register defines.
>
>> + if (!master)
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER0;
>> + else
>> + base = chip->irq_reg_base + SSBI_REG_ADDR_IRQ_MASTER1;
>> +
>> + spin_lock_irqsave(&chip->pm_irq_lock, flags);
>
> No need to lock here as we're just reading a single register.
>
yep done.
>> +
>> + rc = regmap_read(chip->regmap,
>> + base + PM8821_IRQ_RT_STATUS_OFFSET + block, &bits);
>> + if (rc) {
>> + pr_err("Failed Reading Status rc=%d\n", rc);
>> + goto bail_out;
>> + }
>> +
>> + *state = !!(bits & BIT(irq_bit));
>> +
>> +bail_out:
>> + spin_unlock_irqrestore(&chip->pm_irq_lock, flags);
>> +
>> + return rc;
>> +}
>> +
>> +static struct irq_chip pm8821_irq_chip = {
>> + .name = "pm8821",
>> + .irq_mask_ack = pm8821_irq_mask_ack,
>> + .irq_unmask = pm8821_irq_unmask,
>> + .irq_set_type = pm8821_irq_set_type,
>> + .irq_get_irqchip_state = pm8821_irq_get_irqchip_state,
>> + .flags = IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE,
>> +};
>> +
>
> Regards,
> Bjorn
>
^ permalink raw reply
* [PATCH 0/5] net: thunderx: Miscellaneous fixes
From: Matthias Brugger @ 2016-11-14 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114.123253.476733911183519472.davem@davemloft.net>
On 11/14/2016 06:32 PM, David Miller wrote:
> From: Matthias Brugger <mbrugger@suse.com>
> Date: Mon, 14 Nov 2016 13:01:25 +0100
>
>>
>>
>> On 14/11/16 11:54, sunil.kovvuri at gmail.com wrote:
>>> From: Sunil Goutham <sgoutham@cavium.com>
>>>
>>> This patchset includes fixes for incorrect LMAC credits,
>>> unreliable driver statistics, memory leak upon interface
>>> down e.t.c
>>>
>>
>> Are these fixes relevant to for older kernels as well?
>> If so, please add "Cc: stable at vger.kernel.org" to the Sigend-off list.
>
> This is not appropriate for networking patches.
>
> People instead explicitly request -stable inclusion when the
> submit networking changes to me, and I queue them up for
> later submission.
>
Ok, thanks for clarification.
^ permalink raw reply
* [PATCHv2 00/11] arm64: move thread_info off of the task stack
From: Catalin Marinas @ 2016-11-14 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478204593-29145-1-git-send-email-mark.rutland@arm.com>
On Thu, Nov 03, 2016 at 08:23:02PM +0000, Mark Rutland wrote:
> Mark Rutland (11):
> arm64: thread_info remove stale items
> arm64: asm-offsets: remove unused definitions
> arm64: factor out current_stack_pointer
> arm64: traps: simplify die() and __die()
> arm64: unexport walk_stackframe
> arm64: prep stack walkers for THREAD_INFO_IN_TASK
> arm64: move sp_el0 and tpidr_el1 into cpu_suspend_ctx
> arm64: smp: prepare for smp_processor_id() rework
> arm64: make cpu number a percpu variable
> arm64: assembler: introduce ldr_this_cpu
> arm64: split thread_info from task stack
I queued these patches for 4.10, together with the two on
core-ti-stack-split (subject to more testing).
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 17:52 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support to PM8821 PMIC and interrupt support.
PM8821 is companion device that supplements primary PMIC PM8921 IC.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes from v1:
- Removed unnessary locking spotted by Bjorn
- updated register naming to reflect PM8821
- lot of cleanups suggested by Bjorn
- rebased on top of Linus Walleij's pm8xxx namespace
cleanup patch.
.../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
2 files changed, 238 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
index 37a088f..8f1b4ec 100644
--- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
@@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
Definition: must be one of:
"qcom,pm8058"
"qcom,pm8921"
+ "qcom,pm8821"
- #address-cells:
Usage: required
diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
index 7f9620e..dc347d3 100644
--- a/drivers/mfd/qcom-pm8xxx.c
+++ b/drivers/mfd/qcom-pm8xxx.c
@@ -24,6 +24,7 @@
#include <linux/err.h>
#include <linux/ssbi.h>
#include <linux/regmap.h>
+#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/mfd/core.h>
@@ -39,6 +40,20 @@
#define SSBI_REG_ADDR_IRQ_CONFIG (SSBI_REG_ADDR_IRQ_BASE + 7)
#define SSBI_REG_ADDR_IRQ_RT_STATUS (SSBI_REG_ADDR_IRQ_BASE + 8)
+#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
+#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
+#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
+#define PM8821_SSBI_REG(m, b, offset) \
+ ((m == 0) ? \
+ (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
+ (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
+#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
+#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
+#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
+#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
+
+#define PM8821_BLOCKS_PER_MASTER 7
+
#define PM_IRQF_LVL_SEL 0x01 /* level select */
#define PM_IRQF_MASK_FE 0x02 /* mask falling edge */
#define PM_IRQF_MASK_RE 0x04 /* mask rising edge */
@@ -54,6 +69,7 @@
#define REG_HWREV_2 0x0E8 /* PMIC4 revision 2 */
#define PM8XXX_NR_IRQS 256
+#define PM8821_NR_IRQS 112
struct pm_irq_chip {
struct regmap *regmap;
@@ -65,6 +81,12 @@ struct pm_irq_chip {
u8 config[0];
};
+struct pm_irq_data {
+ int num_irqs;
+ const struct irq_domain_ops *irq_domain_ops;
+ void (*irq_handler)(struct irq_desc *desc);
+};
+
static int pm8xxx_read_block_irq(struct pm_irq_chip *chip, unsigned int bp,
unsigned int *ip)
{
@@ -182,6 +204,84 @@ static void pm8xxx_irq_handler(struct irq_desc *desc)
chained_irq_exit(irq_chip, desc);
}
+static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
+ int master, int block)
+{
+ int pmirq, irq, i, ret;
+ unsigned int bits;
+
+ ret = regmap_read(chip->regmap,
+ PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
+ if (ret) {
+ pr_err("Failed reading %d block ret=%d", block, ret);
+ return;
+ }
+ if (!bits) {
+ pr_err("block bit set in master but no irqs: %d", block);
+ return;
+ }
+
+ /* Convert block offset to global block number */
+ block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
+
+ /* Check IRQ bits */
+ for (i = 0; i < 8; i++) {
+ if (bits & BIT(i)) {
+ pmirq = block * 8 + i;
+ irq = irq_find_mapping(chip->irqdomain, pmirq);
+ generic_handle_irq(irq);
+ }
+ }
+
+}
+
+static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
+ int master, u8 master_val)
+{
+ int block;
+
+ for (block = 1; block < 8; block++)
+ if (master_val & BIT(block))
+ pm8821_irq_block_handler(chip, master, block);
+
+}
+
+static void pm8821_irq_handler(struct irq_desc *desc)
+{
+ struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
+ struct irq_chip *irq_chip = irq_desc_get_chip(desc);
+ unsigned int master;
+ int ret;
+
+ chained_irq_enter(irq_chip, desc);
+ ret = regmap_read(chip->regmap,
+ PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
+ if (ret) {
+ pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
+ return;
+ }
+
+ /* bits 1 through 7 marks the first 7 blocks in master 0*/
+ if (master & GENMASK(7, 1))
+ pm8821_irq_master_handler(chip, 0, master);
+
+ /* bit 0 marks if master 1 contains any bits */
+ if (!(master & BIT(0)))
+ goto done;
+
+ ret = regmap_read(chip->regmap,
+ PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
+ if (ret) {
+ pr_err("Failed to read master 1 ret=%d\n", ret);
+ return;
+ }
+
+ pm8821_irq_master_handler(chip, 1, master);
+
+done:
+ chained_irq_exit(irq_chip, desc);
+}
+
static void pm8xxx_irq_mask_ack(struct irq_data *d)
{
struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
@@ -299,6 +399,110 @@ static const struct irq_domain_ops pm8xxx_irq_domain_ops = {
.map = pm8xxx_irq_domain_map,
};
+static void pm8821_irq_mask_ack(struct irq_data *d)
+{
+ struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
+ unsigned int pmirq = irqd_to_hwirq(d);
+ u8 block, master;
+ int irq_bit, rc;
+
+ block = pmirq / 8;
+ master = block / PM8821_BLOCKS_PER_MASTER;
+ irq_bit = pmirq % 8;
+ block %= PM8821_BLOCKS_PER_MASTER;
+
+ rc = regmap_update_bits(chip->regmap,
+ PM8821_SSBI_ADDR_IRQ_MASK(master, block),
+ BIT(irq_bit), BIT(irq_bit));
+
+ if (rc) {
+ pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
+ return;
+ }
+
+ rc = regmap_update_bits(chip->regmap,
+ PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
+ BIT(irq_bit), BIT(irq_bit));
+
+ if (rc) {
+ pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
+ pmirq, rc);
+ }
+
+}
+
+static void pm8821_irq_unmask(struct irq_data *d)
+{
+ struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
+ unsigned int pmirq = irqd_to_hwirq(d);
+ int irq_bit, rc;
+ u8 block, master;
+
+ block = pmirq / 8;
+ master = block / PM8821_BLOCKS_PER_MASTER;
+ irq_bit = pmirq % 8;
+ block %= PM8821_BLOCKS_PER_MASTER;
+
+ rc = regmap_update_bits(chip->regmap,
+ PM8821_SSBI_ADDR_IRQ_MASK(master, block),
+ BIT(irq_bit), ~BIT(irq_bit));
+
+ if (rc)
+ pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
+
+}
+
+static int pm8821_irq_get_irqchip_state(struct irq_data *d,
+ enum irqchip_irq_state which,
+ bool *state)
+{
+ struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
+ int rc, pmirq = irqd_to_hwirq(d);
+ u8 block, irq_bit, master;
+ unsigned int bits;
+
+ block = pmirq / 8;
+ master = block / PM8821_BLOCKS_PER_MASTER;
+ irq_bit = pmirq % 8;
+ block %= PM8821_BLOCKS_PER_MASTER;
+
+ rc = regmap_read(chip->regmap,
+ PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
+ if (rc) {
+ pr_err("Failed Reading Status rc=%d\n", rc);
+ return rc;
+ }
+
+ *state = !!(bits & BIT(irq_bit));
+
+ return rc;
+}
+
+static struct irq_chip pm8821_irq_chip = {
+ .name = "pm8821",
+ .irq_mask_ack = pm8821_irq_mask_ack,
+ .irq_unmask = pm8821_irq_unmask,
+ .irq_get_irqchip_state = pm8821_irq_get_irqchip_state,
+ .flags = IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE,
+};
+
+static int pm8821_irq_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct pm_irq_chip *chip = d->host_data;
+
+ irq_set_chip_and_handler(irq, &pm8821_irq_chip, handle_level_irq);
+ irq_set_chip_data(irq, chip);
+ irq_set_noprobe(irq);
+
+ return 0;
+}
+
+static const struct irq_domain_ops pm8821_irq_domain_ops = {
+ .xlate = irq_domain_xlate_twocell,
+ .map = pm8821_irq_domain_map,
+};
+
static const struct regmap_config ssbi_regmap_config = {
.reg_bits = 16,
.val_bits = 8,
@@ -308,22 +512,44 @@ static const struct regmap_config ssbi_regmap_config = {
.reg_write = ssbi_reg_write
};
+static const struct pm_irq_data pm8xxx_data = {
+ .num_irqs = PM8XXX_NR_IRQS,
+ .irq_domain_ops = &pm8xxx_irq_domain_ops,
+ .irq_handler = pm8xxx_irq_handler,
+};
+
+static const struct pm_irq_data pm8821_data = {
+ .num_irqs = PM8821_NR_IRQS,
+ .irq_domain_ops = &pm8821_irq_domain_ops,
+ .irq_handler = pm8821_irq_handler,
+};
+
static const struct of_device_id pm8xxx_id_table[] = {
- { .compatible = "qcom,pm8018", },
- { .compatible = "qcom,pm8058", },
- { .compatible = "qcom,pm8921", },
+ { .compatible = "qcom,pm8018", .data = &pm8xxx_data},
+ { .compatible = "qcom,pm8058", .data = &pm8xxx_data},
+ { .compatible = "qcom,pm8821", .data = &pm8821_data},
+ { .compatible = "qcom,pm8921", .data = &pm8xxx_data},
{ }
};
MODULE_DEVICE_TABLE(of, pm8xxx_id_table);
static int pm8xxx_probe(struct platform_device *pdev)
{
+ const struct of_device_id *match;
+ const struct pm_irq_data *data;
struct regmap *regmap;
int irq, rc;
unsigned int val;
u32 rev;
struct pm_irq_chip *chip;
- unsigned int nirqs = PM8XXX_NR_IRQS;
+
+ match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
+ if (!match) {
+ dev_err(&pdev->dev, "No matching driver data found\n");
+ return -EINVAL;
+ }
+
+ data = match->data;
irq = platform_get_irq(pdev, 0);
if (irq < 0)
@@ -354,25 +580,26 @@ static int pm8xxx_probe(struct platform_device *pdev)
rev |= val << BITS_PER_BYTE;
chip = devm_kzalloc(&pdev->dev, sizeof(*chip) +
- sizeof(chip->config[0]) * nirqs,
- GFP_KERNEL);
+ sizeof(chip->config[0]) * data->num_irqs,
+ GFP_KERNEL);
if (!chip)
return -ENOMEM;
platform_set_drvdata(pdev, chip);
chip->regmap = regmap;
- chip->num_irqs = nirqs;
+ chip->num_irqs = data->num_irqs;
chip->num_blocks = DIV_ROUND_UP(chip->num_irqs, 8);
chip->num_masters = DIV_ROUND_UP(chip->num_blocks, 8);
spin_lock_init(&chip->pm_irq_lock);
- chip->irqdomain = irq_domain_add_linear(pdev->dev.of_node, nirqs,
- &pm8xxx_irq_domain_ops,
+ chip->irqdomain = irq_domain_add_linear(pdev->dev.of_node,
+ data->num_irqs,
+ data->irq_domain_ops,
chip);
if (!chip->irqdomain)
return -ENODEV;
- irq_set_chained_handler_and_data(irq, pm8xxx_irq_handler, chip);
+ irq_set_chained_handler_and_data(irq, data->irq_handler, chip);
irq_set_irq_wake(irq, 1);
rc = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: apq8064: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 268bd47..c61ba32 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -627,6 +627,33 @@
clock-names = "core";
};
+ ssbi at c00000 {
+ compatible = "qcom,ssbi";
+ reg = <0x00c00000 0x1000>;
+ qcom,controller-type = "pmic-arbiter";
+
+ pm8821: pmic at 1 {
+ compatible = "qcom,pm8821";
+ interrupt-parent = <&tlmm_pinmux>;
+ interrupts = <76 IRQ_TYPE_LEVEL_LOW>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pm8821_mpps: mpps at 50 {
+ compatible = "qcom,pm8821-mpp", "qcom,ssbi-mpp";
+ reg = <0x50>;
+ interrupts = <24 IRQ_TYPE_NONE>,
+ <25 IRQ_TYPE_NONE>,
+ <26 IRQ_TYPE_NONE>,
+ <27 IRQ_TYPE_NONE>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
+
qcom,ssbi at 500000 {
compatible = "qcom,ssbi";
reg = <0x00500000 0x1000>;
--
2.10.1
^ permalink raw reply related
* [PATCH 1/2] mfd: pm8921: add support to pm8821
From: Bjorn Andersson @ 2016-11-14 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <852fbb95-852e-0612-77a8-b0b072a68c51@linaro.org>
On Mon 14 Nov 09:33 PST 2016, Srinivas Kandagatla wrote:
[..]
> >>+static int pm8821_irq_block_handler(struct pm_irq_chip *chip,
> >>+ int master_number, int block)
> >>+{
> >>+ int pmirq, irq, i, ret;
> >>+ unsigned int bits;
> >>+
> >>+ ret = pm8821_read_block_irq(chip, master_number, block, &bits);
> >>+ if (ret) {
> >>+ pr_err("Failed reading %d block ret=%d", block, ret);
> >>+ return ret;
> >>+ }
> >>+ if (!bits) {
> >>+ pr_err("block bit set in master but no irqs: %d", block);
> >>+ return 0;
> >>+ }
> >>+
> >>+ /* Convert block offset to global block number */
> >>+ block += (master_number * PM8821_BLOCKS_PER_MASTER) - 1;
> >
> >So this is block -= 1 for master 0 and block += 6 for master 1, is the
> >latter correct?
> >
> Yes, both of them are correct.
>
> for master 0 which has block numbers from 1-7 should translate to 0-6 in
> linear space.
> for master 1 which has block numbers from 1-7 should translate to 7-13 in
> linear space.
>
> so for master0 it is -=1 and and for master1 it is +=6 seems correct.
>
Ahh, because block is 1-indexed when we enter, so have to switch base
and then calculate the global number, like:
block = block - 1 + (master * PER_MASTER) + 7
but we cancel out the subtraction. I agree that this looks correct then.
I would prefer less of a mixture between 0-indexing and 1-indexing, but
I don't have any good ideas on how to restructure it to make it better.
Regards,
Bjorn
^ permalink raw reply
* [PATCH RFC 3/2] ARM: improve arch_irq_work_has_interrupt()
From: Russell King - ARM Linux @ 2016-11-14 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e14b943-e3a5-6993-48c7-68200c8b08a2@arm.com>
On Mon, Nov 14, 2016 at 04:30:57PM +0000, Marc Zyngier wrote:
> diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
> index 3d6dc8b..45612d2 100644
> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -48,6 +48,16 @@ extern void smp_init_cpus(void);
> */
> extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
>
> +#ifdef CONFIG_SMP
> +#define setup_smp_ipi(f,i) \
> + do { \
> + set_smp_cross_call(f); \
> + irq_controller_can_ipi = (i); \
> + } while(0)
> +#else
> +#define setup_smp_ipi(f,i) do { } while (0)
> +#endif
> +
> /*
> * Called from platform specific assembly code, this is the
> * secondary CPU entry point.
>
> with the similar entry point for arm64?
Note that asm/smp.h is not included if CONFIG_SMP is not set, so it's
not that easy.
Both ARM64 and ARM have asm/smp_plat.h which contains the platform
specifics of SMP, which is where set_smp_cross_call() really should
be anyway, and the GIC code already includes this. So I'm moving
set_smp_cross_call() there for both arches.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback
From: Doug Anderson @ 2016-11-14 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479106911-16049-2-git-send-email-wulf@rock-chips.com>
William
On Sun, Nov 13, 2016 at 11:01 PM, William Wu <wulf@rock-chips.com> wrote:
> Since we needs to delay ~1ms to wait for 480MHz output clock
> of USB2 PHY to become stable after turn on it, the delay time
> is pretty long for something that's supposed to be "atomic"
> like a clk_enable(). Consider that clk_enable() will disable
> interrupt and that a 1ms interrupt latency is not sensible.
>
> The 480MHz output clock should be handled in prepare callbacks
> which support gate a clk if the operation may sleep.
>
> Signed-off-by: William Wu <wulf@rock-chips.com>
> ---
> drivers/phy/phy-rockchip-inno-usb2.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCH v3 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: Doug Anderson @ 2016-11-14 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479115631-20137-3-git-send-email-wulf@rock-chips.com>
William,
On Mon, Nov 14, 2016 at 1:27 AM, William Wu <wulf@rock-chips.com> wrote:
> We found that the system crashed due to 480MHz output clock of
> USB2 PHY was unstable after clock had been enabled by gpu module.
>
> Theoretically, 1 millisecond is a critical value for 480MHz
> output clock stable time, so we try to change the delay time
> to 1.2 millisecond to avoid this issue.
>
> And the commit ed907fb1d7c3 ("phy: rockchip-inno-usb2: correct
> clk_ops callback") used prepare callbacks instead of enable
> callbacks to support gate a clk if the operation may sleep. So
> we can switch from delay to sleep functions.
>
> Signed-off-by: William Wu <wulf@rock-chips.com>
> ---
> Changes in v3:
> - fix kbuild test error: too few arguments to function 'usleep_range'
>
> Changes in v2:
> - use usleep_range() function instead of mdelay()
>
> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
> index 365e077..0e52b25 100644
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -166,7 +166,7 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
> return ret;
>
> /* waitting for the clk become stable */
> - mdelay(1);
> + usleep_range(1200, 1300);
Sight nit that you could also fix the spelling from "waitting" to "waiting".
...but that's pre-existing, so:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Catalin Marinas @ 2016-11-14 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103155106.GF25852@remoulade>
On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
> > On 11/02/2016 04:52 PM, Mark Rutland wrote:
> > >On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
> > >>
> > >>__pa_symbol is technically the marco that should be used for kernel
> > >>symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
> > >
> > >Nit: s/marco/macro/
> > >
> > >I see there are some other uses of __pa() that look like they could/should be
> > >__pa_symbol(), e.g. in mark_rodata_ro().
> > >
> > >I guess strictly speaking those need to be updated to? Or is there a reason
> > >that we should not?
> >
> > If the concept of __pa_symbol is okay then yes I think all uses of __pa
> > should eventually be converted for consistency and debugging.
>
> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
> for consistency with other architectures.
At a quick grep, it seems to only be used by mips and x86 and a single
place in mm/memblock.c.
Since we haven't seen any issues on arm/arm64 without this macro, can we
not just continue to use __pa()?
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <427a3d44-16aa-258c-8722-48d9c7ffb593@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Hi Linus,
>
> Am 14.11.2016 um 13:23 schrieb Linus Walleij:
>> From: Phil Elwell <phil@raspberrypi.org>
>>
>> Contrary to the documentation, the BCM2835 GPIO controller actually
>> has four interrupt lines - one each for the three IRQ groups and one
>> common. Confusingly, the GPIO interrupt groups don't correspond
>> directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
>> GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
>>
>> Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
>> so split out a function to process the interrupts for a single GPIO
>> bank.
>>
>> Cc: Stefan Wahren <stefan.wahren@i2se.com>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> I want to apply this to cater for my GPIOLIB_IRQCHIP
>> refactorings.
>> ---
>> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
>> 1 file changed, 39 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> index b2dd278f18b1..1d8fc104e26b 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>>
> ...
>> @@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
>> .remove = bcm2835_pinctrl_remove,
>> .driver = {
>> .name = MODULE_NAME,
>> + .owner = THIS_MODULE,
>
> this is unnecessary. Please remove it.
>
> Thanks for submitting these patches
With that dropped,
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/2938bc95/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] pinctrl: bcm2835: Return pins to inputs when freed
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126214-20529-1-git-send-email-linus.walleij@linaro.org>
Linus Walleij <linus.walleij@linaro.org> writes:
> From: Phil Elwell <phil@raspberrypi.org>
>
> When dynamically unloading overlays, it is important that freed pins are
> restored to being inputs to prevent functions from being enabled in
> multiple places at once.
>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/9b3ddd85/attachment-0001.sig>
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-14 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114155222.GZ2078@8bytes.org>
On 14/11/16 15:52, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
>> If we've already made the decision to move away from bus ops, I don't
>> see that it makes sense to deliberately introduce new dependencies on
>> them. Besides, as it stands, this patch literally implements "tell the
>> iommu-core which hardware-iommus exist in the system and a seperate
>> iommu_ops ptr for each of them" straight off.
>
> Not sure which code you are looking at, but as I see it we have only
> per-device iommu-ops now (with this patch). That is different from
> having core-visible hardware-iommu instances where devices could link
> to.
The per-device IOMMU ops are already there since 57f98d2f61e1. This
patch generalises the other end, moving the "registering an IOMMU
instance" (i.e. iommu_fwentry) bit into the IOMMU core, from being
OF-specific. I'd be perfectly happy if we rename iommu_fwentry to
iommu_instance, fwnode_iommu_set_ops() to iommu_register_instance(), and
such if that makes the design intent clearer.
If you'd also prefer to replace iommu_fwspec::ops with an opaque
iommu_fwspec::iommu_instance pointer so that things are a bit more
centralised (and users are forced to go through the API rather then call
ops directly), I'd have no major objection either. My main point is that
we've been deliberately putting the relevant building blocks in place -
the of_iommu_{get,set}_ops stuff was designed from the start to
accommodate per-instance ops, via the ops pointer *being* the instance
token; the iommu_fwspec stuff is deliberately intended to provide
per-device ops on top of that. The raw functionality is either there in
iommu.c already, or moving there in patches already written, so if it
doesn't look right all we need to focus on is making it look right.
> Also the rest of iommu-core code still makes use of the per-bus ops. The
> per-device ops are only used for the of_xlate fn-ptr.
Hence my aforementioned patches intended for 4.10, directly following on
from introducing iommu_fwspec in 4.9:
http://www.mail-archive.com/iommu at lists.linux-foundation.org/msg14576.html
...the purpose being to provide a smooth transition from per-bus ops to
per-device, per-instance ops. Apply those and we're 90% of the way there
for OF-based IOMMU drivers (not that any of those actually need
per-instance ops, admittedly; I did prototype it for the ARM SMMU ages
ago, but it didn't seem worth the bother). Lorenzo's series broadens the
scope to ACPI-based systems and moves the generically-useful parts into
the core where we can easily build on them further if necessary. The
major remaining work is to convert external callers of the current
bus-dependent functions like iommu_domain_alloc(), iommu_present(), etc.
to device-based alternatives.
Robin.
^ permalink raw reply
* [PATCH] ARM: Drop fixed 200 Hz timer requirement from Exynos platforms
From: Krzysztof Kozlowski @ 2016-11-14 18:27 UTC (permalink / raw)
To: linux-arm-kernel
All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
200 Hz. Unfortunately in case of multiplatform image this affects also
other platforms when Exynos is selected.
This looks like an very old legacy code, dating back to initial
upstreaming of S3C24xx. Probably it was required for s3c24xx timer
driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
unused plat-samsung/time.c").
Since then, this fixed 200 Hz spread everywhere, including out-of-tree
Samsung kernels (SoC vendor's and Tizen's). I believe this choice
was rather an effect of coincidence instead of conscious choice. In
fact Exynos can work with different timers.
Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
other values.
Reported-by: Lee Jones <lee.jones@linaro.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Testing on other Exynos platforms would be appreciated.
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..0d10e45f9175 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1497,7 +1497,7 @@ source kernel/Kconfig.preempt
config HZ_FIXED
int
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
- ARCH_S5PV210 || ARCH_EXYNOS4
+ ARCH_S5PV210
default 128 if SOC_AT91RM9200
default 0
--
2.7.4
^ permalink raw reply related
* [PATCH v2] staging: vc04_services: rework ioctl code path
From: Michael Zoran @ 2016-11-14 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111134646.GI28701@mwanda>
On Mon, 2016-11-14 at 12:48 +0300, Dan Carpenter wrote:
> On Thu, Nov 10, 2016 at 10:15:31PM -0800, Michael Zoran wrote:
> > +static void *
> > +vchiq_ioctl_kmalloc(struct vchiq_ioctl_call_context *ctxt, size_t
> > size)
> > +{
> > + void *mem;
> > +
> > + if (!ctxt->stackmem_used && size < sizeof(ctxt->stackmem))
> > {
> > + ctxt->stackmem_used = true;
> > + return ctxt->stackmem;
> > + }
> > +
> > + mem = kmalloc(size + sizeof(void *), GFP_KERNEL);
>
> This is a potential integer overflow leading to corruption.??I don't
> understand why we need this complicated memory management anyway...
>
You could be right. This patch was very large and it hasn't received
the review that it probably should get. Also the checkpatch.pl
utility is complaining about obsolete kernel functionality that the old
code had and I really don't have the time to redo.
Perhaps the entire patch should be removed from consideration until I
can possibly work out a V3?
> > + if (!mem)
> > + return NULL;
> > +
> > + *(void **)mem = ctxt->prev_kmalloc;
> > + ctxt->prev_kmalloc = mem;
> > +
> > + return mem + sizeof(void *);
> > +}
>
> regards,
> dan carpenter
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes
From: Kevin Hilman @ 2016-11-14 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112130719.24995-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> All boards from the Tronsmart Vega S95 series are sharing similar MMC
> based hardware.
> sd_emmc_a is used to connect a Broadcom based SDIO wifi card (supported
> by the brcmfmac driver). The 32.768KHz LPO clock for the wifi chip is
> generated by PWM_E.
> sd_emmc_b is routed to the SD-card. Unlike p20x there is no GPIO
> regulator, meaning it only supports 3.3V (which seems to be hard-wired).
> The eMMC chip is connected to sd_emmc_c and is implemented similar to
> the meson-gxbb-p20x boards (meaning that hard-wired fixed regulators
> are used).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Applied to v4.10/dt64.
Kevin
^ permalink raw reply
* [GIT PULL] arm: mediatek: dts changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
although late, please pull the following changes.
Thanks,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-dts
for you to fetch changes up to 28d6e3647bd7c869bfc251f9a7e283d78cef5fc5:
arm: dts: mt2701: Use real clock for UARTs (2016-11-11 15:25:09 +0100)
----------------------------------------------------------------
- Add bindings for mtk-scpsys for mt2701
- Add clocks for auxadc on mt8173-evb
- Add nodes needed by clock controller for mt2701
- Use clocks from the clock controller for the uart of mt2701
----------------------------------------------------------------
Erin Lo (1):
arm: dts: mt2701: Use real clock for UARTs
James Liao (1):
arm: dts: mt2701: Add clock controller device nodes
Matthias Brugger (1):
arm64: dts: mt8173: Fix auxadc node
Shunli Wang (1):
soc: mediatek: Add MT2701 power dt-bindings
.../devicetree/bindings/soc/mediatek/scpsys.txt | 13 +++---
arch/arm/boot/dts/mt2701.dtsi | 50
+++++++++++++++++++---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 3 ++
include/dt-bindings/power/mt2701-power.h | 27 ++++++++++++
4 files changed, 83 insertions(+), 10 deletions(-)
create mode 100644 include/dt-bindings/power/mt2701-power.h
^ 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