* Tegra baseline test results for v4.9-rc7
From: Jon Hunter @ 2016-12-12 9:37 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.9-rc7.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9-rc7/20161127133104/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.9-rc6 (9c763584b7c8911106bb77af7e648bef09af9d80)):
text data bss total kernel
-88 +88 0 0 defconfig
+1312 0 0 +1312 multi_v7_defconfig
+928 0 0 +928 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.9-rc6 (9c763584b7c8911106bb77af7e648bef09af9d80))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
^ permalink raw reply
* Tegra baseline test results for v4.8-rc6
From: Jon Hunter @ 2016-12-12 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9eb90711-3de9-09dd-7751-fb8e3bfc91dd@nvidia.com>
Ignore this, wrong $subject ... still half asleep!
On 12/12/16 09:29, Jon Hunter wrote:
> Here are some basic Tegra test results for Linux v4.9-rc6.
> Logs and other details at:
>
> https://nvtb.github.io//linux/test_v4.9-rc6/20161121033104/
>
>
> Test summary
> ------------
>
> Build: zImage:
> Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
>
> Build: Image:
> Pass: ( 1/ 1): defconfig
>
> Boot to userspace: defconfig:
> Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
> tegra210-p2371-0000, tegra210-smaug
>
> Boot to userspace: multi_v7_defconfig:
> Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
>
> Boot to userspace: tegra_defconfig:
> Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
>
> PM: System suspend: multi_v7_defconfig:
> Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
>
> PM: System suspend: tegra_defconfig:
> Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
> tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
>
>
> vmlinux object size
> (delta in bytes from test_v4.9-rc5 (a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6)):
> text data bss total kernel
> -329 +592 0 +263 defconfig
> +1307 +64 0 +1371 multi_v7_defconfig
> +1143 0 0 +1143 tegra_defconfig
>
>
> Boot-time memory difference
> (delta in bytes from test_v4.9-rc5 (a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6))
> avail rsrvd high freed board kconfig dtb
> . . . . qemu-vexpress64 defconfig __internal
> . . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
> . . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
> . . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
> . . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
> . . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
> . . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
> . . . . tegra132-norrin defconfig tegra132-norrin
> . . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
> . . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
> . . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
> . . . . tegra210-smaug defconfig tegra210-smaug
> . . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
> . . . . tegra30-beaver tegra_defconfig tegra30-beaver
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
nvpublic
^ permalink raw reply
* Tegra baseline test results for v4.9-rc8
From: Jon Hunter @ 2016-12-12 9:40 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.9-rc8.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9-rc8/20161206040103/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.9-rc7 (e5517c2a5a49ed5e99047008629f1cd60246ea0e)):
text data bss total kernel
+3849 +216 0 +4065 defconfig
+936 0 0 +936 multi_v7_defconfig
+228 0 0 +228 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.9-rc7 (e5517c2a5a49ed5e99047008629f1cd60246ea0e))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
^ permalink raw reply
* Tegra baseline test results for v4.9
From: Jon Hunter @ 2016-12-12 9:41 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.9.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.9/20161211123105/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.9-rc8 (3e5de27e940d00d8d504dfb96625fb654f641509)):
text data bss total kernel
-96 +96 0 0 defconfig
+672 0 0 +672 multi_v7_defconfig
+432 0 0 +432 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.9-rc8 (3e5de27e940d00d8d504dfb96625fb654f641509))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
^ permalink raw reply
* [RFC v3 PATCH 00/25] Allow NOMMU for MULTIPLATFORM
From: mickael guene @ 2016-12-12 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584E6DA3.5070009@arm.com>
Hi Vladimir,
At the end of https://github.com/mickael-guene/fdpic_manifest you can
find a set of patch to apply for kernel fdpic support. Unfortunately
they are quite old ... But I have done some test on May for
stm32f469-disco platform and I have attached patches against more
recent kernel.
I also remove Maxime address since he quit st few month ago and his
address is no more valid.
Regards
Mickael
On 12/12/2016 10:28 AM, Vladimir Murzin wrote:
> Hi,
>
> On 12/12/16 07:07, mickael guene wrote:
>> Hi all,
>>
>> You can find an R toolchain here:
>> https://github.com/mickael-guene/fdpic_manifest/releases/download/v7-r-1.0.1/toolset-v7-r-1.0.1-0-gbdcc6a7c-armv7-r.tgz
>>
>> It's an fdpic toolset for cortex-r cpu class. gcc version is
>> quite old (4.7).
>>
>> Note also that generated code may crash on class A cpu due to
>> generation of udiv/sdiv which is optional for class A.
>> (cortex a15 is ok but not a9).
>>
>> Hope it helps
>
> Unfortunately, it doesn't help because it depends on FDPIC Linux patches
> which are out of tree and no link has been given.
>
> M-class toolchain should just work with A-class; you don't even need to
> disable MMU to try it out after d782e42 ("ARM: 8594/1: enable binfmt_flat on
> systems with an MMU").
>
> Cheers
> Vladimir
>
>>
>> Regards
>> Mickael
>>
>> On 12/11/2016 09:01 PM, Peter Korsgaard wrote:
>>>>>>>> "Afzal" == Afzal Mohammed <afzal.mohd.ma@gmail.com> writes:
>>>
>>> Hi,
>>>
>>> >> You can build a toolchain and initramfs with Buildroot. Have a look at
>>> >> the stm32f429 nommu config:
>>> >>
>>> >> https://git.buildroot.net/buildroot/tree/configs/stm32f429_disco_defconfig
>>>
>>> > iiuc, it builds one for Cortex-M. i already had a file system w/
>>> > busybox compiled using a Cortex-M toolchain (stolen from
>>> > Pengutronix's OSELAS.Toolchain), which works on Cortex M4 (Vybrid
>>> > VF610 M4 core). But it does not work here, i.e. on Cortex A, seems the
>>> > above mentioned also would have the same effect.
>>>
>>> Hmm, I'm not sure why a cortex-M toolchain wouldn't work on cortex-A, I
>>> thought the 'M' instruction set was a pure subset of the 'A'.
>>>
>>> > And in buildroot, couldn't see Cortex R option in menuconfig, and
>>> > selecting Cortex-A's excludes flat binary target & presents only with
>>> > ELF.
>>>
>>> We indeed don't have cortex-R support. I'm not aware of any cortex-R
>>> Linux support.
>>>
>>> When you select a cortex-A variant, then we enable MMU support by
>>> default, but you can disable it under toolchain options (Enable MMU) and
>>> then the flat binary option is available.
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-fdpic-Add-support-for-fdpic-binaries-loading.patch
Type: text/x-patch
Size: 10273 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/39f2c4af/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-fdpic-add-support-to-return-to-thumb2-code-from-sign.patch
Type: text/x-patch
Size: 2673 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/39f2c4af/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-fdpic-Add-get_tls-syscall.patch
Type: text/x-patch
Size: 1430 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/39f2c4af/attachment-0007.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-fdpic-Add-tls-support-for-cortex-m-cpu-family.patch
Type: text/x-patch
Size: 894 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/39f2c4af/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-fdpic-Workaround-to-fix-futex-bug-on-mmu-less.patch
Type: text/x-patch
Size: 3635 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161212/39f2c4af/attachment-0009.bin>
^ permalink raw reply
* [PATCH] watchdog: bcm2835_wdt: set WDOG_HW_RUNNING bit when appropriate
From: Rasmus Villemoes @ 2016-12-12 9:48 UTC (permalink / raw)
To: linux-arm-kernel
A bootloader may start the watchdog device before handing control to
the kernel - in that case, we should tell the kernel about it so the
watchdog framework can keep it alive until userspace opens
/dev/watchdog0.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/watchdog/bcm2835_wdt.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
index 4dddd82..c32c45b 100644
--- a/drivers/watchdog/bcm2835_wdt.c
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -55,6 +55,15 @@ struct bcm2835_wdt {
static unsigned int heartbeat;
static bool nowayout = WATCHDOG_NOWAYOUT;
+static bool bcm2835_wdt_is_running(struct bcm2835_wdt *wdt)
+{
+ uint32_t cur;
+
+ cur = readl(wdt->base + PM_RSTC);
+
+ return !!(cur & PM_RSTC_WRCFG_FULL_RESET);
+}
+
static int bcm2835_wdt_start(struct watchdog_device *wdog)
{
struct bcm2835_wdt *wdt = watchdog_get_drvdata(wdog);
@@ -181,6 +190,17 @@ static int bcm2835_wdt_probe(struct platform_device *pdev)
watchdog_init_timeout(&bcm2835_wdt_wdd, heartbeat, dev);
watchdog_set_nowayout(&bcm2835_wdt_wdd, nowayout);
bcm2835_wdt_wdd.parent = &pdev->dev;
+ if (bcm2835_wdt_is_running(wdt)) {
+ /*
+ * The currently active timeout value (set by the
+ * bootloader) may be different from the module
+ * heartbeat parameter or the value in device
+ * tree. But we just need to set WDOG_HW_RUNNING,
+ * because then the framework will "immediately" ping
+ * the device, updating the timeout.
+ */
+ set_bit(WDOG_HW_RUNNING, &bcm2835_wdt_wdd.status);
+ }
err = watchdog_register_device(&bcm2835_wdt_wdd);
if (err) {
dev_err(dev, "Failed to register watchdog device");
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: mm: Fix NOMAP page initialization
From: Yisheng Xie @ 2016-12-12 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83d6e6d0-cfb3-ec8b-241b-ec6a50dc2aa9@huawei.com>
hi Robert,
On 2016/12/12 11:12, Yisheng Xie wrote:
> hi Robert,
>
> On 2016/12/10 2:10, Robert Richter wrote:
>> On ThunderX systems with certain memory configurations we see the
>> following BUG_ON():
>>
>> kernel BUG at mm/page_alloc.c:1848!
>>
>> This happens for some configs with 64k page size enabled. The BUG_ON()
>> checks if start and end page of a memmap range belongs to the same
>> zone.
>>
>> The BUG_ON() check fails if a memory zone contains NOMAP regions. In
>> this case the node information of those pages is not initialized. This
>> causes an inconsistency of the page links with wrong zone and node
>> information for that pages. NOMAP pages from node 1 still point to the
>> mem zone from node 0 and have the wrong nid assigned.
>>
> The patch can work for zone contains NOMAP regions.
>
> However, if BIOS do not add WB/WT/WC attribute to a physical address range, the
> is_memory(md) will return false and this range will not be added to memblock.
> efi_init
> -> reserve_regions
> if (is_memory(md)) {
> early_init_dt_add_memory_arch(paddr, size);
>
> if (!is_usable_memory(md))
> memblock_mark_nomap(paddr, size);
> }
>
> Then BUG_ON() check will also fails. Any idea about it?
>
It seems that memblock_is_memory() is also too strict for early_pfn_valid,
so what about this patch, which use common pfn_valid as early_pfn_valid
when CONFIG_HAVE_ARCH_PFN_VALID=y:
------------
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0f088f3..9d596f3 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -1200,7 +1200,17 @@ static inline int pfn_present(unsigned long pfn)
#define pfn_to_nid(pfn) (0)
#endif
+#ifdef CONFIG_HAVE_ARCH_PFN_VALID
+static inline int early_pfn_valid(unsigned long pfn)
+{
+ if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
+ return 0;
+ return valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
+}
+#define early_pfn_valid early_pfn_valid
+#else
#define early_pfn_valid(pfn) pfn_valid(pfn)
+#endif
void sparse_init(void);
#else
#define sparse_init() do {} while (0)
^ permalink raw reply related
* [PATCH 3/8] rtc: add STM32 RTC driver
From: Amelie DELAUNAY @ 2016-12-12 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183709.tbkapu34ljlg4skp@piout.net>
Hi Alexandre,
On 12/07/2016 07:37 PM, Alexandre Belloni wrote:
> On 05/12/2016 at 10:43:14 +0100, Amelie DELAUNAY wrote :
>>>> +
>>>> + device_init_wakeup(&pdev->dev, true);
>>>
>>> What happens if device_init_wakeup() returns an error?
>> It means that RTC won't be able to wake up the board with RTC alarm. I can
>> add a warning for the user in this case ?
>>>
>
> There is exactly one driver ever checking the return value of
> device_init_wakeup(). It basically always succeeds.
>
>
OK so, is it OK for everyone that I bet on the fact that it will always
succeed?
^ permalink raw reply
* 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
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