* [GIT PULL 2/4] DaVinci SoC updates for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-1-nsekhar@ti.com>
The following changes since commit ced95ac0815501f47a6041548d70d8900400912d:
ARM: davinci: da8xx: register USB PHY clocks in the DT file (2016-11-01 15:24:24 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/soc-2
for you to fetch changes up to 7e431af8fa0b9ed9d74378c99514856211cb9db8:
ARM: davinci: PM: support da8xx DT platforms (2016-11-16 14:45:07 +0530)
----------------------------------------------------------------
Adds suspend-to-RAM support for DT boot mode
on DA850.
----------------------------------------------------------------
Kevin Hilman (1):
ARM: davinci: PM: support da8xx DT platforms
arch/arm/mach-davinci/da8xx-dt.c | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [GIT PULL 3/4] DaVinci DT updates for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-1-nsekhar@ti.com>
The following changes since commit 1b499f255589204466d8f8ab26e6b577d7b5c88f:
ARM: dts: da850: Add cfgchip syscon node (2016-11-01 15:11:10 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/dt-2
for you to fetch changes up to 83de086cc89410a8d4e0b6345e8a1116797ea703:
ARM: dts: da850-lcdk: Enable the usb otg device node (2016-11-20 17:02:18 +0530)
----------------------------------------------------------------
Adds device tree nodes enabling DDR controller
and bus master priority settings needed for
stable LCDC operation on DA850.
Also adds support for MUSB device on DA850
providing USB OTG support.
----------------------------------------------------------------
Alexandre Bailon (2):
ARM: dts: da850: Add the usb otg device node
ARM: dts: da850-lcdk: Enable the usb otg device node
Bartosz Golaszewski (1):
ARM: dts: da850: add the mstpri and ddrctl nodes
arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
arch/arm/boot/dts/da850.dtsi | 18 ++++++++++++++++++
2 files changed, 26 insertions(+)
^ permalink raw reply
* [GIT PULL 4/4] DaVinci defconfig updates for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-1-nsekhar@ti.com>
The following changes since commit 6e9be8608771192851a3adf59f0ba9240e3f802c:
ARM: davinci_all_defconfig: enable LED default-on trigger (2016-11-01 11:42:54 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/defconfig-2
for you to fetch changes up to a652baa06413a4beacc09425883e518c5f1ed100:
ARM: davinci_all_defconfig: add missing options for systemd (2016-11-15 15:44:52 +0530)
----------------------------------------------------------------
Enables newly introduced DDR controller and
master priority setting drivers in kernel.
Also, update defconfig to boot latest systemd
based filesystems on DA850.
----------------------------------------------------------------
Bartosz Golaszewski (1):
ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
Sekhar Nori (1):
ARM: davinci_all_defconfig: add missing options for systemd
arch/arm/configs/davinci_all_defconfig | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Jörg Krause @ 2016-11-20 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <585759233.283839.1cb53b4d-2805-48ea-aef1-dd282306d108.open-xchange@email.1und1.de>
Hi Stefan,
On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> Hi J?rg,
>
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016
> > um 13:27
> > geschrieben:
> >
> >
> > Hi,
> >
> > I started the discussion on this mailing list in another thread
> > [1],
> > but I'd like to move it to a new thread, because it might be mmc
> > specific.
> >
> > The issue is that I am noticed low wifi network throughput on an
> > i.MX28
> > board with the mainline kernel (v4.7.10, about 6 Mbps) compared to
> > the
> > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The wifi chip
> > is
> > attached using the SDIO interface.
> >
> > I started investigation where the bottleneck in the mainline
> > kernel?might come from. Therefore I checked that the configs and
> > settings for the interfaces and drivers are the same. They are.
>
> so you're not using the mxs_defconfig settings anymore?
No, I changed the settings.
> Better provide your settings because there are differences between
> the vendor defconfig and mainline defconfig.
The configs I have for the vendor and mainline kernel are pretty much
the same for the parts you showed as an example:
Vendor kernel config:
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_HZ=100
CONFIG_DEFAULT_IOSCHED="cfq"
Mainline kernel config:
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_HZ=100
CONFIG_DEFAULT_IOSCHED="cfq"
J?rg
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-11-20 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9f36244f-62d4-08e3-d64a-2b04ad4dc2e0@arm.com>
Hi Robin,
>Hi Robin,
>
>>Hi Robin,
>>
>>>On 04/11/16 15:16, Sricharan wrote:
>>>> Hi Robin,
>>>>
>>>>>>> Yikes, on second look, that definitely shouldn't be happening.
>>>>>>> Everything below is probably the resulting fallout.
>>>>>>
>>>>>> [ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>>>>>>
>>>>>> I think the above print which says "failed to setup iommu_ops"
>>>>>> because the call ops->add_device failed in of_pci_iommu_configure
>>>>>> is the reason for the failure, in my case i simply do not get this even with
>>>>>> your scripts. ops->add_device succeeds in the rebind as well. So still
>>>>>> checking what could be happening in your case.
>>>>>
>>>>> I was looking at your code base from [1].The ops->add_device
>>>>> callback from of_pci_iommu_configure on the rebind is the
>>>>> one which is causing the failure. But not able to spot out
>>>>>from code which point is causing the failure. It would be very helpful
>>>>> if i can know which is the return value from the add_device callback
>>>>> or point inside add_device callback which fails in your setup.
>>>>>
>>>>>
>>>>> [1] git://linux-arm.org/linux-rm iommu/misc
>>>>
>>>> With little more try, i saw an issue where i had an failure
>>>> similar to what you reported. The issue happens when multiple
>>>> devices fall in to same group due to matching sids. I ended up
>>>> doing a fix like below and it would be nice to verify if it is the same
>>>> that we are seeing in your setup and if the fix makes a difference ?
>>>>
>>>> From: Sricharan R <sricharan@codeaurora.org>
>>>> Date: Fri, 4 Nov 2016 20:28:49 +0530
>>>> Subject: [PATCH] iommu/arm-smmu: Fix group's reference counting
>>>>
>>>> iommu_group_get_for_dev which gets called in the add_device
>>>> callback, increases the reference count of the iommu_group,
>>>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>>>> inturn calls device_group callback and in the case of arm-smmu
>>>> we call generic_device_group/pci_device_group which takes
>>>> care of increasing the group's reference. But when we return
>>>> an already existing group(when multiple devices have same group)
>>>> the reference is not incremented, resulting in issues when the
>>>> remove_device callback for the devices is invoked.
>>>> Fixing the same here.
>>>
>>>Bah, yes, this does look like my fault - after flip-flopping between
>>>about 3 different ways to keep refcounts for the S2CR entries, none of
>>>which would quite work, I ripped it all out but apparently still got
>>>things wrong, oh well. Thanks for figuring it out.
>> >
>>>On the probe-deferral angle, whilst it's useful to have uncovered this
>>>bug, I don't think we should actually be calling remove_device() from
>>>DMA teardown. I think it's preferable from a user perspective if group
>>>numbering remains stable, rather than changing depending on the order in
>>>which they unbind/rebind VFIO drivers. I'm really keen to try and get
>>>this in shape for 4.10, so I've taken the liberty of hacking up my own
>>>branch (iommu/defer) based on v3 - would you mind taking a look at the
>>>two "iommu/of:" commits to see what you think? (Ignore the PCI changes
>>>to your later patches - that was an experiment which didn't really work out)
>>
>>Ok, will take a look at this now and respond more on this.
>>
>Sorry for the delayed response on this. I was OOO for the last few days.
>So i tested this branch and it worked fine. I tested it with a pci device
>for both normal and deferred probe cases. The of/iommu patches
>are the cleanup/preparation patches and it looks fine. One thing is without
>calling the remove_device callback, the resources like (smes for exmaple)
>and the group association of the device all remain allocated. That does not
>feel correct, given that the associated device does not exist. So to
>understand that, what happens with VFIO in this case which makes the
>group renumbering/rebinding a problem ?
>
Would it be ok if i post a V4 based on your branch above ?
Regards,
Sricharan
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Stefan Wahren @ 2016-11-20 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479652929.2841.1.camel@embedded.rocks>
> J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016 um 15:42
> geschrieben:
>
>
> Hi Stefan,
>
> On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> > Hi J?rg,
> >
> > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016
> > > um 13:27
> > > geschrieben:
> > >
> > >
> > > Hi,
> > >
> > > I started the discussion on this mailing list in another thread
> > > [1],
> > > but I'd like to move it to a new thread, because it might be mmc
> > > specific.
> > >
> > > The issue is that I am noticed low wifi network throughput on an
> > > i.MX28
> > > board with the mainline kernel (v4.7.10, about 6 Mbps) compared to
> > > the
> > > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The wifi chip
> > > is
> > > attached using the SDIO interface.
> > >
> > > I started investigation where the bottleneck in the mainline
> > > kernel?might come from. Therefore I checked that the configs and
> > > settings for the interfaces and drivers are the same. They are.
> >
> > so you're not using the mxs_defconfig settings anymore?
>
> No, I changed the settings.
>
What happens to performance to if you change the following settings to the same
like in mxs_defconfig?
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_DEFAULT_IOSCHED="noop"
^ permalink raw reply
* [PATCH] spi: davinci: Allow device tree devices to use DMA
From: David Lechner @ 2016-11-20 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79f186b5-ac71-189f-c19f-977670395043@ti.com>
On 11/20/2016 06:59 AM, Sekhar Nori wrote:
> On Saturday 19 November 2016 10:11 AM, David Lechner wrote:
>> This makes SPI devices specified in a device tree use DMA when the master
>> controller has DMA configured.
>>
>> Since device tree is supposed to only describe the hardware, adding a
>> configuration option to device tree to enable DMA per-device would not be
>> acceptable. So, this is the best we can do for now to get SPI devices
>> working with DMA when using device tree.
>>
>> Unfortunately, this excludes the possibility of using one SPI device with
>> DMA and one without on the same master.
>>
>> I have tested this on LEGO MINDSTORMS EV3 using the NOR flash. Reading the
>> flash memory would fail with -EIO when DMA is not enabled for the device.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> drivers/spi/spi-davinci.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
>> index d36c11b..c6cf73a 100644
>> --- a/drivers/spi/spi-davinci.c
>> +++ b/drivers/spi/spi-davinci.c
>> @@ -388,6 +388,7 @@ static int davinci_spi_setup_transfer(struct spi_device *spi,
>> static int davinci_spi_of_setup(struct spi_device *spi)
>> {
>> struct davinci_spi_config *spicfg = spi->controller_data;
>> + struct davinci_spi *dspi = spi_master_get_devdata(spi->master);
>> struct device_node *np = spi->dev.of_node;
>> u32 prop;
>>
>> @@ -400,6 +401,9 @@ static int davinci_spi_of_setup(struct spi_device *spi)
>> if (!of_property_read_u32(np, "ti,spi-wdelay", &prop))
>> spicfg->wdelay = (u8)prop;
>> spi->controller_data = spicfg;
>> + /* Use DMA for device if master supports it */
>> + if (dspi->dma_rx)
>
> This should be
>
> if (!(IS_ERR(dpsi->dma_rx) || IS_ERR(dspi->dma_tx))
There is the following code in davinci_spi_probe():
ret = davinci_spi_request_dma(dspi);
if (ret == -EPROBE_DEFER) {
goto free_clk;
} else if (ret) {
dev_info(&pdev->dev, "DMA is not supported (%d)\n", ret);
dspi->dma_rx = NULL;
dspi->dma_tx = NULL;
}
So, I does not look like it is possible to get anything other than NULL
or a valid pointer for dpsi->dma_rx and that checking dpsi->dma_tx is
not necessary.
So, I think if (dspi->dma_rx) is sufficient. In fact the same check is
used during unwinding if the probe function fails.
>
>> + spicfg->io_type = SPI_IO_TYPE_DMA;
>
> Otherwise looks good to me.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Nicolas Pitre @ 2016-11-20 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120132502.GV1041@n2100.armlinux.org.uk>
On Sun, 20 Nov 2016, Russell King - ARM Linux wrote:
> On Sun, Nov 20, 2016 at 01:56:16PM +0100, Tobias Jakobi wrote:
> > Hey Russell,
> >
> > thanks for the quick reply and looking into this!
> >
> > Added Nicolas Pitre to Cc since the ksym trim stuff came from him.
>
> Arnd's patch "kbuild: provide include/asm/asm-prototypes.h for ARM" fixes
> it, but I think it's a mixture of fixes, and partially dependent on some
> other patches. I don't know what the status of his patch is, but my
> feeling is that it consists of more than a single fix, and needs
> splitting. Certainly the asm-prototypes.h is not relevant to this
> problem, but the rest of it seems to be.
Well... the problem for the current breakage was identified a while ago:
https://lkml.org/lkml/2016/2/10/686
I'm surprised that Al didn't fold my patch into his. Now that this has
hit mainline, CONFIG_TRIM_UNUSED_KSYMS is now broken on ARM.
And I don't see how the asm-prototypes.h is going to fix it either (if
anything, at the moment it looks like it might be another source of
breakage).
So I think the folowing patch should go into mainline:
----- >8
>From 3225f625c116a350c54f361df491bf3e1c6d32b3 Mon Sep 17 00:00:00 2001
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Wed, 10 Feb 2016 17:40:04 -0500
Subject: [PATCH] ARM: don't use assembler macro arguments with EXPORT_SYMBOL()
Committ 4dd1837d75 ("arm: move exports to definitions") added
EXPORT_SYMBOL(\name) to bitops.h. Here \name is an assembler macro
argument which is not subject to preprocessor substitutions. And the
assembler doesn't handle preprocessor macros either. That has the effect
of breaking CONFIG_TRIM_UNUSED_KSYMS=y.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
index df06638b32..7d807cfd8e 100644
--- a/arch/arm/lib/bitops.h
+++ b/arch/arm/lib/bitops.h
@@ -1,6 +1,5 @@
#include <asm/assembler.h>
#include <asm/unwind.h>
-#include <asm/export.h>
#if __LINUX_ARM_ARCH__ >= 6
.macro bitop, name, instr
@@ -26,7 +25,6 @@ UNWIND( .fnstart )
bx lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
.macro testop, name, instr, store
@@ -57,7 +55,6 @@ UNWIND( .fnstart )
2: bx lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
#else
.macro bitop, name, instr
@@ -77,7 +74,6 @@ UNWIND( .fnstart )
ret lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
/**
@@ -106,6 +102,5 @@ UNWIND( .fnstart )
ret lr
UNWIND( .fnend )
ENDPROC(\name )
-EXPORT_SYMBOL(\name )
.endm
#endif
diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
index f402786217..1cfdb138d2 100644
--- a/arch/arm/lib/changebit.S
+++ b/arch/arm/lib/changebit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
bitop _change_bit, eor
+
+EXPORT_SYMBOL(_change_bit)
diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
index f6b75fb64d..e901ca5af0 100644
--- a/arch/arm/lib/clearbit.S
+++ b/arch/arm/lib/clearbit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
bitop _clear_bit, bic
+
+EXPORT_SYMBOL(_clear_bit)
diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
index 618fedae4b..3c8b11240f 100644
--- a/arch/arm/lib/setbit.S
+++ b/arch/arm/lib/setbit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
bitop _set_bit, orr
+
+EXPORT_SYMBOL(_set_bit)
diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
index 4becdc3a59..e3d19b87fb 100644
--- a/arch/arm/lib/testchangebit.S
+++ b/arch/arm/lib/testchangebit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
testop _test_and_change_bit, eor, str
+
+EXPORT_SYMBOL(_test_and_change_bit)
diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
index 918841dcce..d247e6f70f 100644
--- a/arch/arm/lib/testclearbit.S
+++ b/arch/arm/lib/testclearbit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
testop _test_and_clear_bit, bicne, strne
+
+EXPORT_SYMBOL(_test_and_clear_bit)
diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
index 8d1b2fe9e4..76800ff601 100644
--- a/arch/arm/lib/testsetbit.S
+++ b/arch/arm/lib/testsetbit.S
@@ -9,7 +9,10 @@
*/
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/export.h>
#include "bitops.h"
.text
testop _test_and_set_bit, orreq, streq
+
+EXPORT_SYMBOL(_test_and_set_bit)
^ permalink raw reply related
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-11-20 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117151805.GJ2151@rric.localdomain>
On 17 November 2016 at 15:18, Robert Richter <robert.richter@cavium.com> wrote:
> Thanks for your answer.
>
> On 17.11.16 14:25:29, Will Deacon wrote:
>> On Wed, Nov 09, 2016 at 08:51:32PM +0100, Robert Richter wrote:
>> > Thus, I don't see where my patch breaks code. Even acpi_os_ioremap()
>> > keeps the same behaviour as before since it still uses memblock_is_
>> > memory(). Could you more describe your concerns why do you think this
>> > patch breaks the kernel and moves the problem somewhere else? I
>> > believe it fixes the problem at all.
>>
>> acpi_os_ioremap always ends up in __ioremap_caller, regardless of
>> memblock_is_memory(). __ioremap_caller then fails if pfn_valid is true.
>
> But that's the reason my patch changed the code to use memblock_is_
> map_memory() instead. I was looking into the users of pfn_valid() esp.
> in arm64 code and changed it where required.
>
> This week I looked into the kernel again for code that might break by
> a pfn_valid() change. I found try_ram_remap() in memremap.c that has
> changed behaviour now, but this is explicit for MEMREMAP_WB, so it
> should be fine.
>
> Maybe it might be better to use page_is_ram() in addition to
> pfn_valid() where necessary. This should work now after commit:
>
> e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
>
> I still think pfn_valid() is not the correct use to determine the mem
> attributes for mappings, there are further checks required.
>
> The risk of breaking something with my patch is small and limited only
> to the mapping of efi reserved regions (which is the state of 4.4). If
> something breaks anyway it can easily be fixed by adding more checks
> to pfn_valid() as suggested above.
>
As I noted before, it looks to me like setting CONFIG_HOLES_IN_ZONE is
the correct way to address this. However, doing that does uncover a
bug in move_freepages() where the VM_BUG_ON_PAGE() dereferences struct
page fields before the pfn_valid_within() check, so it seems those
need to be switched around.
Robert, you mentioned that CONFIG_HOLES_IN_ZONE seems inappropriate
for sparsemem. Care to elaborate why?
^ permalink raw reply
* commit 4dd1837d7589f468ed109556513f476e7a7f9121 breaks build
From: Russell King - ARM Linux @ 2016-11-20 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.20.1611201131300.1814@knanqh.ubzr>
On Sun, Nov 20, 2016 at 12:03:50PM -0500, Nicolas Pitre wrote:
> On Sun, 20 Nov 2016, Russell King - ARM Linux wrote:
>
> > On Sun, Nov 20, 2016 at 01:56:16PM +0100, Tobias Jakobi wrote:
> > > Hey Russell,
> > >
> > > thanks for the quick reply and looking into this!
> > >
> > > Added Nicolas Pitre to Cc since the ksym trim stuff came from him.
> >
> > Arnd's patch "kbuild: provide include/asm/asm-prototypes.h for ARM" fixes
> > it, but I think it's a mixture of fixes, and partially dependent on some
> > other patches. I don't know what the status of his patch is, but my
> > feeling is that it consists of more than a single fix, and needs
> > splitting. Certainly the asm-prototypes.h is not relevant to this
> > problem, but the rest of it seems to be.
>
> Well... the problem for the current breakage was identified a while ago:
>
> https://lkml.org/lkml/2016/2/10/686
>
> I'm surprised that Al didn't fold my patch into his. Now that this has
> hit mainline, CONFIG_TRIM_UNUSED_KSYMS is now broken on ARM.
>
> And I don't see how the asm-prototypes.h is going to fix it either (if
> anything, at the moment it looks like it might be another source of
> breakage).
>
> So I think the folowing patch should go into mainline:
... which looks the same as Arnd's patch with the following changes:
- no asm-prototypes.h
- adding asm/export.h to each file using EXPORT_SYMBOL() instead of
bitops.h
- not touching:
arch/arm/lib/csumpartialcopy.S
arch/arm/lib/csumpartialcopygeneric.S
arch/arm/lib/csumpartialcopyuser.S
other than that, it's doing the same thing.
I think Arnd's changes to the csumpartial code are unnecessary, and
yours is, although larger, puts the asm/export.h include in the right
place. So please drop yours into the patch system so we can move
forward fixing some of the problems created during the last merge
window.
> ----- >8
> >From 3225f625c116a350c54f361df491bf3e1c6d32b3 Mon Sep 17 00:00:00 2001
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
> Date: Wed, 10 Feb 2016 17:40:04 -0500
> Subject: [PATCH] ARM: don't use assembler macro arguments with EXPORT_SYMBOL()
>
> Committ 4dd1837d75 ("arm: move exports to definitions") added
> EXPORT_SYMBOL(\name) to bitops.h. Here \name is an assembler macro
> argument which is not subject to preprocessor substitutions. And the
> assembler doesn't handle preprocessor macros either. That has the effect
> of breaking CONFIG_TRIM_UNUSED_KSYMS=y.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/arch/arm/lib/bitops.h b/arch/arm/lib/bitops.h
> index df06638b32..7d807cfd8e 100644
> --- a/arch/arm/lib/bitops.h
> +++ b/arch/arm/lib/bitops.h
> @@ -1,6 +1,5 @@
> #include <asm/assembler.h>
> #include <asm/unwind.h>
> -#include <asm/export.h>
>
> #if __LINUX_ARM_ARCH__ >= 6
> .macro bitop, name, instr
> @@ -26,7 +25,6 @@ UNWIND( .fnstart )
> bx lr
> UNWIND( .fnend )
> ENDPROC(\name )
> -EXPORT_SYMBOL(\name )
> .endm
>
> .macro testop, name, instr, store
> @@ -57,7 +55,6 @@ UNWIND( .fnstart )
> 2: bx lr
> UNWIND( .fnend )
> ENDPROC(\name )
> -EXPORT_SYMBOL(\name )
> .endm
> #else
> .macro bitop, name, instr
> @@ -77,7 +74,6 @@ UNWIND( .fnstart )
> ret lr
> UNWIND( .fnend )
> ENDPROC(\name )
> -EXPORT_SYMBOL(\name )
> .endm
>
> /**
> @@ -106,6 +102,5 @@ UNWIND( .fnstart )
> ret lr
> UNWIND( .fnend )
> ENDPROC(\name )
> -EXPORT_SYMBOL(\name )
> .endm
> #endif
> diff --git a/arch/arm/lib/changebit.S b/arch/arm/lib/changebit.S
> index f402786217..1cfdb138d2 100644
> --- a/arch/arm/lib/changebit.S
> +++ b/arch/arm/lib/changebit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> bitop _change_bit, eor
> +
> +EXPORT_SYMBOL(_change_bit)
> diff --git a/arch/arm/lib/clearbit.S b/arch/arm/lib/clearbit.S
> index f6b75fb64d..e901ca5af0 100644
> --- a/arch/arm/lib/clearbit.S
> +++ b/arch/arm/lib/clearbit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> bitop _clear_bit, bic
> +
> +EXPORT_SYMBOL(_clear_bit)
> diff --git a/arch/arm/lib/setbit.S b/arch/arm/lib/setbit.S
> index 618fedae4b..3c8b11240f 100644
> --- a/arch/arm/lib/setbit.S
> +++ b/arch/arm/lib/setbit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> bitop _set_bit, orr
> +
> +EXPORT_SYMBOL(_set_bit)
> diff --git a/arch/arm/lib/testchangebit.S b/arch/arm/lib/testchangebit.S
> index 4becdc3a59..e3d19b87fb 100644
> --- a/arch/arm/lib/testchangebit.S
> +++ b/arch/arm/lib/testchangebit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> testop _test_and_change_bit, eor, str
> +
> +EXPORT_SYMBOL(_test_and_change_bit)
> diff --git a/arch/arm/lib/testclearbit.S b/arch/arm/lib/testclearbit.S
> index 918841dcce..d247e6f70f 100644
> --- a/arch/arm/lib/testclearbit.S
> +++ b/arch/arm/lib/testclearbit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> testop _test_and_clear_bit, bicne, strne
> +
> +EXPORT_SYMBOL(_test_and_clear_bit)
> diff --git a/arch/arm/lib/testsetbit.S b/arch/arm/lib/testsetbit.S
> index 8d1b2fe9e4..76800ff601 100644
> --- a/arch/arm/lib/testsetbit.S
> +++ b/arch/arm/lib/testsetbit.S
> @@ -9,7 +9,10 @@
> */
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/export.h>
> #include "bitops.h"
> .text
>
> testop _test_and_set_bit, orreq, streq
> +
> +EXPORT_SYMBOL(_test_and_set_bit)
--
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
* mmc: core: complete/wait_for_completion performance
From: Jörg Krause @ 2016-11-20 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <187975187.249177.bccdc17e-e9c6-48c2-aeaf-3b81f1b61ec7.open-xchange@email.1und1.de>
On Sun, 2016-11-20 at 16:44 +0100, Stefan Wahren wrote:
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016
> > um 15:42
> > geschrieben:
> >
> >
> > Hi Stefan,
> >
> > On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> > > Hi J?rg,
> > >
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November
> > > > 2016
> > > > um 13:27
> > > > geschrieben:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I started the discussion on this mailing list in another thread
> > > > [1],
> > > > but I'd like to move it to a new thread, because it might be
> > > > mmc
> > > > specific.
> > > >
> > > > The issue is that I am noticed low wifi network throughput on
> > > > an
> > > > i.MX28
> > > > board with the mainline kernel (v4.7.10, about 6 Mbps) compared
> > > > to
> > > > the
> > > > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The wifi
> > > > chip
> > > > is
> > > > attached using the SDIO interface.
> > > >
> > > > I started investigation where the bottleneck in the mainline
> > > > kernel?might come from. Therefore I checked that the configs
> > > > and
> > > > settings for the interfaces and drivers are the same. They are.
> > >
> > > so you're not using the mxs_defconfig settings anymore?
> >
> > No, I changed the settings.
> >
>
> What happens to performance to if you change the following settings
> to the same
> like in mxs_defconfig?
>
> CONFIG_PREEMPT_VOLUNTARY=y
> CONFIG_DEFAULT_IOSCHED="noop"
No much change at all. The time difference between complete() and
wait_for_complete() decreases in best case to 110 us, but also varies
to above 130 us.
^ permalink raw reply
* [PATCH] arm: spin one more cycle in timer-based delays
From: Doug Anderson @ 2016-11-20 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119110301.GQ1041@n2100.armlinux.org.uk>
Hi,
On Sat, Nov 19, 2016 at 3:03 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> Linus, how about we add something like this to linux/delay.h to document
> this fact?
>
> include/linux/delay.h | 12 +++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/linux/delay.h b/include/linux/delay.h
> index a6ecb34cf547..2ecb3c46b20a 100644
> --- a/include/linux/delay.h
> +++ b/include/linux/delay.h
> @@ -5,6 +5,18 @@
> * Copyright (C) 1993 Linus Torvalds
> *
> * Delay routines, using a pre-computed "loops_per_jiffy" value.
> + *
> + * Please note that ndelay(), udelay() and mdelay() may return early for
> + * several reasons:
> + * 1. computed loops_per_jiffy too low (due to the time taken to
> + * execute the timer interrupt.)
> + * 2. cache behaviour affecting the time it takes to execute the
> + * loop function.
> + * 3. CPU clock rate changes.
> + * As a result, delays should always be over-stated.
> + *
> + * Please see this thread:
> + * http://lists.openwall.net/linux-kernel/2011/01/09/56
> */
Any reason not to land Mason's patch _and_ land your comment change.
They you eliminate the arbitrary/pointless inaccuracy but still
reinforce that delays are not accurate.
^ permalink raw reply
* [RFC PATCH v2 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-11-20 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479478912-14067-1-git-send-email-andrei.pistirica@microchip.com>
On Fri, Nov 18, 2016 at 03:21:51PM +0100, Andrei Pistirica wrote:
> - Frequency adjustment is not directly supported by this IP.
This statement still makes no sense. Doesn't the following text...
> addend is the initial value ns increment and similarly addendesub.
> The ppb (parts per billion) provided is used as
> ns_incr = addend +/- (ppb/rate).
> Similarly the remainder of the above is used to populate subns increment.
describe how frequency adjustment is in fact supported?
> +config MACB_USE_HWSTAMP
> + bool "Use IEEE 1588 hwstamp"
> + depends on MACB
> + default y
> + select PTP_1588_CLOCK
This "select" pattern is going to be replaced with "imply" soon.
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1269181.html
You should use the new "imply" key word and reference that series in
your change log.
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index 3f385ab..2ee9af8 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -10,6 +10,10 @@
> #ifndef _MACB_H
> #define _MACB_H
>
> +#include <linux/net_tstamp.h>
> +#include <linux/ptp_clock.h>
> +#include <linux/ptp_clock_kernel.h>
Don't need net_tstamp.h here. Move it into the .c file please.
> @@ -840,8 +902,26 @@ struct macb {
>
> unsigned int rx_frm_len_mask;
> unsigned int jumbo_max_len;
> +
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> + unsigned int hwts_tx_en;
> + unsigned int hwts_rx_en;
These two can be bool'eans.
> + spinlock_t tsu_clk_lock;
> + unsigned int tsu_rate;
> +
> + struct ptp_clock *ptp_clock;
> + struct ptp_clock_info ptp_caps;
> + unsigned int ns_incr;
> + unsigned int subns_incr;
These two are 32 bit register values, right? Then use the u32 type.
> +#endif
> };
> +static inline void macb_tsu_set_time(struct macb *bp,
> + const struct timespec64 *ts)
> +{
> + u32 ns, sech, secl;
> + s64 word_mask = 0xffffffff;
> +
> + sech = (u32)ts->tv_sec;
> + secl = (u32)ts->tv_sec;
> + ns = ts->tv_nsec;
> + if (ts->tv_sec > word_mask)
> + sech = (ts->tv_sec >> 32);
> +
> + spin_lock(&bp->tsu_clk_lock);
> +
> + /* TSH doesn't latch the time and no atomicity! */
> + gem_writel(bp, TSH, sech);
> + gem_writel(bp, TSL, secl);
If TN overflows here then the clock will be off by one whole second!
Why not clear TN first?
> + gem_writel(bp, TN, ns);
> +
> + spin_unlock(&bp->tsu_clk_lock);
> +}
> +
> +static int macb_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> +{
> + struct macb *bp = container_of(ptp, struct macb, ptp_caps);
> + u32 addend, addend_frac, rem;
> + u64 drift_tmr, diff, diff_frac = 0;
> + int neg_adj = 0;
> +
> + if (ppb < 0) {
> + neg_adj = 1;
> + ppb = -ppb;
> + }
> +
> + /* drift/period */
> + drift_tmr = (bp->ns_incr * ppb) +
> + ((bp->subns_incr * ppb) >> 16);
What? Why the 16 bit shift? Last time your said it was 24 bits.
> + /* drift/cycle */
> + diff = div_u64_rem(drift_tmr, 1000000000ULL, &rem);
> +
> + /* drift fraction/cycle, if necessary */
> + if (rem) {
> + u64 fraction = rem;
> + fraction = fraction << 16;
> +
> + diff_frac = div_u64(fraction, 1000000000ULL);
If you use a combined tuning word like I explained last time, then you
will not need a second division.
Also, please use the new adjfine() PHC method, as adjfreq() is now deprecated.
> + }
> +
> + /* adjustmets */
> + addend = neg_adj ? (bp->ns_incr - diff) : (bp->ns_incr + diff);
> + addend_frac = neg_adj ? (bp->subns_incr - diff_frac) :
> + (bp->subns_incr + diff_frac);
> +
> + spin_lock(&bp->tsu_clk_lock);
> +
> + gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, addend_frac));
> + gem_writel(bp, TI, GEM_BF(NSINCR, addend));
> +
> + spin_unlock(&bp->tsu_clk_lock);
> + return 0;
> +}
> +void macb_ptp_init(struct net_device *ndev)
> +{
> + struct macb *bp = netdev_priv(ndev);
> + struct timespec64 now;
> + u32 rem = 0;
> +
> + if (!(bp->caps | MACB_CAPS_GEM_HAS_PTP)){
> + netdev_vdbg(bp->dev, "Platform does not support PTP!\n");
> + return;
> + }
> +
> + spin_lock_init(&bp->tsu_clk_lock);
> +
> + bp->ptp_caps = macb_ptp_caps;
> + bp->tsu_rate = clk_get_rate(bp->pclk);
> +
> + getnstimeofday64(&now);
> + macb_tsu_set_time(bp, (const struct timespec64 *)&now);
> +
> + bp->ns_incr = div_u64_rem(NSEC_PER_SEC, bp->tsu_rate, &rem);
> + if (rem) {
> + u64 adj = rem;
> + /* Multiply by 2^16 as subns register is 16 bits */
Last time you said:
> + /* Multiple by 2^24 as subns field is 24 bits */
> + adj <<= 16;
> + bp->subns_incr = div_u64(adj, bp->tsu_rate);
> + } else {
> + bp->subns_incr = 0;
> + }
> +
> + gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, bp->subns_incr));
> + gem_writel(bp, TI, GEM_BF(NSINCR, bp->ns_incr));
> + gem_writel(bp, TA, 0);
> +
> + bp->ptp_clock = ptp_clock_register(&bp->ptp_caps, NULL);
You call regsiter, but you never call unregister!
> + if (IS_ERR(&bp->ptp_clock)) {
> + bp->ptp_clock = NULL;
> + pr_err("ptp clock register failed\n");
> + return;
> + }
> +
> + dev_info(&bp->pdev->dev, "%s ptp clock registered.\n", GMAC_TIMER_NAME);
> +}
> +
> --
> 1.9.1
>
Thanks,
Richard
^ permalink raw reply
* [PATCH] arm: spin one more cycle in timer-based delays
From: Doug Anderson @ 2016-11-20 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58309A02.4030804@free.fr>
Hi,
On Sat, Nov 19, 2016 at 10:29 AM, Mason <slash.tmp@free.fr> wrote:
>> Exactly - and the reason for that (as I've explained several times in
>> the past) the "standard" software delay loop calibrated against the
>> timer interrupt is _always_ going to be short.
>
> OK, so loop-based delays are known to be short. Would you or Linus
> accept a patch that adds a X% cushion *in the implementation* ?
>
> You are saying "people shouldn't expect udelay(10) to delay at least
> 10 ?s, thus they should write udelay(10+N)".
>
> Why not hide that implementation detail inside the implementation,
> so as not to force the pessimization on every other implementation
> behind the udelay/ndelay wrapper?
>
> void loop_based_udelay(long us) {
> spin_for_some_us(us + us/8);
> }
IMHO this would be an extremely sane thing to do.
Then, if you happened to be on a platform where udelay _was_ accurate
then you could eliminate the pointless overhead. ...and also if you
were writing code to a datasheet and it said "delay for 50 us between
A and B" you could actually write udelay(50) instead of everyone
needing to know that they should write "udelay(53)".
-Doug
^ permalink raw reply
* [RFT v2 0/5] ASoC: samsung: Minor cleanup for old machines
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Few patches removing dead code (machines not supported).
Changes since v1:
1. Squash two smdk_wm8580 changes into patch #2. Now num_dai_links
is always equal to two, so remove also SEC_PLAYBACK dai_link.
(suggested by Lars-Peter Clausen).
The second patch ([RFT v2 2/5] ASoC: samsung: smdk_wm8580: Remove old platforms and
drop mach-types usage) requires testing. I hope I understood the code
correctly.
The last ARM patch is independent. I will take it through samsung-soc
tree. I put it here for reference.
Best regards,
Krzysztof
Krzysztof Kozlowski (5):
ASoC: samsung: Remove non-existing MACH dependencies
ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types
usage
ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580
ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc
ARM: s5pv210_defconfig: Remove old MACHs
arch/arm/configs/s5pv210_defconfig | 4 ----
sound/soc/samsung/Kconfig | 8 +++++---
sound/soc/samsung/smdk_wm8580.c | 28 ++--------------------------
3 files changed, 7 insertions(+), 33 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/5] ASoC: samsung: Remove non-existing MACH dependencies
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-1-git-send-email-krzk@kernel.org>
MACH_SMDKC100 was removed in commit b8529ec1c1b0 ("ARM: S5PC100: no more
support S5PC100 SoC"). MACH_SMDKV210 and MACH_SMDKC110 in commit
28c8331d386 ("ARM: S5PV210: Remove support for board files").
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
sound/soc/samsung/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 79ae6a7c93ff..ea0fa9971a0c 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -49,7 +49,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110
+ depends on MACH_SMDK6410
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
--
2.7.4
^ permalink raw reply related
* [RFT v2 2/5] ASoC: samsung: smdk_wm8580: Remove old platforms and drop mach-types usage
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-1-git-send-email-krzk@kernel.org>
MACH_SMDKC100, MACH_SMDKV210 and MACH_SMDKC110 are no longer supported
so we can drop the dead code. After this the driver no longer
differentiates between machines (S3C24xx machines are not supported by
it) so there is no need to override I2S device id in cpu_dai_name and
SEC_PLAYBACK dai_link can be removed as well.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested. The driver did not override .platform_name which looks
suspicious to me. However I did not want to add changes which could have
some visible impact on output code.
Changes since v1:
1. Squash two smdk_wm8580 patches and use ARRAY_SIZE(smdk_dai), after
suggestion from Lars-Peter Clausen.
2. Remove also SEC_PLAYBACK dai_link.
---
sound/soc/samsung/smdk_wm8580.c | 30 +++---------------------------
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/sound/soc/samsung/smdk_wm8580.c b/sound/soc/samsung/smdk_wm8580.c
index 548bfd993788..de724ce7b955 100644
--- a/sound/soc/samsung/smdk_wm8580.c
+++ b/sound/soc/samsung/smdk_wm8580.c
@@ -14,8 +14,6 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include <asm/mach-types.h>
-
#include "../codecs/wm8580.h"
#include "i2s.h"
@@ -147,7 +145,6 @@ static int smdk_wm8580_init_paiftx(struct snd_soc_pcm_runtime *rtd)
enum {
PRI_PLAYBACK = 0,
PRI_CAPTURE,
- SEC_PLAYBACK,
};
#define SMDK_DAI_FMT (SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | \
@@ -157,7 +154,7 @@ static struct snd_soc_dai_link smdk_dai[] = {
[PRI_PLAYBACK] = { /* Primary Playback i/f */
.name = "WM8580 PAIF RX",
.stream_name = "Playback",
- .cpu_dai_name = "samsung-i2s.0",
+ .cpu_dai_name = "samsung-i2s.2",
.codec_dai_name = "wm8580-hifi-playback",
.platform_name = "samsung-i2s.0",
.codec_name = "wm8580.0-001b",
@@ -167,7 +164,7 @@ static struct snd_soc_dai_link smdk_dai[] = {
[PRI_CAPTURE] = { /* Primary Capture i/f */
.name = "WM8580 PAIF TX",
.stream_name = "Capture",
- .cpu_dai_name = "samsung-i2s.0",
+ .cpu_dai_name = "samsung-i2s.2",
.codec_dai_name = "wm8580-hifi-capture",
.platform_name = "samsung-i2s.0",
.codec_name = "wm8580.0-001b",
@@ -175,23 +172,13 @@ static struct snd_soc_dai_link smdk_dai[] = {
.init = smdk_wm8580_init_paiftx,
.ops = &smdk_ops,
},
- [SEC_PLAYBACK] = { /* Sec_Fifo Playback i/f */
- .name = "Sec_FIFO TX",
- .stream_name = "Playback",
- .cpu_dai_name = "samsung-i2s-sec",
- .codec_dai_name = "wm8580-hifi-playback",
- .platform_name = "samsung-i2s-sec",
- .codec_name = "wm8580.0-001b",
- .dai_fmt = SMDK_DAI_FMT,
- .ops = &smdk_ops,
- },
};
static struct snd_soc_card smdk = {
.name = "SMDK-I2S",
.owner = THIS_MODULE,
.dai_link = smdk_dai,
- .num_links = 2,
+ .num_links = ARRAY_SIZE(smdk_dai),
.dapm_widgets = smdk_wm8580_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(smdk_wm8580_dapm_widgets),
@@ -204,17 +191,6 @@ static struct platform_device *smdk_snd_device;
static int __init smdk_audio_init(void)
{
int ret;
- char *str;
-
- if (machine_is_smdkc100()
- || machine_is_smdkv210() || machine_is_smdkc110()) {
- smdk.num_links = 3;
- } else if (machine_is_smdk6410()) {
- str = (char *)smdk_dai[PRI_PLAYBACK].cpu_dai_name;
- str[strlen(str) - 1] = '2';
- str = (char *)smdk_dai[PRI_CAPTURE].cpu_dai_name;
- str[strlen(str) - 1] = '2';
- }
smdk_snd_device = platform_device_alloc("soc-audio", -1);
if (!smdk_snd_device)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/5] ASoC: samsung: Enable COMPILE_TEST for SmartQ and WM8580
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-1-git-send-email-krzk@kernel.org>
The I2S sound drivers for SmartQ board and WM8580 codec can be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
sound/soc/samsung/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index ea0fa9971a0c..426ef1c7b265 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -49,7 +49,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on MACH_SMDK6410
+ depends on MACH_SMDK6410 || COMPILE_TEST
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
@@ -109,7 +109,8 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380
config SND_SOC_SMARTQ
tristate "SoC I2S Audio support for SmartQ board"
- depends on MACH_SMARTQ && I2C
+ depends on MACH_SMARTQ || COMPILE_TEST
+ depends on I2C
select SND_SAMSUNG_I2S
select SND_SOC_WM8750
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/5] ASoC: samsung: Enable COMPILE_TEST for entire Samsung ASoc
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-1-git-send-email-krzk@kernel.org>
Instead of build time, Samsung ASoC drivers have rather runtime
dependency on Exynos or other Samsung platforms. For building they
require Common Clock Framework. If it is provided they could be compile
tested to increase build coverage.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
sound/soc/samsung/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 426ef1c7b265..a6cc6ca93fa7 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,6 +1,7 @@
menuconfig SND_SOC_SAMSUNG
tristate "ASoC support for Samsung"
- depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
+ depends on PLAT_SAMSUNG || ARCH_EXYNOS || COMPILE_TEST
+ depends on COMMON_CLK
select SND_SOC_GENERIC_DMAENGINE_PCM
---help---
Say Y or M if you want to add support for codecs attached to
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/5] ARM: s5pv210_defconfig: Remove old MACHs
From: Krzysztof Kozlowski @ 2016-11-20 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479669895-19124-1-git-send-email-krzk@kernel.org>
Remove non-existing MACH symbols from S5PV210 defconfig.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/configs/s5pv210_defconfig | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/configs/s5pv210_defconfig b/arch/arm/configs/s5pv210_defconfig
index fa989902236d..c51f0f02012b 100644
--- a/arch/arm/configs/s5pv210_defconfig
+++ b/arch/arm/configs/s5pv210_defconfig
@@ -9,10 +9,6 @@ CONFIG_ARCH_S5PV210=y
CONFIG_S3C_LOWLEVEL_UART_PORT=1
CONFIG_S3C_DEV_FB=y
CONFIG_S5PV210_SETUP_FB_24BPP=y
-CONFIG_MACH_AQUILA=y
-CONFIG_MACH_GONI=y
-CONFIG_MACH_SMDKC110=y
-CONFIG_MACH_SMDKV210=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_VMSPLIT_2G=y
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v2 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-11-20 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479478912-14067-1-git-send-email-andrei.pistirica@microchip.com>
On Fri, Nov 18, 2016 at 03:21:51PM +0100, Andrei Pistirica wrote:
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> +void macb_ptp_init(struct net_device *ndev);
> +#else
> +void macb_ptp_init(struct net_device *ndev) { }
static inline ^^^
> +#endif
> +void macb_ptp_init(struct net_device *ndev)
> +{
> + struct macb *bp = netdev_priv(ndev);
> + struct timespec64 now;
> + u32 rem = 0;
> +
> + if (!(bp->caps | MACB_CAPS_GEM_HAS_PTP)){
> + netdev_vdbg(bp->dev, "Platform does not support PTP!\n");
> + return;
> + }
You would have needed '&' and not '|' here.
Also, using a flag limits the code to your platform. This works for
you, but it is short sighted. The other MACB PTP blocks have
different register layouts, and this patch does not lay the ground
work for the others.
The driver needs to be designed to support the other platforms.
Thanks,
Richard
^ permalink raw reply
* [PATCH] arm: spin one more cycle in timer-based delays
From: Russell King - ARM Linux @ 2016-11-20 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WQCfpvVrn64LjxfeG2S7peU5ZWKVGsRyU83-zNCVZmxg@mail.gmail.com>
On Sun, Nov 20, 2016 at 11:18:48AM -0800, Doug Anderson wrote:
> Hi,
>
> On Sat, Nov 19, 2016 at 10:29 AM, Mason <slash.tmp@free.fr> wrote:
> >> Exactly - and the reason for that (as I've explained several times in
> >> the past) the "standard" software delay loop calibrated against the
> >> timer interrupt is _always_ going to be short.
> >
> > OK, so loop-based delays are known to be short. Would you or Linus
> > accept a patch that adds a X% cushion *in the implementation* ?
> >
> > You are saying "people shouldn't expect udelay(10) to delay at least
> > 10 ?s, thus they should write udelay(10+N)".
> >
> > Why not hide that implementation detail inside the implementation,
> > so as not to force the pessimization on every other implementation
> > behind the udelay/ndelay wrapper?
Try sending Linus a patch for it.
--
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
* [RFC PATCH v2 2/2] macb: Enable 1588 support in SAMA5D2 platform.
From: Richard Cochran @ 2016-11-20 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479478912-14067-2-git-send-email-andrei.pistirica@microchip.com>
On Fri, Nov 18, 2016 at 03:21:52PM +0100, Andrei Pistirica wrote:
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index d975882..eb66b76 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -697,6 +697,8 @@ static void macb_tx_interrupt(struct macb_queue *queue)
>
> /* First, update TX stats if needed */
> if (skb) {
> + macb_ptp_do_txstamp(bp, skb);
This is in the hot path, and so you should have an inline wrapper that
tests (bp->hwts_tx_en) and THEN calls into macb_ptp.c
In case PTP isn't configured, then the inline wrapper should be empty.
> netdev_vdbg(bp->dev, "skb %u (data %p) TX complete\n",
> macb_tx_ring_wrap(tail), skb->data);
> bp->stats.tx_packets++;
> @@ -853,6 +855,8 @@ static int gem_rx(struct macb *bp, int budget)
> GEM_BFEXT(RX_CSUM, ctrl) & GEM_RX_CSUM_CHECKED_MASK)
> skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> + macb_ptp_do_rxstamp(bp, skb);
Same here.
> bp->stats.rx_packets++;
> bp->stats.rx_bytes += skb->len;
>
> @@ -1946,6 +1950,8 @@ static int macb_open(struct net_device *dev)
>
> netif_tx_start_all_queues(dev);
>
> + macb_ptp_init(dev);
This leaks PHC instances starting the second time that the interface goes up!
> return 0;
> }
>
> @@ -2204,7 +2210,7 @@ static const struct ethtool_ops gem_ethtool_ops = {
> .get_regs_len = macb_get_regs_len,
> .get_regs = macb_get_regs,
> .get_link = ethtool_op_get_link,
> - .get_ts_info = ethtool_op_get_ts_info,
> + .get_ts_info = macb_get_ts_info,
You enable the time stamping logic unconditionally here ...
> .get_ethtool_stats = gem_get_ethtool_stats,
> .get_strings = gem_get_ethtool_strings,
> .get_sset_count = gem_get_sset_count,
> @@ -2221,7 +2227,14 @@ static int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> if (!phydev)
> return -ENODEV;
>
> - return phy_mii_ioctl(phydev, rq, cmd);
> + switch (cmd) {
> + case SIOCSHWTSTAMP:
> + return macb_hwtst_set(dev, rq, cmd);
> + case SIOCGHWTSTAMP:
> + return macb_hwtst_get(dev, rq);
and here.
Is that logic always available on every MACB device? If so, is the
implementation also identical?
Thanks,
Richard
^ permalink raw reply
* [PATCH] arm: spin one more cycle in timer-based delays
From: Mason @ 2016-11-20 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120194439.GY1041@n2100.armlinux.org.uk>
On 20/11/2016 20:44, Russell King - ARM Linux wrote:
> On Sun, Nov 20, 2016 at 11:18:48AM -0800, Doug Anderson wrote:
>
>> On Sat, Nov 19, 2016 at 10:29 AM, Mason <slash.tmp@free.fr> wrote:
>>
>>> OK, so loop-based delays are known to be short. Would you or Linus
>>> accept a patch that adds a X% cushion *in the implementation* ?
>>>
>>> You are saying "people shouldn't expect udelay(10) to delay at least
>>> 10 ?s, thus they should write udelay(10+N)".
>>>
>>> Why not hide that implementation detail inside the implementation,
>>> so as not to force the pessimization on every other implementation
>>> behind the udelay/ndelay wrapper?
>
> Try sending Linus a patch for it.
OK, I will.
BTW, any reason why you replied to me via Doug's reply?
Are my messages not reaching your server?
Regards.
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-20 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479586147.10840.0@smtp.gmail.com>
Hello Tomas,
On Sat, Nov 19, 2016 at 09:09:07PM +0100, tomas.hlavacek at nic.cz wrote:
> On Mon, Nov 14, 2016 at 9:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > Interrupts don't seem to work very well with the nxp,pca9538. Which
> > is probably why it is disabled by default.
>
> I was thinking about this issue and I can remember that there was an earlier
> prototype that had a shared interrupt line from PHY (88E1514) and from the
> PCA9538. In this case we needed to specifically disable the interrupt of the
> PHY to release the interrupt line (which needed a hack into PHY driver
> code). The IRQ from PHY is connected as an ordinary input to PCA9538 in
> later board prototype. And the same holds for the production version.
That would explain why I see an "irq but nobody cared" message when
booting the original system.
This isn't the problem I meant though. When adding interrupt-parent =
<&pcawan>; interrupts = <7 IRQ_TYPE_LEVEL_LOW>; to the phy node I get an
error saying that there is no irq domain associated with this device.
> Do you have CZ11NIC13 or older board revision?
CZ11NIC12 is indicated on my board.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161120/6ded9bfe/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