* Re: [PATCH 1/1] arm/module: maximum utilization of module area.
From: Vaneet Narang @ 2016-12-12 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161206091317epcas3p3702de092ecce4ac079b27180dd48c744@epcas3p3.samsung.com>
Hi Ard,
>> +#ifndef CONFIG_THUMB2_KERNEL
>> +#define MODULES_START ALIGN((unsigned long)_etext - SZ_32M, PAGE_SIZE)
>
>On a multi_v7_defconfig kernel, the text size is >8 MB, which means
>you are only adding ~7 MB to the module area, while consuming 16 MB of
>additional address space.
I am not sure if 16MB virtual address space will make any difference on embedded
systems where physical memory is already less than virtual address space.
if required address space wastage can be reduced by keeping TASK_SIZE as
PAGE_OFFSET - 24MB like below
#define MODULES_VADDR (PAGE_OFFSET - SZ_24M)
#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_24M))
> Given that 20 MB modules are very uncommon,
Size of all modules can be 20MB, this seems to be normal scenario.
>I think it is better to enable CONFIG_ARM_MODULE_PLTS instead. That
CONFIG_ARM_MODULE_PLTS has function call overhead as it refers PLT table
while calling kernel functions. Also size of modules will also gets increased a bit.
So using short calls from modules to kernel will be faster.
These changes trying to utilize best available space for kernel modules for
making short calls.
So CONFIG_ARM_MODULE_PLTS is not required when modules
can be accomdated within 20MB.
>way, there is no need to update these defaults for everyone.
>
>> +#else
>> +#define MODULES_START MODULES_VADDR
Thanks & Regards,
Vaneet Narang
^ permalink raw reply
* [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2016-12-12 10:18 UTC (permalink / raw)
To: linux-arm-kernel
The Amlogic Meson GXBB secure monitor uses part of the memory space, this
patch adds these reserved zones and redefines the usable memory range for
each boards.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 +++++++++++++++++++++
.../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
.../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
.../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
.../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
.../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
.../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
11 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 7a078be..ac40b2d 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -56,7 +56,7 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio_boot {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..e085588 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,27 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secos: secos {
+ reg = <0x0 0x05300000 0x0 0x2000000>;
+ no-map;
+ };
+
+ pstore: pstore {
+ reg = <0x0 0x07300000 0x0 0x100000>;
+ no-map;
+ };
+
+ secmon: secmon {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 9696820..25b8832 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -62,7 +62,7 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ reg = <0x0 0x1000000 0x0 0x3f000000>;
};
leds {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 238fbea..839c66a 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -61,7 +61,7 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
usb_otg_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 203be28..9a39518 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -55,7 +55,7 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ reg = <0x0 0x1000000 0x0 0x3f000000>;
};
usb_pwr: regulator-usb-pwrs {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
index 62fb496..287a4c7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
@@ -50,6 +50,6 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
index 9a9663a..8bdbbe2 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
@@ -50,6 +50,6 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x40000000>;
+ reg = <0x0 0x1000000 0x0 0x3f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
index 2fe167b..2d85295 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
@@ -50,6 +50,6 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
index e99101a..4ec2bbb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
@@ -60,7 +60,7 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_card: gpio-regulator {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
index 9639f01..b8b5b74 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
@@ -59,7 +59,7 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index f859d75..1544747 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -62,7 +62,7 @@
memory at 0 {
device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
+ reg = <0x0 0x1000000 0x0 0x7f000000>;
};
vddio_boot: regulator-vddio-boot {
--
2.7.0
^ permalink raw reply related
* [PATCH 3/8] rtc: add STM32 RTC driver
From: Amelie DELAUNAY @ 2016-12-12 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc5c308d-472a-bf05-89b8-6d813fb5321d@st.com>
Hi,
Thanks for the review.
On 12/07/2016 08:08 PM, Alexandre Belloni wrote:
> Hi,
>
> It seems mostly fine.
>
> On 02/12/2016 at 15:09:56 +0100, Amelie Delaunay wrote :
>> This patch adds support for the STM32 RTC.
>>
>> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
>> ---
>> drivers/rtc/Kconfig | 10 +
>> drivers/rtc/Makefile | 1 +
>> drivers/rtc/rtc-stm32.c | 777 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 788 insertions(+)
>> create mode 100644 drivers/rtc/rtc-stm32.c
>>
>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>> index e859d14..dd8b218 100644
>> --- a/drivers/rtc/Kconfig
>> +++ b/drivers/rtc/Kconfig
>> @@ -1706,6 +1706,16 @@ config RTC_DRV_PIC32
>> This driver can also be built as a module. If so, the module
>> will be called rtc-pic32
>>
>> +config RTC_DRV_STM32
>> + tristate "STM32 On-Chip RTC"
>> + depends on ARCH_STM32
>
> Can you add COMPILE_TEST? Looking at it, nothing seemed to be
> architecture specific and this nicely increases compile test coverage.
>
> It should also probably select REGMAP_MMIO.
>
Ok.
>> diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
>> new file mode 100644
>> index 0000000..9e710ff
>> --- /dev/null
>> +++ b/drivers/rtc/rtc-stm32.c
>> @@ -0,0 +1,777 @@
>> +/*
>> + * Copyright (C) Amelie Delaunay 2015
>> + * Author: Amelie Delaunay <adelaunay.stm32@gmail.com>
>
> This differs from your SoB. I don't really care but it seems odd.
>
Yes, I've already changed it in my upcoming V2!
>> + * License terms: GNU General Public License (GPL), version 2
>> + */
>> +
>> +#include <linux/bcd.h>
>> +#include <linux/clk.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/ioport.h>
>> +#include <linux/kernel.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/rtc.h>
>> +#include <linux/spinlock.h>
>> +
>
> I have the feeling that some of those headers are not necessary maybe
> some cleanup should be done.
>
Ok I'll have a look.
>> +static struct regmap *dbp;
>> +
>> +struct stm32_rtc {
>> + struct rtc_device *rtc_dev;
>> + void __iomem *base;
>> + struct clk *pclk;
>> + struct clk *ck_rtc;
>> + unsigned int clksrc;
>> + spinlock_t lock; /* Protects registers accesses */
>
> That comment makes checkpatch happy but is not super useful :) Anyway...
>
Lack of inspiration :)
>> +static irqreturn_t stm32_rtc_alarm_irq(int irq, void *dev_id)
>> +{
>
> ...can you make that one a threaded IRQ? If that's the case, just take
> the rtc_device mutex here and remove the spinlock. All the other
> function are already protected.
>
Ok I'll study this point.
>> +static int stm32_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
>> +{
>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>> + struct rtc_time *tm = &alrm->time;
>> + unsigned int alrmar, cr, isr;
>> + unsigned long irqflags;
>> +
>> + spin_lock_irqsave(&rtc->lock, irqflags);
>> +
>> + alrmar = stm32_rtc_readl(rtc, STM32_RTC_ALRMAR);
>> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
>> + isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
>> +
>> + spin_unlock_irqrestore(&rtc->lock, irqflags);
>> +
>> + if (alrmar & STM32_RTC_ALRMXR_DATE_MASK) {
>> + /*
>> + * Date/day don't care in Alarm comparison so alarm triggers
>
> I guess you meant "doesn't matter" (that is also valid for the other
> usages of "don't care".
>
>> + * every day
>> + */
>> + tm->tm_mday = -1;
>> + tm->tm_wday = -1;
>> + } else {
>> + if (alrmar & STM32_RTC_ALRMXR_WDSEL) {
>> + /* Alarm is set to a day of week */
>> + tm->tm_mday = -1;
>> + tm->tm_wday = (alrmar & STM32_RTC_ALRMXR_WDAY) >>
>> + STM32_RTC_ALRMXR_WDAY_SHIFT;
>> + tm->tm_wday %= 7;
>> + } else {
>> + /* Alarm is set to a day of month */
>> + tm->tm_wday = -1;
>> + tm->tm_mday = (alrmar & STM32_RTC_ALRMXR_DATE) >>
>> + STM32_RTC_ALRMXR_DATE_SHIFT;
>> + }
>> + }
>> +
>> + if (alrmar & STM32_RTC_ALRMXR_HOUR_MASK) {
>> + /* Hours don't care in Alarm comparison */
>> + tm->tm_hour = -1;
>> + } else {
>> + tm->tm_hour = (alrmar & STM32_RTC_ALRMXR_HOUR) >>
>> + STM32_RTC_ALRMXR_HOUR_SHIFT;
>> + if (alrmar & STM32_RTC_ALRMXR_PM)
>> + tm->tm_hour += 12;
>> + }
>> +
>> + if (alrmar & STM32_RTC_ALRMXR_MIN_MASK) {
>> + /* Minutes don't care in Alarm comparison */
>> + tm->tm_min = -1;
>> + } else {
>> + tm->tm_min = (alrmar & STM32_RTC_ALRMXR_MIN) >>
>> + STM32_RTC_ALRMXR_MIN_SHIFT;
>> + }
>> +
>> + if (alrmar & STM32_RTC_ALRMXR_SEC_MASK) {
>> + /* Seconds don't care in Alarm comparison */
>> + tm->tm_sec = -1;
>> + } else {
>> + tm->tm_sec = (alrmar & STM32_RTC_ALRMXR_SEC) >>
>> + STM32_RTC_ALRMXR_SEC_SHIFT;
>> + }
>> +
> I'm not sure those multiple cases (including STM32_RTC_ALRMXR_WDSEL) are
> useful because the core will always give you valid tm_sec, tm_min,
> tm_hour and tm_mday (it is actually checked up to four times!) so you
> should always end up in the same configuration.
>
> If you think some code other than Linux may set an alarm (e.g. the
> bootloader) then you may keep them in read_alarm but at least you can
> remove them from set_alarm.
>
>
Ok I'll clean this part.
>> +static int stm32_rtc_probe(struct platform_device *pdev)
>> +{
>> + struct stm32_rtc *rtc;
>> + struct resource *res;
>> + int ret;
>> +
>> + rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
>> + if (!rtc)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + rtc->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(rtc->base))
>> + return PTR_ERR(rtc->base);
>> +
>> + dbp = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "st,syscfg");
>> + if (IS_ERR(dbp)) {
>> + dev_err(&pdev->dev, "no st,syscfg\n");
>> + return PTR_ERR(dbp);
>> + }
>> +
>> + spin_lock_init(&rtc->lock);
>> +
>> + rtc->ck_rtc = devm_clk_get(&pdev->dev, "ck_rtc");
>> + if (IS_ERR(rtc->ck_rtc)) {
>> + dev_err(&pdev->dev, "no ck_rtc clock");
>> + return PTR_ERR(rtc->ck_rtc);
>> + }
>> +
>> + ret = clk_prepare_enable(rtc->ck_rtc);
>> + if (ret)
>> + return ret;
>> +
>> + if (dbp)
>> + regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, PWR_CR_DBP);
>> +
>> + ret = stm32_rtc_init(pdev, rtc);
>> + if (ret)
>> + goto err;
>> +
>
> Isn't that RTC backuped in some way, do you really need to reinit it
> each time the system reboots?
>
>
Indeed, RTC is backuped. I need to reinit it only if RTC parent clock
has changed.
Best Regards,
Amelie
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Andrei.Pistirica at microchip.com @ 2016-12-12 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BN3PR07MB2516992DEE883FAD6DC3ED08C9870@BN3PR07MB2516.namprd07.prod.outlook.com>
> -----Original Message-----
> From: Rafal Ozieblo [mailto:rafalo at cadence.com]
> Sent: Friday, December 09, 2016 11:20 AM
> To: Andrei Pistirica - M16132; richardcochran at gmail.com
> Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; davem at davemloft.net;
> nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
> harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
> anirudh at xilinx.com; boris.brezillon at free-electrons.com;
> alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com
> Subject: RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence
> GEM.
>
> -----Original Message-----
> > From: Andrei.Pistirica at microchip.com
> > [mailto:Andrei.Pistirica at microchip.com]
> > Sent: 8 grudnia 2016 15:42
> > To: richardcochran at gmail.com
> > Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org;
> > linux-arm-kernel at lists.infradead.org; davem at davemloft.net;
> > nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
> > harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
> > anirudh at xilinx.com; boris.brezillon at free-electrons.com;
> > alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com; Rafal
> > Ozieblo
> > Subject: RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
> Cadence GEM.
> >
> >
> >
> > > -----Original Message-----
> > > From: Richard Cochran [mailto:richardcochran at gmail.com]
> > > Sent: Wednesday, December 07, 2016 11:04 PM
> > > To: Andrei Pistirica - M16132
> > > Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> > > kernel at lists.infradead.org; davem at davemloft.net;
> > > nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
> > > harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
> > > anirudh at xilinx.com; boris.brezillon at free-electrons.com;
> > > alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com;
> > > rafalo at cadence.com
> > > Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
> > > Cadence GEM.
> > >
> > > On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
> > > > > +static s32 gem_ptp_max_adj(unsigned int f_nom) {
> > > > > + u64 adj;
> > > > > +
> > > > > + /* The 48 bits of seconds for the GEM overflows every:
> > > > > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
> > > > > + * thus the maximum adjust frequency must not overflow
> > > > > + CNS
> > > register:
> > > > > + *
> > > > > + * addend = 10^9/nominal_freq
> > > > > + * adj_max = +/- addend*ppb_max/10^9
> > > > > + * max_ppb = (2^8-1)*nominal_freq-10^9
> > > > > + */
> > > > > + adj = f_nom;
> > > > > + adj *= 0xffff;
> > > > > + adj -= 1000000000ULL;
> > > >
> > > > What is this computation, and how does it relate to the comment?
> >
> > I considered the following simple equation: increment value at nominal
> frequency (which is 10^9/nominal frequency nsecs) + the maximum drift
> value (nsecs) <= maximum increment value@nominal frequency (which is
> 8bit:0xffff).
> > If maximum drift is written as function of nominal frequency and
> maximum ppb, then the equation above yields that the maximum ppb is:
> (2^8 - 1) *nominal_frequency - 10^9. The equation is also simplified by the
> fact that the drift is written as ppm + 16bit_fractions and the increment
> value is written as nsec + 16bit_fractions.
> >
> > Rafal said that this value is hardcoded: 0x64E6, while Harini said:
> 250000000.
>
> To clarify a little bit. In my reference code this value (0x64E6) was taken
> from our legacy code. It was used for testing only. I know it should be
> change to something more accurate. This is the reason why I asked how did
> you count it (250000000). According to our calculations this value depends
> on actual set period (incr_ns and incr_sub_ns) and min and max value we
> can set. The calculation were a little bit intricate, so we decided to leave it
> as it was.
>
> >
> > I need to dig into this...
> >
> > >
> > > I am not sure what you meant, but it sounds like you are on the wrong
> track.
> > > Let me explain...
> >
> > Thanks.
> >
> > >
> > > The max_adj has nothing at all to do with the width of the time register.
> > > Rather, it should reflect the maximum possible change in the tuning
> word.
> > >
> > > For example, with a nominal 8 ns period, the tuning word is 0x80000.
> > > Looking at running the clock more slowly, the slowest possible word
> > > is 0x00001, meaning a difference of 0x7FFFF. This implies an
> > > adjustment of
> > > 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can
> > > already have 0x100000, twice as fast, or just under 2 billion ppb.
> > >
> > > You should consider the extreme cases to determine the most limited
> > > (smallest) max_adj value:
> > >
> > > Case 1 - high frequency
> > > ~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > With a nominal 1 ns period, we have the nominal tuning word 0x10000.
> > > The smallest is 0x1 for a difference of 0xFFFF. This corresponds to
> > > an adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
> > >
> > > Case 2 - low frequency
> > > ~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > With a nominal 255 ns period, the nominal word is 0xFF0000, the
> > > largest 0xFFFFFF, and the difference is 0xFFFF. This corresponds to
> > > and adjustment of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
> > >
> > > Since 3921508 ppb is a huge adjustment, you can simply use that as a
> > > safe maximum, ignoring the actual input clock.
> > >
> > > Thanks,
> > > Richard
> > >
> > >
> >
> > Regards,
> > Andrei
> >
>
> Best regards,
> Rafal Ozieblo | Firmware System Engineer,
> phone nbr.: +48 32 5085469
> www.cadence.com
Hi Guys,
Based on Richard's input, this is what I want to do for our platforms:
struct macb_ptp_info {
void (*ptp_init)(struct net_device *ndev);
void (*ptp_remove)(struct net_device *ndev);
+ s32 (*get_ptp_max_adj)(void);
unsigned int (*get_tsu_rate)(struct macb *bp);
int (*get_ts_info)(struct net_device *dev,
struct ethtool_ts_info *info);
int (*get_hwtst)(struct net_device *netdev,
struct ifreq *ifr);
int (*set_hwtst)(struct net_device *netdev,
struct ifreq *ifr, int cmd);
};
+static s32 gem_get_ptp_max_adj(void)
+{
+ return 3921508;
+}
static struct macb_ptp_info gem_ptp_info = {
.ptp_init = gem_ptp_init,
.ptp_remove = gem_ptp_remove,
+ .get_ptp_max_adj = gem_get_ptp_max_adj,
.get_tsu_rate = gem_get_tsu_rate,
.get_ts_info = gem_get_ts_info,
.get_hwtst = gem_get_hwtst,
.set_hwtst = gem_set_hwtst,
};
[...]
void gem_ptp_init(struct net_device *ndev)
{
[...]
/* nominal frequency and maximum adjustment in ppb */
bp->tsu_rate = bp->ptp_info->get_tsu_rate(bp);
+ bp->ptp_caps.max_adj = bp->ptp_info->get_ptp_max_adj();
[...]
}
Richard, are you agree with this?
Harini, you can fill the callback with the value for your platform. Tell me if you are ok with function's signature.
Regards,
Andrei
^ permalink raw reply
* imx-sdma UART series failed for i.MX51
From: Alexander Shiyan @ 2016-12-12 10:23 UTC (permalink / raw)
To: linux-arm-kernel
Hello all.
Upgrading the kernel from version 4.7 (to latest) has resulted in inoperable for i.MX51 DMA.
It appears on sound playback (fsl_ssi with DMA). The sound is intermittent and a feeling that
the each sound channel eats a part of buffer from another channel.
Git-bisect found a first bad commit "first bad commit: [5881826ded79cf3c3314ee2d84c3bfa94e111b42]
dmaengine: imx-sdma - update the residue calculation for cyclic channels" and after revert this commit,
the problem has gone.
Additionally, I had to disable DMA for the UART, because the revert the patch above led to the
inoperability of the UART receiving part, although even before the series of all UART-SDMA
patches still functioned normally (with imx6q check commented out).
Any ideas?
Thanks.
shc at shc /home/ARM/linux $ git bisect log
git bisect start
# good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
git bisect good c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
# bad: [2e972325da7a2984b9045844d4185f4406e7a4b0] Revert "USB debug"
git bisect bad 2e972325da7a2984b9045844d4185f4406e7a4b0
# bad: [41844e36206be90cd4d962ea49b0abc3612a99d0] Merge tag 'staging-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad 41844e36206be90cd4d962ea49b0abc3612a99d0
# bad: [d268dbe76a53d72cc41316eb59e7968db60e77ad] Merge tag 'pinctrl-v4.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
git bisect bad d268dbe76a53d72cc41316eb59e7968db60e77ad
# bad: [02bafd96f3a5d8e610b19033ffec55b92459aaae] Merge tag 'docs-4.9' of git://git.lwn.net/linux
git bisect bad 02bafd96f3a5d8e610b19033ffec55b92459aaae
# good: [9929780e86854833e649b39b290b5fe921eb1701] Merge tag 'driver-core-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
git bisect good 9929780e86854833e649b39b290b5fe921eb1701
# bad: [77b0a4aa0732f1856aef85b8db085864e5971a14] Merge tag 'hwmon-for-linus-v4.9' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
git bisect bad 77b0a4aa0732f1856aef85b8db085864e5971a14
# good: [f21ca2c9999872da113a1fc70abb527129b72af3] Merge tag 'usb-ci-v4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-testing
git bisect good f21ca2c9999872da113a1fc70abb527129b72af3
# bad: [e6dce825fba05f447bd22c865e27233182ab3d79] Merge tag 'tty-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect bad e6dce825fba05f447bd22c865e27233182ab3d79
# bad: [5d7519dfc963ec8b6a10a51356840580fc005a1e] serial: mxs-auart: Disable clock on error path
git bisect bad 5d7519dfc963ec8b6a10a51356840580fc005a1e
# good: [a13e19cf3dc1080cf8a3a174cefd9199610faed7] serial: 8250_lpss: split LPSS driver to separate module
git bisect good a13e19cf3dc1080cf8a3a174cefd9199610faed7
# skip: [5d9b9530e36bca7cd8306c5097623692e1134c39] tty: serial: jsm_tty: constify uart_ops structures
git bisect skip 5d9b9530e36bca7cd8306c5097623692e1134c39
# skip: [fecdef932b0093b4a7e1ae88b1dbd63eb74ecc34] serial: 8250_lpss: enable DMA on Intel Quark UART
git bisect skip fecdef932b0093b4a7e1ae88b1dbd63eb74ecc34
# skip: [5c7dcdb60d88e4d68bc59eff7c6a5c418808552b] tty/serial: at91: constify uart_ops structures
git bisect skip 5c7dcdb60d88e4d68bc59eff7c6a5c418808552b
# bad: [b53761e36a509609e91a797fa63648ec43aecc13] Merge 4.8-rc5 into tty-next
git bisect bad b53761e36a509609e91a797fa63648ec43aecc13
# skip: [03bd797f33ddbe1d14de7abc70a9dd21b2a12d3f] serial: altera: constify uart_ops structures
git bisect skip 03bd797f33ddbe1d14de7abc70a9dd21b2a12d3f
# skip: [e06b6b854163a7f9931d6e0d859b9378a23fe7af] serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 SoC
git bisect skip e06b6b854163a7f9931d6e0d859b9378a23fe7af
# skip: [eeb8bc1a92751557d3eea69d54e1b422569e7238] serial: st-asc: constify uart_ops structures
git bisect skip eeb8bc1a92751557d3eea69d54e1b422569e7238
# good: [15f30f513111528c5b0c6185b2bfb7b1a58a6499] dmaengine: imx-sdma - reduce transfer latency for DMA cyclic clients
git bisect good 15f30f513111528c5b0c6185b2bfb7b1a58a6499
# bad: [069a47e5adfd5a1544c3c6d87a36889a691ea156] tty: serial: constify uart_ops structures
git bisect bad 069a47e5adfd5a1544c3c6d87a36889a691ea156
# bad: [8232884e2dfa606edef66b2c889d4d2ebe042cb8] serial/arc: constify uart_ops structures
git bisect bad 8232884e2dfa606edef66b2c889d4d2ebe042cb8
# bad: [41d98b5da92f8b7bd11885e7c4797197b5f3e2c3] serial: imx-serial - update RX error counters when DMA is used
git bisect bad 41d98b5da92f8b7bd11885e7c4797197b5f3e2c3
# bad: [5881826ded79cf3c3314ee2d84c3bfa94e111b42] dmaengine: imx-sdma - update the residue calculation for cyclic channels
git bisect bad 5881826ded79cf3c3314ee2d84c3bfa94e111b42
# first bad commit: [5881826ded79cf3c3314ee2d84c3bfa94e111b42] dmaengine: imx-sdma - update the residue calculation for cyclic channels
---
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Russell King - ARM Linux @ 2016-12-12 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481012975-44478-1-git-send-email-maninder1.s@samsung.com>
On Tue, Dec 06, 2016 at 01:59:35PM +0530, Maninder Singh wrote:
> This patch defines new macro MODULE_START to ensure kernel text
> and module remains within 32 MB of address range.
>
> Tried this patch by inserting 20 MB size module on 4.1 kernel:-
>
> Earlier:-
> ==========
> sh# insmod size.ko
> ....
> insmod: ERROR: could not insert module size.ko: Cannot allocate memory
> sh#
>
> With this patch
> ===============
> sh# insmod size.ko
> ...
> sh# lsmod
> Module Size Used by
> size 20972425 0
>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> Reviewed-by: Ajeet Yadav <ajeet.y@samsung.com>
A PC24 relocation has a range of +/-32MB. This means that where-ever
the module is placed, it must be capable of reaching any function
within the kernel text, which may itself be quite large (eg, 8MB, or
possibly larger). The module area exists to allow modules to be
located in an area where PC24 relocations are able to reach all of the
kernel text on sensibly configured kernels, thereby allowing for
optimal performance.
If you wish to load large modules, then enable ARM_MODULE_PLTS, which
will use the less efficient PLT method (which is basically an indirect
function call) for relocations that PC24 can't handle, and will allow
the module to be loaded into the vmalloc area.
Growing the module area so that smaller modules also get penalised by
the PLT indirection is not sane.
So, I'm afraid this change is not acceptable.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v7 1/2] provide lock-less versions of clk_{enable|disable}
From: Alexandre Bailon @ 2016-12-12 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e548f7cf-a1d5-0bc2-1095-db8464a1bcc4@ti.com>
On 12/12/2016 10:02 AM, Sekhar Nori wrote:
> Hi Uwe,
>
> On Saturday 10 December 2016 12:24 AM, Uwe Kleine-K?nig wrote:
>> Hello,
>>
>> On Fri, Dec 09, 2016 at 05:59:32PM +0100, Alexandre Bailon wrote:
>>> Rename __clk_{enable|disble} in davinci_clk_{enable|disable}.
>>> davinci_clk_{enable|disable} is a lock-less version of
>>> clk_{enable|disable}.
>>> This is useful to recursively enable clock without doing recursive call
>>> to clk_enable(), which would cause a recursive locking issue.
>>> The lock-less version could be used by example by the usb20 phy clock,
>>> that need to enable the usb20 clock before to start.
>>
>> I wouldn't call that lock-less. The difference is that the newly exposed
>> funcion requires the caller to already hold the lock. So maybe a better
>
> Right.
Is it enough to update the commit message or should I also update the
patch title?
If so, could you suggest one because I don't know how to describe it
shortly.
Thanks,
Alexandre
^ permalink raw reply
* [PATCH renesas/devel 10/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
From: Sergei Shtylyov @ 2016-12-12 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-11-git-send-email-horms+renesas@verge.net.au>
Hello!
On 12/12/2016 12:11 PM, Simon Horman wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
s/iii/iic/?
> DT for r8a7790 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7790 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH renesas/devel 11/13] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
From: Sergei Shtylyov @ 2016-12-12 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-12-git-send-email-horms+renesas@verge.net.au>
Hello.
On 12/12/2016 12:11 PM, Simon Horman wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
s/iii/iic/?
> DT for r8a7791 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH renesas/devel 12/13] ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes
From: Sergei Shtylyov @ 2016-12-12 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-13-git-send-email-horms+renesas@verge.net.au>
On 12/12/2016 12:11 PM, Simon Horman wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
s/iii/iic/?
> DT for r8a7793 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7793 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH renesas/devel 13/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
From: Sergei Shtylyov @ 2016-12-12 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-14-git-send-email-horms+renesas@verge.net.au>
On 12/12/2016 12:11 PM, Simon Horman wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
s/iii/iic/?
> DT for r8a7794 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
MBR, Sergei
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Harini Katakam @ 2016-12-12 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07C910AB6AC6C345A093D5A08F5AF568CB74D84D@CHN-SV-EXMX03.mchp-main.com>
Hi Andrei,
On Mon, Dec 12, 2016 at 3:52 PM, <Andrei.Pistirica@microchip.com> wrote:
>
>
>> -----Original Message-----
>> From: Rafal Ozieblo [mailto:rafalo at cadence.com]
>> Sent: Friday, December 09, 2016 11:20 AM
>> To: Andrei Pistirica - M16132; richardcochran at gmail.com
>> Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org; davem at davemloft.net;
>> nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
>> harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
>> anirudh at xilinx.com; boris.brezillon at free-electrons.com;
>> alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com
>> Subject: RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence
>> GEM.
>>
>> -----Original Message-----
>> > From: Andrei.Pistirica at microchip.com
>> > [mailto:Andrei.Pistirica at microchip.com]
>> > Sent: 8 grudnia 2016 15:42
>> > To: richardcochran at gmail.com
>> > Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org;
>> > linux-arm-kernel at lists.infradead.org; davem at davemloft.net;
>> > nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
>> > harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
>> > anirudh at xilinx.com; boris.brezillon at free-electrons.com;
>> > alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com; Rafal
>> > Ozieblo
>> > Subject: RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
>> Cadence GEM.
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: Richard Cochran [mailto:richardcochran at gmail.com]
>> > > Sent: Wednesday, December 07, 2016 11:04 PM
>> > > To: Andrei Pistirica - M16132
>> > > Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
>> > > kernel at lists.infradead.org; davem at davemloft.net;
>> > > nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
>> > > harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
>> > > anirudh at xilinx.com; boris.brezillon at free-electrons.com;
>> > > alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com;
>> > > rafalo at cadence.com
>> > > Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
>> > > Cadence GEM.
>> > >
>> > > On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
>> > > > > +static s32 gem_ptp_max_adj(unsigned int f_nom) {
>> > > > > + u64 adj;
>> > > > > +
>> > > > > + /* The 48 bits of seconds for the GEM overflows every:
>> > > > > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
>> > > > > + * thus the maximum adjust frequency must not overflow
>> > > > > + CNS
>> > > register:
>> > > > > + *
>> > > > > + * addend = 10^9/nominal_freq
>> > > > > + * adj_max = +/- addend*ppb_max/10^9
>> > > > > + * max_ppb = (2^8-1)*nominal_freq-10^9
>> > > > > + */
>> > > > > + adj = f_nom;
>> > > > > + adj *= 0xffff;
>> > > > > + adj -= 1000000000ULL;
>> > > >
>> > > > What is this computation, and how does it relate to the comment?
>> >
>> > I considered the following simple equation: increment value at nominal
>> frequency (which is 10^9/nominal frequency nsecs) + the maximum drift
>> value (nsecs) <= maximum increment value@nominal frequency (which is
>> 8bit:0xffff).
>> > If maximum drift is written as function of nominal frequency and
>> maximum ppb, then the equation above yields that the maximum ppb is:
>> (2^8 - 1) *nominal_frequency - 10^9. The equation is also simplified by the
>> fact that the drift is written as ppm + 16bit_fractions and the increment
>> value is written as nsec + 16bit_fractions.
>> >
>> > Rafal said that this value is hardcoded: 0x64E6, while Harini said:
>> 250000000.
>>
>> To clarify a little bit. In my reference code this value (0x64E6) was taken
>> from our legacy code. It was used for testing only. I know it should be
>> change to something more accurate. This is the reason why I asked how did
>> you count it (250000000). According to our calculations this value depends
>> on actual set period (incr_ns and incr_sub_ns) and min and max value we
>> can set. The calculation were a little bit intricate, so we decided to leave it
>> as it was.
>>
>> >
>> > I need to dig into this...
>> >
>> > >
>> > > I am not sure what you meant, but it sounds like you are on the wrong
>> track.
>> > > Let me explain...
>> >
>> > Thanks.
>> >
>> > >
>> > > The max_adj has nothing at all to do with the width of the time register.
>> > > Rather, it should reflect the maximum possible change in the tuning
>> word.
>> > >
>> > > For example, with a nominal 8 ns period, the tuning word is 0x80000.
>> > > Looking at running the clock more slowly, the slowest possible word
>> > > is 0x00001, meaning a difference of 0x7FFFF. This implies an
>> > > adjustment of
>> > > 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can
>> > > already have 0x100000, twice as fast, or just under 2 billion ppb.
>> > >
>> > > You should consider the extreme cases to determine the most limited
>> > > (smallest) max_adj value:
>> > >
>> > > Case 1 - high frequency
>> > > ~~~~~~~~~~~~~~~~~~~~~~~
>> > >
>> > > With a nominal 1 ns period, we have the nominal tuning word 0x10000.
>> > > The smallest is 0x1 for a difference of 0xFFFF. This corresponds to
>> > > an adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
>> > >
>> > > Case 2 - low frequency
>> > > ~~~~~~~~~~~~~~~~~~~~~~
>> > >
>> > > With a nominal 255 ns period, the nominal word is 0xFF0000, the
>> > > largest 0xFFFFFF, and the difference is 0xFFFF. This corresponds to
>> > > and adjustment of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
>> > >
>> > > Since 3921508 ppb is a huge adjustment, you can simply use that as a
>> > > safe maximum, ignoring the actual input clock.
>> > >
>> > > Thanks,
>> > > Richard
>> > >
>> > >
>> >
>> > Regards,
>> > Andrei
>> >
>>
>> Best regards,
>> Rafal Ozieblo | Firmware System Engineer,
>> phone nbr.: +48 32 5085469
>> www.cadence.com
>
> Hi Guys,
>
> Based on Richard's input, this is what I want to do for our platforms:
>
> struct macb_ptp_info {
> void (*ptp_init)(struct net_device *ndev);
> void (*ptp_remove)(struct net_device *ndev);
> + s32 (*get_ptp_max_adj)(void);
> unsigned int (*get_tsu_rate)(struct macb *bp);
> int (*get_ts_info)(struct net_device *dev,
> struct ethtool_ts_info *info);
> int (*get_hwtst)(struct net_device *netdev,
> struct ifreq *ifr);
> int (*set_hwtst)(struct net_device *netdev,
> struct ifreq *ifr, int cmd);
> };
>
> +static s32 gem_get_ptp_max_adj(void)
> +{
> + return 3921508;
> +}
>
> static struct macb_ptp_info gem_ptp_info = {
> .ptp_init = gem_ptp_init,
> .ptp_remove = gem_ptp_remove,
> + .get_ptp_max_adj = gem_get_ptp_max_adj,
> .get_tsu_rate = gem_get_tsu_rate,
> .get_ts_info = gem_get_ts_info,
> .get_hwtst = gem_get_hwtst,
> .set_hwtst = gem_set_hwtst,
> };
>
> [...]
> void gem_ptp_init(struct net_device *ndev)
> {
> [...]
> /* nominal frequency and maximum adjustment in ppb */
> bp->tsu_rate = bp->ptp_info->get_tsu_rate(bp);
> + bp->ptp_caps.max_adj = bp->ptp_info->get_ptp_max_adj();
> [...]
> }
>
> Richard, are you agree with this?
>
> Harini, you can fill the callback with the value for your platform. Tell me if you are ok with function's signature.
>
Thanks, this works for me.
Regards,
Harini
^ permalink raw reply
* [PATCH v4] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Dave Martin @ 2016-12-12 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_VPA81H2-Kr_dyUWMmgqc_DevBYwr4adh+L2nBBqY5yA@mail.gmail.com>
On Fri, Dec 09, 2016 at 08:57:20PM +0000, Ard Biesheuvel wrote:
> On 9 December 2016 at 19:29, Dave Martin <Dave.Martin@arm.com> wrote:
> > On Fri, Dec 09, 2016 at 06:21:55PM +0000, Catalin Marinas wrote:
> >> On Fri, Dec 09, 2016 at 04:46:32PM +0000, Ard Biesheuvel wrote:
> >> > void kernel_neon_begin_partial(u32 num_regs)
> >> > {
> >> > - if (in_interrupt()) {
> >> > - struct fpsimd_partial_state *s = this_cpu_ptr(
> >> > - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> >> > + struct fpsimd_partial_state *s;
> >> > + int level;
> >> > +
> >> > + preempt_disable();
> >> > +
> >> > + level = this_cpu_inc_return(kernel_neon_nesting_level);
> >> > + BUG_ON(level > 3);
> >> > +
> >> > + if (level > 1) {
> >> > + s = this_cpu_ptr(nested_fpsimdstate);
> >> >
> >> > - BUG_ON(num_regs > 32);
> >> > - fpsimd_save_partial_state(s, roundup(num_regs, 2));
> >> > + WARN_ON_ONCE(num_regs > 32);
> >> > + num_regs = min(roundup(num_regs, 2), 32U);
> >> > +
> >> > + fpsimd_save_partial_state(&s[level - 2], num_regs);
> >> > } else {
> >> > /*
> >> > * Save the userland FPSIMD state if we have one and if we
> >> > @@ -241,7 +256,6 @@ void kernel_neon_begin_partial(u32 num_regs)
> >> > * that there is no longer userland FPSIMD state in the
> >> > * registers.
> >> > */
> >> > - preempt_disable();
> >> > if (current->mm &&
> >> > !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> >> > fpsimd_save_state(¤t->thread.fpsimd_state);
> >>
> >> I wonder whether we could actually do this saving and flag/level setting
> >> in reverse to simplify the races. Something like your previous patch but
> >> only set TIF_FOREIGN_FPSTATE after saving:
> >>
> >> level = this_cpu_read(kernel_neon_nesting_level);
> >> if (level > 0) {
> >> ...
> >> fpsimd_save_partial_state();
> >> } else {
> >> if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
> >> fpsimd_save_state();
> >> set_thread_flag(TIF_FOREIGN_FPSTATE);
> >> }
> >> this_cpu_inc(kernel_neon_nesting_level);
> >>
> >> There is a risk of extra saving if we get an interrupt after
> >> test_thread_flag() and before set_thread_flag() but I don't think this
> >> would corrupt any state, just writing things twice.
> >
> > I would worry that we can save two states over the same buffer and then
> > restore an uninitialised buffer in this case unless we are careful.
> > Because the level-dependent code is now misbracketed by the inc/dec,
> > a preempting call races with the outer call and use the same value.
> >
> > I guess we could do
> >
> > if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
> > fpsimd_save_state();
> > clear_thread_flag(TIF_FOREIGN_FPSTATE);
> >
> > at the start unconditionally, before the _inc_return().
> >
> > The task state may then get saved in the middle of being saved, but
> > as you say it shouldn't have changed in the meantime.
>
> It /will/ have changed in the meantime: when the interrupted context
> is resumed, it will happily proceed with saving the state where it
> left off, but now the register file contains whatever was left after
> the interrupt handler is done with the NEON.
Hmmm, true. The NEON regs will have been restored by kernel_neon_end()
in the inner context, but the extra SVE bits won't have been.
>
> > The nested
> > save code may then do a partial save of the same state on top of that
> > which could get restored at the inner kernel_neon_end() call.
> >
>
> I'm afraid the only way to deal with this correctly is to treat the
> whole sequence as a critical section, which means execute it with
> interrupts disabled.
Or we make the KERNEL_MODE_NEON code SVE-aware, which is where I started
off. In that case, we do SVE (partial) save/restore whenever
kernel_mode_neon() is called with live SVE state. The change here is
that would we consider that there is always live SVE state until the
fpsimd_save_state() actually finishes at the outer level. We may want
to delay setting of TIF_FOREIGN_FPSTATE for that purpose.
This means you do take an additional latency hit if you want to use NEON
in an interrupting context and there happens to be live SVE state. It's
a consequence of the architecture though -- I don't think there's any
way to get around it. We can still scale the cost by implementing
sve_save_partial_state() or something equivalent.
You original inc()+save() ... restore()+dec() seems sound enough if
viewed this way. Unless I'm missing something?
Cheers
---Dave
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Will Deacon @ 2016-12-12 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584E2F40.10904@codeaurora.org>
On Mon, Dec 12, 2016 at 10:31:52AM +0530, Srinivas Ramana wrote:
> On 12/06/2016 05:43 PM, Will Deacon wrote:
> >On Sun, Dec 04, 2016 at 02:06:23PM +0530, Srinivas Ramana wrote:
> >>On 12/02/2016 04:38 PM, Will Deacon wrote:
> >>>On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
> >>>>Extend the trace_clock to support the arch timer cycle
> >>>>counter so that we can get the monotonic cycle count
> >>>>in the traces. This will help in correlating the traces with the
> >>>>timestamps/events in other subsystems in the soc which share
> >>>>this common counter for driving their timers.
> >>>
> >>>I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
> >>>particular, the "perf" trace_clock hangs off sched_clock, which should
> >>>be backed by the architected counter anyway. What does the cycle counter in
> >>>isolation tell you, given that the frequency isn't architected?
> >>>
> >>>I think I'm missing something here.
> >>>
> >>
> >>Having cycle counter would help in the cases where we want to correlate the
> >>time with other subsystems which are outside cpu subsystem.
> >
> >Do you have an example of these subsystems? Can they be used to generate
> >trace data with mainline?
>
> Some of the subsystems i can list are Modem(on a mobilephone), GPU or video
> subsystem, or a DSP among others.
Oh, you're talking about hardware subsystems. That makes this slightly more
compelling, but I don't think you want the virtual counter here, since
I assume those other subsystems don't take into account CNTVOFF (and I
don't really see how they could, it being a per-cpu thing). So, if you
want to expose the *physical* counter as a trace clock, I think that's
justifiable.
> >>local_clock or even the perf track_clock uses sched_clock which gets
> >>suspended during system suspend. Yes, they are backed up by the
> >>architected counter but they ignore the cycles spent in suspend.i
> >
> >Does mono_raw solve this (also hangs off the architected counter and is
> >supported in the vdso)?
>
> Doesn't seem like. Any of the existing clock sources are designed not show
> the jump, when there is a suspend and resume. Even though they run out of
> architected counter they just cane give exact correlation with the counter.
> Furthermore, during the initial kernel boot, these just run out of jiffies
> clock source. They also not account for the time spent in boot loaders.
Hmm, there's a thing called CLOCK_BOOTTIME, but I don't think that helps
you when CNTVOFF comes into play.
> >>so, when comparing with monotonically increasing cycle counter, other
> >>clocks doesn't help. It seems X86 uses the TSC counter to help such cases.
> >
> >Does this mean we need a way to expose the frequency to userspace, too?
>
> Not really. The CNTFRQ_EL0 of timer subsystem holds the clock frequency of
> system timer and is available to EL0.
Experience shows that CNTFRQ_EL0 is often unreliable, and the frequency
can be overridden by the device-tree. There are also systems where the
counter stops ticking across suspend. Whilst both of these can be considered
"broken", I suspect we want runtime buy-in from the arch-timer driver
before registering this trace_clock.
Will
^ permalink raw reply
* [PATCH 1/1] Fixed checkpatch error to mmu.c
From: Ozgur Karatas @ 2016-12-12 10:46 UTC (permalink / raw)
To: linux-arm-kernel
Hello all,
I tested to mmu.c and I have fixed to some errors.
mmu.c:510: ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
arch/arm/kvm/mmu.c | 2 +-
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index a5265ed..a83cf47 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -507,7 +507,7 @@ void free_hyp_pgds(void)
unmap_hyp_range(hyp_pgd, hyp_idmap_start, PAGE_SIZE);
for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);
- for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
+ for (addr = VMALLOC_START; is_vmalloc_addr((void *)addr); addr += PGDIR_SIZE)
unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);
--
2.1.4
^ permalink raw reply related
* [PATCH 1/1] Fixed checkpatch error to mmu.c
From: Marc Zyngier @ 2016-12-12 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <962731481539605@web19g.yandex.ru>
Hi Ozgur,
On 12/12/16 10:46, Ozgur Karatas wrote:
> Hello all,
>
> I tested to mmu.c and I have fixed to some errors.
>
> mmu.c:510: ERROR: "(foo*)" should be "(foo *)"
>
> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
> ---
> arch/arm/kvm/mmu.c | 2 +-
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index a5265ed..a83cf47 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -507,7 +507,7 @@ void free_hyp_pgds(void)
> unmap_hyp_range(hyp_pgd, hyp_idmap_start, PAGE_SIZE);
> for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
> unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);
> - for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
> + for (addr = VMALLOC_START; is_vmalloc_addr((void *)addr); addr += PGDIR_SIZE)
> unmap_hyp_range(hyp_pgd, kern_hyp_va(addr), PGDIR_SIZE);
>
I'm not overly sympathetic to pure checkpatch patches. If you find
something that is a functional bug in that file, I'll consider it as
part of a series. But on its own, this is just noise.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* RE: Re: [PATCH 1/1] arm/module: maximum utilization of module area.
From: Vaneet Narang @ 2016-12-12 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161212102403epcas4p2e039072e2acdc3d20c1b8ac86e823375@epcas4p2.samsung.com>
Hi,
>A PC24 relocation has a range of +/-32MB. This means that where-ever
>the module is placed, it must be capable of reaching any function
>within the kernel text, which may itself be quite large (eg, 8MB, or
>possibly larger). The module area exists to allow modules to be
>located in an area where PC24 relocations are able to reach all of the
>kernel text on sensibly configured kernels, thereby allowing for
>optimal performance.
>
>If you wish to load large modules, then enable ARM_MODULE_PLTS, which
>will use the less efficient PLT method (which is basically an indirect
>function call) for relocations that PC24 can't handle, and will allow
>the module to be loaded into the vmalloc area.
>
>Growing the module area so that smaller modules also get penalised by
>the PLT indirection is not sane.
This is exactly what i am saying. These changes are useful to accomdate
22MB modules without enabling ARM_MODULE_PLTS.
Without these changes ARM_MODULE_PLTS needs to be enabled to insert more than 14MB
modules but with these changes 22MB modules (considering 8MB uImage) can be inserted
without enabling ARM_MODULE_PLTS.
So till 22MB modules are not penalised but without these changes once size of modules
gets over 14MB PLT becomes must.?
Regards,
Vaneet Narang
^ permalink raw reply
* [PATCH 1/2] arm64: setup: introduce kaslr_offset()
From: Will Deacon @ 2016-12-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481417456-28826-2-git-send-email-alex.popov@linux.com>
On Sun, Dec 11, 2016 at 03:50:55AM +0300, Alexander Popov wrote:
> Introduce kaslr_offset() similarly to x86_64 for fixing kcov.
>
> Signed-off-by: Alexander Popov <alex.popov@linux.com>
> ---
> arch/arm64/include/asm/setup.h | 19 +++++++++++++++++++
> arch/arm64/include/uapi/asm/setup.h | 4 ++--
> arch/arm64/kernel/setup.c | 8 ++++----
> 3 files changed, 25 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm64/include/asm/setup.h
>
> diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
> new file mode 100644
> index 0000000..e7b59b9
> --- /dev/null
> +++ b/arch/arm64/include/asm/setup.h
> @@ -0,0 +1,19 @@
> +/*
> + * arch/arm64/include/asm/setup.h
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __ASM_SETUP_H
> +#define __ASM_SETUP_H
> +
> +#include <uapi/asm/setup.h>
> +
> +static inline unsigned long kaslr_offset(void)
> +{
> + return kimage_vaddr - KIMAGE_VADDR;
> +}
> +
> +#endif
You could probably just stick this in asm/memory.h, since that's where
kimage_vaddr is declared and it would save adding a new header file.
> diff --git a/arch/arm64/include/uapi/asm/setup.h b/arch/arm64/include/uapi/asm/setup.h
> index 9cf2e46..26631c8 100644
> --- a/arch/arm64/include/uapi/asm/setup.h
> +++ b/arch/arm64/include/uapi/asm/setup.h
> @@ -16,8 +16,8 @@
> * You should have received a copy of the GNU General Public License
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
> -#ifndef __ASM_SETUP_H
> -#define __ASM_SETUP_H
> +#ifndef _UAPI__ASM_SETUP_H
> +#define _UAPI__ASM_SETUP_H
>
> #include <linux/types.h>
You can drop this hunk.
With those changes:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 1/1] arm: mm: Fix comments in sg_sync functions
From: Sakari Ailus @ 2016-12-12 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <560A6C80.1050808@arm.com>
Hi Robin and others,
On Tue, Sep 29, 2015 at 11:48:32AM +0100, Robin Murphy wrote:
> Hi Sakari,
>
> On 28/09/15 21:20, Sakari Ailus wrote:
> >The comment on the usage of arm_dma_sync_sg_for_cpu(),
> >arm_dma_sync_sg_for_device(), arm_iommu_sync_sg_for_cpu() and
> >arm_iommu_sync_sg_for_device() functions wrongly noted that the "nelems"
> >parameter is the number of sglist entries returned by dma_map_sg(), while
> >this must be the number of entiries passed to dma_map_sg() instead.
>
> Oops, I somehow missed you off cc when I posted [0] last week, apologies. I
> was planning to stick that in Russell's patch system today, but since you've
> done a slightly more thorough job with s/map/sync/ than I managed, I'm happy
> for this version to take precedence over mine:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
I was cleaning up my old branches and noticed this patch isn't merged yet.
It still applies cleanly though. How shall we proceed, should I send a pull
request?
>
> I'd hope that the lack of objections to my patch so far (and Dan's approval)
> also apply transitively to this one ;)
>
> Robin.
>
> [0]:http://thread.gmane.org/gmane.linux.ports.arm.kernel/441862
>
> >Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
> >Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> >---
> >Hi folks,
> >
> >This related patch was applied to Jonathan Corbet's tree:
> >
> ><URL:http://www.spinics.net/lists/linux-doc/msg31801.html>
> >
> >The comments were indeed wrong. This may have contributed to a related
> >videobuf2 bug:
> >
> ><URL:http://www.spinics.net/lists/linux-media/msg93765.html>
> >
> > arch/arm/mm/dma-mapping.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> >diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> >index e626043..1c0154a 100644
> >--- a/arch/arm/mm/dma-mapping.c
> >+++ b/arch/arm/mm/dma-mapping.c
> >@@ -958,7 +958,7 @@ void arm_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
> > * arm_dma_sync_sg_for_cpu
> > * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
> > * @sg: list of buffers
> >- * @nents: number of buffers to map (returned from dma_map_sg)
> >+ * @nents: number of buffers to sync (same as was passed to dma_map_sg)
> > * @dir: DMA transfer direction (same as was passed to dma_map_sg)
> > */
> > void arm_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> >@@ -977,7 +977,7 @@ void arm_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> > * arm_dma_sync_sg_for_device
> > * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
> > * @sg: list of buffers
> >- * @nents: number of buffers to map (returned from dma_map_sg)
> >+ * @nents: number of buffers to sync (same as was passed to dma_map_sg)
> > * @dir: DMA transfer direction (same as was passed to dma_map_sg)
> > */
> > void arm_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
> >@@ -1672,7 +1672,7 @@ void arm_iommu_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
> > * arm_iommu_sync_sg_for_cpu
> > * @dev: valid struct device pointer
> > * @sg: list of buffers
> >- * @nents: number of buffers to map (returned from dma_map_sg)
> >+ * @nents: number of buffers to sync (same as was passed to dma_map_sg)
> > * @dir: DMA transfer direction (same as was passed to dma_map_sg)
> > */
> > void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> >@@ -1690,7 +1690,7 @@ void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
> > * arm_iommu_sync_sg_for_device
> > * @dev: valid struct device pointer
> > * @sg: list of buffers
> >- * @nents: number of buffers to map (returned from dma_map_sg)
> >+ * @nents: number of buffers to sync (same as was passed to dma_map_sg)
> > * @dir: DMA transfer direction (same as was passed to dma_map_sg)
> > */
> > void arm_iommu_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
> >
>
>
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
^ permalink raw reply
* [PATCH 3/3] dts: hisi: add dts files for Hi3516CV300 demo board
From: Jiancheng Xue @ 2016-12-12 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017120705.3726-4-wenpan@hisilicon.com>
On 2016/10/17 20:07, Pan Wen wrote:
> Add dts files for Hi3516CV300 demo board.
>
> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
> ---
Could you help to review this patch, please?
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/hi3516cv300-demb.dts | 148 ++++++++++++
> arch/arm/boot/dts/hi3516cv300.dtsi | 397 +++++++++++++++++++++++++++++++++
> 3 files changed, 546 insertions(+)
> create mode 100644 arch/arm/boot/dts/hi3516cv300-demb.dts
> create mode 100644 arch/arm/boot/dts/hi3516cv300.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..1f25530 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -171,6 +171,7 @@ dtb-$(CONFIG_ARCH_HIP01) += \
> dtb-$(CONFIG_ARCH_HIP04) += \
> hip04-d01.dtb
> dtb-$(CONFIG_ARCH_HISI) += \
> + hi3516cv300-demb.dtb \
> hi3519-demb.dtb
> dtb-$(CONFIG_ARCH_HIX5HD2) += \
> hisi-x5hd2-dkb.dtb
> diff --git a/arch/arm/boot/dts/hi3516cv300-demb.dts b/arch/arm/boot/dts/hi3516cv300-demb.dts
> new file mode 100644
> index 0000000..6a75cd6
> --- /dev/null
> +++ b/arch/arm/boot/dts/hi3516cv300-demb.dts
> @@ -0,0 +1,148 @@
> +/*
> + * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + *
> + */
> +
> +
> +/dts-v1/;
> +#include "hi3516cv300.dtsi"
> +
> +/ {
> + model = "Hisilicon Hi3516CV300 DEMO Board";
> + compatible = "hisilicon,hi3516cv300";
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + i2c0 = &i2c_bus0;
> + i2c1 = &i2c_bus1;
> + spi0 = &spi_bus0;
> + spi1 = &spi_bus1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x80000000 0x10000000>;
> + };
> +};
> +
> +&dual_timer0 {
> + status = "okay";
> +};
> +
> +&watchdog {
> + status = "okay";
> +};
> +
> +&pwm {
> + status = "okay";
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&i2c_bus0 {
> + status = "okay";
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pmux>;
> +};
> +
> +&i2c_bus1 {
> + status = "okay";
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pmux>;
> +};
> +
> +&spi_bus0{
> + status = "disabled";
> + num-cs = <1>;
> + cs-gpios = <&gpio_chip0 6 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pmux>;
> +};
> +
> +&spi_bus1{
> + status = "okay";
> + num-cs = <2>;
> + cs-gpios = <&gpio_chip5 3 0>, <&gpio_chip5 4 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi1_pmux>;
> +};
> +
> +&fmc {
> + spi-nor at 0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <160000000>;
> + m25p,fast-read;
> + };
> +};
> +
> +&mdio {
> + phy0: phy at 1 {
> + reg = <1>;
> + };
> +};
> +
> +&hisi_femac {
> + mac-address = [00 00 00 00 00 00];
> + phy-mode = "rmii";
> + phy-handle = <&phy0>;
> + hisilicon,phy-reset-delays-us = <10000 10000 150000>;
> +};
> +
> +&dmac {
> + status = "okay";
> +};
> +
> +&pmux {
> + i2c0_pmux: i2c0_pmux {
> + pinctrl-single,pins = <
> + 0x2c 0x3
> + 0x30 0x3>;
> + };
> +
> + i2c1_pmux: i2c1_pmux {
> + pinctrl-single,pins = <
> + 0x20 0x1
> + 0x24 0x1>;
> + };
> +
> + spi0_pmux: spi0_pmux {
> + pinctrl-single,pins = <
> + 0x28 0x1
> + 0x2c 0x1
> + 0x30 0x1
> + 0x34 0x1>;
> + };
> +
> + spi1_pmux: spi1_pmux {
> + pinctrl-single,pins = <
> + 0xc4 0x1
> + 0xc8 0x1
> + 0xcc 0x1
> + 0xd0 0x1
> + 0xd4 0x1>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/hi3516cv300.dtsi b/arch/arm/boot/dts/hi3516cv300.dtsi
> new file mode 100644
> index 0000000..1da41ab
> --- /dev/null
> +++ b/arch/arm/boot/dts/hi3516cv300.dtsi
> @@ -0,0 +1,397 @@
> +/*
> + * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * 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 "skeleton.dtsi"
> +#include <dt-bindings/clock/hi3516cv300-clock.h>
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,arm926ej-s";
> + reg = <0>;
> + };
> + };
> +
> + vic: interrupt-controller at 10040000 {
> + compatible = "arm,pl190-vic";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x10040000 0x1000>;
> + };
> +
> + soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + interrupt-parent = <&vic>;
> + ranges;
> +
> + clk_3m: clk_3m {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <3000000>;
> + };
> +
> + clk_apb: clk_apb {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <50000000>;
> + };
> +
> + crg: clock-reset-controller at 12010000 {
> + compatible = "hisilicon,hi3516cv300-crg";
> + reg = <0x12010000 0x1000>;
> + #clock-cells = <1>;
> + #reset-cells = <2>;
> + };
> +
> + sysctrl: system-controller at 12020000 {
> + compatible = "hisilicon,hi3516cv300-sysctrl", "syscon";
> + reg = <0x12020000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + reboot {
> + compatible = "syscon-reboot";
> + regmap = <&sysctrl>;
> + offset = <0x4>;
> + mask = <0xdeadbeef>;
> + };
> +
> + dual_timer0: dual_timer at 12000000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x12000000 0x1000>;
> + interrupts = <3>;
> + clocks = <&clk_3m>, <&clk_3m>, <&clk_apb>;
> + clock-names = "timer0", "timer1", "apb_pclk";
> + status = "disabled";
> + };
> +
> + dual_timer1: dual_timer at 12001000 {
> + compatible = "arm,sp804", "arm,primecell";
> + reg = <0x12001000 0x1000>;
> + interrupts = <4>;
> + clocks = <&clk_3m>, <&clk_3m>, <&clk_apb>;
> + clock-names = "timer0", "timer1", "apb_pclk";
> + status = "disabled";
> + };
> +
> + watchdog: watchdog at 12080000 {
> + compatible = "arm,sp805-wdt", "arm,primecell";
> + arm,primecell-periphid = <0x00141805>;
> + reg = <0x12080000 0x1000>;
> + clocks = <&sysctrl HI3516CV300_WDT_CLK>,
> + <&crg HI3516CV300_APB_CLK>;
> + clock-names = "wdog_clk", "apb_pclk";
> + status = "disabled";
> + };
> +
> + pwm: pwm at 12130000 {
> + compatible = "hisilicon,hi3516cv300-pwm",
> + "hisilicon,hibvt-pwm";
> + reg = <0x12130000 0x10000>;
> + clocks = <&crg HI3516CV300_PWM_CLK>;
> + resets = <&crg 0x38 0>;
> + #pwm-cells = <2>;
> + status = "disabled";
> + };
> +
> + uart0: uart at 12100000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12100000 0x1000>;
> + interrupts = <5>;
> + clocks = <&crg HI3516CV300_UART0_CLK>;
> + clock-names = "apb_pclk";
> + status = "disabled";
> + };
> +
> + uart1: uart at 12101000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12101000 0x1000>;
> + interrupts = <30>;
> + clocks = <&crg HI3516CV300_UART1_CLK>;
> + clock-names = "apb_pclk";
> + status = "disabled";
> + };
> +
> + uart2: uart at 12102000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x12102000 0x1000>;
> + interrupts = <25>;
> + clocks = <&crg HI3516CV300_UART2_CLK>;
> + clock-names = "apb_pclk";
> + status = "disabled";
> + };
> +
> + i2c_bus0: i2c at 12110000 {
> + compatible = "hisilicon,hi3516cv300-i2c",
> + "hisilicon,hibvt-i2c";
> + reg = <0x12110000 0x1000>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + status = "disabled";
> + };
> +
> + i2c_bus1: i2c at 12112000 {
> + compatible = "hisilicon,hi3516cv300-i2c",
> + "hisilicon,hibvt-i2c";
> + reg = <0x12112000 0x1000>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + status = "disabled";
> + };
> +
> + spi_bus0: spi at 12120000 {
> + compatible = "arm,pl022", "arm,primecell";
> + reg = <0x12120000 0x1000>;
> + interrupts = <6>;
> + clocks = <&crg HI3516CV300_SPI0_CLK>;
> + clock-names = "apb_pclk";
> + dmas = <&dmac 12 1>, <&dmac 13 2>;
> + dma-names = "rx", "tx";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi_bus1: spi at 12121000 {
> + compatible = "arm,pl022", "arm,primecell";
> + reg = <0x12121000 0x1000>, <0x12030000 0x4>;
> + interrupts = <7>;
> + clocks = <&crg HI3516CV300_SPI1_CLK>;
> + clock-names = "apb_pclk";
> + dmas = <&dmac 14 1>, <&dmac 15 2>;
> + dma-names = "rx", "tx";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + fmc: spi-nor-controller at 10000000 {
> + compatible = "hisilicon,fmc-spi-nor";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x10000000 0x1000>, <0x14000000 0x1000000>;
> + reg-names = "control", "memory";
> + clocks = <&crg HI3516CV300_FMC_CLK>;
> + assigned-clocks = <&crg HI3516CV300_FMC_CLK>;
> + assigned-clock-rates = <24000000>;
> + };
> +
> + mdio: mdio at 10051100 {
> + compatible = "hisilicon,hisi-femac-mdio";
> + reg = <0x10051100 0x10>;
> + clocks = <&crg HI3516CV300_ETH_CLK>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + hisi_femac: ethernet at 10090000 {
> + compatible = "hisilicon,hi3516cv300-femac",
> + "hisilicon,hisi-femac-v2";
> + reg = <0x10050000 0x1000>,<0x10051300 0x200>;
> + interrupts = <12>;
> + clocks = <&crg HI3516CV300_ETH_CLK>;
> + resets = <&crg 0xec 0>, <&crg 0xec 3>;
> + reset-names = "mac","phy";
> + };
> +
> + dmac: dma-controller at 10030000 {
> + compatible = "arm,pl080", "arm,primecell";
> + reg = <0x10030000 0x1000>;
> + interrupts = <14>;
> + clocks = <&crg HI3516CV300_DMAC_CLK>;
> + clock-names = "apb_pclk";
> + lli-bus-interface-ahb1;
> + lli-bus-interface-ahb2;
> + mem-bus-interface-ahb1;
> + mem-bus-interface-ahb2;
> + memcpy-burst-size = <256>;
> + memcpy-bus-width = <32>;
> + #dma-cells = <2>;
> + status = "disabled";
> + };
> +
> + gpio_chip0: gpio at 12140000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12140000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 61 2>,
> + <&pmux 4 11 1>,
> + <&pmux 5 10 1>,
> + <&pmux 6 13 2>;
> +
> + status = "disabled";
> + };
> +
> + gpio_chip1: gpio at 12141000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12141000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 16 7>,
> + <&pmux 7 0 1>;
> + status = "disabled";
> + };
> +
> + gpio_chip2: gpio at 12142000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12142000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 46 1>,
> + <&pmux 1 45 1>,
> + <&pmux 2 44 1>,
> + <&pmux 3 43 1>,
> + <&pmux 4 39 1>,
> + <&pmux 5 38 1>,
> + <&pmux 6 40 1>,
> + <&pmux 7 48 1>;
> + status = "disabled";
> + };
> +
> + gpio_chip3: gpio at 12143000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12143000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 37 1>,
> + <&pmux 1 36 1>,
> + <&pmux 2 35 1>,
> + <&pmux 3 34 1>,
> + <&pmux 4 23 2>,
> + <&pmux 6 8 2>;
> + status = "disabled";
> + };
> +
> + gpio_chip4: gpio at 12144000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12144000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 27 1>,
> + <&pmux 1 26 1>,
> + <&pmux 2 31 1>,
> + <&pmux 3 30 1>,
> + <&pmux 4 28 2>,
> + <&pmux 6 33 1>,
> + <&pmux 7 32 1>;
> + status = "disabled";
> + };
> +
> + gpio_chip5: gpio at 12145000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12145000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 53 1>,
> + <&pmux 1 51 2>,
> + <&pmux 3 50 1>,
> + <&pmux 4 49 1>,
> + <&pmux 5 47 1>,
> + <&pmux 6 40 2>;
> + status = "disabled";
> + };
> +
> + gpio_chip6: gpio at 12146000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12146000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 7 1>,
> + <&pmux 1 6 1>,
> + <&pmux 2 4 1>,
> + <&pmux 3 5 1>,
> + <&pmux 4 15 1>,
> + <&pmux 5 1 3>;
> + status = "disabled";
> + };
> +
> + gpio_chip7: gpio at 12147000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12147000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 1 55 6>,
> + <&pmux 7 25 1>;
> + status = "disabled";
> + };
> +
> + gpio_chip8: gpio at 12148000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0x12148000 0x1000>;
> + interrupts = <31>;
> + clocks = <&crg HI3516CV300_APB_CLK>;
> + clock-names = "apb_pclk";
> + #gpio-cells = <2>;
> + gpio-ranges = <&pmux 0 63 3>,
> + <&pmux 3 12 1>;
> + status = "disabled";
> + };
> +
> + pmux: pinmux at 12040000 {
> + compatible = "pinctrl-single";
> + reg = <0x12040000 0x108>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #gpio-range-cells = <3>;
> + ranges;
> +
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <7>;
> + /* pin base, nr pins & gpio function */
> + pinctrl-single,gpio-range = <&range 0 54 0
> + &range 55 6 1 &range 61 5 0>;
> +
> + range: gpio-range {
> + #pinctrl-single,gpio-range-cells = <3>;
> + };
> + };
> +
> + pconf: pinconf at 12040800 {
> + compatible = "pinconf-single";
> + reg = <0x12040800 0x130>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + pinctrl-single,register-width = <32>;
> + };
> + };
> +};
>
^ permalink raw reply
* [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-12-12 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209145234.GB14257@rric.localdomain>
On 9 December 2016 at 14:52, Robert Richter <robert.richter@cavium.com> wrote:
> On 09.12.16 21:15:12, Yisheng Xie wrote:
>> For invalid pages, their zone and node information is not initialized, and it
>> do have risk to trigger the BUG_ON, so I have a silly question,
>> why not just change the BUG_ON:
>
> We need to get the page handling correct. Modifying the BUG_ON() just
> hides that something is wrong.
>
Actually, I think this is a reasonable question. We are trying very
hard to work around the BUG_ON(), which arguably does something wrong
by calling page_to_nid() on a struct page without checking if it is a
valid page.
Looking at commit 344c790e3821 ("mm: make setup_zone_migrate_reserve()
aware of overlapping nodes"), the BUG_ON() has a specific purpose
related to adjacent zones.
What will go wrong if we ignore this check?
>
>> -----------
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 6de9440..af199b8 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -1860,12 +1860,13 @@ int move_freepages(struct zone *zone,
>> * Remove at a later date when no bug reports exist related to
>> * grouping pages by mobility
>> */
>> - VM_BUG_ON(page_zone(start_page) != page_zone(end_page));
>> + VM_BUG_ON(early_pfn_valid(start_page) && early_pfn_valid(end_page) &&
>> + page_zone(start_page) != page_zone(end_page));
>> #endif
>>
>> for (page = start_page; page <= end_page;) {
>> /* Make sure we are not inadvertently changing nodes */
>> - VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page);
>> + VM_BUG_ON_PAGE(early_pfn_valid(page) && (page_to_nid(page) != zone_to_nid(zone)), page);
>>
>> if (!pfn_valid_within(page_to_pfn(page))) {
>> page++;
>
^ permalink raw reply
* [RFC PATCH 15/23] arm: use kconfig fragments for ARCH_PXA defconfigs (part 1)
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8c415hs.fsf@belgarion.home>
Hi,
On Saturday, December 10, 2016 10:46:23 AM Robert Jarzmik wrote:
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> writes:
>
> > Replace [lpd270,lubbock,mainstone,pxa255-idp]_defconfig-s with
> > a Makefile target using merge_config.
> >
> > The patch was verified with doing:
> >
> > $ make [lpd270,...]_defconfig
> > $ make savedefconfig
> >
> > and comparing resulting defconfig files (before/after the patch).
> >
> > Cc: Daniel Mack <daniel@zonque.org>
> > Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> > Cc: Robert Jarzmik <robert.jarzmik@free.fr>
> > Cc: Cyril Bur <cyrilbur@gmail.com>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>
> Hi Bartolomiej,
>
> It's a bit hard to judge without any context for me, especially I'm receiving
> patches 11 to 21 but not the others. I suppose the advantage of defconfig
Sorry about that.
> fragments was already discussed somewhere, could you point me to that please ?
http://marc.info/?l=linux-kernel&m=148102838302106&w=2
I've put the patches on hold for now after the feedback from Olof & Arnd.
> One small thing that could be improved is the "pxa_basic*" names.
>
> I think pxa_basic1 is "pxa_refboards" or something like that, as these are the
> initial reference designs as far as I know from Intel and validation vehicles
> rather that form factors.
>
> In the same way, pxa_basic2 is rather "pxa_sharpsl" as these are sharp designs.
>
> And pxa_basic3 looks like Motorola platforms, so "pxa_motorola" perhaps ?
>
> I noticed imote2.config ended up based on pxa_basic3, while I would have
> expected it to be based on pxa_basic1 as it looks like a reference board to me
> ...
Thank you for your comments.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [linux-sunxi] sunxi-ng clocks: leaving certain clocks alone?
From: Andre Przywara @ 2016-12-12 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67kCAr6Ty5=Gg8vOGNC6xhuRM66Wa=H+C3AD=_d_H+N8w@mail.gmail.com>
Hi Chen-Yu,
thanks for the answer!
On 12/12/16 04:41, Chen-Yu Tsai wrote:
> On Mon, Dec 12, 2016 at 7:54 AM, Andr? Przywara <andre.przywara@arm.com> wrote:
>> Hi,
>>
>> I was observing that the new sunxi-ng clock code apparently explicitly
>> turns off _all_ clocks that are not used or needed. I find this rather
>> unfortunate, as I wanted to use the THS temperature sensor from ARM
>> Trusted Firmware to implement emergency shutdown or DVFS throttling.
>> That works until the clock framework finds the clock (as enumerated in
>> ccu-sun50i-a64.c) and obviously explicitly clears bit 31 in the THS mod
>> clock register and bit 8 in the respective clock gate register.
>> Turning them manually back on via /dev/mem or removing the THS clock
>> from the sunxi-ng driver fixes this for me.
>>
>> This was not happening with the old Allwinner clocks, since the kernel
>> wouldn't even know about it if there was no driver and the clock wasn't
>> mentioned in the DT.
>>
>> Now with sunxi-ng even though the THS clock is not actually referenced
>> or used in the DT, the kernel turns it off. I would expect that upon
>> entering the kernel all unneeded clocks are turned off anyway, so there
>> is no need to mess with clocks that have no user, but are enumerated in
>> the ccu driver.
>
> I can't say that's absolutely true (wink).
>
>>
>> I wonder if this kills simplefb as well, for instance, since I believe
>> that U-Boot needs to turn on certain clocks and relies on them staying up.
>
> The simplefb bindings takes clocks and regulators expressly for the
> purpose of keeping them enabled.
Right, I should have checked this before ...
>>
>> So my questions:
>> 1) Is this expected behaviour?
>
> Yes.
>
>> 2) If yes, should it really be?
>> 3) If yes, shouldn't there be way to explicitly tell Linux to leave that
>> clock alone, preferably via DT? Although the sunxi-ng clocks take
>> control over the whole CCU unit, I wonder if it should really mess with
>> clocks there are not referenced in the DT.
>
> As it owns the whole CCU unit, why not? And how would it know if some
> clock is referenced or not, unless going through the whole device tree?
I was hoping that it just provides clocks to any users (drivers) and
wouldn't bother with tinkering with every clock unless explicitly being
asked for (by a driver being pointed to a specific clock through DT).
So it would need to iterate through anything - neither the whole DT nor
it's own list of clocks.
> Furthermore, nothing prevents another device driver from referencing
> said clock and turning it off when it's not in use. Think THS driver
> with runtime PM.
I am totally OK with that: Any potential Linux THS driver can take over,
if the DT references this device and the clock.
My point is that atm there is no such driver and so the clocks framework
shouldn't turn that clock off.
> Are you also mapping the THS to secure only? Otherwise nothing would
> prevent Linux from also claiming it.
Unfortunately the THS is always unsecure. And even if it could be
switched, after a recent IRC discussion I came to believe that those
secure peripherals features only works when the secure boot feature is
used, which requires to blow an efuse and thus is not easily doable on
most boards and also irreversible.
Also I am not sure whether this security feature actually extends to the
mod clocks and the bus reset and clock gates bits.
But I was relying on that Linux doesn't touch hardware that's not
referenced in the DT, so if firmware uses the THS, any Linux THS node
would need to go - or the other way around: if there is a Linux THS
node, firmware backs off.
>> Maybe there is some way to reference those clocks via some dummy driver
>> or DT node to avoid this behaviour? Is there any prior art in this respect?
>
> If you want a clock to not be disabled by anyone, adding CLK_IS_CRITICAL
> to its flags is the proper option. This is done in the clk driver though.
Yes, I was thinking about that, but it indeed sounds like a hack to
follow this.
> If you just don't want the clk subsystem to disable unused clks at boot
> time, you can add "clk_ignore_unused" to the kernel boot parameters.
> I think this is more of a hack and debugging tool though.
Good point, but indeed looks like a debug feature.
> About dummy drivers, simplefb comes to mind again. But simplefb disables
> them when it gets kicked out by the drm driver.
Which I am fine with. If people are desperate about a THS driver, this
could take over, although I would expect a firmware driving the THS
would discourage this - for instance by removing a THS node.
> Maybe there are other examples.
OK, thanks for the pointer, I will look into this direction.
Cheers,
Andre.
>> I think this issue will affect more future users (thinking of EFI RTC,
>> EFI graphics, etc.), so I wanted to start a discussion on this.
>>
>> Any input welcome.
>>
>> Cheers,
>> Andre.
>>
>> P.S. For reference my use case: ARM Trusted Firmware (ATF) enables the
>> temperature sensor (THS) and programs a shutdown value. It programs the
>> respective interrupt as secure and registers an IRQ handler in ATF to
>> shutdown the system or take other appropriate matters to avoid
>> overheating. Additionally the sensor is exported via the generic SCPI
>> interface, so the existing scpi-hwmon driver picks it up and reports it
>> to whoever is interested in Linux land via the normal interfaces.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH 1/1] arm: mm: Fix comments in sg_sync functions
From: Robin Murphy @ 2016-12-12 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212113053.GR16630@valkosipuli.retiisi.org.uk>
Hi Sakari,
On 12/12/16 11:30, Sakari Ailus wrote:
> Hi Robin and others,
>
> On Tue, Sep 29, 2015 at 11:48:32AM +0100, Robin Murphy wrote:
>> Hi Sakari,
>>
>> On 28/09/15 21:20, Sakari Ailus wrote:
>>> The comment on the usage of arm_dma_sync_sg_for_cpu(),
>>> arm_dma_sync_sg_for_device(), arm_iommu_sync_sg_for_cpu() and
>>> arm_iommu_sync_sg_for_device() functions wrongly noted that the "nelems"
>>> parameter is the number of sglist entries returned by dma_map_sg(), while
>>> this must be the number of entiries passed to dma_map_sg() instead.
>>
>> Oops, I somehow missed you off cc when I posted [0] last week, apologies. I
>> was planning to stick that in Russell's patch system today, but since you've
>> done a slightly more thorough job with s/map/sync/ than I managed, I'm happy
>> for this version to take precedence over mine:
>>
>> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
> I was cleaning up my old branches and noticed this patch isn't merged yet.
> It still applies cleanly though. How shall we proceed, should I send a pull
> request?
I guess it should probably go through the ARM tree, so the best course
of action would be to submit it to Russell's patch system[1] for him to
pick up.
Robin.
[1]:http://www.armlinux.org.uk/developer/patches/
>>
>> I'd hope that the lack of objections to my patch so far (and Dan's approval)
>> also apply transitively to this one ;)
>>
>> Robin.
>>
>> [0]:http://thread.gmane.org/gmane.linux.ports.arm.kernel/441862
>>
>>> Suggested-by: Daniel Kurtz <djkurtz@chromium.org>
>>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>>> ---
>>> Hi folks,
>>>
>>> This related patch was applied to Jonathan Corbet's tree:
>>>
>>> <URL:http://www.spinics.net/lists/linux-doc/msg31801.html>
>>>
>>> The comments were indeed wrong. This may have contributed to a related
>>> videobuf2 bug:
>>>
>>> <URL:http://www.spinics.net/lists/linux-media/msg93765.html>
>>>
>>> arch/arm/mm/dma-mapping.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>>> index e626043..1c0154a 100644
>>> --- a/arch/arm/mm/dma-mapping.c
>>> +++ b/arch/arm/mm/dma-mapping.c
>>> @@ -958,7 +958,7 @@ void arm_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
>>> * arm_dma_sync_sg_for_cpu
>>> * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
>>> * @sg: list of buffers
>>> - * @nents: number of buffers to map (returned from dma_map_sg)
>>> + * @nents: number of buffers to sync (same as was passed to dma_map_sg)
>>> * @dir: DMA transfer direction (same as was passed to dma_map_sg)
>>> */
>>> void arm_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
>>> @@ -977,7 +977,7 @@ void arm_dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
>>> * arm_dma_sync_sg_for_device
>>> * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
>>> * @sg: list of buffers
>>> - * @nents: number of buffers to map (returned from dma_map_sg)
>>> + * @nents: number of buffers to sync (same as was passed to dma_map_sg)
>>> * @dir: DMA transfer direction (same as was passed to dma_map_sg)
>>> */
>>> void arm_dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
>>> @@ -1672,7 +1672,7 @@ void arm_iommu_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
>>> * arm_iommu_sync_sg_for_cpu
>>> * @dev: valid struct device pointer
>>> * @sg: list of buffers
>>> - * @nents: number of buffers to map (returned from dma_map_sg)
>>> + * @nents: number of buffers to sync (same as was passed to dma_map_sg)
>>> * @dir: DMA transfer direction (same as was passed to dma_map_sg)
>>> */
>>> void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
>>> @@ -1690,7 +1690,7 @@ void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
>>> * arm_iommu_sync_sg_for_device
>>> * @dev: valid struct device pointer
>>> * @sg: list of buffers
>>> - * @nents: number of buffers to map (returned from dma_map_sg)
>>> + * @nents: number of buffers to sync (same as was passed to dma_map_sg)
>>> * @dir: DMA transfer direction (same as was passed to dma_map_sg)
>>> */
>>> void arm_iommu_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
>>>
>>
>>
>
^ permalink raw reply
* [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Maxime Ripard @ 2016-12-12 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <afcb938d-d2df-4740-6c85-cdf2766f671c@schinagl.nl>
On Thu, Dec 08, 2016 at 02:23:39PM +0100, Olliver Schinagl wrote:
> Hey Maxime,
>
> first off, also sorry for the slow delay :) (pun not intended)
>
> On 27-08-16 00:19, Maxime Ripard wrote:
> > On Thu, Aug 25, 2016 at 07:50:10PM +0200, Olliver Schinagl wrote:
> > > When we inform the PWM block to stop toggeling the output, we may end up
> > > in a state where the output is not what we would expect (e.g. not the
> > > low-pulse) but whatever the output was at when the clock got disabled.
> > >
> > > To counter this we have to wait for maximally the time of one whole
> > > period to ensure the pwm hardware was able to finish. Since we already
> > > told the PWM hardware to disable it self, it will not continue toggling
> > > but merly finish its current pulse.
> > >
> > > If a whole period is considered to much, it may be contemplated to use a
> > > half period + a little bit to ensure we get passed the transition.
> > >
> > > Signed-off-by: Olliver Schinagl<oliver@schinagl.nl>
> > > ---
> > > drivers/pwm/pwm-sun4i.c | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> > > index 03a99a5..5e97c8a 100644
> > > --- a/drivers/pwm/pwm-sun4i.c
> > > +++ b/drivers/pwm/pwm-sun4i.c
> > > @@ -8,6 +8,7 @@
> > > #include <linux/bitops.h>
> > > #include <linux/clk.h>
> > > +#include <linux/delay.h>
> > > #include <linux/err.h>
> > > #include <linux/io.h>
> > > #include <linux/module.h>
> > > @@ -245,6 +246,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
> > > spin_lock(&sun4i_pwm->ctrl_lock);
> > > val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> > > val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
> > > + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> > > + spin_unlock(&sun4i_pwm->ctrl_lock);
> > > +
> > > + /* Allow for the PWM hardware to finish its last toggle. The pulse
> > > + * may have just started and thus we should wait a full period.
> > > + */
> > > + ndelay(pwm_get_period(pwm));
> > Can't that use the ready bit as well?
>
> I started to implement our earlier discussed suggestions, but I do not think
> they will work. The read bit is not to let the user know it is ready with
> all of its commands, but only if the period registers are ready. I think it
> is some write lock while it copies the data into its internal control loop.
> From the manual:
> PWM0 period register ready.
> 0: PWM0 period register is ready to write,
> 1: PWM0 period register is busy.
>
>
> So no, I don't think i can use the ready bit here at all. The only thing we
> can do here, but I doubt it's worth it, is to read the period register,
> caluclate a time from it, and then ndelay(pwm_get_period(pwm) - ran_time)
>
> The only 'win' then is that we could are potentially not waiting the full
> pwm period, but only a fraction of it. Since we are disabling the hardware
> (for power reasons) anyway, I don't think this is any significant win,
> except for extreme situations. E.g. we have a pwm period of 10 seconds, we
> disable it after 9.9 second, and now we have to wait for 10 seconds before
> the pwm_disable is finally done. So this could in that case be reduced to
> then only wait for 0.2 seconds since it is 'done' sooner.
>
> However that optimization is also not 'free'. We have to read the period
> register and calculate back the time. I suggest to do that when reworking
> this driver to work with atomic mode, and merge this patch 'as is' to
> atleast fix te bug where simply not finish properly.
That whole discussion made me realise something that is really
bad. AFAIK, pwm_get_period returns a 32 bits register, which means a
theorical period of 4s. Busy looping during 4 seconds is already very
bad, as you basically kill one CPU during that time, but doing so in a
(potentially) atomic context is even worse.
NACK.
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/20161212/e5f22cbb/attachment.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