* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-12-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481093992-30520-1-git-send-email-gerg@uclinux.org>
Allow the arm versatile machine to be configured for no-MMU operation.
The approach taken is similar to the support for no-MMU arm v7 machines.
A new define, CONFIG_ARM_SINGLE_ARMV5, is used to enable a class of v5
core based machines that are supported for building with !CONFIG_MMU.
Currently only the versatile machine is configured to support this.
Older kernels had the ability to build the versatile machine with the MMU
disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
to device tree lost this ability. (Although older kernels could be built
they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/mach-versatile/Kconfig | 3 ++-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529f..74a0e7a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -353,6 +353,16 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
+config ARM_SINGLE_ARMV5
+ bool "ARMv5 based platforms (ARM926T)"
+ depends on !MMU
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select GENERIC_CLOCKEVENTS
+ select SPARSE_IRQ
+ select USE_OF
+
config ARCH_GEMINI
bool "Cortina Systems Gemini"
select CLKSRC_MMIO
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c3..483709e 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1712,7 +1712,8 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARMV5
default "mach/uncompress.h"
config EARLY_PRINTK
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index c257d40..2613f0f 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -1,12 +1,13 @@
config ARCH_VERSATILE
bool "ARM Ltd. Versatile family"
- depends on ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
select CLKSRC_VERSATILE
select COMMON_CLK_VERSATILE
select CPU_ARM926T
+ select GPIOLIB
select ICST
select MFD_SYSCON
select PLAT_VERSATILE
--
1.9.1
^ permalink raw reply related
* [PATCH] usb: mtu3: fix U3 port link issue
From: Chunfeng Yun @ 2016-12-07 7:23 UTC (permalink / raw)
To: linux-arm-kernel
the issue is introduced when @is_u3_ip is used in mtu3_device_enabe()
before initialized in mtu3_mem_alloc(), so get global IP information
at first before used by following functins.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_core.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index 520e55a..af3e531 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -481,21 +481,14 @@ static int mtu3_mem_alloc(struct mtu3 *mtu)
void __iomem *mbase = mtu->mac_base;
struct mtu3_ep *ep_array;
int in_ep_num, out_ep_num;
- u32 cap_epinfo, cap_dev;
+ u32 cap_epinfo;
int ret;
int i;
- mtu->hw_version = mtu3_readl(mtu->ippc_base, U3D_SSUSB_HW_ID);
-
- cap_dev = mtu3_readl(mtu->ippc_base, U3D_SSUSB_IP_DEV_CAP);
- mtu->is_u3_ip = !!SSUSB_IP_DEV_U3_PORT_NUM(cap_dev);
-
cap_epinfo = mtu3_readl(mbase, U3D_CAP_EPINFO);
in_ep_num = CAP_TX_EP_NUM(cap_epinfo);
out_ep_num = CAP_RX_EP_NUM(cap_epinfo);
- dev_info(mtu->dev, "IP version 0x%x(%s IP)\n", mtu->hw_version,
- mtu->is_u3_ip ? "U3" : "U2");
dev_info(mtu->dev, "fifosz/epnum: Tx=%#x/%d, Rx=%#x/%d\n",
mtu3_readl(mbase, U3D_CAP_EPNTXFFSZ), in_ep_num,
mtu3_readl(mbase, U3D_CAP_EPNRXFFSZ), out_ep_num);
@@ -730,8 +723,17 @@ irqreturn_t mtu3_irq(int irq, void *data)
static int mtu3_hw_init(struct mtu3 *mtu)
{
+ u32 cap_dev;
int ret;
+ mtu->hw_version = mtu3_readl(mtu->ippc_base, U3D_SSUSB_HW_ID);
+
+ cap_dev = mtu3_readl(mtu->ippc_base, U3D_SSUSB_IP_DEV_CAP);
+ mtu->is_u3_ip = !!SSUSB_IP_DEV_U3_PORT_NUM(cap_dev);
+
+ dev_info(mtu->dev, "IP version 0x%x(%s IP)\n", mtu->hw_version,
+ mtu->is_u3_ip ? "U3" : "U2");
+
mtu3_device_reset(mtu);
ret = mtu3_device_enable(mtu);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] usb: mtu3: enable auto switch from U3 to U2
From: Chunfeng Yun @ 2016-12-07 7:24 UTC (permalink / raw)
To: linux-arm-kernel
inform mac2 to build U2 link automatically after U3 detect
fail without software setting soft_connect.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index af3e531..ca05021 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -568,6 +568,8 @@ static void mtu3_regs_init(struct mtu3 *mtu)
SW_U1_REQUEST_ENABLE | SW_U2_REQUEST_ENABLE);
/* device responses to u3_exit from host automatically */
mtu3_clrbits(mbase, U3D_LTSSM_CTRL, SOFT_U3_EXIT_EN);
+ /* automatically build U2 link when U3 detect fail */
+ mtu3_setbits(mbase, U3D_USB2_TEST_MODE, U2U3_AUTO_SWITCH);
}
mtu3_set_speed(mtu);
--
1.7.9.5
^ permalink raw reply related
* mmc: core: complete/wait_for_completion performance
From: Jörg Krause @ 2016-12-07 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1198138554.59982.63209ba1-8fb4-4a13-9ee0-f746a192f4c7.open-xchange@email.1und1.de>
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Jörg Krause @ 2016-12-07 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1198138554.59982.63209ba1-8fb4-4a13-9ee0-f746a192f4c7.open-xchange@email.1und1.de>
Hit Stefan,
On Sat, 2016-11-26 at 20:10 +0100, Stefan Wahren wrote:
> Hi J?rg,
>
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016
> > um 20:10
> > geschrieben:
> >
> >
> > On Sun, 2016-11-20 at 16:44 +0100, Stefan Wahren wrote:
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November
> > > > 2016
> > > > um 15:42
> > > > geschrieben:
> > > >
> > > >
> > > > Hi Stefan,
> > > >
> > > > On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> > > > > Hi J?rg,
> > > > >
> > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20.
> > > > > > November
> > > > > > 2016
> > > > > > um 13:27
> > > > > > geschrieben:
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I started the discussion on this mailing list in another
> > > > > > thread
> > > > > > [1],
> > > > > > but I'd like to move it to a new thread, because it might
> > > > > > be
> > > > > > mmc
> > > > > > specific.
> > > > > >
> > > > > > The issue is that I am noticed low wifi network throughput
> > > > > > on
> > > > > > an
> > > > > > i.MX28
> > > > > > board with the mainline kernel (v4.7.10, about 6 Mbps)
> > > > > > compared
> > > > > > to
> > > > > > the
> > > > > > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The
> > > > > > wifi
> > > > > > chip
> > > > > > is
> > > > > > attached using the SDIO interface.
> > > > > >
> > > > > > I started investigation where the bottleneck in the
> > > > > > mainline
> > > > > > kernel?might come from. Therefore I checked that the
> > > > > > configs
> > > > > > and
> > > > > > settings for the interfaces and drivers are the same. They
> > > > > > are.
> > > > >
> > > > > so you're not using the mxs_defconfig settings anymore?
> > > >
> > > > No, I changed the settings.
> > > >
> > >
> > > What happens to performance to if you change the following
> > > settings
> > > to the same
> > > like in mxs_defconfig?
> > >
> > > CONFIG_PREEMPT_VOLUNTARY=y
> > > CONFIG_DEFAULT_IOSCHED="noop"
> >
> > No much change at all. The time difference between complete() and
> > wait_for_complete() decreases in best case to 110 us, but also
> > varies
> > to above 130 us.
>
> just a weird idea. Did you tried to add MMC_CAP_CMD23 into the caps
> [1]?
>
> [1] - http://lxr.free-electrons.com/source/drivers/mmc/host/mxs-mmc.c
> ?v=4.8#L642
I tried, but it did not improved the timing or throughput. However,
many thanks for the input.
J?rg
^ permalink raw reply
* [PATCH V2 1/5] ARM: BCM5301X: Fix LAN LED labels for Luxul XWR-3100
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Rafa? Mi?ecki <rafal@milecki.pl>
They were named incorrectly most likely due to copy & paste mistake.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index 2f4a651..93cc91d 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -31,13 +31,13 @@
};
lan3 {
- label = "bcm53xx:green:lan1";
+ label = "bcm53xx:green:lan3";
gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
lan4 {
- label = "bcm53xx:green:lan0";
+ label = "bcm53xx:green:lan4";
gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
@@ -49,7 +49,7 @@
};
lan1 {
- label = "bcm53xx:green:lan3";
+ label = "bcm53xx:green:lan1";
gpios = <&chipcommon 4 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
--
2.10.1
^ permalink raw reply related
* [PATCH V2 2/5] ARM: BCM5301X: Specify USB controllers in DT
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207075655.7396-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
There are 3 separated controllers, one per USB /standard/. With PHY
drivers in place they can be simply supported with generic drivers.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
V2: Fix node names and reorder ehci with ohci. Thanks Ray!
---
arch/arm/boot/dts/bcm5301x.dtsi | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index f09a2bb..a4614c9 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -248,8 +248,26 @@
#address-cells = <1>;
#size-cells = <1>;
+ ranges;
- phys = <&usb2_phy>;
+ interrupt-parent = <&gic>;
+
+ ehci: ehci at 21000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-ehci";
+ reg = <0x00021000 0x1000>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb2_phy>;
+ };
+
+ ohci: ohci at 22000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-ohci";
+ reg = <0x00022000 0x1000>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
usb3: usb3 at 23000 {
@@ -257,6 +275,19 @@
#address-cells = <1>;
#size-cells = <1>;
+ ranges;
+
+ interrupt-parent = <&gic>;
+
+ xhci: xhci at 23000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-xhci";
+ reg = <0x00023000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb3_phy>;
+ phy-names = "usb";
+ };
};
spi at 29000 {
--
2.10.1
^ permalink raw reply related
* [PATCH V2 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207075655.7396-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
There is one GPIO controlling power for both USB ports.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
V2: Avoid double Signed-off-by due to different e-mail address
---
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index 0225d82..7ab1176 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -100,3 +100,11 @@
};
};
};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
+};
--
2.10.1
^ permalink raw reply related
* [PATCH V2 4/5] ARM: BCM5301X: Specify all RAM by including an extra block
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207075655.7396-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
The first 128 MiB of RAM can be accessed using an alias at address 0x0.
In theory we could access whole RAM using 0x80000000 - 0xbfffffff range
(up to 1 GiB) but it doesn't seem to work on Northstar. For some reason
(hardware setup left by the bootloader maybe?) 0x80000000 - 0x87ffffff
range can't be used. I reproduced this problem on:
1) Buffalo WZR-600DHP2 (BCM47081)
2) Netgear R6250 (BCM4708)
3) D-Link DIR-885L (BCM47094)
So it seems we're forced to access first 128 MiB using alias at 0x0 and
the rest using real base address + 128 MiB offset which is 0x88000000.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
V2: Updated commit message, thanks Jon!
Included XWR-3100
---
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 ++-
arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 ++-
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 3 ++-
arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 ++-
arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 3 ++-
arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 ++-
arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 ++-
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 3 ++-
arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 3 ++-
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 ++-
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 3 ++-
arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 ++-
16 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
index 112a5a8..d241cee 100644
--- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
+++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
index 3600f56..b0e6204 100644
--- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
+++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
index d49afec0..c9ba6b9 100644
--- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
+++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
spi {
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
index 8519548..b9f66c0 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
index 6229ef2..ae0199f 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
index 74cfcd3..36b628b1 100644
--- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
+++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
index 71b98cf..db8608b 100644
--- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
+++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
index 2922536..d51586d 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
spi {
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
index 184fd92..de041b8 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
gpio-keys {
diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
index eac0f52..eaca687 100644
--- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
+++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
index aab39c9..b32957c 100644
--- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
+++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index 7ab1176..f459a98 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
index 56d38a3..cd13534 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index 7fb9270..64ded76 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
nand: nand at 18028000 {
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index 93cc91d..5cf4ab1 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -18,7 +18,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
index 7ecd57c..600795e 100644
--- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
+++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
@@ -18,7 +18,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
leds {
--
2.10.1
^ permalink raw reply related
* [PATCH V2 5/5] ARM: BCM53573: Specify USB ports of on-SoC controllers
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207075655.7396-1-zajec5@gmail.com>
From: Rafa? Mi?ecki <rafal@milecki.pl>
Broadcom OHCI and EHCI controllers always have 2 ports each on the root
hub. Describe them in DT to allow specifying extra info or referencing
port nodes.
Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm53573.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/bcm53573.dtsi b/arch/arm/boot/dts/bcm53573.dtsi
index e2c496a..2da04d0 100644
--- a/arch/arm/boot/dts/bcm53573.dtsi
+++ b/arch/arm/boot/dts/bcm53573.dtsi
@@ -124,6 +124,17 @@
reg = <0x4000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ehci_port1: port at 1 {
+ reg = <1>;
+ };
+
+ ehci_port2: port at 2 {
+ reg = <2>;
+ };
};
ohci: ohci at d000 {
@@ -133,6 +144,17 @@
reg = <0xd000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ohci_port1: port at 1 {
+ reg = <1>;
+ };
+
+ ohci_port2: port at 2 {
+ reg = <2>;
+ };
};
};
--
2.10.1
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: remove smp hook from machine descriptor
From: Pankaj Dubey @ 2016-12-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel
Use CPU_METHOD_OF_DECLARE() for smp_ops instead of using it
via machine descriptor.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/boot/dts/exynos3250.dtsi | 1 +
arch/arm/boot/dts/exynos4210.dtsi | 1 +
arch/arm/boot/dts/exynos4212.dtsi | 1 +
arch/arm/boot/dts/exynos4412.dtsi | 1 +
arch/arm/boot/dts/exynos5250.dtsi | 1 +
arch/arm/boot/dts/exynos5260.dtsi | 1 +
arch/arm/boot/dts/exynos5410.dtsi | 1 +
arch/arm/boot/dts/exynos5420-cpus.dtsi | 1 +
arch/arm/boot/dts/exynos5422-cpus.dtsi | 1 +
arch/arm/boot/dts/exynos5440.dtsi | 1 +
arch/arm/mach-exynos/common.h | 2 --
arch/arm/mach-exynos/exynos.c | 1 -
arch/arm/mach-exynos/platsmp.c | 2 ++
13 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index ba17ee1..f28f669 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -53,6 +53,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 7f3a18c..6dfd98d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -35,6 +35,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 900 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
index 5389011..3e8982e 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -25,6 +25,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at A00 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 40beede..faf2fb8 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -25,6 +25,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at A00 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index b6d7444..580897c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -52,6 +52,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
index 5818718..1af6e76 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -32,6 +32,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index 2b6adaf..b092cdc 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -33,6 +33,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index 5c052d7..a587704 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -24,6 +24,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index bf3c6f1..7fcdfd0 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -23,6 +23,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 100 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 2a2e570..0a958e8 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -50,6 +50,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index fb12d11..051e1ab 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -143,8 +143,6 @@ static inline void exynos_pm_init(void) {}
extern void exynos_cpu_resume(void);
extern void exynos_cpu_resume_ns(void);
-extern const struct smp_operations exynos_smp_ops;
-
extern void exynos_cpu_power_down(int cpu);
extern void exynos_cpu_power_up(int cpu);
extern int exynos_cpu_power_state(int cpu);
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index fa08ef9..f0a766e 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -211,7 +211,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
/* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
.l2c_aux_val = 0x3c400001,
.l2c_aux_mask = 0xc20fffff,
- .smp = smp_ops(exynos_smp_ops),
.map_io = exynos_init_io,
.init_early = exynos_firmware_init,
.init_irq = exynos_init_irq,
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 94405c7..43eec10 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -474,3 +474,5 @@ const struct smp_operations exynos_smp_ops __initconst = {
.cpu_die = exynos_cpu_die,
#endif
};
+
+CPU_METHOD_OF_DECLARE(exynos_smp, "samsung,exynos-smp", &exynos_smp_ops);
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
From: Scott Branden @ 2016-12-07 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5840E659.6000104@huawei.com>
Hi Xishi,
I followed you suggestions and found pfn_valid is always true. Answers
to your questions inline.
I could keep debugging this but hope Marcin sends out some code - I'm
quite willing to test and help clean up the patchset.
On 16-12-01 07:11 PM, Xishi Qiu wrote:
> On 2016/12/2 10:38, Scott Branden wrote:
>
>> Hi Xishi,
>>
>> Thanks for the reply - please see comments below.
>>
>> On 16-12-01 05:49 PM, Xishi Qiu wrote:
>>> On 2016/12/2 8:19, Scott Branden wrote:
>>>
>>>> This patchset is sent for comment to add memory hotplug support for ARM64
>>>> based platforms. It follows hotplug code added for other architectures
>>>> in the linux kernel.
>>>>
>>>> I tried testing the memory hotplug feature following documentation from
>>>> Documentation/memory-hotplug.txt. I don't think it is working as expected
>>>> - see below:
>>>>
>>>> To add memory to the system I did the following:
>>>> echo 0x400000000 > /sys/devices/system/memory/probe
>>>>
>>>> The memory is displayed as system ram:
>>>> cat /proc/iomem:
>>>> 74000000-77ffffff : System RAM
>>>> 74080000-748dffff : Kernel code
>>>> 74950000-749d2fff : Kernel data
>>>> 400000000-43fffffff : System RAM
>>>>
>>>> But does not seem to be added to the kernel memory.
>>>> /proc/meminfo did not change.
>>>>
>>>> What else needs to be done so the memory is added to the kernel memory
>>>> pool for normal allocation?
>>>>
>>>
>>> Hi Scott,
>>>
>>> Do you mean it still don't support hod-add after apply this patchset?
>>
>> After applying the patch it appears to partially support hot-add. Please let me know if you think it is working as expected?
>>
>> The memory probe functions in that the memory is registered with the system and shows up in /proc/iomem. But, the memory is not available in /proc/meminfo. Do you think something else needs to be adjusted for ARM64 to hotadd the memory
>>
>> I just found another clue:
>> under /sys/devices/system/memory I only see one memory entry (before or after I try to hotadd additional memory).
>>
>> /sys/devices/system/memory # ls
>> auto_online_blocks memory0 uevent
>> block_size_bytes probe
>>
>> In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 30 to 28 and recompile I get the following:
>> /sys/devices/system/memory # ls
>> auto_online_blocks memory7 uevent
>> block_size_bytes probe
>>
>>
>> In arch/arm64/include/asm/sparsemem.h if I change SECTION_SIZE_BITS from 30 to 27 and recompile I get the following:
>> /sys/devices/system/memory # ls
>> auto_online_blocks memory14 uevent
>> block_size_bytes probe
>>
>> If looks to me like something is not working properly in the ARM64 implementation. I should expect to see multiple memoryX entries under /sys/devices/system/memory?
>>
>
> Hi Scott,
>
> 1. Do you enable the following configs?
> CONFIG_SPARSEMEM
> MEMORY_HOTPLUG
> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
Yes, these configs are enabled
>
> 2. I find you missed create mapping in arch_add_memory(), and x86 has it.
Could you please explain this further? The patch I submitted hass
arch_add_memory identical to the ia64 implementation.
>
> 3. We will add memblock first, so pfn_valid() maybe always return true(in the
> following function), and this will lead __add_section() failed. Please check
> it.
You are correct - pfn_valid always returns true. The function is in
arch/arm64/mm/init.c and different than the one you indicated below:
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
return memblock_is_map_memory(pfn << PAGE_SHIFT);
}
EXPORT_SYMBOL(pfn_valid);
#endif
>
> int pfn_valid(unsigned long pfn)
> {
> return (pfn & PFN_MASK) == pfn && memblock_is_memory(pfn << PAGE_SHIFT);
> }
>
> add_memory
> add_memory_resource
> memblock_add_node
> arch_add_memory
> __add_pages
> __add_section
> pfn_valid
>
> Thanks,
> Xishi Qiu
>
>>
>>
>>>
>>> Thanks,
>>> Xishi Qiu
>>>
>>>> Scott Branden (2):
>>>> arm64: memory-hotplug: Add MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
>>>> MEMORY_PROBE
>>>> arm64: defconfig: enable MEMORY_HOTPLUG config options
>>>>
>>>> arch/arm64/Kconfig | 10 ++++++++++
>>>> arch/arm64/configs/defconfig | 3 +++
>>>> arch/arm64/mm/init.c | 42 ++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 55 insertions(+)
>>>>
>>>
>>>
>>>
>>
>> .
>>
>
>
>
^ permalink raw reply
* [PATCH v3 0/4] mm: fix the "counter.sh" failure for libhugetlbfs
From: Huang Shijie @ 2016-12-07 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205093100.GF30758@dhcp22.suse.cz>
On Mon, Dec 05, 2016 at 05:31:01PM +0800, Michal Hocko wrote:
> On Mon 05-12-16 17:17:07, Huang Shijie wrote:
> [...]
> > The failure is caused by:
> > 1) kernel fails to allocate a gigantic page for the surplus case.
> > And the gather_surplus_pages() will return NULL in the end.
> >
> > 2) The condition checks for some functions are wrong:
> > return_unused_surplus_pages()
> > nr_overcommit_hugepages_store()
> > hugetlb_overcommit_handler()
>
> OK, so how is this any different from gigantic (1G) hugetlb pages on
> x86_64? Do we need the same functionality or is it just 32MB not being
> handled in the same way as 1G?
I tested this patch set on the Softiron board(ARM64) which has 16G memory.
I appended "hugepagesz=1G hugepages=6" in the kernel cmdline, the arm64
will use the PUD_SIZE for the hugetlb page.
The 1G page size can run well, I post the log here:
--------------------------------------------------------
counters.sh (1024M: 64): PASS
********** TEST SUMMARY
* 1024M
* 32-bit 64-bit
* Total testcases: 0 1
* Skipped: 0 0
* PASS: 0 1
* FAIL: 0 0
* Killed by signal: 0 0
* Bad configuration: 0 0
* Expected FAIL: 0 0
* Unexpected PASS: 0 0
* Strange test result: 0 0
**********
--------------------------------------------------------
My desktop is x86_64, but its memory is just 8G.
I will expand its memory capacity, and continue to
the test for x86_64.
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH 1/2] ARM: dts: at91: sama5d4: change DMA allocation for secure peripherals
From: Alexandre Belloni @ 2016-12-07 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130173630.11944-1-nicolas.ferre@atmel.com>
On 30/11/2016 at 18:36:29 +0100, Nicolas Ferre wrote :
> Some peripherals are "Programmable Secure" but left as "Secure" by default.
> If tried to be connected to Non-Secure DMA controller, the possibility to
> leak secure data is prevented so using these peripherals with DMA1 is not
> possible with this default configuration (MATRIX_SPSELR registers setup by
> bootloader).
> Move them to DMA0 which is an "Always-Secure" DMA controller.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/sama5d4.dtsi | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
All applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/3] ARM: dts: at91: add dma1 definition to sama5d2
From: Alexandre Belloni @ 2016-12-07 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104949.23985-1-nicolas.ferre@atmel.com>
On 01/12/2016 at 11:49:47 +0100, Nicolas Ferre wrote :
> The sama5d2 SoC has a second DMA controller and can be used just like DMA0.
> By default both DMA controllers are configured as "Secure" in
> MATRIX_SPSELR so we can use whichever we want in a "single Secure World"
> configuration.
> Surprisingly the DMA1 has a lower address than DMA0. To avoid confusion
> place it after DMA0 node anyway.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/sama5d2.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
All applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 08/16] drivers/fsi: Add crc4 helpers
From: Greg KH @ 2016-12-07 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481076574-54711-2-git-send-email-christopher.lee.bostic@gmail.com>
On Tue, Dec 06, 2016 at 08:09:31PM -0600, Chris Bostic wrote:
> From: Jeremy Kerr <jk@ozlabs.org>
>
> Add some helpers for the crc checks for the slave configuration table.
> This works 4-bits-at-a-time, using a simple table approach.
>
> We will need this in the FSI core code, as well as any master
> implementations that need to calculate CRCs in software.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
> ---
> drivers/fsi/fsi-core.c | 21 +++++++++++++++++++++
> drivers/fsi/fsi-master.h | 21 +++++++++++++++++++++
> 2 files changed, 42 insertions(+)
Why not just create lib/crc4.c with these functions, like the other crc
functions in the kernel? Don't bury these in some random driver
subsystem please.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
From: Nicolas Ferre @ 2016-12-07 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481052157-23400-2-git-send-email-peda@axentia.se>
Le 06/12/2016 ? 20:22, Peter Rosin a ?crit :
> The SSC is currently not usable with the ASoC simple-audio-card, as
> every SSC audio user has to build a platform driver that may do as
> little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
> allocates the SSC and registers a DAI with the ASoC subsystem).
>
> So, have that happen automatically, if the #sound-dai-cells property
> is present in devicetree, which it has to be anyway for simple audio
> card to work.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Sounds okay: thanks Peter.
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
I don't think my tag is needed for second patch but you can add it if
you wish.
Regards,
> ---
> .../devicetree/bindings/misc/atmel-ssc.txt | 2 +
> drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
> include/linux/atmel-ssc.h | 1 +
> 3 files changed, 53 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> index efc98ea1f23d..f8629bb73945 100644
> --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> @@ -24,6 +24,8 @@ Optional properties:
> this parameter to choose where the clock from.
> - By default the clock is from TK pin, if the clock from RK pin, this
> property is needed.
> + - #sound-dai-cells: Should contain <0>.
> + - This property makes the SSC into an automatically registered DAI.
>
> Examples:
> - PDC transfer:
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index 0516ecda54d3..b2a0340f277e 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -20,6 +20,8 @@
>
> #include <linux/of.h>
>
> +#include "../../sound/soc/atmel/atmel_ssc_dai.h"
> +
> /* Serialize access to ssc_list and user count */
> static DEFINE_SPINLOCK(user_lock);
> static LIST_HEAD(ssc_list);
> @@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
> platform_get_device_id(pdev)->driver_data;
> }
>
> +#ifdef CONFIG_SND_ATMEL_SOC_SSC
> +static int ssc_sound_dai_probe(struct ssc_device *ssc)
> +{
> + struct device_node *np = ssc->pdev->dev.of_node;
> + int ret;
> + int id;
> +
> + ssc->sound_dai = false;
> +
> + if (!of_property_read_bool(np, "#sound-dai-cells"))
> + return 0;
> +
> + id = of_alias_get_id(np, "ssc");
> + if (id < 0)
> + return id;
> +
> + ret = atmel_ssc_set_audio(id);
> + ssc->sound_dai = !ret;
> +
> + return ret;
> +}
> +
> +static void ssc_sound_dai_remove(struct ssc_device *ssc)
> +{
> + if (!ssc->sound_dai)
> + return;
> +
> + atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
> +}
> +#else
> +static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
> +{
> + if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
> + return -ENOTSUPP;
> +
> + return 0;
> +}
> +
> +static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
> +{
> +}
> +#endif
> +
> static int ssc_probe(struct platform_device *pdev)
> {
> struct resource *regs;
> @@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
> ssc->regs, ssc->irq);
>
> + if (ssc_sound_dai_probe(ssc))
> + dev_err(&pdev->dev, "failed to auto-setup ssc for audio\n");
> +
> return 0;
> }
>
> @@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
> {
> struct ssc_device *ssc = platform_get_drvdata(pdev);
>
> + ssc_sound_dai_remove(ssc);
> +
> spin_lock(&user_lock);
> list_del(&ssc->list);
> spin_unlock(&user_lock);
> diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
> index 7c0f6549898b..fdb545101ede 100644
> --- a/include/linux/atmel-ssc.h
> +++ b/include/linux/atmel-ssc.h
> @@ -20,6 +20,7 @@ struct ssc_device {
> int user;
> int irq;
> bool clk_from_rk_pin;
> + bool sound_dai;
> };
>
> struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 04/16] drivers/fsi: Add fsi master definition
From: Greg KH @ 2016-12-07 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481076574-54711-1-git-send-email-christopher.lee.bostic@gmail.com>
On Tue, Dec 06, 2016 at 08:09:30PM -0600, Chris Bostic wrote:
> From: Jeremy Kerr <jk@ozlabs.org>
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
> ---
> drivers/fsi/fsi-core.c | 20 ++++++++++++++++++++
> drivers/fsi/fsi-master.h | 37 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 57 insertions(+)
> create mode 100644 drivers/fsi/fsi-master.h
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index 3d55bd5..ce9428d 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -17,6 +17,26 @@
> #include <linux/fsi.h>
> #include <linux/module.h>
>
> +#include "fsi-master.h"
> +
> +static atomic_t master_idx = ATOMIC_INIT(-1);
You don't really want/need an atomic variable, please use the simple ida
interface instead.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'
From: Robert Richter @ 2016-12-07 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206173810.GU2498@arm.com>
On 06.12.16 17:38:11, Will Deacon wrote:
> On Mon, Dec 05, 2016 at 03:42:14PM +0000, Ard Biesheuvel wrote:
> > On 2 December 2016 at 14:49, James Morse <james.morse@arm.com> wrote:
> > > Patch "arm64: mm: Fix memmap to be initialized for the entire section"
> > > changes pfn_valid() in a way that breaks hibernate. These patches fix
> > > hibernate, and provided struct page's are allocated for nomap pages,
> > > can be applied before [0].
> > >
> > > Hibernate core code belives 'valid' to mean "I can access this". It
> > > uses pfn_valid() to test the page if the page is 'valid'.
> > >
> > > pfn_valid() needs to be changed so that all struct pages in a numa
> > > node have the same node-id. Currently 'nomap' pages are skipped, and
> > > retain their pre-numa node-ids, which leads to a later BUG_ON().
> > >
> > > These patches make hibernate's savable_page() take its escape route
> > > via 'if (PageReserved(page) && pfn_is_nosave(pfn))'.
> > >
> >
> > This makes me feel slightly uneasy. Robert makes a convincing point,
> > but I wonder if we can expect more fallout from the ambiguity of
> > pfn_valid(). Now we are not only forced to assign non-existing (as far
> > as the OS is concerned) pages to the correct NUMA node, we also need
> > to set certain page flags.
>
> Yes, I really don't know how to proceed here. Playing whack-a-mole with
> pfn_valid() users doesn't sounds like an improvement on the current
> situation to me.
>
> Robert -- if we leave pfn_valid() as it is, would a point-hack to
> memmap_init_zone help, or do you anticipate other problems?
I would suggest to fix the hibernation code as I commented on before
to use pfn_is_nosave() that defaults to pfn_valid() but uses memblock_
is_nomap() for arm64. Let's just fix it and see if no other issues
arise. I am trying to send a patch for this until tomorrow.
I am also going to see how early_pfn_valid() could be redirected to
use memblock_is_nomap() on arm64. That would "quick fix" the problem,
though I rather prefer to go further with the current solution.
-Robert
^ permalink raw reply
* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Alexandre Bailon @ 2016-12-07 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22aec236-83f0-ea2d-8657-c99f95389611@lechnology.com>
On 12/06/2016 07:56 PM, David Lechner wrote:
> On 12/06/2016 03:57 AM, Sekhar Nori wrote:
>> On Tuesday 06 December 2016 03:21 PM, Alexandre Bailon wrote:
>>> On 12/06/2016 10:33 AM, Sekhar Nori wrote:
>>>> On Monday 05 December 2016 07:43 PM, Alexandre Bailon wrote:
>>>>> Everytime the usb20 phy is enabled, there is a
>>>>> "sleeping function called from invalid context" BUG.
>>>>>
>>>>> clk_enable() from arch/arm/mach-davinci/clock.c uses
>>>>> spin_lock_irqsave()
>>>>> before to invoke the callback usb20_phy_clk_enable().
>>>>> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
>>>>> which may sleep.
>>>>> Move clk_get() to da8xx_register_usb20_phy_clk() and
>>>>> replace clk_prepare_enable() by clk_enable().
>>>>>
>>>>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>>>>
>>>> This will still cause the recursive locking problem reported by David.
>>>> Not sure what the point of sending this version was.
>>>>
>>>> Thanks,
>>>> Sekhar
>>>>
>>
>>> What am I supposed to do ?
>>
>> That needs to be resolved between you and David. Perhaps convert the fix
>> sent by David into a proper patch and base this patch on that. Or wait
>> for David to send it himself and let him also make the modifications
>> needed in this patch.
>>
>> David ?
>>
>> Thanks,
>> Sekhar
>>
>
> Alexandre, I was hoping that you would just squash my patch with your
> patch and take Sekhar's suggestion about a separate patch to make the
> private __clk_enable() public as davinci_clk_enable() when you re-submit.
OK.
>
> You can add "Suggested-By: David Lechner <david@lechnology.com>" to the
> commit message if you would like to give me some credit for my ideas.
That was my concern. I will do that.
Thanks,
Alexandre
^ permalink raw reply
* [PATCH 0/4] arm/versatile: no-MMU support
From: Vladimir Murzin @ 2016-12-07 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481090912-29835-1-git-send-email-gerg@uclinux.org>
Hi Greg,
On 07/12/16 06:08, Greg Ungerer wrote:
> Does the ARM Versatile machine have a maintainer?
> I have CC'ed this patch set to those names reported by get_maintainer.
> I had no feedback on the first posting of this series back in August.
>
> The following patches support configuring and building the versatile
> machine with a no-MMU kernel.
>
> There is only a few minor changes required. It was previously possible
> in older kernels to build for versatile with CONFIG_MMU disabled, but
> the change to devicetree lost that capability. These changes make it
> possible again.
>
> One patch is a fix for address translation (broken in older kernels too),
> two are build problems when CONFIG_MMU is disabled, and the last is the
> actuall configuration changes needed.
>
> The motivation for this is that the versatile machine is well supported
> in qemu. And this provides an excellent platform for development and
> testing no-MMU support on ARM in general. With these patches applied
> it is possible to build and run a kernel with MMU disabled on qemu.
I'm wondering if my "Allow NOMMU for MULTIPLATFORM" series [1] work for you?
[1] https://www.spinics.net/lists/arm-kernel/msg546823.html
Cheers
Vladimir
>
> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
> ---
> arch/arm/Kconfig | 10 ++++++++++
> arch/arm/Kconfig.debug | 3 ++-
> arch/arm/include/asm/mach/map.h | 1 +
> arch/arm/mach-versatile/Kconfig | 3 ++-
> arch/arm/mach-versatile/Makefile.boot | 3 +++
> arch/arm/mach-versatile/versatile_dt.c | 4 ++++
> 6 files changed, 22 insertions(+), 2 deletions(-)
>
>
> _______________________________________________
> 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 11/16] drivers/fsi: Add device read/write/peek functions
From: Greg KH @ 2016-12-07 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481076574-54711-4-git-send-email-christopher.lee.bostic@gmail.com>
On Tue, Dec 06, 2016 at 08:09:33PM -0600, Chris Bostic wrote:
> diff --git a/include/linux/fsi.h b/include/linux/fsi.h
> index efa55ba..66bce48 100644
> --- a/include/linux/fsi.h
> +++ b/include/linux/fsi.h
> @@ -27,6 +27,12 @@ struct fsi_device {
> uint32_t size;
> };
>
> +extern int fsi_device_read(struct fsi_device *dev, uint32_t addr,
> + void *val, size_t size);
> +extern int fsi_device_write(struct fsi_device *dev, uint32_t addr,
> + const void *val, size_t size);
> +extern int fsi_device_peek(struct fsi_device *dev, void *val);
> +
> struct fsi_device_id {
> u8 engine_type;
> u8 version;
> @@ -40,7 +46,6 @@ struct fsi_device_id {
> #define FSI_DEVICE_VERSIONED(t, v) \
> .engine_type = (t), .version = (v),
>
> -
> struct fsi_driver {
> struct device_driver drv;
> const struct fsi_device_id *id_table;
Strange whitespace change here :)
Not a real problem, I like the fact that you have broken this down into
very logical pieces making it much easier to review, thanks so much for
doing this.
greg k-h
^ permalink raw reply
* [PATCH 14/16] drivers/fsi: Add master unscan
From: Greg KH @ 2016-12-07 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481069677-53660-15-git-send-email-christopher.lee.bostic@gmail.com>
On Tue, Dec 06, 2016 at 06:14:35PM -0600, Chris Bostic wrote:
> From: Chris Bostic <cbostic@us.ibm.com>
>
> Allow a master to undo a previous scan. Should a master scan a bus
> twice it will need to ensure it doesn't double register any
> previously detected device.
>
> Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
> ---
> drivers/fsi/fsi-core.c | 36 +++++++++++++++++++++++++++++++++++-
> drivers/fsi/fsi-master.h | 2 ++
> include/linux/fsi.h | 1 +
> 3 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index a28434b..8ccfe50 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -41,6 +41,8 @@
> static atomic_t master_idx = ATOMIC_INIT(-1);
>
> struct fsi_slave {
> + struct list_head list_link; /* Master's list of slaves */
> + struct list_head my_engines;
> struct device dev;
> struct fsi_master *master;
> int link;
> @@ -196,6 +198,8 @@ static int fsi_slave_scan(struct fsi_slave *slave)
> uint32_t conf;
> int rc, i;
>
> + INIT_LIST_HEAD(&slave->my_engines);
> +
> /*
> * scan engines
> *
> @@ -264,7 +268,9 @@ static int fsi_slave_scan(struct fsi_slave *slave)
> if (rc) {
> dev_warn(&slave->dev, "add failed: %d\n", rc);
> put_device(&dev->dev);
> + continue;
> }
> + list_add(&dev->link, &slave->my_engines);
> }
>
> engine_addr += slots * engine_page_size;
> @@ -357,7 +363,7 @@ static int fsi_slave_init(struct fsi_master *master,
> put_device(&slave->dev);
> return rc;
> }
> -
> + list_add(&slave->list_link, &master->my_slaves);
> fsi_slave_scan(slave);
> return 0;
> }
> @@ -388,6 +394,11 @@ static int fsi_master_scan(struct fsi_master *master)
> int link, slave_id, rc;
> uint32_t smode;
>
> + if (!master->slave_list) {
> + INIT_LIST_HEAD(&master->my_slaves);
> + master->slave_list = true;
> + }
> +
> for (link = 0; link < master->n_links; link++) {
> rc = fsi_master_link_enable(master, link);
> if (rc) {
> @@ -423,9 +434,31 @@ static int fsi_master_scan(struct fsi_master *master)
> return 0;
> }
>
> +static void fsi_master_unscan(struct fsi_master *master)
> +{
> + struct fsi_slave *slave, *slave_tmp;
> + struct fsi_device *fsi_dev, *fsi_dev_tmp;
> +
> + if (!master->slave_list)
> + return;
> +
> + list_for_each_entry_safe(slave, slave_tmp, &master->my_slaves,
> + list_link) {
> + list_del(&slave->list_link);
> + list_for_each_entry_safe(fsi_dev, fsi_dev_tmp,
> + &slave->my_engines, link) {
> + list_del(&fsi_dev->link);
> + put_device(&fsi_dev->dev);
> + }
> + device_unregister(&slave->dev);
> + }
> + master->slave_list = false;
> +}
> +
> int fsi_master_register(struct fsi_master *master)
> {
> master->idx = atomic_inc_return(&master_idx);
> + master->slave_list = false;
> get_device(master->dev);
> fsi_master_scan(master);
> return 0;
> @@ -434,6 +467,7 @@ int fsi_master_register(struct fsi_master *master)
>
> void fsi_master_unregister(struct fsi_master *master)
> {
> + fsi_master_unscan(master);
> put_device(master->dev);
> }
> EXPORT_SYMBOL_GPL(fsi_master_unregister);
> diff --git a/drivers/fsi/fsi-master.h b/drivers/fsi/fsi-master.h
> index 56aad0e..454af2b 100644
> --- a/drivers/fsi/fsi-master.h
> +++ b/drivers/fsi/fsi-master.h
> @@ -20,6 +20,8 @@
> #include <linux/device.h>
>
> struct fsi_master {
> + struct list_head my_slaves;
> + bool slave_list;
> struct device *dev;
> int idx;
> int n_links;
> diff --git a/include/linux/fsi.h b/include/linux/fsi.h
> index 66bce48..924502b 100644
> --- a/include/linux/fsi.h
> +++ b/include/linux/fsi.h
> @@ -18,6 +18,7 @@
> #include <linux/device.h>
>
> struct fsi_device {
> + struct list_head link; /* for slave's list */
Can't you use the device list on the bus instead? Putting a device on
multiple lists gets tricky very quickly :(
thanks,
greg k-h
^ permalink raw reply
* [Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k
From: Alexandre Courbot @ 2016-12-07 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKb7UvgW331K53x3wub5o+6LOqeLN5PqgiiJG6WXi+WJDVDzDg@mail.gmail.com>
On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> That's right -- nouveau currently requires 4k page sizes to work. This is a
> software limitation, not a hardware one though.
Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>
>
> On Dec 1, 2016 5:13 PM, "Jeremy Linton" <jeremy.linton@arm.com> wrote:
>
> Hi,
>
> I placed a 9600GT in a softiron 3k running fedora 25, and the nouveau driver
> failed to claim the device with :
>
> [drm] Initialized
> nouveau 0000:01:00.0: NVIDIA G94 (094100a1)
> nouveau 0000:01:00.0: bios: version 62.94.0d.00.04
> nouveau: probe of 0000:01:00.0 failed with error -22
>
> Which with a little bit of debugging seems to be a failure in:
>
> [77216.692605] [<ffff000001404120>] ttm_bo_validate+0xb0/0x1e8 [ttm]
> [77216.698697] [<ffff0000014045ac>] ttm_bo_init+0x354/0x410 [ttm]
> [77216.704706] [<ffff0000019d7bd0>] nouveau_bo_new+0x1f4/0x314 [nouveau]
> [77216.711308] [<ffff0000019e4620>] nv50_display_create+0x10c/0xa1c
> [nouveau]
> [77216.718340] [<ffff0000019df898>] nouveau_display_create+0x50c/0x59c
> [nouveau]
> [77216.725632] [<ffff0000019d3e24>] nouveau_drm_load+0x22c/0x8c0 [nouveau]
> [77216.732286] [<ffff00000137a1a0>] drm_dev_register+0xc0/0xf0 [drm]
> [77216.738409] [<ffff00000137b8a4>] drm_get_pci_dev+0xbc/0x188 [drm]
> [77216.744663] [<ffff0000019d35e8>] nouveau_drm_probe+0x180/0x208 [nouveau]
> [77216.751354] [<ffff0000084c30dc>] local_pci_probe+0x50/0xb4
> [77216.756827] [<ffff0000084c3e40>] pci_device_probe+0xf8/0x148
> [77216.762474] [<ffff0000085b6a10>] driver_probe_device+0x284/0x420
> [77216.768467] [<ffff0000085b6ccc>] __driver_attach+0x120/0x124
> [77216.774115] [<ffff0000085b446c>] bus_for_each_dev+0x6c/0xac
> [77216.779673] [<ffff0000085b6204>] driver_attach+0x2c/0x34
> [77216.784972] [<ffff0000085b5cb4>] bus_add_driver+0x244/0x2b0
> [77216.790531] [<ffff0000085b78e4>] driver_register+0x68/0xfc
> [77216.796004] [<ffff0000084c29a8>] __pci_register_driver+0x60/0x6c
> [77216.802047] [<ffff00000137bcb8>] drm_pci_init+0x108/0x138 [drm]
> [77216.808146] [<ffff000001530158>] nouveau_drm_init+0x158/0x10000 [nouveau]
> [77216.814922] [<ffff0000080831a8>] do_one_initcall+0x44/0x128
> [77216.820483] [<ffff0000081cad6c>] do_init_module+0x68/0x1e0
> [77216.825957] [<ffff000008150d84>] load_module+0xfac/0x12bc
> [77216.831343] [<ffff00000815132c>] SyS_finit_module+0xe4/0xf0
> [77216.836902] [<ffff000008082b70>] el0_svc_naked+0x24/0x28
>
> By default fedora is using a 64k page kernel, switching to a mainline
> 4.9-rc7 kernel using the same configuration the same problem exists (there
> are a couple others, mentioned briefly in the defect). Changing the mainline
> kernel from 64k to 4k pages corrects the problem and a terminal display can
> be seen.
>
> The fedora defect is:
> https://bugzilla.redhat.com/show_bug.cgi?id=1400623
>
>
> Thanks,
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Pavel Machek @ 2016-12-07 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2eefdb8f-7e87-6009-6e50-c536d4b95dd6@synopsys.com>
Hi!
> > Thanks!
>
> Regarding this subject, I am thinking of making the following adaption:
>
> a) delete ethernet/synopsys
> b) rename ethernet/stmicro/stmmac to ethernet/synopsys
>
> and send you a patch for you to evaluate. Both agree with the approach?
> To have a new work base would be important, because I will add to the "new"
> structure some missing QoS features like Multichannel support, CBS
> and later TSN.
Rename should be the easy part. Please do that last.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/ec5e4ab2/attachment-0001.sig>
^ 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