* [PATCH 2/3] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Viresh Kumar @ 2016-10-18 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476629958-25368-3-git-send-email-yamada.masahiro@socionext.com>
On 16-10-16, 23:59, Masahiro Yamada wrote:
> + cluster0_opp: opp_table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp at 245000000 {
> + opp-hz = /bits/ 64 <245000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 250000000 {
> + opp-hz = /bits/ 64 <250000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 490000000 {
> + opp-hz = /bits/ 64 <490000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 653333333 {
Why isn't ^^ matching with below values ? Same in next patch as well.
> + opp-hz = /bits/ 64 <653334000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 666666666 {
> + opp-hz = /bits/ 64 <666667000>;
> + clock-latency-ns = <300>;
> + };
> + opp at 980000000 {
> + opp-hz = /bits/ 64 <980000000>;
> + clock-latency-ns = <300>;
> + };
> + };
> +
> clocks {
> refclk: ref {
> compatible = "fixed-clock";
> --
> 1.9.1
--
viresh
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Neil Armstrong @ 2016-10-18 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018110807.GD1641@makrotopia.org>
On 10/18/2016 01:08 PM, Daniel Golle wrote:
> Hi Neil,
>
> great to see progress towards supporting OX820!
> The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
> looks very similar, see
>
> https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
>
> To me therefore this looks quite good, just one small question below.
Hi Daniel,
Yes, I work step by step, I hope to have something booting for 4.10 !
Indeed, they look identical except the part_probes[] stuff, are they necessary ?
My primary source of code was Ma Haiju's tree and OPenWRT's tree, but would some people like to push some of the openwrt driver upstream somehow ?
Thanks,
Neil
>
> Cheers
>
> Daniel
>
>
> On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
>> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
>> This is a simple memory mapped NAND controller with single chip select and
>> software ECC.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
>> drivers/mtd/nand/Kconfig | 5 +
>> drivers/mtd/nand/Makefile | 1 +
>> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
>> 4 files changed, 174 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
>> create mode 100644 drivers/mtd/nand/oxnas_nand.c
>>
[...]
>> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
>> new file mode 100644
>> index 0000000..ee402ab
>> --- /dev/null
>> +++ b/drivers/mtd/nand/oxnas_nand.c
>> @@ -0,0 +1,144 @@
>> +/*
>> + * Oxford Semiconductor OXNAS NAND driver
>> + *
>> + * Heavily based on plat_nand.c :
>> + * Author: Vitaly Wool <vitalywool@gmail.com>
Hmm, I forgot the OpenWRT and Ma Haijun copyrights here...
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/clk.h>
>> +#include <linux/reset.h>
>> +#include <linux/mtd/mtd.h>
>> +#include <linux/mtd/nand.h>
>> +#include <linux/mtd/partitions.h>
>> +
>> +/* nand commands */
>> +#define NAND_CMD_ALE BIT(18)
>> +#define NAND_CMD_CLE BIT(19)
>> +#define NAND_CMD_CS 0
>> +#define NAND_CMD_RESET 0xff
>> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
>> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
>> +#define NAND_DATA (NAND_CMD_CS)
>> +
>> +struct oxnas_nand_data {
>> + struct nand_chip chip;
>> + void __iomem *io_base;
>
> Why do you redundantly keep io_base in platform data rather than
> just using chip.IO_ADDR_R and >chip.IO_ADDR_W?
For no reason since it's not used in oxnas_nand_cmd_ctrl...
Will remove !
>
>
>> + struct clk *clk;
>> +};
>> +
>> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
>> + unsigned int ctrl)
>> +{
>> + struct nand_chip *this = mtd->priv;
>> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
>> +
>> + if (ctrl & NAND_CTRL_CHANGE) {
>> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
>> + if (ctrl & NAND_CLE)
>> + nandaddr |= NAND_CMD;
>> + else if (ctrl & NAND_ALE)
>> + nandaddr |= NAND_ADDR;
>> + this->IO_ADDR_W = (void __iomem *) nandaddr;
>> + }
>> +
>> + if (cmd != NAND_CMD_NONE)
>> + writeb(cmd, (void __iomem *) nandaddr);
>> +}
[...]
^ permalink raw reply
* [RFC] reduce latency in __purge_vmap_area_lazy
From: Jisheng Zhang @ 2016-10-18 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476773771-11470-1-git-send-email-hch@lst.de>
On Tue, 18 Oct 2016 08:56:05 +0200 Christoph Hellwig wrote:
> Hi all,
>
> this is my spin at sorting out the long lock hold times in
> __purge_vmap_area_lazy. It is based on the patch from Joel sent this
> week. I don't have any good numbers for it, but it survived an
> xfstests run on XFS which is a significant vmalloc user. The
> changelogs could still be improved as well, but I'd rather get it
> out quickly for feedback and testing.
I just tested this series, the preempt off ftrace log doesn't complain
__purge_vmap_area_lazy any more in my test case, this latency is removed!
So feel free to add
Tested-by: Jisheng Zhang <jszhang@marvell.com>
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index 5450367..3b23b32 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy at 2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index 064b322..5450367 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018112020.30273-1-mugunthanvnm@ti.com>
Add documention of ti,min-output-impedance and ti,max-output-impedance
which can be used to correct MAC impedance mismatch using phy extended
registers.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+Optional property:
+ - ti,min-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ minimum value (35 ohms).
+ - ti,max-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
Default child nodes are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
--
2.10.1.445.g3cdd5d1
^ permalink raw reply related
* [PATCH v4 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-18 11:20 UTC (permalink / raw)
To: linux-arm-kernel
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from v3:
* Fixup change log text and no code changes.
Changes from v2:
* Fixed a typo in dts and driver.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23343139/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v4
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: add phy impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.1.445.g3cdd5d1
^ permalink raw reply
* [PATCH v4 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Rongrong Zou @ 2016-10-18 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018074922.GZ20761@phenom.ffwll.local>
Hi Daniel,
Thanks for your review!
? 2016/10/18 15:49, Daniel Vetter ??:
> On Tue, Oct 18, 2016 at 12:01:18PM +0800, Rongrong Zou wrote:
>> Add support for fbdev and framebuffer.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 25 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 25 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 257 ++++++++++++++++++++++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 67 ++++++
>> 5 files changed, 375 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> index d5c40b8..810a37e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
>> @@ -1,5 +1,5 @@
>> ccflags-y := -Iinclude/drm
>> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o hibmc_ttm.o
>> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
>>
>> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
>> #obj-y += hibmc-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index e118f3b..8ddb763 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -66,11 +66,31 @@ static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>>
>> static int hibmc_pm_suspend(struct device *dev)
>> {
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>> +
>> + if (hidev->fbdev.initialized) {
>
> What do you need these checks for? This looks a bit fishy tbh ...
It is delivered from the bochs driver, and I will fix if there are
any problems, Thanks.
>
>> + console_lock();
>> + drm_fb_helper_set_suspend(&hidev->fbdev.helper, 1);
>> + console_unlock();
>
> drm_fb_helper_set_suspend_unlocked is the new fancy one. Please use that
> one instead. Also, that has the check you might need already included,
> which means you can nuke this entire function here and just call it
> directly.
So it should be wrote as:
static int hibmc_pm_suspend(struct device *dev)
{
...
drm_kms_helper_poll_disable(drm_dev);
drm_fb_helper_set_suspend_unlocked(&hidev->fbdev.helper, 1);
...
}
static int hibmc_pm_resume(struct device *dev)
{
...
drm_helper_resume_force_mode(drm_dev);
drm_fb_helper_set_suspend_unlocked(&hidev->fbdev.helper, 0);
drm_kms_helper_poll_enable(drm_dev);
...
}, is it ?
Regards
Rongrong.
> -Daniel
>
>> + }
>> +
>> return 0;
>> }
>>
>> static int hibmc_pm_resume(struct device *dev)
>> {
>> + struct pci_dev *pdev = to_pci_dev(dev);
>> + struct drm_device *drm_dev = pci_get_drvdata(pdev);
>> + struct hibmc_drm_device *hidev = drm_dev->dev_private;
>> +
>> + if (hidev->fbdev.initialized) {
>> + console_lock();
>> + drm_fb_helper_set_suspend(&hidev->fbdev.helper, 0);
>> + console_unlock();
>> + }
>> +
>> return 0;
>> }
>>
>> @@ -170,6 +190,7 @@ static int hibmc_unload(struct drm_device *dev)
>> {
>> struct hibmc_drm_device *hidev = dev->dev_private;
>>
>> + hibmc_fbdev_fini(hidev);
>> hibmc_hw_fini(hidev);
>> dev->dev_private = NULL;
>> return 0;
>> @@ -194,6 +215,10 @@ static int hibmc_load(struct drm_device *dev, unsigned long flags)
>> if (ret)
>> goto err;
>>
>> + ret = hibmc_fbdev_init(hidev);
>> + if (ret)
>> + goto err;
>> +
>> return 0;
>>
>> err:
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 00bb153..4f5887f 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -20,9 +20,23 @@
>> #define HIBMC_DRM_DRV_H
>>
>> #include <drm/drmP.h>
>> +#include <drm/drm_fb_helper.h>
>> #include <drm/ttm/ttm_bo_driver.h>
>> #include <drm/drm_gem.h>
>>
>> +struct hibmc_framebuffer {
>> + struct drm_framebuffer fb;
>> + struct drm_gem_object *obj;
>> + bool is_fbdev_fb;
>> +};
>> +
>> +struct hibmc_fbdev {
>> + struct drm_fb_helper helper;
>> + struct hibmc_framebuffer fb;
>> + int size;
>> + bool initialized;
>> +};
>> +
>> struct hibmc_drm_device {
>> /* hw */
>> void __iomem *mmio;
>> @@ -41,9 +55,13 @@ struct hibmc_drm_device {
>> bool initialized;
>> } ttm;
>>
>> + /* fbdev */
>> + struct hibmc_fbdev fbdev;
>> bool mm_inited;
>> };
>>
>> +#define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer, fb)
>> +
>> struct hibmc_bo {
>> struct ttm_buffer_object bo;
>> struct ttm_placement placement;
>> @@ -65,8 +83,15 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>>
>> #define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT)
>>
>> +int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> +void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>> +
>> int hibmc_gem_create(struct drm_device *dev, u32 size, bool iskernel,
>> struct drm_gem_object **obj);
>> +int hibmc_framebuffer_init(struct drm_device *dev,
>> + struct hibmc_framebuffer *gfb,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object *obj);
>>
>> int hibmc_mm_init(struct hibmc_drm_device *hibmc);
>> int hibmc_bo_pin(struct hibmc_bo *bo, u32 pl_flag, u64 *gpu_addr);
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>> new file mode 100644
>> index 0000000..ea2d86a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
>> @@ -0,0 +1,257 @@
>> +/* Hisilicon Hibmc SoC drm driver
>> + *
>> + * Based on the bochs drm driver.
>> + *
>> + * Copyright (c) 2016 Huawei Limited.
>> + *
>> + * Author:
>> + * Rongrong Zou <zourongrong@huawei.com>
>> + * Rongrong Zou <zourongrong@gmail.com>
>> + * Jianhua Li <lijianhua@huawei.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + */
>> +
>> +#include <drm/drm_crtc.h>
>> +#include <drm/drm_crtc_helper.h>
>> +#include <drm/drm_fb_helper.h>
>> +
>> +#include "hibmc_drm_drv.h"
>> +
>> +/* ---------------------------------------------------------------------- */
>> +
>> +static int hibmcfb_create_object(
>> + struct hibmc_drm_device *hidev,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object **gobj_p)
>> +{
>> + struct drm_gem_object *gobj;
>> + struct drm_device *dev = hidev->dev;
>> + u32 size;
>> + int ret = 0;
>> +
>> + size = mode_cmd->pitches[0] * mode_cmd->height;
>> + ret = hibmc_gem_create(dev, size, true, &gobj);
>> + if (ret)
>> + return ret;
>> +
>> + *gobj_p = gobj;
>> + return ret;
>> +}
>> +
>> +static struct fb_ops hibmc_drm_fb_ops = {
>> + .owner = THIS_MODULE,
>> + .fb_check_var = drm_fb_helper_check_var,
>> + .fb_set_par = drm_fb_helper_set_par,
>> + .fb_fillrect = drm_fb_helper_sys_fillrect,
>> + .fb_copyarea = drm_fb_helper_sys_copyarea,
>> + .fb_imageblit = drm_fb_helper_sys_imageblit,
>> + .fb_pan_display = drm_fb_helper_pan_display,
>> + .fb_blank = drm_fb_helper_blank,
>> + .fb_setcmap = drm_fb_helper_setcmap,
>> +};
>> +
>> +static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
>> + struct drm_fb_helper_surface_size *sizes)
>> +{
>> + struct hibmc_fbdev *gfbdev =
>> + container_of(helper, struct hibmc_fbdev, helper);
>> + struct hibmc_drm_device *hidev =
>> + container_of(helper, struct hibmc_drm_device, fbdev.helper);
>> + struct fb_info *info;
>> + struct drm_framebuffer *fb;
>> + struct drm_mode_fb_cmd2 mode_cmd;
>> + struct drm_gem_object *gobj = NULL;
>> + int ret = 0;
>> + size_t size;
>> + unsigned int bytes_per_pixel;
>> + struct hibmc_bo *bo = NULL;
>> +
>> + DRM_DEBUG_DRIVER("surface width(%d), height(%d) and bpp(%d)\n",
>> + sizes->surface_width, sizes->surface_height,
>> + sizes->surface_bpp);
>> + sizes->surface_depth = 32;
>> +
>> + bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
>> +
>> + mode_cmd.width = sizes->surface_width;
>> + mode_cmd.height = sizes->surface_height;
>> + mode_cmd.pitches[0] = mode_cmd.width * bytes_per_pixel;
>> + mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
>> + sizes->surface_depth);
>> +
>> + size = roundup(mode_cmd.pitches[0] * mode_cmd.height, PAGE_SIZE);
>> +
>> + ret = hibmcfb_create_object(hidev, &mode_cmd, &gobj);
>> + if (ret) {
>> + DRM_ERROR("failed to create fbcon backing object %d\r\n", ret);
>> + return -ENOMEM;
>> + }
>> +
>> + bo = gem_to_hibmc_bo(gobj);
>> +
>> + ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
>> + if (ret)
>> + return ret;
>> +
>> + ret = hibmc_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
>> + if (ret) {
>> + DRM_ERROR("failed to pin fbcon\n");
>> + return ret;
>> + }
>> +
>> + ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
>> +
>> + if (ret) {
>> + DRM_ERROR("failed to kmap fbcon\n");
>> + ttm_bo_unreserve(&bo->bo);
>> + return ret;
>> + }
>> +
>> + ttm_bo_unreserve(&bo->bo);
>> +
>> + info = drm_fb_helper_alloc_fbi(helper);
>> + if (IS_ERR(info))
>> + ret = PTR_ERR(info);
>> +
>> + info->par = gfbdev;
>> +
>> + ret = hibmc_framebuffer_init(hidev->dev, &hidev->fbdev.fb,
>> + &mode_cmd, gobj);
>> + if (ret) {
>> + drm_fb_helper_release_fbi(helper);
>> + return ret;
>> + }
>> +
>> + hidev->fbdev.size = size;
>> + fb = &gfbdev->fb.fb;
>> + if (!fb) {
>> + DRM_INFO("fb is NULL\n");
>> + return -EINVAL;
>> + }
>> +
>> + gfbdev->helper.fb = fb;
>> +
>> + strcpy(info->fix.id, "hibmcdrmfb");
>> +
>> + info->flags = FBINFO_DEFAULT;
>> + info->fbops = &hibmc_drm_fb_ops;
>> +
>> + drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
>> + drm_fb_helper_fill_var(info, &hidev->fbdev.helper, sizes->fb_width,
>> + sizes->fb_height);
>> +
>> + info->screen_base = bo->kmap.virtual;
>> + info->screen_size = size;
>> +
>> + info->fix.smem_start = bo->bo.mem.bus.offset + bo->bo.mem.bus.base;
>> + info->fix.smem_len = size;
>> +
>> + return 0;
>> +}
>> +
>> +static int hibmc_fbdev_destroy(struct drm_device *dev,
>> + struct hibmc_fbdev *fbdev)
>> +{
>> + struct hibmc_framebuffer *gfb = &fbdev->fb;
>> + struct drm_fb_helper *fbh = &fbdev->helper;
>> +
>> + DRM_DEBUG_DRIVER("hibmc_fbdev_destroy\n");
>> +
>> + drm_fb_helper_unregister_fbi(fbh);
>> + drm_fb_helper_release_fbi(fbh);
>> +
>> + if (gfb->obj) {
>> + drm_gem_object_unreference_unlocked(gfb->obj);
>> + gfb->obj = NULL;
>> + }
>> +
>> + drm_fb_helper_fini(fbh);
>> +
>> + drm_framebuffer_unregister_private(&gfb->fb);
>> + drm_framebuffer_cleanup(&gfb->fb);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct drm_fb_helper_funcs hibmc_fbdev_helper_funcs = {
>> + .fb_probe = hibmc_drm_fb_create,
>> +};
>> +
>> +int hibmc_fbdev_init(struct hibmc_drm_device *hidev)
>> +{
>> + int ret;
>> + struct fb_var_screeninfo *var;
>> + struct fb_fix_screeninfo *fix;
>> +
>> + drm_fb_helper_prepare(hidev->dev, &hidev->fbdev.helper,
>> + &hibmc_fbdev_helper_funcs);
>> +
>> + /* Now just one crtc and one channel */
>> + ret = drm_fb_helper_init(hidev->dev,
>> + &hidev->fbdev.helper, 1, 1);
>> +
>> + if (ret)
>> + return ret;
>> +
>> + ret = drm_fb_helper_single_add_all_connectors(&hidev->fbdev.helper);
>> + if (ret)
>> + goto fini;
>> +
>> + ret = drm_fb_helper_initial_config(&hidev->fbdev.helper, 16);
>> + if (ret)
>> + goto fini;
>> +
>> + hidev->fbdev.initialized = true;
>> +
>> + var = &hidev->fbdev.helper.fbdev->var;
>> + fix = &hidev->fbdev.helper.fbdev->fix;
>> +
>> + DRM_DEBUG("Member of info->var is :\n"
>> + "xres=%d\n"
>> + "yres=%d\n"
>> + "xres_virtual=%d\n"
>> + "yres_virtual=%d\n"
>> + "xoffset=%d\n"
>> + "yoffset=%d\n"
>> + "bits_per_pixel=%d\n"
>> + "...\n", var->xres, var->yres, var->xres_virtual,
>> + var->yres_virtual, var->xoffset, var->yoffset,
>> + var->bits_per_pixel);
>> + DRM_DEBUG("Member of info->fix is :\n"
>> + "smem_start=%lx\n"
>> + "smem_len=%d\n"
>> + "type=%d\n"
>> + "type_aux=%d\n"
>> + "visual=%d\n"
>> + "xpanstep=%d\n"
>> + "ypanstep=%d\n"
>> + "ywrapstep=%d\n"
>> + "line_length=%d\n"
>> + "accel=%d\n"
>> + "capabilities=%d\n"
>> + "...\n", fix->smem_start, fix->smem_len, fix->type,
>> + fix->type_aux, fix->visual, fix->xpanstep,
>> + fix->ypanstep, fix->ywrapstep, fix->line_length,
>> + fix->accel, fix->capabilities);
>> +
>> + return 0;
>> +
>> +fini:
>> + drm_fb_helper_fini(&hidev->fbdev.helper);
>> + return ret;
>> +}
>> +
>> +void hibmc_fbdev_fini(struct hibmc_drm_device *hidev)
>> +{
>> + if (!hidev->fbdev.initialized)
>> + return;
>> +
>> + hibmc_fbdev_destroy(hidev->dev, &hidev->fbdev);
>> + hidev->fbdev.initialized = false;
>> +}
>> +
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> index 2dbef04..c8f7f6c 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
>> @@ -489,3 +489,70 @@ int hibmc_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
>> return 0;
>> }
>>
>> +/* ---------------------------------------------------------------------- */
>> +
>> +static void hibmc_user_framebuffer_destroy(struct drm_framebuffer *fb)
>> +{
>> + struct hibmc_framebuffer *hibmc_fb = to_hibmc_framebuffer(fb);
>> +
>> + drm_gem_object_unreference_unlocked(hibmc_fb->obj);
>> + drm_framebuffer_cleanup(fb);
>> + kfree(fb);
>> +}
>> +
>> +static const struct drm_framebuffer_funcs hibmc_fb_funcs = {
>> + .destroy = hibmc_user_framebuffer_destroy,
>> +};
>> +
>> +int hibmc_framebuffer_init(struct drm_device *dev,
>> + struct hibmc_framebuffer *gfb,
>> + const struct drm_mode_fb_cmd2 *mode_cmd,
>> + struct drm_gem_object *obj)
>> +{
>> + int ret;
>> +
>> + drm_helper_mode_fill_fb_struct(&gfb->fb, mode_cmd);
>> + gfb->obj = obj;
>> + ret = drm_framebuffer_init(dev, &gfb->fb, &hibmc_fb_funcs);
>> + if (ret) {
>> + DRM_ERROR("drm_framebuffer_init failed: %d\n", ret);
>> + return ret;
>> + }
>> + return 0;
>> +}
>> +
>> +static struct drm_framebuffer *
>> +hibmc_user_framebuffer_create(struct drm_device *dev,
>> + struct drm_file *filp,
>> + const struct drm_mode_fb_cmd2 *mode_cmd)
>> +{
>> + struct drm_gem_object *obj;
>> + struct hibmc_framebuffer *hibmc_fb;
>> + int ret;
>> +
>> + DRM_DEBUG_DRIVER("%dx%d, format %c%c%c%c\n",
>> + mode_cmd->width, mode_cmd->height,
>> + (mode_cmd->pixel_format) & 0xff,
>> + (mode_cmd->pixel_format >> 8) & 0xff,
>> + (mode_cmd->pixel_format >> 16) & 0xff,
>> + (mode_cmd->pixel_format >> 24) & 0xff);
>> +
>> + obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
>> + if (!obj)
>> + return ERR_PTR(-ENOENT);
>> +
>> + hibmc_fb = kzalloc(sizeof(*hibmc_fb), GFP_KERNEL);
>> + if (!hibmc_fb) {
>> + drm_gem_object_unreference_unlocked(obj);
>> + return ERR_PTR(-ENOMEM);
>> + }
>> +
>> + ret = hibmc_framebuffer_init(dev, hibmc_fb, mode_cmd, obj);
>> + if (ret) {
>> + drm_gem_object_unreference_unlocked(obj);
>> + kfree(hibmc_fb);
>> + return ERR_PTR(ret);
>> + }
>> + return &hibmc_fb->fb;
>> +}
>> +
>> --
>> 1.9.1
>>
>
^ permalink raw reply
* [PATCH] arm64: Cortex-A53 errata workaround: check for kernel addresses
From: Andre Przywara @ 2016-10-18 11:16 UTC (permalink / raw)
To: linux-arm-kernel
Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
errata-affected core") adds code to execute cache maintenance instructions
in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
It turns out that the address hasn't been checked to be a valid user
space address, allowing userland to clean cache lines in kernel space.
Fix this by introducing an access_ok() check before executing the
instructions on behalf of userland, taking care of tagged pointers on
the way.
Reported-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Cc: <stable@vger.kernel.org> # 4.8.x
---
arch/arm64/include/asm/uaccess.h | 4 ++++
arch/arm64/kernel/traps.c | 32 ++++++++++++++++++++++++++++----
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index bcaf6fb..f842b47 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -21,6 +21,7 @@
/*
* User space memory access functions
*/
+#include <linux/bitops.h>
#include <linux/kasan-checks.h>
#include <linux/string.h>
#include <linux/thread_info.h>
@@ -103,6 +104,9 @@ static inline void set_fs(mm_segment_t fs)
})
#define access_ok(type, addr, size) __range_ok(addr, size)
+#define access_ok_tagged(type, addr, size) access_ok(type, \
+ sign_extend64(addr, 55), \
+ size)
#define user_addr_max get_fs
#define _ASM_EXTABLE(from, to) \
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5ff020f..04ea0d7 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -447,6 +447,30 @@ void cpu_enable_cache_maint_trap(void *__unused)
: "=r" (res) \
: "r" (address), "i" (-EFAULT) )
+enum {USER_CACHE_MAINT_DC_CIVAC, USER_CACHE_MAINT_IC_IVAU};
+
+static int do_user_cache_maint(int ins_type, unsigned long address)
+{
+ int ret;
+ unsigned long cl_size = cache_line_size();
+
+ if (!access_ok_tagged(VERIFY_READ,
+ round_down(address, cl_size),
+ cl_size))
+ return -EFAULT;
+
+ switch (ins_type) {
+ case USER_CACHE_MAINT_DC_CIVAC:
+ __user_cache_maint("dc civac", address, ret);
+ break;
+ case USER_CACHE_MAINT_IC_IVAU:
+ __user_cache_maint("ic ivau", address, ret);
+ break;
+ }
+
+ return ret;
+}
+
static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
{
unsigned long address;
@@ -458,16 +482,16 @@ static void user_cache_maint_handler(unsigned int esr, struct pt_regs *regs)
switch (crm) {
case ESR_ELx_SYS64_ISS_CRM_DC_CVAU: /* DC CVAU, gets promoted */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_DC_CVAC: /* DC CVAC, gets promoted */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_DC_CIVAC: /* DC CIVAC */
- __user_cache_maint("dc civac", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_DC_CIVAC, address);
break;
case ESR_ELx_SYS64_ISS_CRM_IC_IVAU: /* IC IVAU */
- __user_cache_maint("ic ivau", address, ret);
+ ret = do_user_cache_maint(USER_CACHE_MAINT_IC_IVAU, address);
break;
default:
force_signal_inject(SIGILL, ILL_ILLOPC, regs, 0);
--
2.9.0
^ permalink raw reply related
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Daniel Golle @ 2016-10-18 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018090927.1990-1-narmstrong@baylibre.com>
Hi Neil,
great to see progress towards supporting OX820!
The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
looks very similar, see
https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/drivers/mtd/nand/oxnas_nand.c;h=f5a142950e32227fee304de731e619278350a91b;hb=refs/heads/oxnas-nand
To me therefore this looks quite good, just one small question below.
Cheers
Daniel
On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> This is a simple memory mapped NAND controller with single chip select and
> software ECC.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
> drivers/mtd/nand/Kconfig | 5 +
> drivers/mtd/nand/Makefile | 1 +
> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
> 4 files changed, 174 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> create mode 100644 drivers/mtd/nand/oxnas_nand.c
>
> diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> new file mode 100644
> index 0000000..83b684d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> @@ -0,0 +1,24 @@
> +* Oxford Semiconductor OXNAS NAND Controller
> +
> +Please refer to nand.txt for generic information regarding MTD NAND bindings.
> +
> +Required properties:
> + - compatible: "oxsemi,ox820-nand"
> + - reg: Base address and length for NAND mapped memory.
> +
> +Optional Properties:
> + - clocks: phandle to the NAND gate clock if needed.
> + - resets: phandle to the NAND reset control if needed.
> +
> +Example:
> +
> +nand: nand at 41000000 {
> + compatible = "oxsemi,ox820-nand";
> + reg = <0x41000000 0x100000>;
> + nand-ecc-mode = "soft";
> + clocks = <&stdclk CLK_820_NAND>;
> + resets = <&reset RESET_NAND>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + status = "disabled";
> +};
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 7b7a887..c023125 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -426,6 +426,11 @@ config MTD_NAND_ORION
> No board specific support is done by this driver, each board
> must advertise a platform_device for the driver to attach.
>
> +config MTD_NAND_OXNAS
> + tristate "NAND Flash support for Oxford Semiconductor SoC"
> + help
> + This enables the NAND flash controller on Oxford Semiconductor SoCs.
> +
> config MTD_NAND_FSL_ELBC
> tristate "NAND support for Freescale eLBC controllers"
> depends on FSL_SOC
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index cafde6f..05fc054 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -35,6 +35,7 @@ obj-$(CONFIG_MTD_NAND_TMIO) += tmio_nand.o
> obj-$(CONFIG_MTD_NAND_PLATFORM) += plat_nand.o
> obj-$(CONFIG_MTD_NAND_PASEMI) += pasemi_nand.o
> obj-$(CONFIG_MTD_NAND_ORION) += orion_nand.o
> +obj-$(CONFIG_MTD_NAND_OXNAS) += oxnas_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_ELBC) += fsl_elbc_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_IFC) += fsl_ifc_nand.o
> obj-$(CONFIG_MTD_NAND_FSL_UPM) += fsl_upm.o
> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
> new file mode 100644
> index 0000000..ee402ab
> --- /dev/null
> +++ b/drivers/mtd/nand/oxnas_nand.c
> @@ -0,0 +1,144 @@
> +/*
> + * Oxford Semiconductor OXNAS NAND driver
> + *
> + * Heavily based on plat_nand.c :
> + * Author: Vitaly Wool <vitalywool@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/mtd/nand.h>
> +#include <linux/mtd/partitions.h>
> +
> +/* nand commands */
> +#define NAND_CMD_ALE BIT(18)
> +#define NAND_CMD_CLE BIT(19)
> +#define NAND_CMD_CS 0
> +#define NAND_CMD_RESET 0xff
> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
> +#define NAND_DATA (NAND_CMD_CS)
> +
> +struct oxnas_nand_data {
> + struct nand_chip chip;
> + void __iomem *io_base;
Why do you redundantly keep io_base in platform data rather than
just using chip.IO_ADDR_R and >chip.IO_ADDR_W?
> + struct clk *clk;
> +};
> +
> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
> + unsigned int ctrl)
> +{
> + struct nand_chip *this = mtd->priv;
> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
> +
> + if (ctrl & NAND_CTRL_CHANGE) {
> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
> + if (ctrl & NAND_CLE)
> + nandaddr |= NAND_CMD;
> + else if (ctrl & NAND_ALE)
> + nandaddr |= NAND_ADDR;
> + this->IO_ADDR_W = (void __iomem *) nandaddr;
> + }
> +
> + if (cmd != NAND_CMD_NONE)
> + writeb(cmd, (void __iomem *) nandaddr);
> +}
> +
> +/*
> + * Probe for the NAND device.
> + */
> +static int oxnas_nand_probe(struct platform_device *pdev)
> +{
> + struct oxnas_nand_data *data;
> + struct mtd_info *mtd;
> + struct resource *res;
> + int err = 0;
> +
> + /* Allocate memory for the device structure (and zero it) */
> + data = devm_kzalloc(&pdev->dev, sizeof(struct oxnas_nand_data),
> + GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + data->io_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(data->io_base))
> + return PTR_ERR(data->io_base);
> +
> + data->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(data->clk))
> + data->clk = NULL;
> +
> + nand_set_flash_node(&data->chip, pdev->dev.of_node);
> + mtd = nand_to_mtd(&data->chip);
> + mtd->dev.parent = &pdev->dev;
> + mtd->priv = &data->chip;
> +
> + data->chip.IO_ADDR_R = data->io_base;
> + data->chip.IO_ADDR_W = data->io_base;
> + data->chip.cmd_ctrl = oxnas_nand_cmd_ctrl;
> + data->chip.chip_delay = 30;
> + data->chip.ecc.mode = NAND_ECC_SOFT;
> + data->chip.ecc.algo = NAND_ECC_HAMMING;
> +
> + platform_set_drvdata(pdev, data);
> +
> + clk_prepare_enable(data->clk);
> + device_reset_optional(&pdev->dev);
> +
> + /* Scan to find existence of the device */
> + if (nand_scan(mtd, 1)) {
> + err = -ENXIO;
> + goto out;
> + }
> +
> + err = mtd_device_parse_register(mtd, NULL, NULL, NULL, 0);
> + if (!err)
> + return err;
> +
> + nand_release(mtd);
> +out:
> + return err;
> +}
> +
> +static int oxnas_nand_remove(struct platform_device *pdev)
> +{
> + struct oxnas_nand_data *data = platform_get_drvdata(pdev);
> +
> + nand_release(nand_to_mtd(&data->chip));
> +
> + return 0;
> +}
> +
> +static const struct of_device_id oxnas_nand_match[] = {
> + { .compatible = "oxsemi,ox820-nand" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, oxnas_nand_match);
> +
> +static struct platform_driver oxnas_nand_driver = {
> + .probe = oxnas_nand_probe,
> + .remove = oxnas_nand_remove,
> + .driver = {
> + .name = "oxnas_nand",
> + .of_match_table = oxnas_nand_match,
> + },
> +};
> +
> +module_platform_driver(oxnas_nand_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Vitaly Wool");
> +MODULE_DESCRIPTION("Oxnas NAND driver");
> +MODULE_ALIAS("platform:oxnas_nand");
> --
> 2.7.0
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Sudeep Holla @ 2016-10-18 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018104539.GB15639@leverpostej>
On 18/10/16 11:45, Mark Rutland wrote:
> On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
>>>> b. in arm64, if some platform has its own suspend flow, couldn't it
>>>> adopts arm/match-xxx to register its own global suspend method?
>>>
>>> No, PSCI is highly recommended.
>>
>> Relying on firmware for suspend on x86 was a great disaster, lets not repeat
>> that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
>> for example) -- feel free to copy that code from arm32.
>
> Quite frankly, copying hundreds of lines of board-specific code
> (including assembly that won't compile) is unlikely to help.
>
> So far arm64 requires well-defined, standard, reusable interfaces (e.g.
> PSCI). That cleanly separates concerns (e.g. anyone can implement the
> backend without mandatory changes to the kernel), and keeps things
> maintainable.
>
> ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
> can use and build atop of. It's open source (three-clause BSD with DCO),
> and accepts board ports. You can have a completely open stack,
> regardless of whether part of that stack is firmware.
>
I think you missed to add the link[1]
--
Regards,
Sudeep
[1] https://github.com/ARM-software/arm-trusted-firmware
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-18 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
On 11 October 2016 at 19:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So this
> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> well, and an additional fix for XTS which escaped my attention before.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> fix is compatible with, not the patch that introduced the algorithm. This is due
> to the fact that the key schedules are incompatible between generic AES and the
> arm64 Crypto Extensions implementation (but only when building for big endian)
> This is not a problem in practice, but it does mean that the AES-CCM and AES in
> EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
> one that is compatible with the generic AES key schedule generation code (which
> it currently no longer uses)
>
> In any case, please apply with cc to stable.
>
Ping?
> Ard Biesheuvel (8):
> crypto: arm64/aes-ce - fix for big endian
> crypto: arm64/ghash-ce - fix for big endian
> crypto: arm64/sha1-ce - fix for big endian
> crypto: arm64/sha2-ce - fix for big endian
> crypto: arm64/aes-ccm-ce: fix for big endian
> crypto: arm64/aes-neon - fix for big endian
> crypto: arm64/aes-xts-ce: fix for big endian
> crypto: arm/aes-ce - fix for big endian
>
> arch/arm/crypto/aes-ce-glue.c | 5 ++
> arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
> arch/arm64/crypto/aes-ce-cipher.c | 25 +++++----
> arch/arm64/crypto/aes-ce.S | 1 +
> arch/arm64/crypto/aes-modes.S | 3 +-
> arch/arm64/crypto/aes-neon.S | 25 +++++----
> arch/arm64/crypto/ghash-ce-core.S | 6 +--
> arch/arm64/crypto/sha1-ce-core.S | 4 +-
> arch/arm64/crypto/sha2-ce-core.S | 4 +-
> 9 files changed, 72 insertions(+), 54 deletions(-)
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 5/5] crypto: arm/sha2-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/sha2-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/sha2-ce-glue.c b/arch/arm/crypto/sha2-ce-glue.c
index 0755b2d657f3..df4dcef054ae 100644
--- a/arch/arm/crypto/sha2-ce-glue.c
+++ b/arch/arm/crypto/sha2-ce-glue.c
@@ -11,6 +11,7 @@
#include <crypto/internal/hash.h>
#include <crypto/sha.h>
#include <crypto/sha256_base.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -100,8 +101,6 @@ static struct shash_alg algs[] = { {
static int __init sha2_ce_mod_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_SHA2))
- return -ENODEV;
return crypto_register_shashes(algs, ARRAY_SIZE(algs));
}
@@ -110,5 +109,5 @@ static void __exit sha2_ce_mod_fini(void)
crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
-module_init(sha2_ce_mod_init);
+module_cpu_feature_match(SHA2, sha2_ce_mod_init);
module_exit(sha2_ce_mod_fini);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] crypto: arm/sha1-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/sha1-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/sha1-ce-glue.c b/arch/arm/crypto/sha1-ce-glue.c
index 80bc2fcd241a..555f72b5e659 100644
--- a/arch/arm/crypto/sha1-ce-glue.c
+++ b/arch/arm/crypto/sha1-ce-glue.c
@@ -11,6 +11,7 @@
#include <crypto/internal/hash.h>
#include <crypto/sha.h>
#include <crypto/sha1_base.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -82,8 +83,6 @@ static struct shash_alg alg = {
static int __init sha1_ce_mod_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_SHA1))
- return -ENODEV;
return crypto_register_shash(&alg);
}
@@ -92,5 +91,5 @@ static void __exit sha1_ce_mod_fini(void)
crypto_unregister_shash(&alg);
}
-module_init(sha1_ce_mod_init);
+module_cpu_feature_match(SHA1, sha1_ce_mod_init);
module_exit(sha1_ce_mod_fini);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] crypto: arm/ghash-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/ghash-ce-glue.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
index 7546b3c02466..6bac8bea9f1e 100644
--- a/arch/arm/crypto/ghash-ce-glue.c
+++ b/arch/arm/crypto/ghash-ce-glue.c
@@ -15,6 +15,7 @@
#include <crypto/cryptd.h>
#include <crypto/internal/hash.h>
#include <crypto/gf128mul.h>
+#include <linux/cpufeature.h>
#include <linux/crypto.h>
#include <linux/module.h>
@@ -311,9 +312,6 @@ static int __init ghash_ce_mod_init(void)
{
int err;
- if (!(elf_hwcap2 & HWCAP2_PMULL))
- return -ENODEV;
-
err = crypto_register_shash(&ghash_alg);
if (err)
return err;
@@ -334,5 +332,5 @@ static void __exit ghash_ce_mod_exit(void)
crypto_unregister_shash(&ghash_alg);
}
-module_init(ghash_ce_mod_init);
+module_cpu_feature_match(PMULL, ghash_ce_mod_init);
module_exit(ghash_ce_mod_exit);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] crypto: arm/aes-ce - enable module autoloading based on CPU feature bits
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/aes-ce-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index aef022a87c53..5b1af6f8b2b5 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -14,6 +14,7 @@
#include <crypto/aes.h>
#include <crypto/ablk_helper.h>
#include <crypto/algapi.h>
+#include <linux/cpufeature.h>
#include <linux/module.h>
#include <crypto/xts.h>
@@ -515,8 +516,6 @@ static struct crypto_alg aes_algs[] = { {
static int __init aes_init(void)
{
- if (!(elf_hwcap2 & HWCAP2_AES))
- return -ENODEV;
return crypto_register_algs(aes_algs, ARRAY_SIZE(aes_algs));
}
@@ -525,5 +524,5 @@ static void __exit aes_exit(void)
crypto_unregister_algs(aes_algs, ARRAY_SIZE(aes_algs));
}
-module_init(aes_init);
+module_cpu_feature_match(AES, aes_init);
module_exit(aes_exit);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Wire up the generic support for exposing CPU feature bits via the
modalias in /sys/device/system/cpu. This allows udev to automatically
load modules for things like crypto algorithms that are implemented
using optional instructions.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..1a0c6a486a9c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -21,6 +21,7 @@ config ARM
select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+ select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
new file mode 100644
index 000000000000..19c3dddd901a
--- /dev/null
+++ b/arch/arm/include/asm/cpufeature.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_CPUFEATURE_H
+#define __ASM_CPUFEATURE_H
+
+#include <asm/hwcap.h>
+
+/*
+ * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
+ * of optional CPU features it defines, ARM's CPU capability bits have been
+ * divided across separate elf_hwcap and elf_hwcap2 variables, each of which
+ * covers a subset of the available CPU features.
+ *
+ * Currently, only a few of those are suitable for automatic module loading
+ * (which is the primary use case of this facility) and those happen to be all
+ * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
+ */
+#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap2))
+#define cpu_feature(x) ilog2(HWCAP2_ ## x)
+
+static inline bool cpu_have_feature(unsigned int num)
+{
+ return elf_hwcap2 & (1UL << num);
+}
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] ARM: add module autoloading support for crypto modules
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
This series wires up the crypto modules that use the ARM 32-bit versions of
the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
feature bits via the CPU modalias. This is very similar to the arm64
implementation, with the notable exception that ARM has its CPU feature
definitions split across HWCAP and HWCAP2.
Given that the crypto feature bits are all exposed via HWCAP2, and considering
that there are currently no features exposed via HWCAP that are relevant to
udev module autoloading, exposing HWCAP2 only should be sufficient, at least
for now.
Note to Herbert: patches #2 - #5 all depend on #1, which requires an ack from
Russell, so please don't pull anything until #1 has been acked and/or merged.
Ard Biesheuvel (5):
ARM: wire up HWCAP2 feature bits to the CPU modalias
crypto: arm/aes-ce - enable module autoloading based on CPU feature
bits
crypto: arm/ghash-ce - enable module autoloading based on CPU feature
bits
crypto: arm/sha1-ce - enable module autoloading based on CPU feature
bits
crypto: arm/sha2-ce - enable module autoloading based on CPU feature
bits
arch/arm/Kconfig | 1 +
arch/arm/crypto/aes-ce-glue.c | 5 ++-
arch/arm/crypto/ghash-ce-glue.c | 6 ++--
arch/arm/crypto/sha1-ce-glue.c | 5 ++-
arch/arm/crypto/sha2-ce-glue.c | 5 ++-
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
6 files changed, 41 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/include/asm/cpufeature.h
--
2.7.4
^ permalink raw reply
* [v12, 0/8] Fix eSDHC host version register bug
From: Ulf Hansson @ 2016-10-18 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu@nxp.com>
On 21 September 2016 at 08:57, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 10 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only available
> method left now. This v11 patchset introduces the soc_device_match interface in
> soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++++++
> drivers/clk/clk-qoriq.c | 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257 +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++----
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h | 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
> rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
>
This looks good to me! I am not sure which tree you want this to be
picked up through, but unless no other volunteers I can take it
through my mmc tree.
Although, before considering to apply, I need an ack from Scott/Arnd
for the guts driver in patch 5/8 and I need an ack from Greg for patch
7/8, where the soc_device_match() interface is added (seems like you
didn't add him on cc/to).
Kind regards
Uffe
^ permalink raw reply
* [PATCH V2 3/4] ACPI,PCI,IRQ: separate ISA penalty calculation
From: Bjorn Helgaas @ 2016-10-18 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467188859-28188-4-git-send-email-okaya@codeaurora.org>
Hi Sinan,
On Wed, Jun 29, 2016 at 04:27:37AM -0400, Sinan Kaya wrote:
> Since commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> the penalty values are calculated on the fly rather than boot time.
>
> This works fine for PCI interrupts but not so well for the ISA interrupts.
> Whether an ISA interrupt is in use or not information is not available
> inside the pci_link.c file. This information gets sent externally via
> acpi_penalize_isa_irq function. If active is true, then the IRQ is in use
> by ISA. Otherwise, IRQ is in use by PCI.
>
> Since the current code relies on PCI Link object for determination of
> penalties, we are factoring in the PCI penalty twice after
> acpi_penalize_isa_irq function is called.
I know this patch has already been merged, but I'm confused.
Can you be a little more specific about how we factor in the PCI
penalty twice? I think that when we enumerate an enabled link device,
we call acpi_penalize_isa_irq(x) in this path:
pnpacpi_allocated_resource
pnpacpi_add_irqresource
pcibios_penalize_isa_irq
acpi_penalize_isa_irq
acpi_isa_irq_penalty[x] = PIRQ_PENALTY_ISA_USED
And I see that acpi_irq_penalty_init() also adds in some penalty
(either "PIRQ_PENALTY_PCI_POSSIBLE / possible_count" or
PIRQ_PENALTY_PCI_POSSIBLE). And when we call acpi_irq_get_penalty(x),
we add in PIRQ_PENALTY_PCI_USING.
It doesn't seem right to me that we're adding both
PIRQ_PENALTY_ISA_USED and PIRQ_PENALTY_PCI_USING. Is that the problem
you're referring to?
> This change is limiting the newly added functionality to just PCI
> interrupts so that old behavior is still maintained.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 714ba4d..8c08971 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -496,9 +496,6 @@ static int acpi_irq_get_penalty(int irq)
> {
> int penalty = 0;
>
> - if (irq < ACPI_MAX_ISA_IRQS)
> - penalty += acpi_isa_irq_penalty[irq];
> -
> /*
> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> @@ -513,6 +510,9 @@ static int acpi_irq_get_penalty(int irq)
> penalty += PIRQ_PENALTY_PCI_USING;
> }
>
> + if (irq < ACPI_MAX_ISA_IRQS)
> + return penalty + acpi_isa_irq_penalty[irq];
> +
> penalty += acpi_irq_pci_sharing_penalty(irq);
> return penalty;
I don't understand what's going on here.
acpi_irq_pci_sharing_penalty(X) basically tells us how many link
devices are already using IRQ X. This change makes it so we don't
consider that information if X < ACPI_MAX_ISA_IRQS.
Let's say we have several link devices that are initially disabled,
e.g.,
LNKA (IRQs 9 10 11)
LNKB (IRQs 9 10 11)
LNKC (IRQs 9 10 11)
When we enable these, I think we'll choose the same IRQ for all of
them because we no longer look@the other links to see how they're
configured.
> }
> --
> 1.8.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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
* how to enable suspend to ram for arm-64 bits
From: Mark Rutland @ 2016-10-18 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018100002.GA4347@xo-6d-61-c0.localdomain>
On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
> > >b. in arm64, if some platform has its own suspend flow, couldn't it
> > >adopts arm/match-xxx to register its own global suspend method?
> >
> > No, PSCI is highly recommended.
>
> Relying on firmware for suspend on x86 was a great disaster, lets not repeat
> that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
> for example) -- feel free to copy that code from arm32.
Quite frankly, copying hundreds of lines of board-specific code
(including assembly that won't compile) is unlikely to help.
So far arm64 requires well-defined, standard, reusable interfaces (e.g.
PSCI). That cleanly separates concerns (e.g. anyone can implement the
backend without mandatory changes to the kernel), and keeps things
maintainable.
ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
can use and build atop of. It's open source (three-clause BSD with DCO),
and accepts board ports. You can have a completely open stack,
regardless of whether part of that stack is firmware.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM: dts: mps2: remove skeleton.dtsi include and fix unit address warnings
From: Vladimir Murzin @ 2016-10-18 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8b698799-6c7a-d20a-6e54-ddd9eb329369@arm.com>
On 17/10/16 17:51, Sudeep Holla wrote:
>
>
> On 17/10/16 12:47, Vladimir Murzin wrote:
>> Removale of skeleton.dtsi allows us also to fix the following
>> warning from the dts compiler:
>> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>>
>> by adding proper unit addresses to the memory nodes.
>>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>
> It's always better to cc device-tree list, anyways applied this to [1].
Thanks!
Vladimir
>
> --
> Regards,
> Sudeep
>
> [1] git.kernel.org/sudeep.holla/linux/h/vexpress-dt/for-next
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
^ permalink raw reply
* [PATCH] ARM: dts: realview: Extend PBX family memory description
From: Robin Murphy @ 2016-10-18 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018102550.GM1041@n2100.armlinux.org.uk>
On 18/10/16 11:25, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 10:21:13AM +0200, Linus Walleij wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> All three platforms sharing the later RealView Platform Baseboard memory
>> map - PBX-A9, PB-A8 and PB11MPCore, provide 512MB of DDR SDRAM on the
>> baseboard, of which the boot alias at 0x0 maps the first 256MB. Expand
>> the size of the default memory node to reflect that, and describe the
>> full memory regions in each board's DTS, but leave those commented by
>> default to avoid breaking existing bootloaders.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ARM SoC folks: I forgot to send this patch for ARM SoC earlier.
>> As it is a small change I suggest you just apply it to the ARM
>> SoC tree as I do not foresee any other RealView work in the near
>> future. If you think it can go into v4.9 then put it in as a fix,
>> else just push it to the next merge window.
>> Robin: sorry for screwing up :(
>
> Normally, memory nodes describe different regions of unique memory.
> This is not unique memory, but is an alias of some already-described
> memory.
Well, really, this is _the_ memory, and the 256MB at 0 is the alias, but
only the separate PB11MPCore DTS has the luxury of being correct from
the off, thanks to the precedent of the QEMU PB-A8 model being popular
and expecting to use the low alias.
> The problem with adding the aliased memory addresses is that we end
> up needing platform knowledge to reject the "other alias" from the
> memory description, which really isn't good.
>
> The only reason it works is that we reject memory nodes where the
> physical address < PHYS_OFFSET. That works provided the alias is
> below PHYS_OFFSET, but that isn't always the case.
Look again ;) It works perfectly because whilst the information is in
the DTS for completeness, as-is it's not in the DTB that the kernel
gets. And if someone _does_ adjust their kernel load address and
uncomment the .dts node accordingly, the "reg" property from the .dtsi
node gets overridden, not added to, so it's still fine.
Robin.
>
> So, I think it is completely wrong to describe the aliased memory
> regions in DT.
>
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Lorenzo Pieralisi @ 2016-10-18 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018100002.GA4347@xo-6d-61-c0.localdomain>
On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
> Hi!
>
> > >b. in arm64, if some platform has its own suspend flow, couldn't it
> > >adopts arm/match-xxx to register its own global suspend method?
> > >
> >
> > No, PSCI is highly recommended.
>
> Relying on firmware for suspend on x86 was a great disaster, lets not
> repeat that mistake. arm32 has better powermanagement than x86 ever
> will (see Nokia N900 for example) -- feel free to copy that code from
> arm32.
Yes sure, feel free to copy my:
NACKed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
to all the resulting patches then. On ARM64 if he wants to implement
suspend-to-RAM his PSCI firmware will have to implement PSCI system
suspend method, end of this discussion.
By the way, why are you advising people on this subject ?
What do you know about the PSCI firmware interface to state what
you are saying above ?
Lorenzo
^ 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