* [PATCH 1/3] ARM: dts: keystone: add mdio devices entries
From: Grygorii Strashko @ 2014-07-17 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404911660-10047-2-git-send-email-grygorii.strashko@ti.com>
The Keystone 2 has MDIO HW block which are compatible
to Davinci SoCs:
See "Gigabit Ethernet (GbE) Switch Subsystem"
See http://www.ti.com/lit/ug/sprugv9d/sprugv9d.pdf
Hence, add corresponding DT entry for Keystone 2.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/boot/dts/keystone.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index c1414cb..9e31fe7 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -266,5 +266,16 @@
ranges = <0 0 0x30000000 0x10000000
1 0 0x21000A00 0x00000100>;
};
+
+ mdio: mdio at 02090300 {
+ compatible = "ti,keystone_mdio", "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x02090300 0x100>;
+ status = "disabled";
+ clocks = <&clkpa>;
+ clock-names = "fck";
+ bus_freq = <2500000>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v7 00/11] arm64: Support 4 levels of translation tables
From: Jungseok Lee @ 2014-07-17 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B063E1CA-27E4-4A0B-BDAB-CB57014348A5@gmail.com>
On Wed, 16 Jul 2014 20:09:41 +0100, Catalin Marinas wrote:
> Hi,
>
> I've taken over Jungseok's 4-level page table series here:
>
>
> https://lkml.kernel.org/g/000001cf6dc6$03ded0c0$0b9c7240$@samsung.com
>
>
> I kept the same series numbering, so this is normally version 7. Changes
> since v6:
>
> - Additional fixes for duplicate (SWAPPER|IDMAP)_DIR_SIZE definitions
> - Removed the fixmap pmd from swapper_pg_dir populated in head.S
> - Several clean-ups in Jungseok's patches (annotated above my
> signed-off-by line)
> - Removal of the pgtable-*level-hwdef.h files
> - Converting levels config options to int ARM64_PGTABLE_LEVELS
>
> Important change: I dropped the KVM support for 4 levels temporarily. I
> plan to revive them but didn't have for v7.
>
> You can also access the branch here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 pgtable-4levels
>
> The branch is on top of the arm64 for-next/core branch.
>
> Thanks.
Hi Catalin,
I've reviewed the whole patches. It's better and neater than the previous version.
I really thank you for improving this series.
I will leave a minor comment on 07/11 patch.
- Jungseok Lee
^ permalink raw reply
* [PATCH 5/5] tty: serial: Add 8250-core based omap driver
From: Felipe Balbi @ 2014-07-17 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405521903-5877-6-git-send-email-bigeasy@linutronix.de>
Hi,
On Wed, Jul 16, 2014 at 04:45:03PM +0200, Sebastian Andrzej Siewior wrote:
> +static int omap_8250_startup(struct uart_port *port)
> +{
> + struct uart_8250_port *up =
> + container_of(port, struct uart_8250_port, port);
> + struct omap8250_priv *priv = port->private_data;
> +
> + int ret;
> +
> + if (priv->wakeirq) {
> + ret = request_irq(priv->wakeirq, omap_wake_irq,
> + port->irqflags, "wakeup irq", port);
> + if (ret)
> + return ret;
> + disable_irq(priv->wakeirq);
> + }
> +
> + ret = serial8250_do_startup(port);
> + if (ret)
> + goto err;
> +
> + pm_runtime_get_sync(port->dev);
should this pm_runtime_get_sync() be placed above
serial8250_do_startup() call ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/86425844/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: audit: Fix build for audit changes
From: Mark Brown @ 2014-07-17 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717115937.GF18203@arm.com>
On Thu, Jul 17, 2014 at 12:59:38PM +0100, Catalin Marinas wrote:
> On Thu, Jul 17, 2014 at 12:26:42PM +0100, Mark Brown wrote:
> > Commit 3efe33f5d2 (audit: x86: drop arch from __audit_syscall_entry()
> > interface) removed the arch parameter from __audit_syscall_entry() and
> Thanks. This will have to be applied after 3.17-rc1 since commit
> 3efe33f5d2 does not seem to be in mainline yet (nor the arm64 audit
> patches).
That's not great and is kind of missing the point of -next - the core
idea is to find these inter-tree dependencies, ensure things work when
they're merged together and avoid things like massive bisection breaks.
Leaving things also causes problems for anyone trying to do integration
testing on -next.
What would be better would be if we could get the two trees synced up,
in this case something like picking the audit change up in the ARMv8
tree (or vice versa) seems like it'd be quick and easy since it looks
like neither tree uses topic branches.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/eb7fde8e/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 5/5] i2c: tegra: Remove suspension check
From: Bastian Hecht @ 2014-07-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405608520-5644-1-git-send-email-hechtb@gmail.com>
We now take care of suspension in the i2c core code. So we can remove this
check here.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
same as v1
drivers/i2c/busses/i2c-tegra.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index f1bb2fc..c279d85 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -172,7 +172,6 @@ struct tegra_i2c_dev {
size_t msg_buf_remaining;
int msg_read;
u32 bus_clk_rate;
- bool is_suspended;
};
static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val, unsigned long reg)
@@ -628,9 +627,6 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
int i;
int ret = 0;
- if (i2c_dev->is_suspended)
- return -EBUSY;
-
ret = tegra_i2c_clock_enable(i2c_dev);
if (ret < 0) {
dev_err(i2c_dev->dev, "Clock enable failed %d\n", ret);
@@ -817,17 +813,6 @@ static int tegra_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_SLEEP
-static int tegra_i2c_suspend(struct device *dev)
-{
- struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
-
- i2c_lock_adapter(&i2c_dev->adapter);
- i2c_dev->is_suspended = true;
- i2c_unlock_adapter(&i2c_dev->adapter);
-
- return 0;
-}
-
static int tegra_i2c_resume(struct device *dev)
{
struct tegra_i2c_dev *i2c_dev = dev_get_drvdata(dev);
@@ -842,14 +827,12 @@ static int tegra_i2c_resume(struct device *dev)
return ret;
}
- i2c_dev->is_suspended = false;
-
i2c_unlock_adapter(&i2c_dev->adapter);
return 0;
}
-static SIMPLE_DEV_PM_OPS(tegra_i2c_pm, tegra_i2c_suspend, tegra_i2c_resume);
+static SIMPLE_DEV_PM_OPS(tegra_i2c_pm, tegra_i2c_resume);
#define TEGRA_I2C_PM (&tegra_i2c_pm)
#else
#define TEGRA_I2C_PM NULL
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/5] i2c: sc3c2410: Remove suspension check
From: Bastian Hecht @ 2014-07-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405608520-5644-1-git-send-email-hechtb@gmail.com>
We now take care of suspension in the i2c core code. So we can remove this
check here.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
same as v1
drivers/i2c/busses/i2c-s3c2410.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index e828a1d..568b993 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -103,7 +103,6 @@ enum s3c24xx_i2c_state {
struct s3c24xx_i2c {
wait_queue_head_t wait;
kernel_ulong_t quirks;
- unsigned int suspended:1;
struct i2c_msg *msg;
unsigned int msg_num;
@@ -714,9 +713,6 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
unsigned long timeout;
int ret;
- if (i2c->suspended)
- return -EIO;
-
ret = s3c24xx_i2c_set_master(i2c);
if (ret != 0) {
dev_err(i2c->dev, "cannot get bus (error %d)\n", ret);
@@ -1257,16 +1253,6 @@ static int s3c24xx_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_SLEEP
-static int s3c24xx_i2c_suspend_noirq(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
-
- i2c->suspended = 1;
-
- return 0;
-}
-
static int s3c24xx_i2c_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -1275,7 +1261,6 @@ static int s3c24xx_i2c_resume(struct device *dev)
clk_prepare_enable(i2c->clk);
s3c24xx_i2c_init(i2c);
clk_disable_unprepare(i2c->clk);
- i2c->suspended = 0;
return 0;
}
@@ -1284,7 +1269,6 @@ static int s3c24xx_i2c_resume(struct device *dev)
#ifdef CONFIG_PM
static const struct dev_pm_ops s3c24xx_i2c_dev_pm_ops = {
#ifdef CONFIG_PM_SLEEP
- .suspend_noirq = s3c24xx_i2c_suspend_noirq,
.resume = s3c24xx_i2c_resume,
#endif
};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/5] i2c: exynos5: Remove suspension check
From: Bastian Hecht @ 2014-07-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405608520-5644-1-git-send-email-hechtb@gmail.com>
We now take care of suspension in the i2c core code. So we can remove this
check here.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
same as v1
drivers/i2c/busses/i2c-exynos5.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 63d2292..a80cf28 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -145,7 +145,6 @@
struct exynos5_i2c {
struct i2c_adapter adap;
- unsigned int suspended:1;
struct i2c_msg *msg;
struct completion msg_complete;
@@ -610,11 +609,6 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
struct exynos5_i2c *i2c = adap->algo_data;
int i = 0, ret = 0, stop = 0;
- if (i2c->suspended) {
- dev_err(i2c->dev, "HS-I2C is not initialized.\n");
- return -EIO;
- }
-
clk_prepare_enable(i2c->clk);
for (i = 0; i < num; i++, msgs++) {
@@ -757,16 +751,6 @@ static int exynos5_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_SLEEP
-static int exynos5_i2c_suspend_noirq(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- struct exynos5_i2c *i2c = platform_get_drvdata(pdev);
-
- i2c->suspended = 1;
-
- return 0;
-}
-
static int exynos5_i2c_resume_noirq(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -783,14 +767,12 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
exynos5_i2c_init(i2c);
clk_disable_unprepare(i2c->clk);
- i2c->suspended = 0;
return 0;
}
#endif
-static SIMPLE_DEV_PM_OPS(exynos5_i2c_dev_pm_ops, exynos5_i2c_suspend_noirq,
- exynos5_i2c_resume_noirq);
+static SIMPLE_DEV_PM_OPS(exynos5_i2c_dev_pm_ops, exynos5_i2c_resume_noirq);
static struct platform_driver exynos5_i2c_driver = {
.probe = exynos5_i2c_probe,
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/5] i2c: eg20t: Remove suspension check
From: Bastian Hecht @ 2014-07-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405608520-5644-1-git-send-email-hechtb@gmail.com>
We now take care of suspension in the i2c core code. So we can remove this
check here.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
same as v1
drivers/i2c/busses/i2c-eg20t.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/drivers/i2c/busses/i2c-eg20t.c b/drivers/i2c/busses/i2c-eg20t.c
index a44ea13..aae0413 100644
--- a/drivers/i2c/busses/i2c-eg20t.c
+++ b/drivers/i2c/busses/i2c-eg20t.c
@@ -162,15 +162,12 @@ struct i2c_algo_pch_data {
* struct adapter_info - This structure holds the adapter information for the
PCH i2c controller
* @pch_data: stores a list of i2c_algo_pch_data
- * @pch_i2c_suspended: specifies whether the system is suspended or not
- * perhaps with more lines and words.
* @ch_num: specifies the number of i2c instance
*
* pch_data has as many elements as maximum I2C channels
*/
struct adapter_info {
struct i2c_algo_pch_data pch_data[PCH_I2C_MAX_DEV];
- bool pch_i2c_suspended;
int ch_num;
};
@@ -677,13 +674,6 @@ static s32 pch_i2c_xfer(struct i2c_adapter *i2c_adap,
if (ret)
return ret;
- if (adap->p_adapter_info->pch_i2c_suspended) {
- mutex_unlock(&pch_mutex);
- return -EBUSY;
- }
-
- pch_dbg(adap, "adap->p_adapter_info->pch_i2c_suspended is %d\n",
- adap->p_adapter_info->pch_i2c_suspended);
/* transfer not completed */
adap->pch_i2c_xfer_in_progress = true;
@@ -786,7 +776,6 @@ static int pch_i2c_probe(struct pci_dev *pdev,
for (i = 0; i < adap_info->ch_num; i++) {
pch_adap = &adap_info->pch_data[i].pch_adapter;
- adap_info->pch_i2c_suspended = false;
adap_info->pch_data[i].p_adapter_info = adap_info;
@@ -862,8 +851,6 @@ static int pch_i2c_suspend(struct pci_dev *pdev, pm_message_t state)
struct adapter_info *adap_info = pci_get_drvdata(pdev);
void __iomem *p = adap_info->pch_data[0].pch_base_address;
- adap_info->pch_i2c_suspended = true;
-
for (i = 0; i < adap_info->ch_num; i++) {
while ((adap_info->pch_data[i].pch_i2c_xfer_in_progress)) {
/* Wait until all channel transfers are completed */
@@ -912,8 +899,6 @@ static int pch_i2c_resume(struct pci_dev *pdev)
for (i = 0; i < adap_info->ch_num; i++)
pch_i2c_init(&adap_info->pch_data[i]);
- adap_info->pch_i2c_suspended = false;
-
return 0;
}
#else
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/5] i2c: Don't start transfers when suspended
From: Bastian Hecht @ 2014-07-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
i2c transfer requests come in very uncontrolled, like from interrupt routines.
We might be suspended when this happens. To avoid i2c timeouts caused by
powered down busses we check for suspension.
Several bus drivers handle this problem on their own. We can clean things up
by moving the protection mechanism into the core.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
---
changelog v2:
- commit message extended.
- initialization added for adap->suspended
- swapped branch for increased performance
drivers/i2c/i2c-core.c | 25 ++++++++++++++++++++++++-
include/linux/i2c.h | 1 +
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 7c7f4b8..b15dc20 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -343,6 +343,13 @@ static int i2c_legacy_resume(struct device *dev)
static int i2c_device_pm_suspend(struct device *dev)
{
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+ struct i2c_adapter *adap = i2c_verify_adapter(dev);
+
+ if (adap) {
+ i2c_lock_adapter(adap);
+ adap->suspended = true;
+ i2c_unlock_adapter(adap);
+ }
if (pm)
return pm_generic_suspend(dev);
@@ -353,6 +360,13 @@ static int i2c_device_pm_suspend(struct device *dev)
static int i2c_device_pm_resume(struct device *dev)
{
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+ struct i2c_adapter *adap = i2c_verify_adapter(dev);
+
+ if (adap) {
+ i2c_lock_adapter(adap);
+ adap->suspended = false;
+ i2c_unlock_adapter(adap);
+ }
if (pm)
return pm_generic_resume(dev);
@@ -1243,6 +1257,7 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
dev_set_name(&adap->dev, "i2c-%d", adap->nr);
adap->dev.bus = &i2c_bus_type;
adap->dev.type = &i2c_adapter_type;
+ adap->suspended = false;
res = device_register(&adap->dev);
if (res)
goto out_list;
@@ -1819,7 +1834,10 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
i2c_lock_adapter(adap);
}
- ret = __i2c_transfer(adap, msgs, num);
+ if (!adap->suspended)
+ ret = __i2c_transfer(adap, msgs, num);
+ else
+ ret = -EIO;
i2c_unlock_adapter(adap);
return ret;
@@ -2577,6 +2595,10 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, unsigned short flags,
if (adapter->algo->smbus_xfer) {
i2c_lock_adapter(adapter);
+ if (adapter->suspended) {
+ res = -EIO;
+ goto unlock;
+ }
/* Retry automatically on arbitration loss */
orig_jiffies = jiffies;
@@ -2590,6 +2612,7 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr, unsigned short flags,
orig_jiffies + adapter->timeout))
break;
}
+unlock:
i2c_unlock_adapter(adapter);
if (res != -EOPNOTSUPP || !adapter->algo->master_xfer)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index b556e0a..af08c75 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -434,6 +434,7 @@ struct i2c_adapter {
int timeout; /* in jiffies */
int retries;
struct device dev; /* the adapter device */
+ unsigned int suspended:1;
int nr;
char name[48];
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support
From: Suravee Suthikulanit @ 2014-07-17 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717135534.GM30313@leverpostej>
On 7/17/2014 8:55 AM, Mark Rutland wrote:
> Hi Jason,
>
> On Thu, Jul 17, 2014 at 02:18:54PM +0100, Jason Cooper wrote:
>> On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpanit at amd.com wrote:
>>> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>>>
>>> This patch set introduces support for MSI(-X) in GICv2m specification,
>>> which is implemented in some variation of GIC400.
>>>
>>> This depends on and has been tested with the V7 of"Add support for PCI in AArch64"
>>> (https://lkml.org/lkml/2014/3/14/320).
>>>
>>> Changes in V3:
>>> * Rebase to git://git.infradead.org/users/jcooper/linux.git irqchip/gic
>>> (per Jason Cooper request)
>>> * Misc fix/clean up per Mark Rutland comments
>>> * Minor Clean up in the driver/irqchip/irq-gic-v2m.c: alloc_msi_irqs()
>>> * Patch 4 is new to the series:
>>> * Add ARM64-specific version arch_setup_msi_irqs() to allow support
>>> for Multiple MSI.
>>> * Add support for Multiple MSI for GICv2m.
>>>
>>> Suravee Suthikulpanit (4):
>>> irqchip: gic: Add binding probe for ARM GIC400
>>> irqchip: gic: Restructuring ARM GIC code
>>> irqchip: gic: Add supports for ARM GICv2m MSI(-X)
>>> irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
>>
>> Ok, patch #1 applied to irqchip/urgent. Patches 2 and 3 applied to
>> irqchip/gic with irqchip/urgent merged in. To facilitate
>> testing/merging, I've prepared an unsigned tag for you on the
>> irqchip/gic branch:
>
> I'm a little concerned that this is all going through for v3.17 without
> a {Reviewed,Acked}-by from Marc or anyone working with GIC{,v2m}.
> While his comments on v1 have been addressed, he has not had a chance to
> acknowledge the solutions. I appreciate Marc's holiday is unfortunately
> timed.
>
> I also have an open concern with the binding with regard to the
> orthogonality of GICV GICH and the MSI registers.
The MSI part is normally enabled from the optional "msi-controller"
keyword. It should not really matter which compatible ID it uses.
Ooops. I noticed that was accidentally dropped the check for
"msi-controller" in the gicv2m_of_init() function. I'll send a follow
up patch to fix this.
> Suravee, do you need this urgently for v3.17? I was under the impression
> that we wouldn't have full PCIe support by then.
>
PCI is the dependency for this patch to function. So, it should be
aligned with upstreaming of PCI patches.
Suravee
^ permalink raw reply
* [PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences
From: Tomasz Figa @ 2014-07-17 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C53A1A.6060701@samsung.com>
Hi Kukjin,
On 15.07.2014 16:26, Tomasz Figa wrote:
> Forgot to CC Daniel and linux-pm. Sorry for the noise.
>
> On 15.07.2014 16:24, Tomasz Figa wrote:
>> Due to recent consolidation of Exynos suspend and cpuidle code, some
>> parts of suspend and resume sequences are executed two times, once from
>> exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
>> breaks suspend, at least on Exynos4-based boards. In addition, simple
>> core power down from a cpuidle driver could, in case of CPU 0 could
>> result in calling functions that are specific to suspend and deeper idle
>> states.
>>
>> This patch fixes the issue by moving those operations outside the CPU PM
>> notifier into suspend and AFTR code paths. This leads to a bit of code
>> duplication, but allows additional code simplification, so in the end
>> more code is removed than added.
>>
>> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
>> ---
>> arch/arm/mach-exynos/pm.c | 164 ++++++++++++++++++---------------------
>> drivers/cpuidle/cpuidle-exynos.c | 25 +-----
>> 2 files changed, 80 insertions(+), 109 deletions(-)
>>
Please consider this patch for next pull request with rc fixes. It
replaces following patches posted in this thread:
[PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies
[PATCH v2 5/6] ARM: EXYNOS: Fix suspend/resume sequences
and also similar patch by Chander:
[PATCH 2/2] cpuidle: Exynos: fix cpuidle for all states
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP
From: Arnd Bergmann @ 2014-07-17 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717142720.GM21153@arm.com>
On Thursday 17 July 2014 15:27:20 Will Deacon wrote:
> On Thu, Jul 17, 2014 at 02:12:24PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jul 17, 2014 at 02:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thursday 17 July 2014 09:33:42 Russell King - ARM Linux wrote:
> > > > No - the problem is that we're running from the page table in question
> > > > with global mappings, and we need to switch all these mappings, including
> > > > the ones we're currently using to execute from.
> > > >
> > > > We can't even create a new page table and switch to it because the
> > > > mappings in question are global mappings.
> > > >
> > > > The only way to do that safely from an architectural point of view would
> > > > be to turn the MMU off, and drop back to assembly code to change the
> > > > page tables, and re-enable the MMU. For something as obscure as Marvell's
> > > > coherency stuff, that's not something I want to see in core code.
> > >
> > > Is this different from what we do in the LPAE version of
> > > early_paging_init()? That code already adjusts all the page
> > > table entries on a per-platform setting and should be very
> > > easy to extend for a modified procinfo->__cpu_mm_mmu_flags,
> > > and possibly able to extend for traditional (non-LPAE)
> > > page tables without a lot of duplication.
> >
> > I'm going to have to profess no knowledge of how the LPAE stuff works.
> > LPAE is something I can't run, and something that I was not involved
> > in its creation. Therefore, I know very little about it and zero
> > experience thereof.
> >
> > From a glance over that function, I think that is unsafe for all the
> > reasons I've stated. However, I'll pass this over to Will Deacon
> > to comment further on.
>
> Just an FYI, but I've had to check internally to clarify the behaviour
> around TLB conflict aborts. We're changing live page tables here, but the
> *only* thing to differ is the output address, which I would hope is ok but
> need to check to be sure.
The two cases are slightly different:
- The existing keystone code changes the output address but not the flags
- The hypothetical mvebu code needs to change the flags but not the address.
Arnd
^ permalink raw reply
* [PATCHv4 0/5] arm64: handle heterogeneous system register values
From: Will Deacon @ 2014-07-17 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717142133.GO30313@leverpostej>
On Thu, Jul 17, 2014 at 03:21:33PM +0100, Mark Rutland wrote:
> On Thu, Jul 17, 2014 at 12:03:33PM +0100, Catalin Marinas wrote:
> > On Wed, Jul 16, 2014 at 04:32:42PM +0100, Mark Rutland wrote:
> > > Mark Rutland (5):
> > > arm64: add MIDR_EL1 field accessors
> > > arm64: cpuinfo: record cpu system register values
> > > arm64: cachetype: report weakest cache policy
> > > arm64: add runtime system sanity checks
> >
> > For these 4 patches:
> >
> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Thanks.
>
> I take it you'll pick these up directly and apply the tags from you and
> Will?
>
> Or would you prefer I place these in a branch?
We'll grab them later today, I expect. If testing explodes, I'll let you
know ;)
Will
^ permalink raw reply
* [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP
From: Will Deacon @ 2014-07-17 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717131224.GW21766@n2100.arm.linux.org.uk>
On Thu, Jul 17, 2014 at 02:12:24PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 17, 2014 at 02:39:42PM +0200, Arnd Bergmann wrote:
> > On Thursday 17 July 2014 09:33:42 Russell King - ARM Linux wrote:
> > > No - the problem is that we're running from the page table in question
> > > with global mappings, and we need to switch all these mappings, including
> > > the ones we're currently using to execute from.
> > >
> > > We can't even create a new page table and switch to it because the
> > > mappings in question are global mappings.
> > >
> > > The only way to do that safely from an architectural point of view would
> > > be to turn the MMU off, and drop back to assembly code to change the
> > > page tables, and re-enable the MMU. For something as obscure as Marvell's
> > > coherency stuff, that's not something I want to see in core code.
> >
> > Is this different from what we do in the LPAE version of
> > early_paging_init()? That code already adjusts all the page
> > table entries on a per-platform setting and should be very
> > easy to extend for a modified procinfo->__cpu_mm_mmu_flags,
> > and possibly able to extend for traditional (non-LPAE)
> > page tables without a lot of duplication.
>
> I'm going to have to profess no knowledge of how the LPAE stuff works.
> LPAE is something I can't run, and something that I was not involved
> in its creation. Therefore, I know very little about it and zero
> experience thereof.
>
> From a glance over that function, I think that is unsafe for all the
> reasons I've stated. However, I'll pass this over to Will Deacon
> to comment further on.
Just an FYI, but I've had to check internally to clarify the behaviour
around TLB conflict aborts. We're changing live page tables here, but the
*only* thing to differ is the output address, which I would hope is ok but
need to check to be sure.
The ARM ARM recommends always going via an invalid mapping, but that's not
always the most practical thing to do.
Will
^ permalink raw reply
* [PATCHv4 0/5] arm64: handle heterogeneous system register values
From: Mark Rutland @ 2014-07-17 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717110332.GE18203@arm.com>
On Thu, Jul 17, 2014 at 12:03:33PM +0100, Catalin Marinas wrote:
> On Wed, Jul 16, 2014 at 04:32:42PM +0100, Mark Rutland wrote:
> > Mark Rutland (5):
> > arm64: add MIDR_EL1 field accessors
> > arm64: cpuinfo: record cpu system register values
> > arm64: cachetype: report weakest cache policy
> > arm64: add runtime system sanity checks
>
> For these 4 patches:
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks.
I take it you'll pick these up directly and apply the tags from you and
Will?
Or would you prefer I place these in a branch?
>
> > arm64: cpuinfo: print info for all CPUs
>
> This is still up for discussion.
Sure, that's what I had expected. At least it's out in the open.
Cheers,
Mark.
^ permalink raw reply
* [GIT PULL 1/3] ARM: tegra: rework PCIe regulators
From: Thierry Reding @ 2014-07-17 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140710101527.GC21583@ulmo>
On Thu, Jul 10, 2014 at 12:15:28PM +0200, Thierry Reding wrote:
> On Mon, Jul 07, 2014 at 09:45:46PM -0700, Olof Johansson wrote:
[...]
> > If you have to stay compatible, then I suggest you try to fill in
> > local driver variables with derivatives of the old properties (and
> > directly from the newer properties where you can). I haven't looked at
> > the specifics here so I don't know how hard it might be.
> >
> > If you are 100% sure that you don't have to stay compatible, then you
> > can remove the code handling the old bindings. Still, even then I am a
> > little worried about dependencies (and more importantly conflicts)
> > between these dtsi changes and others done by tegra platform code for
> > this release. I suppose that can be resolved by having this as a base
> > of any DT changes for tegra if needed.
>
> To be honest, I'm very much tempted to just drop this series. Even if
> that means keeping a totally broken DT binding. But frankly I don't have
> any energy left to debate DT stability.
So this kept bugging me and I couldn't leave it alone after all. How
about if I squash in the attached patch. I've verified that that keeps
compatibility with old device trees on TrimSlice and Beaver. I think the
remainder of the series could still remain as-is (the top few commits
that you said shouldn't be there) if I squash this into
PCI: tegra: Implement accurate power supply scheme
That way the binding will be the new one so that people don't get any
wrong ideas about taking shortcuts while still preserving compatibility
with existing DTBs.
Interestingly, despite my initial disgust for having to keep around old
code (it's in fact new code in this case) for compatibility reasons, it
ended up making the code look more mature.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PCI-tegra-Preserve-DT-backwards-compatibility.patch
Type: text/x-diff
Size: 3572 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/2f969e7c/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/2f969e7c/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 7/8] drivers: cpuidle: initialize Exynos driver through DT
From: Lorenzo Pieralisi @ 2014-07-17 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5019714.S4WTdsyrXS@amdc1032>
On Wed, Jun 25, 2014 at 04:23:38PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, June 25, 2014 03:10:20 PM Lorenzo Pieralisi wrote:
> > With the introduction of DT based idle states, CPUidle drivers for
> > ARM can now initialize idle states data through properties in the device
> > tree.
> >
> > This patch adds code to the Exynos CPUidle driver to dynamically
> > initialize idle states data through the updated device tree source
> > files.
> >
> > Cc: Kukjin Kim <kgene.kim@samsung.com>
> > Cc: Tomasz Figa <t.figa@samsung.com>
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > ---
> > Compile tested, I am not sure I patched the right dts files, please check.
>
> cpuidle-exynos driver is currently working properly in deeper cpuidle
> mode (AFTR) on Exynos4210 and Exynos5250 (please also see the following
> patch from Tomasz Figa: [1]). There is ongoing work to AFTR mode work
> also on Exynos4x12 and Exynos3250 but it is not complete yet. Exynos5410
> OTOH should probably use the generic big little cpuidle driver (this SoC
> is similar to Exynos5420 one for which Chander Kashyap has developed
> cpuidle-big_little support [2]).
>
> Making long story short, I think that your patch should depend on patch
> [1] and update only exynos4210.dtsi and exynos5250.dtsi. Also for your
> patch #6 there needs to be some coordination with merging of Chander's
> patchset ([2]).
>
> [1] http://www.spinics.net/lists/arm-kernel/msg341023.html
> [2] https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg664470.html
exynos4210.dtsi does not even have cpu nodes in it. Should I add them or
this might trigger regression (ie cpu_logical_map()) ?
I will post a new version soon, should I just patch 5250 for now ?
I would need help to test this patch thanks.
Lorenzo
> > .../devicetree/bindings/arm/exynos/idle-states.txt | 27 ++++++++++++++++++++
> > arch/arm/boot/dts/exynos3250.dtsi | 16 ++++++++++++
> > arch/arm/boot/dts/exynos5250.dtsi | 15 +++++++++++
> > arch/arm/boot/dts/exynos5410.dtsi | 17 +++++++++++++
> > drivers/cpuidle/Kconfig.arm | 1 +
> > drivers/cpuidle/cpuidle-exynos.c | 29 +++++++++++++---------
> > 6 files changed, 93 insertions(+), 12 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/arm/exynos/idle-states.txt
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH] irqchip: gic: Add binding probe for ARM GIC400
From: Suravee Suthikulanit @ 2014-07-17 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717124804.GI13108@titan.lakedaemon.net>
On 7/17/2014 7:48 AM, Jason Cooper wrote:
> On Tue, Jul 15, 2014 at 12:03:03AM +0200, Heiko St?bner wrote:
>> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>>
>> Commit 3ab72f9156bb "dt-bindings: add GIC-400 binding" added the
>> "arm,gic-400" compatible string, but the corresponding IRQCHIP_DECLARE
>> was never added to the gic driver.
>>
>> Therefore add the missing irqchip declaration for it.
>>
>> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>>
>> Removed additional empty line and adapted commit message to mark it
>> as fixing an issue.
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>> ---
>> As I really need this, I took the liberty of adapting the patch accordingly
>> to make it apply on top of the current irqchip/for-next (or urgent) and
>> explicitly state the fixed issue. Hope that is ok
>>
>> drivers/irqchip/irq-gic.c | 1 +
>> 1 file changed, 1 insertion(+)
>
> Applied to irqchip/urgent with Will's Ack and Cc'd to stable for v3.14+
>
> thx,
>
> Jason.
>
Thank you,
Suravee
^ permalink raw reply
* [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support
From: Jason Cooper @ 2014-07-17 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717135534.GM30313@leverpostej>
On Thu, Jul 17, 2014 at 02:55:34PM +0100, Mark Rutland wrote:
> Hi Jason,
>
> On Thu, Jul 17, 2014 at 02:18:54PM +0100, Jason Cooper wrote:
> > On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpanit at amd.com wrote:
> > > From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> > >
> > > This patch set introduces support for MSI(-X) in GICv2m specification,
> > > which is implemented in some variation of GIC400.
> > >
> > > This depends on and has been tested with the V7 of"Add support for PCI in AArch64"
> > > (https://lkml.org/lkml/2014/3/14/320).
> > >
> > > Changes in V3:
> > > * Rebase to git://git.infradead.org/users/jcooper/linux.git irqchip/gic
> > > (per Jason Cooper request)
> > > * Misc fix/clean up per Mark Rutland comments
> > > * Minor Clean up in the driver/irqchip/irq-gic-v2m.c: alloc_msi_irqs()
> > > * Patch 4 is new to the series:
> > > * Add ARM64-specific version arch_setup_msi_irqs() to allow support
> > > for Multiple MSI.
> > > * Add support for Multiple MSI for GICv2m.
> > >
> > > Suravee Suthikulpanit (4):
> > > irqchip: gic: Add binding probe for ARM GIC400
> > > irqchip: gic: Restructuring ARM GIC code
> > > irqchip: gic: Add supports for ARM GICv2m MSI(-X)
> > > irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
> >
> > Ok, patch #1 applied to irqchip/urgent. Patches 2 and 3 applied to
> > irqchip/gic with irqchip/urgent merged in. To facilitate
> > testing/merging, I've prepared an unsigned tag for you on the
> > irqchip/gic branch:
>
> I'm a little concerned that this is all going through for v3.17 without
> a {Reviewed,Acked}-by from Marc or anyone working with GIC{,v2m}.
Well, that's why it's not in irqchip/core yet. ;-) It can be undone if
needed.
> While his comments on v1 have been addressed, he has not had a chance to
> acknowledge the solutions. I appreciate Marc's holiday is unfortunately
> timed.
>
> I also have an open concern with the binding with regard to the
> orthogonality of GICV GICH and the MSI registers.
>
> Suravee, do you need this urgently for v3.17? I was under the impression
> that we wouldn't have full PCIe support by then.
If Suravee is ok with it, I can drop them for now and he can resend for
v3.18. Since we've worked out a way to merge it all in one window, I
don't think it would hurt anything to wait.
I'll leave these in irqchip/for-next until I hear from Suravee, then
I'll drop the lot till we hear from Marc and look at the timing.
thx,
Jason.
^ permalink raw reply
* [PATCH v2] arm64/efi: efistub: jump to 'stext' directly, not through the header
From: Mark Salter @ 2014-07-17 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8kvU8ndeG2vF5HqRhjK+_F=8D52eabHzy++nTHt_pAYQ@mail.gmail.com>
On Wed, 2014-07-16 at 23:13 +0200, Ard Biesheuvel wrote:
> On 16 July 2014 23:03, Mark Salter <msalter@redhat.com> wrote:
> > On Wed, 2014-07-16 at 22:38 +0200, Ard Biesheuvel wrote:
> >> On 16 July 2014 21:45, Mark Salter <msalter@redhat.com> wrote:
> >> > On Wed, 2014-07-16 at 16:53 +0100, Mark Rutland wrote:
> >> >> On Wed, Jul 16, 2014 at 03:51:37PM +0100, Mark Salter wrote:
> >> >> > On Tue, 2014-07-15 at 12:58 +0200, Ard Biesheuvel wrote:
> >> >> > > After the EFI stub has done its business, it jumps into the kernel by branching
> >> >> > > to offset #0 of the loaded Image, which is where it expects to find the header
> >> >> > > containing a 'branch to stext' instruction.
> >> >> > >
> >> >> > > However, the header is not covered by any PE/COFF section, so the header may
> >> >> > > not actually be loaded at the expected offset. So instead, jump to 'stext'
> >> >> > > directly, which is at the base of the PE/COFF .text section, by supplying a
> >> >> > > symbol 'stext_offset' to efi-entry.o which contains the relative offset of
> >> >> > > stext into the Image. Also replace other open coded calculations of the same
> >> >> > > value with a reference to 'stext_offset'
> >> >> >
> >> >> > Have you actually seen a situation where the header isn't there?
> >> >> > Isn't the kernel header actually part of the pe/coff file and
> >> >> > firmware loads the whole file into RAM?
> >> >>
> >> >> From my understanding of Ard's earlier comments, this part isn't
> >> >> guaranteed per the UEFI spec.
> >> >>
> >> >> I would rather we weren't relying on implementation details.
> >> >>
> >> >
> >> > Could be. I didn't see anything about it in the UEFI spec, but I
> >> > probably wasn't exhaustive in my search. In any case, there's at
> >> > least one other place broken if the kernel header isn't included
> >> > in the loaded image.
> >> >
> >>
> >> I have not been able to find anything in the PE/COFF documents that
> >> tells you what to put in memory areas that are not covered by a
> >> section. Expecting the header to be there is indeed relying on an
> >> implementation detail, which seems risky.
> >> And indeed, if there are any other (non EFI related) uses of header
> >> fields in the kernel, it would be good to have a look at those well,
> >
> > I think we need to come up with a loader which does load an image
> > without kernel header so that we can test. Otherwise, we'll probably
> > end up with buggy code anyway. The stub code assumes the the loaded
> > image pointed to by the system table is the whole image. Seems like
> > we'd need to add code to determine if it is whole kernel image or
> > image without initial header. Stub would have to handle both cases.
> > For instance, one case would want image placed at 2MiB+TEXT_OFFSET,
> > other case would want 2MiB+TEXT_OFFSET+sizeof(kernel header).
> >
>
> No, this has nothing to do with misaligned data.
>
> The PE/COFF .text section does not start at virtual offset #0 but at
> virtual offset 'stext - efi_head'.
> In other words, there is a hole in the virtual image where the header
> is supposed to be.
> So if there is no PE/COFF section describing what data should be put
> at offset #0 by the loader, we can't assume the header is there, even
> if ImageBase does start at #0
I get that. You're supposing UEFI will always allocate memory for the
full image, but only sometimes copy the PE/COFF headers. I can see your
point from a PE/COFF perspective, but not so much from the UEFI spec
perspective where the language leads me to think it treats the PE/COFF
images as one unit wrt loading. In any case, it really isn't worth
arguing about. I don't have any objection to the patch since it won't
break anything from my perspective and it'll protect against breakage
which could possibly occur with some firmware implementations.
^ permalink raw reply
* [PATCH 0/4 v2] hwmon: ntc_thermistor: prepose vendor prefix change
From: Javier Martinez Canillas @ 2014-07-17 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHfPSqCGf2d6xXDGr974+4ipNsYx3-fOLT+u2OGN=c9FVPEkZg@mail.gmail.com>
Hello Naveen,
On Thu, Jul 17, 2014 at 6:21 AM, Naveen Krishna Ch
<naveenkrishna.ch@gmail.com> wrote:
>
> Can you pull the 3/4 and 4/4 patches.
>
Patch 4/4 depends on the max77802 support series [0] since the ADC
uses the max77802 ldo9 regulator as its voltage supply. So that patch
can't be merged before the series land in mainline.
Best regards,
Javier
[0]: https://lkml.org/lkml/2014/7/14/273
^ permalink raw reply
* [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
From: Peter Maydell @ 2014-07-17 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717123533.GJ21153@arm.com>
On 17 July 2014 13:35, Will Deacon <will.deacon@arm.com> wrote:
> We're not denying the possibility of heterogeneity, we're trying to expose a
> consistent view of the system to userspace. Differences between cores should
> be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly
> passed off to userspace.
On that basis, why report anything at all about invididual cores?
Just have /proc/cpuinfo report "number of processors: 4" and
no per-CPU information at all...
-- PMM
^ permalink raw reply
* [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support
From: Mark Rutland @ 2014-07-17 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717131854.GN13108@titan.lakedaemon.net>
Hi Jason,
On Thu, Jul 17, 2014 at 02:18:54PM +0100, Jason Cooper wrote:
> On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpanit at amd.com wrote:
> > From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> >
> > This patch set introduces support for MSI(-X) in GICv2m specification,
> > which is implemented in some variation of GIC400.
> >
> > This depends on and has been tested with the V7 of"Add support for PCI in AArch64"
> > (https://lkml.org/lkml/2014/3/14/320).
> >
> > Changes in V3:
> > * Rebase to git://git.infradead.org/users/jcooper/linux.git irqchip/gic
> > (per Jason Cooper request)
> > * Misc fix/clean up per Mark Rutland comments
> > * Minor Clean up in the driver/irqchip/irq-gic-v2m.c: alloc_msi_irqs()
> > * Patch 4 is new to the series:
> > * Add ARM64-specific version arch_setup_msi_irqs() to allow support
> > for Multiple MSI.
> > * Add support for Multiple MSI for GICv2m.
> >
> > Suravee Suthikulpanit (4):
> > irqchip: gic: Add binding probe for ARM GIC400
> > irqchip: gic: Restructuring ARM GIC code
> > irqchip: gic: Add supports for ARM GICv2m MSI(-X)
> > irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
>
> Ok, patch #1 applied to irqchip/urgent. Patches 2 and 3 applied to
> irqchip/gic with irqchip/urgent merged in. To facilitate
> testing/merging, I've prepared an unsigned tag for you on the
> irqchip/gic branch:
I'm a little concerned that this is all going through for v3.17 without
a {Reviewed,Acked}-by from Marc or anyone working with GIC{,v2m}.
While his comments on v1 have been addressed, he has not had a chance to
acknowledge the solutions. I appreciate Marc's holiday is unfortunately
timed.
I also have an open concern with the binding with regard to the
orthogonality of GICV GICH and the MSI registers.
Suravee, do you need this urgently for v3.17? I was under the impression
that we wouldn't have full PCIe support by then.
Cheers,
Mark.
^ permalink raw reply
* The imx6q suspend/resume is broken on 3.16-rc due to PCIe
From: Lucas Stach @ 2014-07-17 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140716065505.GB2612@dragon>
Hi Shawn,
Am Mittwoch, den 16.07.2014, 14:55 +0800 schrieb Shawn Guo:
> On Mon, Jul 07, 2014 at 09:55:03PM +0800, Shawn Guo wrote:
> > On Mon, Jul 07, 2014 at 11:10:51AM +0200, Lucas Stach wrote:
> > > Hi Shawn,
> > >
> > > Over the weekend I tried to reproduce your problem on a SabreSD board,
> > > but wasn't able to trigger the issue. 3.16-rc3 with PCIe active works
> > > just fine over a suspend and resume cycle for me.
> >
> > That's strange. In my setup, PCIe support is enabled in kernel and DT,
> > but I do not have a PCIe device connected to the board.
> >
> > >
> > > One possibly relevant difference is that I've booted with NFSroot, while
> > > it seems you are using a SATA connected device. Is this right?
> >
> > I have a SATA disk connected, but did boot with NFSroot.
> >
> > > If so,
> > > can you test if it works if you boot from SDcard or the like? This might
> > > be relevant as PCIe and SATA share some clocks.
> >
> > I tried to disable SATA support completely, but it doesn't help.
>
> Lucas, any news on this? Or should we just try to use Richard's patch
> to solve the problem?
I would like to understand the problem first before throwing "fixes" at
the issue. As you said this isn't a regression we are in no hurry and
should try to analyze the issue properly. I just retested and I'm still
not able to reproduce the issue on my SabreSD. Maybe there are board
revision that exhibit different behavior? My board has two sticks on
saying "Rev B3" and "Rev X3".
As you can see from the log suspend/resume is working fine for me with
kernel 3.16-rc5 + imx_v6_v7_defconfig.
root at XXX:~ echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.004 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 95.846 msecs
PM: suspend devices took 0.100 seconds
PM: late suspend of devices complete after 5.395 msecs
PM: noirq suspend of devices complete after 4.914 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Enabling non-boot CPUs ...
CPU1: Booted secondary processor
CPU1 is up
CPU2: Booted secondary processor
CPU2 is up
CPU3: Booted secondary processor
CPU3 is up
PM: noirq resume of devices complete after 1556.385 msecs
PM: early resume of devices complete after 3.134 msecs
PM: resume of devices complete after 153.568 msecs
PM: resume devices took 0.160 seconds
Restarting tasks ... done.
ata1: SATA link down (SStatus 0 SControl 300)
fec 2188000.ethernet eth0: Link is Down
fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
root at XXX:~ echo mem > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 87.638 msecs
PM: suspend devices took 0.090 seconds
PM: late suspend of devices complete after 4.528 msecs
PM: noirq suspend of devices complete after 5.031 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Enabling non-boot CPUs ...
CPU1: Booted secondary processor
CPU1 is up
CPU2: Booted secondary processor
CPU2 is up
CPU3: Booted secondary processor
CPU3 is up
PM: noirq resume of devices complete after 1425.302 msecs
PM: early resume of devices complete after 2.736 msecs
PM: resume of devices complete after 156.013 msecs
PM: resume devices took 0.160 seconds
Restarting tasks ... done.
ata1: SATA link down (SStatus 0 SControl 300)
fec 2188000.ethernet eth0: Link is Down
fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
root at XXX:~
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 1/8] ARM: Add platform support for Fujitsu MB86S7X SoCs
From: Arnd Bergmann @ 2014-07-17 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJe_Zhc91g1=CTJUBaFaqk9Np4u4oEqddZEx_zeVxn7EdMEjmw@mail.gmail.com>
On Thursday 17 July 2014 19:02:53 Jassi Brar wrote:
> On 16 July 2014 01:39, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 15 July 2014 23:07:58 Jassi Brar wrote:
>
> >> >> diff --git a/arch/arm/mach-mb86s7x/Kconfig b/arch/arm/mach-mb86s7x/Kconfig
> >> >> new file mode 100644
> >> >> index 0000000..44f5b0c
> >> >> --- /dev/null
> >> >> +++ b/arch/arm/mach-mb86s7x/Kconfig
> >> >> @@ -0,0 +1,18 @@
> >> >> +config ARCH_MB86S7X
> >> >> + bool "Fujitsu MB86S7x platforms" if (ARCH_MULTI_V7 && ARM_LPAE)
> >> >> + select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
> >> >
> >> > Why the LPAE dependency? Is none of the RAM reachable by regular
> >> > kernels?
> >> >
> >> Some devices like PCI, LLI need it and the S70-evb has half of its ram
> >> above 4GB.
> >> Maybe ARM_LPAE should be selected by inclusion of support for those?
> >
> > No, you can't select ARM_LPAE because that would break machines that
> > do not support it in the same configuration.
> >
> To be clear, I meant selecting LPAE from config options specific to
> S70-evb and PCI on S7x.
I understood that.
> > Losing half the RAM or PCI should not be a problem, you'd just run
> > with reduced functionality. You wouldn't want to do that in practice,
> > but it's different from a hard dependency.
> >
> Sorry I am not sure what you mean. Is it ok as such?
What I mean is that it should be ok to drop the dependency, but you
can't add a 'select ARM_LPAE'. The memory should be handled correctly
already (you will just not see the upper 2GB), while the PCI host
driver should probably be checked for its error handling so it
prints a meaningful error message when it can't reach its MMIO space.
> >> >> +static void got_data(u32 code)
> >> >> +{
> >> >> + struct completion *c = NULL;
> >> >> + mhu_handler_t hndlr = NULL;
> >> >> + unsigned long flags;
> >> >> + int ev;
> >> >> +
> >> >> + if (code & RESP_BIT)
> >> >> + ev = EV_RR;
> >> >> + else
> >> >> + ev = EV_RC;
> >> >> +
> >> >> + spin_lock_irqsave(&fsm_lock, flags);
> >> >> +
> >> >> + if (mhu_fsm[fsm_state][ev] == MHU_INVLD) {
> >> >> + spin_unlock_irqrestore(&fsm_lock, flags);
> >> >> + pr_err("State-%d EV-%d FSM Broken!\n", fsm_state, ev);
> >> >> + return;
> >> >> + }
> >> >> + fsm_state = mhu_fsm[fsm_state][ev];
> >> >> +
> >> >> + if (code & RESP_BIT) {
> >> >> + c = ax->c;
> >> >> + memcpy_fromio(ax->buf, rsp_from_scb, ax->len);
> >> >> + list_move(&ax->node, &free_xfers);
> >> >> + ax = NULL;
> >> >> + } else {
> >> >> + /* Find and dispatch relevant registered handler */
> >> >> + if (code < MHU_NUM_CMDS)
> >> >> + hndlr = handler[code];
> >> >> + if (!hndlr)
> >> >> + pr_err("No handler for CMD_%u\n", code);
> >> >> + }
> >> >> +
> >> >> + spin_unlock_irqrestore(&fsm_lock, flags);
> >> >> +
> >> >> + if (hndlr)
> >> >> + hndlr(code, cmd_from_scb);
> >> >> + if (c)
> >> >> + complete(c);
> >> >> +}
> >> >> +
> >> >> +static void mhu_recv(struct mbox_client *cl, void *data)
> >> >> +{
> >> >> + got_data((u32)data);
> >> >> + schedule_work(&scb_work);
> >> >> +}
> >> >
> >> > Why the cast between integer and pointer?
> >> >
> >> The common mailbox framework passes around pointers to data packets.
> >> Its completely between controller and client drivers to decide the
> >> format of the packet. In my case the packet is a simple u32 value.
> >
> > I don't think the mailbox framework should allow that much
> > flexibility, because that would break portable drivers that
> > rely on a particular behavior from the mailbox provider.
> >
> > I understand that your driver is not portable to another mailbox
> > provider, but it still seems like a mistake in the API that should
> > better be fixed sooner than later.
> >
> Here is what I remember of many discussions on the point over the last year :)
> o We want to support zero-copy receives, which implies the mailbox
> framework must simply forward the pointer to "data packet" from
> controller to client driver.
> o We could not think of a generic enough structure for 'data packet'
> that could fit all protocols. So we assume the data packet format is
> an explicit understanding between the controller(+remote) and the
> client driver.
>
> Or did I miss your point?
Forwarding a pointer is ok, but then I think you should not overload
the 'void *data' argument. In the case above, you don't actually use
a pointer at all, but instead you use a 'code' that is taken as
an index into an array or a flag.
This is particularly broken when you think about 64-bit machines
on which you cannot cast a pointer to an u32.
What I think you should do is define your own data type for the
mailbox, which would be specific to your mailbox client and change
the code above to
struct mhu_mbox_message {
u32 code; /* another client could store a pointer here */
};
static void mhu_recv(struct mbox_client *cl, void *data)
{
struct mhu_mbox_message *msg = data;
got_data(msg->code);
schedule_work(&scp_work);
}
You get the cost of another register load here, but that should
be almost free.
There should probably also be some way to ensure that the amount
of data passed in the structure matches between mbox provider
and client.
> >> >> + do {
> >> >> +retry:
> >> >> + /* Wait until we get reply */
> >> >> + count = 0x1000000;
> >> >> + do {
> >> >> + cpu_relax();
> >> >> + val = readl_relaxed(
> >> >> + rx_reg + INTR_STAT_OFS);
> >> >> + } while (--count && !val);
> >> >> +
> >> >> + if (!val) {
> >> >> + pr_err("%s:%d SCB didn't reply\n",
> >> >> + __func__, __LINE__);
> >> >> + goto retry;
> >> >
> >> > It seems like this loop is unbounded and will just print an error every
> >> > 16M loops but never give up or re-enable interrupts if called with
> >> > interrupts disabled.
> >> >
> >> > It should probably be changed to either enforce being called with interrupts
> >> > enabled so you can call msleep() inbetween, or you should add error-handling
> >> > in case the remote side does not reply.
> >> >
> >> We can do that for completeness but otherwise my platform is as good
> >> as dead if the remote doesn't reply for some reason. And there is no
> >> fool-proof way to recover the state-machine from a failed
> >> communication.
> >
> > Do you know how long it takes normally? If you can prove that the
> > reply normally comes within a few microseconds, you can instead call
> > WARN_ON() once after too much time passes, and then continue polling.
> >
> > The case to avoid here is just accidentally polling for multiple
> > milliseconds with interrupts disabled, which would cause a lot of
> > problems.
> >
> From a few hundred micro-sec for CPU reset, to potentially tens of
> milli-sec for some I2C transaction ... yes we do have for I2C over
> mailbox! ;)
>
> Probably bailing out of the loop and returning -ETIMEOUT to the
> caller, before a WARN(), is the simplest way to die.
If you can have multiple miliseconds here, I think the code should
be changed to run in non-atomic context and use msleep(1) or
usleep_range() as a back-off. Is that possible?
> >> >> +struct mb86s7x_peri_clk {
> >> >> + u32 payload_size;
> >> >> + u32 cntrlr;
> >> >> + u32 domain;
> >> >> + u32 port;
> >> >> + u32 en;
> >> >> + u64 freqency;
> >> >> +} __packed;
> >> >
> >> > Just mark the last member by itself __packed. I assume you didn't
> >> > actually mean to change the alignment of the data structure to one
> >> > byte, but just want to say that the last one is misaligned.
> >> >
> >> This and others, are data packets that are passed between local and
> >> remote via SharedMemory. __packed is only meant to specify that these
> >> data structures have no holes in them.
> >
> > That would be '__packed __attribute__((aligned(4)))'. A struct of 'u32'
> > already has no padding on any architecture that is supported by Linux.
> > The only reason you need the packing here is because the u64 member is
> > unaligned. Note that marking the entire structure as packed means that
> > accesses are no longer atomic because the compiler may prefer to do them
> > one byte at a time, which can break the protocol on the shared memory
> > area.
> >
> We are not worried about the atomic access because the side sending
> the data doesn't touch it until the other side indicates it has
> consumed it.
It's still wrong though ;-)
Arnd
^ 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