* [PATCH 0/5] ARM: OMAP: dead code removal
From: Joshua Clayton @ 2016-11-02 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478000206-10855-1-git-send-email-Nicolae_Rosia@mentor.com>
On Tuesday, November 01, 2016 01:36:41 PM Nicolae Rosia wrote:
> Hi,
>
> I have identified some dead code which can be removed.
>
> Nicolae Rosia (5):
> ARM: OMAP4: kill omap4_pmic_init and omap4_pmic_get_config
> ARM: OMAP3: kill omap3_pmic_get_config and twl_{get,set}_voltage
> ARM: OMAP3: kill omap3_pmic_init
> ARM: OMAP2: kill omap2_pmic_init
> ARM: OMAP: kill omap_pmic_init
>
> arch/arm/mach-omap2/twl-common.c | 483 ---------------------------------------
> arch/arm/mach-omap2/twl-common.h | 24 --
> 2 files changed, 507 deletions(-)
>
>
I think the commit logs for these patches
need a little detail on why the code is
no longer needed. For posterity.
^ permalink raw reply
* [PATCH -next] [media] c8sectpfe: fix error return code in c8sectpfe_probe()
From: Patrice Chotard @ 2016-11-02 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477792390-24533-1-git-send-email-weiyj.lk@gmail.com>
On 10/30/2016 02:53 AM, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return error code -ENODEV from the error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> index 42b123f..69d9a16 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> @@ -813,6 +813,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
> i2c_bus = of_parse_phandle(child, "i2c-bus", 0);
> if (!i2c_bus) {
> dev_err(&pdev->dev, "No i2c-bus found\n");
> + ret = -ENODEV;
> goto err_clk_disable;
> }
> tsin->i2c_adapter =
> @@ -820,6 +821,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
> if (!tsin->i2c_adapter) {
> dev_err(&pdev->dev, "No i2c adapter found\n");
> of_node_put(i2c_bus);
> + ret = -ENODEV;
> goto err_clk_disable;
> }
> of_node_put(i2c_bus);
>
Hi Wei
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Thanks
^ permalink raw reply
* [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
From: Arnd Bergmann @ 2016-11-02 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478073426-3714-2-git-send-email-clg@kaod.org>
On Wednesday 02 November 2016, C?dric Le Goater wrote:
> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
> other is H8S/2168 compliant.
>
> The current ipmi/bt-bmc driver implements the IPMI version and we
> should reflect its nature in the compatible node name using
> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
> latter should be used for a H8S interface driver if it is implemented
> one day.
>
> Signed-off-by: C?dric Le Goater <clg@kaod.org>
We generally try to avoid changing the compatible strings after the
fact, but it's probably ok in this case.
I don't understand who decides which of the two interfaces is used:
is it the same register set that can be driven by either one or the
other driver, or do you expect to have two drivers that can both
be active in the same system and talk to different hardware once
you get there?
If the first one of these is true, it seems a little awkward to
use the DT compatible string to decide which driver to use rather
than making the decision in the OS.
Arnd
^ permalink raw reply
* [PATCH 3/5] ARM: multi_v7_defconfig: Remove CONFIG_ST_THERMAL_MEMMAP Kconfig symbol
From: Patrice Chotard @ 2016-11-02 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024101408.GA10440@griffinp-ThinkPad-X1-Carbon-2nd>
On 10/24/2016 12:14 PM, Peter Griffin wrote:
> Hi Patrice,
>
> On Fri, 21 Oct 2016, patrice.chotard at st.com wrote:
>
>> From: Patrice Chotard <patrice.chotard@st.com>
>>
>> Driver code has been already removed, see
>> http://www.spinics.net/lists/devicetree/msg143322.html
>> Remove the multi_v7_defconfig part
>>
>> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
>> Cc: <rui.zhang@intel.com>
>> Cc: <edubezval@gmail.com>
>> ---
>> arch/arm/configs/multi_v7_defconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index 15b2f99..45e252b 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -450,7 +450,6 @@ CONFIG_RCAR_THERMAL=y
>> CONFIG_ARMADA_THERMAL=y
>> CONFIG_DAVINCI_WATCHDOG=m
>> CONFIG_EXYNOS_THERMAL=m
>> -CONFIG_ST_THERMAL_MEMMAP=y
>
Hi Peter
> Are you sure you want to remove this?
Well spotted, you are right. It must be kept.
Thanks
>
> This Kconfig symbol is still used for the stih407 family
> thermal parts in drivers/thermal/st/st_thermal_memmap.c?
>
> My patch only removed the stih415/6 parts from the driver.
>
> regards,
>
> Peter.
>
^ permalink raw reply
* flush_dcache_page() in ARM vs ARM64
From: Rabin Vincent @ 2016-11-02 13:27 UTC (permalink / raw)
To: linux-arm-kernel
ARMv7-A and ARMv8-A are, as far as I can see, identical in which cache
behaviours they support. The data cache has to behave as PIPT while for
the instruction cache, PIPT, VIPT, and ASIC-tagged VIVT behaviours are
supported. See section B3.11 of the ARMv7-A ARM and section D4.9 of the
ARMv8-A ARM.
Both ARMv7-A with Multiprocessing Extensions and ARMv8-A broadcast cache
maintenance operations to other cores. See B2.2.5 of the ARMv7-A ARM
and D7.2.57 of the ARMv8-A ARM.
Both arch/arm/ (for ARMv6+) and arch/arm64/ define PG_arch_1 to be
PG_dcache_clean and use it to postpone flushing from flush_dcache_page()
to set_pte_at(). See arch/{arm,arm64}/mm/flush.c.
However, arch/arm64/'s flush_dcache_page() is implemented like this:
void flush_dcache_page(struct page *page)
{
if (test_bit(PG_dcache_clean, &page->flags))
clear_bit(PG_dcache_clean, &page->flags);
}
while arch/arm/ has this:
void flush_dcache_page(struct page *page)
{
struct address_space *mapping;
/*
* The zero page is never written to, so never has any dirty
* cache lines, and therefore never needs to be flushed.
*/
if (page == ZERO_PAGE(0))
return;
mapping = page_mapping(page);
if (!cache_ops_need_broadcast() &&
mapping && !page_mapcount(page))
clear_bit(PG_dcache_clean, &page->flags);
else {
__flush_dcache_page(mapping, page);
if (mapping && cache_is_vivt())
__flush_dcache_aliases(mapping, page);
else if (mapping)
__flush_icache_all();
set_bit(PG_dcache_clean, &page->flags);
}
}
Why does arch/arm/ flush the data cache area in flush_dcache_page() for
the (!mapping || page_mapcount(page)) case even on ARMv7+ME, while
arch/arm64/ doesn't for ARMv8?
Why does arch/arm/ invalidate the instruction cache in
flush_dcache_page() for the (mapping && page_count(page)) case even for
ARMv7+ME, while arch/arm64/ doesn't for ARMv8?
What would break with the following patch?
diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
index 3cced84..f1e6190 100644
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -327,6 +327,12 @@ void flush_dcache_page(struct page *page)
if (page == ZERO_PAGE(0))
return;
+ if (!cache_ops_need_broadcast() && cache_is_vipt_nonaliasing()) {
+ if (test_bit(PG_dcache_clean, &page->flags))
+ clear_bit(PG_dcache_clean, &page->flags);
+ return;
+ }
+
mapping = page_mapping(page);
if (!cache_ops_need_broadcast() &&
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: sun9i: Enable SDIO-based WiFi
From: Maxime Ripard @ 2016-11-02 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028101154.7350-1-wens@csie.org>
On Fri, Oct 28, 2016 at 06:11:51PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> Now that we have support for both PMICs, we can turn on the
> regulators needed for the onboard WiFi chips.
>
> This is a fairly simple series. The WiFi chips themselves are
> supported by the brcmfmac driver, but the user needs to get an
> nvram.txt file and put it in their firmware directory, in
> addition to the firmware file in linux-firmware. Otherwise we
> just need to enable the mmc controller and supply the vmmc and
> vqmmc regulators.
Applied all three, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/f6a550a6/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: sun8i: Support NanoPi SBCs
From: Maxime Ripard @ 2016-11-02 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028065903.23298-1-woogyom.kim@gmail.com>
On Fri, Oct 28, 2016 at 03:59:00PM +0900, Milo Kim wrote:
> NanoPi M1 and NEO have common features, so duplicate properties can be
> moved into new dtsi file.
Applied all three, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/930c8c1d/attachment.sig>
^ permalink raw reply
* [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
From: Nipun Gupta @ 2016-11-02 13:35 UTC (permalink / raw)
To: linux-arm-kernel
The SMTNMB_TLBEN in the Auxiliary Configuration Register (ACR) provides an
option to enable the updation of TLB in case of bypass transactions due to
no stream match in the stream match table. This reduces the latencies of
the subsequent transactions with the same stream-id which bypasses the SMMU.
This provides a significant performance benefit for certain networking
workloads.
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
drivers/iommu/arm-smmu.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ce2a9d4..7010a5c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -246,6 +246,7 @@ enum arm_smmu_s2cr_privcfg {
#define ARM_MMU500_ACTLR_CPRE (1 << 1)
+#define ACR_SMTNMB_TLBEN (1 << 8)
#define ARM_MMU500_ACR_CACHE_LOCK (1 << 26)
#define CB_PAR_F (1 << 0)
@@ -1569,18 +1570,26 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
for (i = 0; i < smmu->num_mapping_groups; ++i)
arm_smmu_write_sme(smmu, i);
+ /* Get the major rev required for configuring ACR */
+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
+ major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
+
/*
* Before clearing ARM_MMU500_ACTLR_CPRE, need to
* clear CACHE_LOCK bit of ACR first. And, CACHE_LOCK
* bit is only present in MMU-500r2 onwards.
*/
- reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID7);
- major = (reg >> ID7_MAJOR_SHIFT) & ID7_MAJOR_MASK;
- if ((smmu->model == ARM_MMU500) && (major >= 2)) {
- reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
+ reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sACR);
+ if ((smmu->model == ARM_MMU500) && (major >= 2))
reg &= ~ARM_MMU500_ACR_CACHE_LOCK;
- writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
- }
+
+ /*
+ * Set the SMTNMB_TLBEN in ACR so that the transactions which
+ * bypass with SMMU due to no stream match found in the SMR table
+ * are updated in the TLB's.
+ */
+ reg |= ACR_SMTNMB_TLBEN;
+ writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sACR);
/* Make sure all context banks are disabled and clear CB_FSR */
for (i = 0; i < smmu->num_context_banks; ++i) {
--
1.9.1
^ permalink raw reply related
* Tegra baseline test results for v4.9-rc1
From: Jon Hunter @ 2016-11-02 13:39 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.9-rc1.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9-rc1/20161102045959/
Test summary
------------
Build: zImage:
FAIL: ( 1/ 2): multi_v7_defconfig
Pass: ( 1/ 2): tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
FAIL: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.8 (c8d2bc9bc39ebea8437fd974fdbc21847bb897a3)):
text data bss total kernel
-3007747 +3664344 +7816 +664413 defconfig
+69649 +14344 +3952 +87945 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.8 (c8d2bc9bc39ebea8437fd974fdbc21847bb897a3))
avail rsrvd high freed board kconfig dtb
-640k 640k . 64k qemu-vexpress64 defconfig __internal
-4k 4k . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
-4k 4k . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
-96k 96k . . tegra132-norrin defconfig tegra132-norrin
-4k 4k . . tegra20-trimslice tegra_defconfig tegra20-trimslice
-660k 660k . 64k tegra210-p2371-0000 defconfig tegra210-p2371-0000
-664k 664k . 64k tegra210-smaug defconfig tegra210-smaug
-4k 4k . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* [PATCH v2 4/4] spi: sun6i: Support Allwinner H3 SPI controller
From: Maxime Ripard @ 2016-11-02 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028065412.23008-5-woogyom.kim@gmail.com>
On Fri, Oct 28, 2016 at 03:54:12PM +0900, Milo Kim wrote:
> H3 has two SPI controllers. The size of the buffer is 64 * 8.
> (8 bit transfer by 64 entry FIFO)
> A31 has four controllers. The size of the buffer is 128 * 8.
> (8 bit transfer by 128 entry FIFO)
>
> Register maps are sharable, so sun6i SPI driver is reusable with
> device configuration.
>
> Use the variable, 'fifo_depth' instead of fixed value to support both SPI
> controllers.
>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/304caca0/attachment.sig>
^ permalink raw reply
* [PATCH] pinctrl: sunxi: make bool drivers explicitly non-modular
From: Maxime Ripard @ 2016-11-02 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030000030.9394-1-paul.gortmaker@windriver.com>
On Sat, Oct 29, 2016 at 08:00:30PM -0400, Paul Gortmaker wrote:
> None of the Kconfigs for any of these drivers are tristate,
> meaning that they currently are not being built as a module by anyone.
>
> Lets remove the modular code that is essentially orphaned, so that
> when reading the drivers there is no doubt they are builtin-only. All
> drivers get essentially the same change, so they are handled in batch.
>
> Changes are (1) use builtin_platform_driver, (2) use init.h header
> (3) delete module_exit related code, (4) delete MODULE_DEVICE_TABLE,
> and (5) delete MODULE_LICENCE/MODULE_AUTHOR and associated tags.
>
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We do delete the MODULE_LICENSE etc. tags since all that information
> is already contained at the top of each file in the comments.
>
> Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> Cc: Hongzhou Yang <hongzhou.yang@mediatek.com>
> Cc: Fabian Frederick <fabf@skynet.be>
> Cc: Maxime Coquelin <maxime.coquelin@st.com>
> Cc: Vishnu Patekar <vishnupatekar0510@gmail.com>
> Cc: Mylene Josserand <mylene.josserand@free-electrons.com>
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161102/127fd0ba/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/2] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-11-02 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9VyAaqUy06kb_Mxewo+BbJnxe=e6=x8pFsVSY0Z6C-h=cg@mail.gmail.com>
On 10/31/2016 12:12 PM, Joachim Eastwood wrote:
> Hi Neil,
>
> On 31 October 2016 at 11:54, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>
>> Acked-by: Joachim Eastwood <manabian@gmail.com>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> +static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
>> +{
>> + unsigned int value;
>> + int ret;
>> +
>> + /* Reset HW here before changing the glue configuration */
>> + ret = device_reset(dwmac->dev);
>> + if (ret)
>> + return ret;
>> +
>> + ret = clk_prepare_enable(dwmac->clk);
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_read(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, &value);
>> + if (ret < 0)
>> + return ret;
>
> If regmap reading fails here, the clock will be left on as probe fails.
>
Indeed, thanks.
Neil
[...]
>
>
> regards,
> Joachim Eastwood
>
^ permalink raw reply
* Tegra baseline test results for v4.9-rc1
From: Jon Hunter @ 2016-11-02 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff60cb86-a8e3-dc25-ac86-b6e3ccf7ea17@nvidia.com>
On 02/11/16 13:39, Jon Hunter wrote:
> Here are some basic Tegra test results for Linux v4.9-rc1.
> Logs and other details at:
>
> https://nvtb.github.io//linux/test_v4.9-rc1/20161102045959/
>
>
> Test summary
> ------------
>
> Build: zImage:
> FAIL: ( 1/ 2): multi_v7_defconfig
This issue was exposed by commit 3f0958d8aea7 ("ARM: multi_v7_defconfig:
enable CONFIG_EFI") because our builder is using an older version on
bin-utils. This has been fixed by commit b0dddf6c147e ("efi/arm: Fix
absolute relocation detection for older toolchains").
> Pass: ( 1/ 2): tegra_defconfig
>
> Build: Image:
> Pass: ( 1/ 1): defconfig
>
> Boot to userspace: defconfig:
> Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
> tegra210-p2371-0000, tegra210-smaug
>
> Boot to userspace: tegra_defconfig:
> Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
>
> PM: System suspend: tegra_defconfig:
> FAIL: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
These failures are not true/hard failures as suspend is still working.
Commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") exposed a issue with one of the messages seen in
suspend (which we look for when testing suspend) and caused the suspend
test to report a failure. This has been fixed by commit 1adb469b9b76
("PM / suspend: Fix missing KERN_CONT for suspend message").
Jon
--
nvpublic
^ permalink raw reply
* Tegra baseline test results for v4.9-rc2
From: Jon Hunter @ 2016-11-02 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.9-rc2.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9-rc2/20161102051347/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
FAIL: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
FAIL: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.9-rc1 (1001354ca34179f3db924eb66672442a173147dc)):
text data bss total kernel
+1 +24 0 +25 defconfig
-55 +64 0 +9 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.9-rc1 (1001354ca34179f3db924eb66672442a173147dc))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
From: Joel Stanley @ 2016-11-02 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201611021415.51081.arnd@arndb.de>
On Wed, Nov 2, 2016 at 11:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 02 November 2016, C?dric Le Goater wrote:
>> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
>> other is H8S/2168 compliant.
>>
>> The current ipmi/bt-bmc driver implements the IPMI version and we
>> should reflect its nature in the compatible node name using
>> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
>> latter should be used for a H8S interface driver if it is implemented
>> one day.
>>
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>
> We generally try to avoid changing the compatible strings after the
> fact, but it's probably ok in this case.
>
> I don't understand who decides which of the two interfaces is used:
> is it the same register set that can be driven by either one or the
> other driver, or do you expect to have two drivers that can both
> be active in the same system and talk to different hardware once
> you get there?
It's the second case. The H8S BT has a different register layout so it
would require a different driver.
We don't yet have a driver for the other BT device, but there was
recent talk of using it as an alternate (non-ipmi channel) between the
BMC and the host. Before that discussion I wasn't aware that the H8S
BT existed. I suggested we fix this up before it hits a final release.
C?dric, do you think ast2400-ibt-bmc or ast2400-ipmi-bt-bmc does a
better job of describing the hardware here?
While we're modifying the binding, should we add a compat string for
the ast2500?
Cheers,
Joel
>
> If the first one of these is true, it seems a little awkward to
> use the DT compatible string to decide which driver to use rather
> than making the decision in the OS.
>
> Arnd
^ permalink raw reply
* [PATCH v3 0/2] net: stmmac: Add OXNAS DWMAC Glue
From: Neil Armstrong @ 2016-11-02 14:02 UTC (permalink / raw)
To: linux-arm-kernel
This patchset add support for the Sysnopsys DWMAC Gigabit Ethernet
controller Glue layer of the Oxford Semiconductor OX820 SoC.
Changes since v2 at http://lkml.kernel.org/r/20161031105345.16711-1-narmstrong at baylibre.com :
- Disable/Unprepare clock if regmap read fails in oxnas_dwmac_init
Changes since v1 at https://patchwork.kernel.org/patch/9388231/ :
- Split dt-bindings in a separate patch
- Add IP version in the dt-bindings compatible
- Check return of clk_prepare_enable()
- use get_stmmac_bsp_priv() helper
- hardwire setup values in oxnas_dwmac_init()
Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
- Drop init/exit callbacks
- Implement proper remove and PM callback
- Call init from probe
- Disable/Unprepare clock if stmmac probe fails
Neil Armstrong (2):
net: stmmac: Add OXNAS Glue Driver
dt-bindings: net: Add OXNAS DWMAC Bindings
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 217 +++++++++++++++++++++
4 files changed, 268 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
--
2.7.0
^ permalink raw reply
* [PATCH v3 1/2] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-11-02 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102140237.6955-1-narmstrong@baylibre.com>
Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
Acked-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 217 ++++++++++++++++++++++
3 files changed, 229 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 3818c5e..6e9fcc3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -69,6 +69,17 @@ config DWMAC_MESON
the stmmac device driver. This driver is used for Meson6,
Meson8, Meson8b and GXBB SoCs.
+config DWMAC_OXNAS
+ tristate "Oxford Semiconductor OXNAS dwmac support"
+ default ARCH_OXNAS
+ depends on OF && COMMON_CLK && (ARCH_OXNAS || COMPILE_TEST)
+ select MFD_SYSCON
+ help
+ Support for Ethernet controller on Oxford Semiconductor OXNAS SoCs.
+
+ This selects the Oxford Semiconductor OXNASSoC glue layer support for
+ the stmmac device driver. This driver is used for OX820.
+
config DWMAC_ROCKCHIP
tristate "Rockchip dwmac support"
default ARCH_ROCKCHIP
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 5d6ece5..8f83a86 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
obj-$(CONFIG_DWMAC_IPQ806X) += dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX) += dwmac-lpc18xx.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
+obj-$(CONFIG_DWMAC_OXNAS) += dwmac-oxnas.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
new file mode 100644
index 0000000..c355975
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
@@ -0,0 +1,217 @@
+/*
+ * Oxford Semiconductor OXNAS DWMAC glue layer
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (C) 2014 Daniel Golle <daniel@makrotopia.org>
+ * Copyright (C) 2013 Ma Haijun <mahaijuns@gmail.com>
+ * Copyright (C) 2012 John Crispin <blogic@openwrt.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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/stmmac.h>
+
+#include "stmmac_platform.h"
+
+/* System Control regmap offsets */
+#define OXNAS_DWMAC_CTRL_REGOFFSET 0x78
+#define OXNAS_DWMAC_DELAY_REGOFFSET 0x100
+
+/* Control Register */
+#define DWMAC_CKEN_RX_IN 14
+#define DWMAC_CKEN_RXN_OUT 13
+#define DWMAC_CKEN_RX_OUT 12
+#define DWMAC_CKEN_TX_IN 10
+#define DWMAC_CKEN_TXN_OUT 9
+#define DWMAC_CKEN_TX_OUT 8
+#define DWMAC_RX_SOURCE 7
+#define DWMAC_TX_SOURCE 6
+#define DWMAC_LOW_TX_SOURCE 4
+#define DWMAC_AUTO_TX_SOURCE 3
+#define DWMAC_RGMII 2
+#define DWMAC_SIMPLE_MUX 1
+#define DWMAC_CKEN_GTX 0
+
+/* Delay register */
+#define DWMAC_TX_VARDELAY_SHIFT 0
+#define DWMAC_TXN_VARDELAY_SHIFT 8
+#define DWMAC_RX_VARDELAY_SHIFT 16
+#define DWMAC_RXN_VARDELAY_SHIFT 24
+#define DWMAC_TX_VARDELAY(d) ((d) << DWMAC_TX_VARDELAY_SHIFT)
+#define DWMAC_TXN_VARDELAY(d) ((d) << DWMAC_TXN_VARDELAY_SHIFT)
+#define DWMAC_RX_VARDELAY(d) ((d) << DWMAC_RX_VARDELAY_SHIFT)
+#define DWMAC_RXN_VARDELAY(d) ((d) << DWMAC_RXN_VARDELAY_SHIFT)
+
+struct oxnas_dwmac {
+ struct device *dev;
+ struct clk *clk;
+ struct regmap *regmap;
+};
+
+static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
+{
+ unsigned int value;
+ int ret;
+
+ /* Reset HW here before changing the glue configuration */
+ ret = device_reset(dwmac->dev);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(dwmac->clk);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, &value);
+ if (ret < 0) {
+ clk_disable_unprepare(dwmac->clk);
+ return ret;
+ }
+
+ /* Enable GMII_GTXCLK to follow GMII_REFCLK, required for gigabit PHY */
+ value |= BIT(DWMAC_CKEN_GTX) |
+ /* Use simple mux for 25/125 Mhz clock switching */
+ BIT(DWMAC_SIMPLE_MUX) |
+ /* set auto switch tx clock source */
+ BIT(DWMAC_AUTO_TX_SOURCE) |
+ /* enable tx & rx vardelay */
+ BIT(DWMAC_CKEN_TX_OUT) |
+ BIT(DWMAC_CKEN_TXN_OUT) |
+ BIT(DWMAC_CKEN_TX_IN) |
+ BIT(DWMAC_CKEN_RX_OUT) |
+ BIT(DWMAC_CKEN_RXN_OUT) |
+ BIT(DWMAC_CKEN_RX_IN);
+ regmap_write(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, value);
+
+ /* set tx & rx vardelay */
+ value = DWMAC_TX_VARDELAY(4) |
+ DWMAC_TXN_VARDELAY(2) |
+ DWMAC_RX_VARDELAY(10) |
+ DWMAC_RXN_VARDELAY(8);
+ regmap_write(dwmac->regmap, OXNAS_DWMAC_DELAY_REGOFFSET, value);
+
+ return 0;
+}
+
+static int oxnas_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct device_node *sysctrl;
+ struct oxnas_dwmac *dwmac;
+ int ret;
+
+ sysctrl = of_parse_phandle(pdev->dev.of_node, "oxsemi,sys-ctrl", 0);
+ if (!sysctrl) {
+ dev_err(&pdev->dev, "failed to get sys-ctrl node\n");
+ return -EINVAL;
+ }
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return -ENOMEM;
+
+ dwmac->dev = &pdev->dev;
+ plat_dat->bsp_priv = dwmac;
+
+ dwmac->regmap = syscon_node_to_regmap(sysctrl);
+ if (IS_ERR(dwmac->regmap)) {
+ dev_err(&pdev->dev, "failed to have sysctrl regmap\n");
+ return PTR_ERR(dwmac->regmap);
+ }
+
+ dwmac->clk = devm_clk_get(&pdev->dev, "gmac");
+ if (IS_ERR(dwmac->clk))
+ return PTR_ERR(dwmac->clk);
+
+ ret = oxnas_dwmac_init(dwmac);
+ if (ret)
+ return ret;
+
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (ret)
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+static int oxnas_dwmac_remove(struct platform_device *pdev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(&pdev->dev);
+ int ret = stmmac_dvr_remove(&pdev->dev);
+
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int oxnas_dwmac_suspend(struct device *dev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
+ int ret;
+
+ ret = stmmac_suspend(dev);
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+static int oxnas_dwmac_resume(struct device *dev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
+ int ret;
+
+ ret = oxnas_dwmac_init(dwmac);
+ if (ret)
+ return ret;
+
+ ret = stmmac_resume(dev);
+
+ return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static SIMPLE_DEV_PM_OPS(oxnas_dwmac_pm_ops,
+ oxnas_dwmac_suspend, oxnas_dwmac_resume);
+
+static const struct of_device_id oxnas_dwmac_match[] = {
+ { .compatible = "oxsemi,ox820-dwmac" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, oxnas_dwmac_match);
+
+static struct platform_driver oxnas_dwmac_driver = {
+ .probe = oxnas_dwmac_probe,
+ .remove = oxnas_dwmac_remove,
+ .driver = {
+ .name = "oxnas-dwmac",
+ .pm = &oxnas_dwmac_pm_ops,
+ .of_match_table = oxnas_dwmac_match,
+ },
+};
+module_platform_driver(oxnas_dwmac_driver);
+
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_DESCRIPTION("Oxford Semiconductor OXNAS DWMAC glue layer");
+MODULE_LICENSE("GPL v2");
--
2.7.0
^ permalink raw reply related
* [PATCH v3 2/2] dt-bindings: net: Add OXNAS DWMAC Bindings
From: Neil Armstrong @ 2016-11-02 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102140237.6955-1-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
new file mode 100644
index 0000000..df0534e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
@@ -0,0 +1,39 @@
+* Oxford Semiconductor OXNAS DWMAC Ethernet controller
+
+The device inherits all the properties of the dwmac/stmmac devices
+described in the file stmmac.txt in the current directory with the
+following changes.
+
+Required properties on all platforms:
+
+- compatible: For the OX820 SoC, it should be :
+ - "oxsemi,ox820-dwmac" to select glue
+ - "snps,dwmac-3.512" to select IP version.
+
+- clocks: Should contain phandles to the following clocks
+- clock-names: Should contain the following:
+ - "stmmaceth" for the host clock - see stmmac.txt
+ - "gmac" for the peripheral gate clock
+
+- oxsemi,sys-ctrl: a phandle to the system controller syscon node
+
+Example :
+
+etha: ethernet at 40400000 {
+ compatible = "oxsemi,ox820-dwmac", "snps,dwmac-3.512";
+ reg = <0x40400000 0x2000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+
+ clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
+ clock-names = "gmac", "stmmaceth";
+ resets = <&reset RESET_MAC>;
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ status = "disabled";
+};
--
2.7.0
^ permalink raw reply related
* Tegra baseline test results for v4.9-rc3
From: Jon Hunter @ 2016-11-02 14:03 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.9-rc3.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9-rc3/20161102060102/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.9-rc2 (07d9a380680d1c0eb51ef87ff2eab5c994949e69)):
text data bss total kernel
-429 +6528 0 +6099 defconfig
+121935 +25312 +64 +147311 multi_v7_defconfig
-185 +3200 0 +3015 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.9-rc2 (07d9a380680d1c0eb51ef87ff2eab5c994949e69))
avail rsrvd high freed board kconfig dtb
20k -20k . . qemu-vexpress64 defconfig __internal
32k -32k . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
36k -36k . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
32k -32k . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
36k -36k . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
32k -32k . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
36k -36k . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
12k -12k . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
16k -16k . . tegra20-trimslice tegra_defconfig tegra20-trimslice
68k -68k . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
64k -64k . . tegra210-smaug defconfig tegra210-smaug
32k -32k . . tegra30-beaver multi_v7_defconfig tegra30-beaver
36k -36k . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: oxnas: Update support for OX820 and use dt-bindings
From: Neil Armstrong @ 2016-11-02 14:18 UTC (permalink / raw)
To: linux-arm-kernel
This patchset updates the ARM DTS for the Oxnas platform by :
- Add support for the Oxford Semicondutor OX820 and the PogoPlug V3
- Fix the MAINTAINERS entry and add the PogoPlug V3 file maintainance
Changes since v1 at http://lkml.kernel.org/r/20161021151037.20112-1-narmstrong at baylibre.com :
- Due to a dt-bindings include dependency from clk and reset, the includes
are removed for the next release, and will be re-introduced after next
merge window.
Neil Armstrong (2):
ARM: dts: Add support for OX820 and Pogoplug V3
MAINTAINERS: oxnas: Add new files definitions
Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
MAINTAINERS | 3 +-
arch/arm/boot/dts/Makefile | 3 +-
.../boot/dts/cloudengines-pogoplug-series-3.dts | 94 +++++++
arch/arm/boot/dts/ox820.dtsi | 296 +++++++++++++++++++++
5 files changed, 399 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
create mode 100644 arch/arm/boot/dts/ox820.dtsi
--
2.7.0
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: Add support for OX820 and Pogoplug V3
From: Neil Armstrong @ 2016-11-02 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102141850.25164-1-narmstrong@baylibre.com>
Add device tree for the Oxford Seminconductor OX820 SoC and the
Cloud Engines PogoPlug v3 board.
Add the SoC and board compatible strings to oxnas bindings.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
arch/arm/boot/dts/Makefile | 3 +-
.../boot/dts/cloudengines-pogoplug-series-3.dts | 94 +++++++
arch/arm/boot/dts/ox820.dtsi | 296 +++++++++++++++++++++
4 files changed, 397 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
create mode 100644 arch/arm/boot/dts/ox820.dtsi
diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt
index b9e4971..ac64e60 100644
--- a/Documentation/devicetree/bindings/arm/oxnas.txt
+++ b/Documentation/devicetree/bindings/arm/oxnas.txt
@@ -5,5 +5,10 @@ Boards with the OX810SE SoC shall have the following properties:
Required root node property:
compatible: "oxsemi,ox810se"
+Boards with the OX820 SoC shall have the following properties:
+ Required root node property:
+ compatible: "oxsemi,ox820"
+
Board compatible values:
- "wd,mbwe" (OX810SE)
+ - "cloudengines,pogoplugv3" (OX820)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..3b0c74f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -604,7 +604,8 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
dtb-$(CONFIG_ARCH_OXNAS) += \
- wd-mbwe.dtb
+ wd-mbwe.dtb \
+ cloudengines-pogoplug-series-3.dtb
dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8060-dragonboard.dtb \
qcom-apq8064-arrow-sd-600eval.dtb \
diff --git a/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
new file mode 100644
index 0000000..bfde32e
--- /dev/null
+++ b/arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
@@ -0,0 +1,94 @@
+/*
+ * cloudengines-pogoplug-series-3.dtsi - Device tree file for Cloud Engines PogoPlug Series 3
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+#include "ox820.dtsi"
+
+/ {
+ model = "Cloud Engines PogoPlug Series 3";
+
+ compatible = "cloudengines,pogoplugv3", "oxsemi,ox820";
+
+ chosen {
+ bootargs = "earlyprintk";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ /* 128Mbytes DDR */
+ reg = <0x60000000 0x8000000>;
+ };
+
+ aliases {
+ serial0 = &uart0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ blue {
+ label = "pogoplug:blue";
+ gpios = <&gpio0 2 0>;
+ default-state = "keep";
+ };
+
+ orange {
+ label = "pogoplug:orange";
+ gpios = <&gpio1 16 1>;
+ default-state = "keep";
+ };
+
+ green {
+ label = "pogoplug:green";
+ gpios = <&gpio1 17 1>;
+ default-state = "keep";
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+};
+
+&nandc {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nand>;
+
+ nand at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "hamming";
+
+ partition at 0 {
+ label = "boot";
+ reg = <0x00000000 0x00e00000>;
+ read-only;
+ };
+
+ partition at e00000 {
+ label = "ubi";
+ reg = <0x00e00000 0x07200000>;
+ };
+ };
+};
+
+ða {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_etha_mdio>;
+};
diff --git a/arch/arm/boot/dts/ox820.dtsi b/arch/arm/boot/dts/ox820.dtsi
new file mode 100644
index 0000000..e40f282
--- /dev/null
+++ b/arch/arm/boot/dts/ox820.dtsi
@@ -0,0 +1,296 @@
+/*
+ * ox820.dtsi - Device tree file for Oxford Semiconductor OX820 SoC
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "oxsemi,ox820";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "oxsemi,ox820-smp";
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,arm11mpcore";
+ clocks = <&armclk>;
+ reg = <0>;
+ };
+
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,arm11mpcore";
+ clocks = <&armclk>;
+ reg = <1>;
+ };
+ };
+
+ memory {
+ /* Max 512MB @ 0x60000000 */
+ reg = <0x60000000 0x20000000>;
+ };
+
+ clocks {
+ osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ gmacclk: gmacclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ };
+
+ sysclk: sysclk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <4>;
+ clock-mult = <1>;
+ clocks = <&osc>;
+ };
+
+ plla: plla {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <850000000>;
+ };
+
+ armclk: armclk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ clocks = <&plla>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <&gic>;
+
+ nandc: nand-controller at 41000000 {
+ compatible = "oxsemi,ox820-nand";
+ reg = <0x41000000 0x100000>;
+ clocks = <&stdclk 11>;
+ resets = <&reset 15>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ etha: ethernet at 40400000 {
+ compatible = "oxsemi,ox820-dwmac", "snps,dwmac";
+ reg = <0x40400000 0x2000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+
+ clocks = <&stdclk 9>, <&gmacclk>;
+ clock-names = "gmac", "stmmaceth";
+ resets = <&reset 6>;
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ status = "disabled";
+ };
+
+ apb-bridge at 44000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x44000000 0x1000000>;
+
+ pinctrl: pinctrl {
+ compatible = "oxsemi,ox820-pinctrl";
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ pinctrl_uart0: uart0 {
+ uart0 {
+ pins = "gpio30", "gpio31";
+ function = "fct5";
+ };
+ };
+
+ pinctrl_uart0_modem: uart0_modem {
+ uart0_modem_a {
+ pins = "gpio24", "gpio24", "gpio26", "gpio27";
+ function = "fct4";
+ };
+ uart0_modem_b {
+ pins = "gpio28", "gpio29";
+ function = "fct5";
+ };
+ };
+
+ pinctrl_uart1: uart1 {
+ uart1 {
+ pins = "gpio7", "gpio8";
+ function = "fct4";
+ };
+ };
+
+ pinctrl_uart1_modem: uart1_modem {
+ uart1_modem {
+ pins = "gpio5", "gpio6", "gpio40", "gpio41", "gpio42", "gpio43";
+ function = "fct4";
+ };
+ };
+
+ pinctrl_etha_mdio: etha_mdio {
+ etha_mdio {
+ pins = "gpio3", "gpio4";
+ function = "fct1";
+ };
+ };
+
+ pinctrl_nand: nand {
+ nand {
+ pins = "gpio12", "gpio13", "gpio14", "gpio15",
+ "gpio16", "gpio17", "gpio18", "gpio19",
+ "gpio20", "gpio21", "gpio22", "gpio23",
+ "gpio24";
+ function = "fct1";
+ };
+ };
+ };
+
+ gpio0: gpio at 000000 {
+ compatible = "oxsemi,ox820-gpio";
+ reg = <0x000000 0x100000>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ngpios = <32>;
+ oxsemi,gpio-bank = <0>;
+ gpio-ranges = <&pinctrl 0 0 32>;
+ };
+
+ gpio1: gpio at 100000 {
+ compatible = "oxsemi,ox820-gpio";
+ reg = <0x100000 0x100000>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ ngpios = <18>;
+ oxsemi,gpio-bank = <1>;
+ gpio-ranges = <&pinctrl 0 32 18>;
+ };
+
+ uart0: serial at 200000 {
+ compatible = "ns16550a";
+ reg = <0x200000 0x100000>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ fifo-size = <16>;
+ reg-io-width = <1>;
+ current-speed = <115200>;
+ no-loopback-test;
+ status = "disabled";
+ clocks = <&sysclk>;
+ resets = <&reset 17>;
+ };
+
+ uart1: serial at 300000 {
+ compatible = "ns16550a";
+ reg = <0x200000 0x100000>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <0>;
+ fifo-size = <16>;
+ reg-io-width = <1>;
+ current-speed = <115200>;
+ no-loopback-test;
+ status = "disabled";
+ clocks = <&sysclk>;
+ resets = <&reset 18>;
+ };
+
+ rps at 400000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x400000 0x100000>;
+
+ intc: interrupt-controller at 0 {
+ compatible = "oxsemi,ox820-rps-irq", "oxsemi,ox810se-rps-irq";
+ interrupt-controller;
+ reg = <0 0x200>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ valid-mask = <0xFFFFFFFF>;
+ clear-mask = <0>;
+ };
+
+ timer0: timer at 200 {
+ compatible = "oxsemi,ox820-rps-timer";
+ reg = <0x200 0x40>;
+ clocks = <&sysclk>;
+ interrupt-parent = <&intc>;
+ interrupts = <4>;
+ };
+ };
+
+ sys: sys-ctrl at e00000 {
+ compatible = "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd";
+ reg = <0xe00000 0x200000>;
+
+ reset: reset-controller {
+ compatible = "oxsemi,ox820-reset", "oxsemi,ox810se-reset";
+ #reset-cells = <1>;
+ };
+
+ stdclk: stdclk {
+ compatible = "oxsemi,ox820-stdclk", "oxsemi,ox810se-stdclk";
+ #clock-cells = <1>;
+ };
+ };
+ };
+
+ apb-bridge at 47000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x47000000 0x1000000>;
+
+ scu: scu at 0 {
+ compatible = "arm,arm11mp-scu";
+ reg = <0x0 0x100>;
+ };
+
+ local-timer at 600 {
+ compatible = "arm,arm11mp-twd-timer";
+ reg = <0x600 0x20>;
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(3)|IRQ_TYPE_LEVEL_HIGH)>;
+ clocks = <&armclk>;
+ };
+
+ gic: gic at 1000 {
+ compatible = "arm,arm11mp-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x1000 0x1000>,
+ <0x100 0x500>;
+ };
+ };
+ };
+};
--
2.7.0
^ permalink raw reply related
* [PATCH v2 2/2] MAINTAINERS: oxnas: Add new files definitions
From: Neil Armstrong @ 2016-11-02 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161102141850.25164-1-narmstrong@baylibre.com>
Fix the dts files maintained by the OXNAS platform, add a new board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..29d8853 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1478,8 +1478,9 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
L: linux-oxnas at lists.tuxfamily.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
-F: arch/arm/boot/dts/oxnas*
+F: arch/arm/boot/dts/ox8*.dtsi
F: arch/arm/boot/dts/wd-mbwe.dts
+F: arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
N: oxnas
ARM/Mediatek RTC DRIVER
--
2.7.0
^ permalink raw reply related
* [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed,ast2400-ibt-bmc'
From: Cédric Le Goater @ 2016-11-02 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XcM1_xmmUu-cCZrSR67Y_qeXuSJ4Xmd_2gcgDT321LdBQ@mail.gmail.com>
On 11/02/2016 02:56 PM, Joel Stanley wrote:
> On Wed, Nov 2, 2016 at 11:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday 02 November 2016, C?dric Le Goater wrote:
>>> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
>>> other is H8S/2168 compliant.
>>>
>>> The current ipmi/bt-bmc driver implements the IPMI version and we
>>> should reflect its nature in the compatible node name using
>>> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
>>> latter should be used for a H8S interface driver if it is implemented
>>> one day.
>>>
>>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>>
>> We generally try to avoid changing the compatible strings after the
>> fact, but it's probably ok in this case.
As the device tree changes are not merged yet, we thought we had some
more time to fine tune the naming.
>> I don't understand who decides which of the two interfaces is used:
>> is it the same register set that can be driven by either one or the
>> other driver, or do you expect to have two drivers that can both
>> be active in the same system and talk to different hardware once
>> you get there?
>
> It's the second case. The H8S BT has a different register layout so it
> would require a different driver.
yes.
> We don't yet have a driver for the other BT device, but there was
> recent talk of using it as an alternate (non-ipmi channel) between the
> BMC and the host. Before that discussion I wasn't aware that the H8S
> BT existed. I suggested we fix this up before it hits a final release.
>
> C?dric, do you think ast2400-ibt-bmc or ast2400-ipmi-bt-bmc does a
> better job of describing the hardware here?
The specs refer to the two interfaces as BT (non IPMI) and iBT (IPMI).
I think we can keep the same naming.
> While we're modifying the binding, should we add a compat string for
> the ast2500?
Well, if the change in this patch is fine for all, may be we can add
the ast2500 compat string in a followup patch ?
Thanks,
C.
> Cheers,
>
> Joel
>
>>
>> If the first one of these is true, it seems a little awkward to
>> use the DT compatible string to decide which driver to use rather
>> than making the decision in the OS.
>>
>> Arnd
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Alexandre Torgue @ 2016-11-02 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFvLkMTCkRcwbRc8GVNBoJFAvKWHYDjOPabueQPjTseZrucadA@mail.gmail.com>
Hi
On 10/31/2016 07:58 PM, Rados?aw Pietrzyk wrote:
> I think wlcore driver searches dma-ranges in its parent that's why sdio
> node needs it.
Yes I agree. In this case it is needed as you have subnode in sdio node.
So IMO empty dma-ranges could be removed from ethernet and usb node, but
kept in future sdio subnode.
Bruno,
Do you plan to push sdio support ?
>
> 2016-10-31 17:41 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
> <mailto:bruherrera@gmail.com>>:
>
> On Mon, Oct 31, 2016 at 12:14 PM, Rados?aw Pietrzyk
> <radoslaw.pietrzyk at gmail.com <mailto:radoslaw.pietrzyk@gmail.com>>
> wrote:
> > This is weird because dma ddresses are recalculated using parent's
> > dma-ranges property and soc already has it so there should be absolutely no
> > problem.
>
> These are my DTS and DTSI file.
> >
> > 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com
> <mailto:bruherrera@gmail.com>>:
> >>
> >> On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
> >> <radoslaw.pietrzyk@gmail.com
> <mailto:radoslaw.pietrzyk@gmail.com>> wrote:
> >> > Have you defined your sdio node within soc node ?
> >>
> >> It is in the SOC node of the DSTI file.
> >>
> >> >
> >> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com
> <mailto:bruherrera@gmail.com>>:
> >> >>
> >> >> Hi Alex,
> >> >>
> >> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>> wrote:
> >> >> > Hi Bruno,
> >> >> >
> >> >> >
> >> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
> >> >> >>
> >> >> >> Hi Alex,
> >> >> >>
> >> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
> >> >> >> <alexandre.torgue at st.com <mailto:alexandre.torgue@st.com>>
> wrote:
> >> >> >>>
> >> >> >>> Hi Bruno,
> >> >> >>>
> >> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Hi Alexandre,
> >> >> >>>>
> >> >> >>>>>
> >> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM
> start address
> >> >> >>>>> remapping
> >> >> >>>>> (to @0) to boost performances. A DMA translation through
> >> >> >>>>> "dma-ranges"
> >> >> >>>>> property was needed for other masters than the M4 CPU.
> >> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need
> this DMA
> >> >> >>>>> translation.
> >> >> >>>>> This patches moves this DMA translation definition from
> stm32f429
> >> >> >>>>> soc
> >> >> >>>>> file
> >> >> >>>>> to board files.
> >> >> >>>>>
> >> >> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com
> <mailto:alexandre.torgue@st.com>>
> >> >> >>>>>
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> index 13c7cd2..a763c15 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>>> @@ -82,6 +82,10 @@
> >> >> >>>>> };
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> + soc {
> >> >> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> + };
> >> >> >>>>> +
> >> >> >>>>> usbotg_hs_phy: usbphy {
> >> >> >>>>> #phy-cells = <0>;
> >> >> >>>>> compatible = "usb-nop-xceiv";
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Shouldn't also the peripheral dma-ranges property move to
> board
> >> >> >>>> specific
> >> >> >>>> too?
> >> >> >>>> I had this patch for while but I didn't had the time to
> submit:
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> Well spot I forgot it. Actually, discussing with Arnd
> ysterday on
> >> >> >>> IIRC,
> >> >> >>> empty dma-ranges is not needed. Can you test on your side by
> >> >> >>> removing
> >> >> >>> dma-ranges in usb node please ?
> >> >> >>
> >> >> >> Unfortunately will take a time for me to set up this
> environment on
> >> >> >> the STM32F4-EVAL board.
> >> >> >> And on the discovery boards we dont have this scenario.
> That was the
> >> >> >> main reason I did not submit the patch right away.
> >> >> >> My conclusion and I might be wrong but is based on the my
> tests with
> >> >> >> SDIO device at STM32F469I-DISCO board.
> >> >> >>
> >> >> >> I started this issue as discussion at ST Forum but Maxime
> gave me
> >> >> >> the
> >> >> >> hint.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
> <https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44>
> >> >> >>
> >> >> >>> I will push a v2 by removing empty dma-ranges if tests are
> ok in
> >> >> >>> your
> >> >> >>> side.
> >> >> >>
> >> >> >>
> >> >> >> From my understating/conclusion is: when empty
> property(dma-ranges)
> >> >> >> is
> >> >> >> the device node, the mapping will be taken in consideration
> when
> >> >> >> using
> >> >> >> DMA otherwise the mapping is ignored.
> >> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
> >> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in
> question
> >> >> >> so
> >> >> >> I suppose it can work without the property.
> >> >> >
> >> >> >
> >> >> > For sure translation has to be done but I'm not sure that an
> empty
> >> >> > "dma-ranges" is needed in device node to activate it. For
> Ethernet
> >> >> > empty
> >> >> > "dma-ranges" is not needed. I will try with usb.
> >> >>
> >> >> In the case of SDIO it is needed. As example this is my
> working SDIO
> >> >> node:
> >> >>
> >> >> sdio: sdio at 40012c00 {
> >> >> compatible = "arm,pl18x", "arm,primecell";
> >> >> arm,primecell-periphid = <0x00480181>;
> >> >> reg = <0x40012c00 0x400>;
> >> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
> >> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
> >> >> dma-names = "rx", "tx";
> >> >> clocks = <&rcc 0 171>;
> >> >> clock-names = "apb_pclk";
> >> >> interrupts = <49>;
> >> >> status = "disabled";
> >> >> };
> >> >>
> >> >> &sdio {
> >> >> status = "okay";
> >> >> vmmc-supply = <&wlan_en>;
> >> >> bus-width = <4>;
> >> >> max-frequency = <24000000>;
> >> >> pinctrl-names = "default";
> >> >> pinctrl-0 = <&sdio_pins>;
> >> >> ti,non-removable;
> >> >> ti,needs-special-hs-handling;
> >> >> dma-ranges;
> >> >> cap-power-off-card;
> >> >> keep-power-in-suspend;
> >> >>
> >> >> #address-cells = <1>;
> >> >> #size-cells = <0>;
> >> >> wlcore: wlcore at 0 {
> >> >> compatible = "ti,wl1835";
> >> >> reg = <2>;
> >> >> interrupt-parent = <&gpioa>;
> >> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
> >> >> };
> >> >> };
> >> >>
> >> >> >
> >> >> > alex
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>>
> >> >> >>> Thanks in advance
> >> >> >>> Alex
> >> >> >>>
> >> >> >>>
> >> >> >>>>
> >> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com
> <mailto:bruherrera@gmail.com>>
> >> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
> >> >> >>>>
> >> >> >>>> ARM: DT: STM32: Use dma-ranges property per board not
> at dtsi
> >> >> >>>> file
> >> >> >>>>
> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> index 6bfc595..2a22a82 100644
> >> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> >> >> >>>> @@ -52,6 +52,10 @@
> >> >> >>>> model = "STMicroelectronics STM32429i-EVAL board";
> >> >> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
> >> >> >>>>
> >> >> >>>> + soc {
> >> >> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
> >> >> >>>> + };
> >> >> >>>> +
> >> >> >>>> chosen {
> >> >> >>>> bootargs = "root=/dev/ram rdinit=/linuxrc";
> >> >> >>>> stdout-path = "serial0:115200n8";
> >> >> >>>> @@ -96,6 +100,7 @@
> >> >> >>>>
> >> >> >>>> ðernet0 {
> >> >> >>>> status = "okay";
> >> >> >>>> + dma-ranges;
> >> >> >>>> pinctrl-0 = <ðernet0_mii>;
> >> >> >>>> pinctrl-names = "default";
> >> >> >>>> phy-mode = "mii-id";
> >> >> >>>> @@ -116,6 +121,7 @@
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> &usbotg_hs {
> >> >> >>>> + dma-ranges;
> >> >> >>>> dr_mode = "host";
> >> >> >>>> phys = <&usbotg_hs_phy>;
> >> >> >>>> phy-names = "usb2-phy";
> >> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> index 7d624a2..697a133 100644
> >> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>> @@ -59,7 +59,6 @@
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> soc {
> >> >> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>
> >> >> >>>> timer2: timer at 40000000 {
> >> >> >>>> compatible = "st,stm32-timer";
> >> >> >>>> @@ -472,13 +471,11 @@
> >> >> >>>> st,syscon = <&syscfg 0x4>;
> >> >> >>>> snps,pbl = <8>;
> >> >> >>>> snps,mixed-burst;
> >> >> >>>> - dma-ranges;
> >> >> >>>> status = "disabled";
> >> >> >>>> };
> >> >> >>>>
> >> >> >>>> usbotg_hs: usb at 40040000 {
> >> >> >>>> compatible = "snps,dwc2";
> >> >> >>>> - dma-ranges;
> >> >> >>>> reg = <0x40040000 0x40000>;
> >> >> >>>> interrupts = <77>;
> >> >> >>>> clocks = <&rcc 0 29>;
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> index 0596d60..3a1cfdd 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> >> >> >>>>> @@ -59,8 +59,6 @@
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> soc {
> >> >> >>>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> -
> >> >> >>>>> timer2: timer at 40000000 {
> >> >> >>>>> compatible = "st,stm32-timer";
> >> >> >>>>> reg = <0x40000000 0x400>;
> >> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> index 9e73656..c2213c0 100644
> >> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> >> >> >>>>> @@ -64,6 +64,10 @@
> >> >> >>>>> aliases {
> >> >> >>>>> serial0 = &usart3;
> >> >> >>>>> };
> >> >> >>>>> +
> >> >> >>>>> + soc {
> >> >> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
> >> >> >>>>> + };
> >> >> >>>>> };
> >> >> >>>>>
> >> >> >>>>> &clk_hse {
> >> >> >>>>> --
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Br.,
> >> >> >>>> Bruno
> >> >> >>>>
> >> >> >>>
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> linux-arm-kernel mailing list
> >> >> linux-arm-kernel at lists.infradead.org
> <mailto:linux-arm-kernel@lists.infradead.org>
> >> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>
> >> >
> >> >
> >
> >
>
>
^ permalink raw reply
* [PATCHv3 0/4] Add Altera A10SR Status & Control Monitor
From: tthayer at opensource.altera.com @ 2016-11-02 14:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Thor Thayer <tthayer@opensource.altera.com>
his patch series adds the Altera Arria10 DevKit System Resource
chip's Status and Control Monitor to the A10SR Multi-Function
Device. An earlier patch added this to the hwmon class which
wasn't the proper place so this functionality is added to the
misc directory.
Version 2 changes the DT names from -mon to -monitor for better
readability and clarity and changed the previous version from
modular to built-in.
Version 3 improves the DT bindings naming and removes an unused
variable.
Thor Thayer (4):
dt-bindings: mfd: Add Altera Arria10 SR Monitor
misc: Add Altera Arria10 System Resource Control
mfd: altr-a10sr: Add Arria10 SR Monitor
ARM: socfpga: dts: Add Monitor to A10-SR MFD
.../devicetree/bindings/mfd/altera-a10sr.txt | 11 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/socfpga_arria10_socdk.dtsi | 4 +
drivers/mfd/altera-a10sr.c | 6 +-
drivers/misc/Kconfig | 7 +
drivers/misc/Makefile | 1 +
drivers/misc/altera-a10sr-monitor.c | 175 +++++++++++++++++++++
7 files changed, 203 insertions(+), 2 deletions(-)
create mode 100644 drivers/misc/altera-a10sr-monitor.c
--
1.9.1
^ 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