* [PATCH v2 2/4] ARM: dts: pxa: add pxa25x cpu operating points
From: Robert Jarzmik @ 2016-10-15 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-1-git-send-email-robert.jarzmik@free.fr>
Add the relevant data taken from the PXA 25x Electrical, Mechanical, and
Thermal Specfication. This will be input data for cpufreq-dt driver.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/boot/dts/pxa25x.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/pxa25x.dtsi b/arch/arm/boot/dts/pxa25x.dtsi
index 0d1e012178c4..16b4e8bad4a5 100644
--- a/arch/arm/boot/dts/pxa25x.dtsi
+++ b/arch/arm/boot/dts/pxa25x.dtsi
@@ -89,4 +89,29 @@
clocks = <&clktimer>;
status = "okay";
};
+
+ pxa250_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp at 99500 {
+ opp-hz = /bits/ 64 <99532800>;
+ opp-microvolt = <950000 1000000 1650000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 199100 {
+ opp-hz = /bits/ 64 <199065600>;
+ opp-microvolt = <1000000 950000 1650000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 298600 {
+ opp-hz = /bits/ 64 <298598400>;
+ opp-microvolt = <1100000 1045000 1650000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 398100 {
+ opp-hz = /bits/ 64 <398131200>;
+ opp-microvolt = <1300000 1235000 1650000>;
+ clock-latency-ns = <20>;
+ };
+ };
};
--
2.1.4
^ permalink raw reply related
* [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Robert Jarzmik @ 2016-10-15 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-1-git-send-email-robert.jarzmik@free.fr>
For device-tree based pxa25x and pxa27x platforms, cpufreq-dt driver is
doing the job as well as pxa2xx-cpufreq, so add these platforms to the
compatibility list.
This won't work for legacy non device-tree platforms where
pxa2xx-cpufreq is still required.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 0bb44d5b5df4..356825b5c9b8 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -32,6 +32,8 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "fsl,imx7d", },
{ .compatible = "marvell,berlin", },
+ { .compatible = "marvell,pxa250", },
+ { .compatible = "marvell,pxa270", },
{ .compatible = "samsung,exynos3250", },
{ .compatible = "samsung,exynos4210", },
--
2.1.4
^ permalink raw reply related
* [PATCH v2 0/4] PXA cpufreq conversion to clock API
From: Robert Jarzmik @ 2016-10-15 19:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This serie is a preparation to shift the cpufreq of pxa2xx platforms to clocks
API.
The first 3 patches are review and merge material :
- patch 1/4 for Viresh and Rafael
- patches 2/4 and 3/4 for me
The 4th on is for review but not merge, as the clock changes must be fully
reviewed and go in first as a prequisite
Robert Jarzmik (4):
cpufreq: pxa: use generic platdev driver for device-tree
ARM: dts: pxa: add pxa25x cpu operating points
ARM: dts: pxa: add pxa27x cpu operating points
cpufreq: pxa: convert to clock API
arch/arm/boot/dts/pxa25x.dtsi | 25 +++++
arch/arm/boot/dts/pxa27x.dtsi | 40 ++++++++
drivers/cpufreq/Kconfig.arm | 2 +-
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +
drivers/cpufreq/pxa2xx-cpufreq.c | 191 +++++++----------------------------
5 files changed, 107 insertions(+), 153 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Bartosz Golaszewski @ 2016-10-15 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2d276e51-9d37-8648-4aad-283bb2b23626@ti.com>
2016-10-15 19:42 GMT+02:00 Sekhar Nori <nsekhar@ti.com>:
> On Wednesday 05 October 2016 06:35 PM, Bartosz Golaszewski wrote:
>> From: Karl Beldan <kbeldan@baylibre.com>
>>
>> Add pins used by the LCD controller and a disabled LCDC node to be
>> reused in device trees including da850.dtsi.
>>
>> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
>> [Bartosz:
>> - added the commit description
>> - changed the dt node name to a generic one
>> - added a da850-specific compatible string
>> - removed the tilcdc,panel node
>> - moved the pins definitions to da850.dtsi as suggested by
>> Sekhar Nori (was in: da850-lcdk.dts)]
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 29 +++++++++++++++++++++++++++++
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..32908ae 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>
>> @@ -399,6 +420,14 @@
>> <&edma0 0 1>;
>> dma-names = "tx", "rx";
>> };
>> +
>> + display: display at 213000 {
>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>
> This should instead be:
>
> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>
> as the closest match should appear first in the list.
>
>> + reg = <0x213000 0x1000>;
>> + interrupt-parent = <&intc>
>
> No need of specifying the interrupt-parent as it is assumed to be that
> from the parent node (soc) if left unspecified.
>
> I made these two fixes locally and pushed the two patches in this series
> to v4.10/dt branch of my tree (for URL see MAINTAINERS). Can you take a
> look and make sure I did not mess anything up?
>
Looks good, thanks!
Bartosz Golaszewski
^ permalink raw reply
* rockchip: drm: analogix_dp-rockchip would stock the kernel
From: ayaka @ 2016-10-15 18:03 UTC (permalink / raw)
To: linux-arm-kernel
Hello:
I meet a problem with eDP in rk3288 with the linux next 20161006, it
is just like the early stage of 4.4
kernel. I have added a eDP panel entry in the firefly reload board,
once the kernel loaded analogix_dp-rockchip.ko, after printed the
following two lines, the kernel stop working.
rockchip-drm display-subsystem: bound ff940000.vop (ops
vop_component_ops [rockchipdrm])
rockchip-drm display-subsystem: bound ff930000.vop (ops
vop_component_ops [rockchipdrm])
In the early June of the 4.4 kernel, I meet the same problem with rk3288
evb board with different error message, I have to disable the display
system that time.
In the today test, I meet the same problem with rk3399 evb board in 4.4.
I have no idea what caused that, and it is a little hard to debug as
kernel still would never kill that task.
Randy Li
^ permalink raw reply
* [PATCH 2/2] ARM: dts: da850: add a node for the LCD controller
From: Sekhar Nori @ 2016-10-15 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475672732-17111-3-git-send-email-bgolaszewski@baylibre.com>
On Wednesday 05 October 2016 06:35 PM, Bartosz Golaszewski wrote:
> From: Karl Beldan <kbeldan@baylibre.com>
>
> Add pins used by the LCD controller and a disabled LCDC node to be
> reused in device trees including da850.dtsi.
>
> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> [Bartosz:
> - added the commit description
> - changed the dt node name to a generic one
> - added a da850-specific compatible string
> - removed the tilcdc,panel node
> - moved the pins definitions to da850.dtsi as suggested by
> Sekhar Nori (was in: da850-lcdk.dts)]
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850.dtsi | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f79e1b9..32908ae 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -399,6 +420,14 @@
> <&edma0 0 1>;
> dma-names = "tx", "rx";
> };
> +
> + display: display at 213000 {
> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
This should instead be:
compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
as the closest match should appear first in the list.
> + reg = <0x213000 0x1000>;
> + interrupt-parent = <&intc>
No need of specifying the interrupt-parent as it is assumed to be that
from the parent node (soc) if left unspecified.
I made these two fixes locally and pushed the two patches in this series
to v4.10/dt branch of my tree (for URL see MAINTAINERS). Can you take a
look and make sure I did not mess anything up?
Regards,
Sekhar
^ permalink raw reply
* [PATCH 1/2] i2c: bcm-iproc: constify i2c_adapter_quirks structures
From: Julia Lawall @ 2016-10-15 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476552722-12352-1-git-send-email-Julia.Lawall@lip6.fr>
Check for i2c_adapter_quirks structures that are only stored in the
quirks field of an i2c_adapter structure. This field is declared
const, so i2c_adapter_quirks structures that have this property can be
declared as const also.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct i2c_adapter_quirks i at p = { ... };
@ok@
identifier r.i;
struct i2c_adapter e;
position p;
@@
e.quirks = &i at p;
@bad@
position p != {r.p,ok.p};
identifier r.i;
struct i2c_adapter_quirks e;
@@
e at i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct i2c_adapter_quirks i = { ... };
// </smpl>
The effect on the layout of the .o file is shown by the following
output of the size command, first before then after the
transformation:
text data bss dec hex filename
3458 744 8 4210 1072 drivers/i2c/busses/i2c-bcm-iproc.o
3490 720 8 4218 107a drivers/i2c/busses/i2c-bcm-iproc.o
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index 326b3db..318df55 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -395,7 +395,7 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
.functionality = bcm_iproc_i2c_functionality,
};
-static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
+static const struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
/* need to reserve one byte in the FIFO for the slave address */
.max_read_len = M_TX_RX_FIFO_SIZE - 1,
};
^ permalink raw reply related
* [PATCH 0/2] constify i2c_adapter_quirks structures
From: Julia Lawall @ 2016-10-15 17:32 UTC (permalink / raw)
To: linux-arm-kernel
Constify i2c_adapter_quirks structures.
---
drivers/i2c/busses/i2c-axxia.c | 2 +-
drivers/i2c/busses/i2c-bcm-iproc.c | 2 +-
drivers/i2c/busses/i2c-dln2.c | 2 +-
drivers/i2c/busses/i2c-viperboard.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH] clk: samsung: clk-exynos-audss: Fix module autoload
From: Krzysztof Kozlowski @ 2016-10-15 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476470645-22159-1-git-send-email-javier@osg.samsung.com>
On Fri, Oct 14, 2016 at 03:44:05PM -0300, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/clk/samsung/clk-exynos-audss.ko | grep alias
> alias: platform:exynos-audss-clk
>
> After this patch:
>
> $ modinfo drivers/clk/samsung/clk-exynos-audss.ko | grep alias
> alias: platform:exynos-audss-clk
> alias: of:N*T*Csamsung,exynos5420-audss-clockC*
> alias: of:N*T*Csamsung,exynos5420-audss-clock
> alias: of:N*T*Csamsung,exynos5410-audss-clockC*
> alias: of:N*T*Csamsung,exynos5410-audss-clock
> alias: of:N*T*Csamsung,exynos5250-audss-clockC*
> alias: of:N*T*Csamsung,exynos5250-audss-clock
> alias: of:N*T*Csamsung,exynos4210-audss-clockC*
> alias: of:N*T*Csamsung,exynos4210-audss-clock
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> drivers/clk/samsung/clk-exynos-audss.c | 1 +
> 1 file changed, 1 insertion(+)
Indeed, this was missed by 4d252fd5719b thus I think it could be
mentioned as fix tag (just for reference...):
Fixes: 4d252fd5719b ("clk: samsung: Allow modular build of the Audio Subsystem CLKCON driver")
Anyway, this fixes the issue, so:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Sinan Kaya @ 2016-10-15 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0iiU-1JwAows+WbE9v3pjYi9cRHDwtDEDBuCUjWk=o=KA@mail.gmail.com>
Hi Rafael,
On 10/15/2016 8:39 AM, Rafael J. Wysocki wrote:
> On Sat, Oct 15, 2016 at 6:31 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
>> resource requirements") removed PCI_USING penalty from
>> acpi_pci_link_allocate function as there is no longer a fixed size penalty
>> array for both PCI interrupts greater than 16.
>>
>> The array size has been reduced to 16 and array name got prefixed as ISA
>> since it only is accountable for the ISA interrupts.
>>
>> The original change in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
>> resource requirements") removed penalty assignment in the code for PCI
>> thinking that we will add the penalty later in acpi_irq_pci_sharing_penalty
>> function.
>
> I'd write the above this way:
>
> "Commit 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
> dropped the PCI_USING penalty from acpi_pci_link_allocate() with the
> assumption that the penalty will be added later in
> acpi_irq_pci_sharing_penalty()."
>
> This conveys essentially the same information (up to some irrelevant
> bits), but in a clearer way IMO.
>
>>
>> However, this function only gets called if the IRQ number is greater than
>> 16 and acpi_irq_get_penalty function gets called before ACPI start in
>> acpi_isa_irq_available and acpi_penalize_isa_irq functions. We can't rely
>> on iterating the link list.
>
> "However, acpi_irq_pci_sharing_penalty() is only called for IRQ
> numbers above 15. Moreover, acpi_irq_get_penalty() is invoked by
> acpi_isa_irq_available() and acpi_penalize_isa_irq() before the ACPI
> initialization and the PCI interrupt links list is not ready at that
> point, so it cannot be relied on when computing the penalty."
>
>>
>> We need to add the PCI_USING penalty for ISA interrupts too if the link is
>> in use and matches our ISA IRQ number.
>
> "For this reason, the PCI_USING penalty has to be added in
> acpi_pci_link_allocate() directly if the link has been enabled
> successfully and the IRQ number is within the ISA range."
>
> IIUC
>
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> drivers/acpi/pci_link.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
>> index c983bf7..a212709 100644
>> --- a/drivers/acpi/pci_link.c
>> +++ b/drivers/acpi/pci_link.c
>> @@ -619,6 +619,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
>> acpi_device_bid(link->device));
>> return -ENODEV;
>> } else {
>> + if (link->irq.active < ACPI_MAX_ISA_IRQS)
>> + acpi_isa_irq_penalty[link->irq.active] +=
>> + PIRQ_PENALTY_PCI_USING;
>> +
>
> There's no need to break the line here and I would put the above after
> the printk().
>
> Or even after the whole "else" branch (which is unnecessary, but let's
> limit changes in this patch).
>
>> printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
>> acpi_device_name(link->device),
>> acpi_device_bid(link->device), link->irq.active);
>> --
>
Thanks for the feedback. I can resubmit with the comments corrected. I'll wait
until I hear from Bjorn first.
> Thanks,
> Rafael
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-10-15 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8C3BD5BA-252F-4A95-B938-50356A23974E@embedded.rocks>
> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016 um 11:41
> geschrieben:
>
>
>
>
> Hi Stefan,
>
> Am 15. Oktober 2016 10:59:41 MESZ, schrieb Stefan Wahren
> <stefan.wahren@i2se.com>:
> >Hi J?rg,
> >
> >> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016 um
> >10:46
> >> geschrieben:
> >>
> >>
> >> Thanks!
> >>
> >>
> >> For the record:
> >>
> >> Note, this is the result for the wireless interface.
> >>
> >> I got one of my custom boards running the legacy Linux Kernel 2.6.35
> >> officially supported from Freescale (NXP) and the bcmdhd driver from
> >> the Wiced project, where I get >20Mbps TCP throughput. The firmware
> >> version reported is:
> >>
> >> # wl ver
> >> 5.90 RC115.2
> >> wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
> >>
> >>
> >> I got it also running with the Linux Kernel 4.1.15 from Freescale
> >[2],
> >> which is not officially supported for the i.MX28 target, with the
> >> latest bcmdhd version where I get <7Mbps TCP throughput (which is
> >much
> >> the same I get with the brcmfmac driver). The firmware version
> >reported
> >> is:
> >>
> >> # wl ver
> >> 1.107 RC5.0
> >> wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
> >>
> >> So, probably something is missing in the newer Kernel version, which
> >is
> >> present in the legacy Kernel 2.6.35.
> >>
> >> [1]
> >http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
> >> imx_2.6.35_1.1.0
> >> [2]
> >http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
> >> imx_4.1.15_1.0.0_ga
> >
> >during implementation of DDR mode for the mmc driver [1] i noticed a
> >performance
> >gap between the vendor kernel and mainline by a factor of 2. I expect
> >that your
> >wireless interface is connected via SDIO.
>
> Yes, it is. I had the suspicion that the MMC or the DMA driver is the
> bootleneck, too.
>
> >
> >[1] -
> >http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-3-mmc-mxs-mmc-implement-ddr-support
>
> Looks like the patches might help.
Unfortunately not, the performance gain is smaller than expected.
> Have you tried SDIO wifi so far?
No.
>
> J?rg
>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add cpu-supply for Olimex A20 EVB
From: Emmanuel Vadot @ 2016-10-15 15:23 UTC (permalink / raw)
To: linux-arm-kernel
sun7i-a20-olimex-som-evb.dts doesn't contain cpu-supply needed for
voltage-scaling with cpufreq-dt so define it.
The default voltages are defined in sun7i-a20.dtsi.
Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
---
arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
index 23aacce..134e0c1 100644
--- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -88,6 +88,10 @@
status = "okay";
};
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
&codec {
status = "okay";
};
--
2.9.2
^ permalink raw reply related
* [PATCH 3/7] ASoC: rockchip: constify snd_soc_ops structures
From: Julia Lawall @ 2016-10-15 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476543351-17858-1-git-send-email-Julia.Lawall@lip6.fr>
Check for snd_soc_ops structures that are only stored in the ops field of a
snd_soc_dai_link structure. This field is declared const, so snd_soc_ops
structures that have this property can be declared as const also.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r disable optional_qualifier@
identifier i;
position p;
@@
static struct snd_soc_ops i at p = { ... };
@ok1@
identifier r.i;
struct snd_soc_dai_link e;
position p;
@@
e.ops = &i at p;
@ok2@
identifier r.i, e;
position p;
@@
struct snd_soc_dai_link e[] = { ..., { .ops = &i at p, }, ..., };
@bad@
position p != {r.p,ok1.p,ok2.p};
identifier r.i;
struct snd_soc_ops e;
@@
e at i@p
@depends on !bad disable optional_qualifier@
identifier r.i;
@@
static
+const
struct snd_soc_ops i = { ... };
// </smpl>
The effect on the layout of the .o files is shown by the following output
of the size command, first before then after the transformation:
text data bss dec hex filename
5027 2488 416 7931 1efb sound/soc/rockchip/rk3399_gru_sound.o
5219 2312 416 7947 1f0b sound/soc/rockchip/rk3399_gru_sound.o
text data bss dec hex filename
3499 1648 384 5531 159b sound/soc/rockchip/rockchip_max98090.o
3563 1584 384 5531 159b sound/soc/rockchip/rockchip_max98090.o
text data bss dec hex filename
3455 1536 384 5375 14ff sound/soc/rockchip/rockchip_rt5645.o
3519 1480 384 5383 1507 sound/soc/rockchip/rockchip_rt5645.o
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
sound/soc/rockchip/rk3399_gru_sound.c | 6 +++---
sound/soc/rockchip/rockchip_max98090.c | 2 +-
sound/soc/rockchip/rockchip_rt5645.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff -u -p a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -228,15 +228,15 @@ static int rockchip_sound_da7219_init(st
return 0;
}
-static struct snd_soc_ops rockchip_sound_max98357a_ops = {
+static const struct snd_soc_ops rockchip_sound_max98357a_ops = {
.hw_params = rockchip_sound_max98357a_hw_params,
};
-static struct snd_soc_ops rockchip_sound_rt5514_ops = {
+static const struct snd_soc_ops rockchip_sound_rt5514_ops = {
.hw_params = rockchip_sound_rt5514_hw_params,
};
-static struct snd_soc_ops rockchip_sound_da7219_ops = {
+static const struct snd_soc_ops rockchip_sound_da7219_ops = {
.hw_params = rockchip_sound_da7219_hw_params,
};
diff -u -p a/sound/soc/rockchip/rockchip_max98090.c b/sound/soc/rockchip/rockchip_max98090.c
--- a/sound/soc/rockchip/rockchip_max98090.c
+++ b/sound/soc/rockchip/rockchip_max98090.c
@@ -119,7 +119,7 @@ static int rk_aif1_hw_params(struct snd_
return ret;
}
-static struct snd_soc_ops rk_aif1_ops = {
+static const struct snd_soc_ops rk_aif1_ops = {
.hw_params = rk_aif1_hw_params,
};
diff -u -p a/sound/soc/rockchip/rockchip_rt5645.c b/sound/soc/rockchip/rockchip_rt5645.c
--- a/sound/soc/rockchip/rockchip_rt5645.c
+++ b/sound/soc/rockchip/rockchip_rt5645.c
@@ -135,7 +135,7 @@ static int rk_init(struct snd_soc_pcm_ru
&headset_jack);
}
-static struct snd_soc_ops rk_aif1_ops = {
+static const struct snd_soc_ops rk_aif1_ops = {
.hw_params = rk_aif1_hw_params,
};
^ permalink raw reply
* [PATCH 0/7] constify snd_soc_ops structures
From: Julia Lawall @ 2016-10-15 14:55 UTC (permalink / raw)
To: linux-arm-kernel
Constify snd_soc_ops structures.
---
sound/soc/atmel/atmel_wm8904.c | 2 +-
sound/soc/fsl/fsl-asoc-card.c | 2 +-
sound/soc/fsl/imx-wm8962.c | 2 +-
sound/soc/generic/simple-card.c | 2 +-
sound/soc/generic/simple-scu-card.c | 2 +-
sound/soc/intel/boards/bdw-rt5677.c | 2 +-
sound/soc/intel/boards/broadwell.c | 2 +-
sound/soc/intel/boards/bxt_da7219_max98357a.c | 4 ++--
sound/soc/intel/boards/bxt_rt298.c | 4 ++--
sound/soc/intel/boards/bytcr_rt5640.c | 4 ++--
sound/soc/intel/boards/bytcr_rt5651.c | 4 ++--
sound/soc/intel/boards/cht_bsw_max98090_ti.c | 4 ++--
sound/soc/intel/boards/cht_bsw_rt5645.c | 4 ++--
sound/soc/intel/boards/cht_bsw_rt5672.c | 4 ++--
sound/soc/intel/boards/haswell.c | 2 +-
sound/soc/intel/boards/skl_nau88l25_max98357a.c | 6 +++---
sound/soc/intel/boards/skl_nau88l25_ssm4567.c | 6 +++---
sound/soc/intel/boards/skl_rt286.c | 4 ++--
sound/soc/kirkwood/armada-370-db.c | 2 +-
sound/soc/mxs/mxs-sgtl5000.c | 2 +-
sound/soc/qcom/storm.c | 2 +-
sound/soc/rockchip/rk3399_gru_sound.c | 6 +++---
sound/soc/rockchip/rockchip_max98090.c | 2 +-
sound/soc/rockchip/rockchip_rt5645.c | 2 +-
sound/soc/tegra/tegra_alc5632.c | 2 +-
sound/soc/tegra/tegra_max98090.c | 2 +-
sound/soc/tegra/tegra_rt5640.c | 2 +-
sound/soc/tegra/tegra_rt5677.c | 2 +-
sound/soc/tegra/tegra_sgtl5000.c | 2 +-
sound/soc/tegra/tegra_wm8753.c | 2 +-
sound/soc/tegra/tegra_wm8903.c | 2 +-
sound/soc/tegra/trimslice.c | 2 +-
32 files changed, 46 insertions(+), 46 deletions(-)
^ permalink raw reply
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Catalin Marinas @ 2016-10-15 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jKMZTo7m=ygm7x8w__1my0jiQiVAiv9NowQ8pfQqCnjmw@mail.gmail.com>
Hi Kees,
On Fri, Oct 14, 2016 at 02:44:33PM -0700, Kees Cook wrote:
> Just checking in on this feature -- I don't see it in -next nor
> already in the tree. Is there any chance this is going to make the
> v4.9 merge window?
As I said in the cover letter, I'll rebase it on top of 4.9-rc1 as there
are some clean-ups that this series would conflict with. So I am
targeting 4.10 with this patch series.
> It didn't sound like there were any unresolved issues remaining?
There are a few issues spotted by Mark which I'll address in the next
version, but nothing major.
--
Catalin
^ permalink raw reply
* [PATCH V3 2/3] Revert "ACPI, PCI, IRQ: remove SCI penalize function"
From: Rafael J. Wysocki @ 2016-10-15 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476505867-24599-3-git-send-email-okaya@codeaurora.org>
On Sat, Oct 15, 2016 at 6:31 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> The SCI function was removed in two steps (first refactor and then remove).
> This patch does the revert in one step.
"The SCI penalize function was removed in two steps (first refactor
and then remove) and these changes are reverted here in one go."
>
> The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> refactored the original code so that SCI penalty is calculated dynamically
> by the time get_penalty function is called. This patch does a partial
> revert for the SCI functionality only.
I'd write the last sentence this way:
"That change is partially reverted here, specifically for the SCI IRQ alone."
> The commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function") is
> for the removal of the function. SCI penalty API was replaced by the
> runtime penalty calculation based on the value of
> acpi_gbl_FADT.sci_interrupt.
"The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
(ACPI,PCI,IRQ: remove SCI penalize function) that replaced the old SCI
penalty API with penalty calculation carried out dynamically and based
on the acpi_gbl_FADT.sci_interrupt value."
> The IRQ type does not get updated at the right time for some platforms and
> results in incorrect penalty assignment for PCI IRQs as
> irq_get_trigger_type returns the wrong type.
"However, that new algorithm relies on the accurate setting of IRQ
types and that doesn't happen early enough on some platforms which
leads to incorrect penalty assignments for PCI IRQs. In those cases,
irq_get_trigger_type() returns incorrect values for the IRQs in
question, because they have not been registered yet by the time the
penalties are calculated."
And then you don't need the paragraph below then.
> The register_gsi function delivers the IRQ found in the ACPI table to
> the interrupt controller driver. Penalties are calculated before a
> link object is enabled to find out which interrupt has the least number
> of users. By the time penalties are calculated, the IRQ is not registered
> yet and the API returns the wrong type.
And I would add:
"For this reason, revert commit 9e5ed6d1fb87 (ACPI,PCI,IRQ: remove SCI
penalize function) completely to restore the correct behavior."
Also, please add Fixes: tags pointing to the commits you're fixing here.
> Tested-by: Jonathan Liu <net147@gmail.com>
> Tested-by: Ondrej Zary <linux@rainbow-software.org>
> Link: https://lkml.org/lkml/2016/10/4/283
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 32 +++++++++++++-------------------
> include/linux/acpi.h | 1 +
> 3 files changed, 15 insertions(+), 19 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
> polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>
> mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> + acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>
> /*
> * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index a212709..1934e2a 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -494,27 +494,10 @@ static int acpi_irq_pci_sharing_penalty(int irq)
>
> static int acpi_irq_get_penalty(int irq)
> {
> - int penalty = 0;
> -
> - /*
> - * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> - * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> - * use for PCI IRQs.
> - */
> - if (irq == acpi_gbl_FADT.sci_interrupt) {
> - u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> - if (type != IRQ_TYPE_LEVEL_LOW)
> - penalty += PIRQ_PENALTY_ISA_ALWAYS;
> - else
> - penalty += PIRQ_PENALTY_PCI_USING;
> - }
> -
> if (irq < ACPI_MAX_ISA_IRQS)
> - return penalty + acpi_isa_irq_penalty[irq];
> + return acpi_isa_irq_penalty[irq];
>
> - penalty += acpi_irq_pci_sharing_penalty(irq);
> - return penalty;
> + return acpi_irq_pci_sharing_penalty(irq);
> }
>
> int __init acpi_irq_penalty_init(void)
> @@ -885,6 +868,17 @@ bool acpi_isa_irq_available(int irq)
> acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
> }
>
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> + if (irq >= 0 && irq < ARRAY_SIZE(acpi_isa_irq_penalty)) {
> + if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
> + polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
> + acpi_isa_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
> + else
> + acpi_isa_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
> + }
> +}
> +
> /*
> * Over-ride default table to reserve additional IRQs for use by ISA
> * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5eaf2f..67d1d3e 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
> int acpi_pci_irq_enable (struct pci_dev *dev);
> void acpi_penalize_isa_irq(int irq, int active);
> bool acpi_isa_irq_available(int irq);
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
> void acpi_pci_irq_disable (struct pci_dev *dev);
>
> extern int ec_read(u8 addr, u8 *val);
> --
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Rafael J. Wysocki @ 2016-10-15 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476505867-24599-2-git-send-email-okaya@codeaurora.org>
On Sat, Oct 15, 2016 at 6:31 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed PCI_USING penalty from
> acpi_pci_link_allocate function as there is no longer a fixed size penalty
> array for both PCI interrupts greater than 16.
>
> The array size has been reduced to 16 and array name got prefixed as ISA
> since it only is accountable for the ISA interrupts.
>
> The original change in commit 103544d86976 ("ACPI,PCI,IRQ: reduce
> resource requirements") removed penalty assignment in the code for PCI
> thinking that we will add the penalty later in acpi_irq_pci_sharing_penalty
> function.
I'd write the above this way:
"Commit 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
dropped the PCI_USING penalty from acpi_pci_link_allocate() with the
assumption that the penalty will be added later in
acpi_irq_pci_sharing_penalty()."
This conveys essentially the same information (up to some irrelevant
bits), but in a clearer way IMO.
>
> However, this function only gets called if the IRQ number is greater than
> 16 and acpi_irq_get_penalty function gets called before ACPI start in
> acpi_isa_irq_available and acpi_penalize_isa_irq functions. We can't rely
> on iterating the link list.
"However, acpi_irq_pci_sharing_penalty() is only called for IRQ
numbers above 15. Moreover, acpi_irq_get_penalty() is invoked by
acpi_isa_irq_available() and acpi_penalize_isa_irq() before the ACPI
initialization and the PCI interrupt links list is not ready at that
point, so it cannot be relied on when computing the penalty."
>
> We need to add the PCI_USING penalty for ISA interrupts too if the link is
> in use and matches our ISA IRQ number.
"For this reason, the PCI_USING penalty has to be added in
acpi_pci_link_allocate() directly if the link has been enabled
successfully and the IRQ number is within the ISA range."
IIUC
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..a212709 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -619,6 +619,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link)
> acpi_device_bid(link->device));
> return -ENODEV;
> } else {
> + if (link->irq.active < ACPI_MAX_ISA_IRQS)
> + acpi_isa_irq_penalty[link->irq.active] +=
> + PIRQ_PENALTY_PCI_USING;
> +
There's no need to break the line here and I would put the above after
the printk().
Or even after the whole "else" branch (which is unnecessary, but let's
limit changes in this patch).
> printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
> acpi_device_name(link->device),
> acpi_device_bid(link->device), link->irq.active);
> --
Thanks,
Rafael
^ permalink raw reply
* [PATCH 4/4] staging/vchi: Remove dependency on CONFIG_BROKEN.
From: Stefan Wahren @ 2016-10-15 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161015112740.GB11674@kroah.com>
Hi Greg,
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> hat am 15. Oktober 2016 um
> 13:27 geschrieben:
>
>
> On Sat, Oct 15, 2016 at 10:35:25AM +0200, Stefan Wahren wrote:
> >
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> hat am 13. Oktober 2016 um
> > > 09:05 geschrieben:
> > >
> > >
> > > On Mon, Oct 03, 2016 at 11:52:09AM -0700, Eric Anholt wrote:
> > > > The driver builds now.
> > > >
> > > > Signed-off-by: Eric Anholt <eric@anholt.net>
> > > > ---
> > > > drivers/staging/vc04_services/Kconfig | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/staging/vc04_services/Kconfig
> > > > b/drivers/staging/vc04_services/Kconfig
> > > > index 9676fb29075a..db8e1beb89f9 100644
> > > > --- a/drivers/staging/vc04_services/Kconfig
> > > > +++ b/drivers/staging/vc04_services/Kconfig
> > > > @@ -1,6 +1,6 @@
> > > > config BCM2708_VCHIQ
> > > > tristate "Videocore VCHIQ"
> > > > - depends on RASPBERRYPI_FIRMWARE && BROKEN
> > > > + depends on RASPBERRYPI_FIRMWARE
> > > > default y
> > > > help
> > > > Kernel to VideoCore communication interface for the
> > >
> > > I've dropped this patch from my branch as there are build errors on
> > > arm64 systems still, and we don't want regressions like that.
> > >
> > > I've forwarded you the error messages, and I'll be glad to add this
> > > patch back once these issues are fixed.
> >
> > I ask the author of this downstream pull request [1] to send the VHCIQ part
> > as
> > indiviual patches.
> > He is interested to submit them upstream.
> >
> > [1] - https://github.com/raspberrypi/linux/pull/1611
>
> Ok, but what does that mean for us here? The code should be all now
> merged into our "upstream" trees, it just needs to be cleaned up
> properly.
>
> confused,
>
> greg k-h
sorry for the confusion. I mean that he wants to send email patches based on
your staging tree. So we avoid patching the kernel twice.
The link was only for illustration that he already fixed most of the arm64 build
issues.
Stefan
^ permalink raw reply
* [PATCH 4/4] staging/vchi: Remove dependency on CONFIG_BROKEN.
From: Greg Kroah-Hartman @ 2016-10-15 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <886598225.386698.0cc5acd0-af27-4ef7-892f-3c2dd86176ba.open-xchange@email.1und1.de>
On Sat, Oct 15, 2016 at 10:35:25AM +0200, Stefan Wahren wrote:
>
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> hat am 13. Oktober 2016 um
> > 09:05 geschrieben:
> >
> >
> > On Mon, Oct 03, 2016 at 11:52:09AM -0700, Eric Anholt wrote:
> > > The driver builds now.
> > >
> > > Signed-off-by: Eric Anholt <eric@anholt.net>
> > > ---
> > > drivers/staging/vc04_services/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/vc04_services/Kconfig
> > > b/drivers/staging/vc04_services/Kconfig
> > > index 9676fb29075a..db8e1beb89f9 100644
> > > --- a/drivers/staging/vc04_services/Kconfig
> > > +++ b/drivers/staging/vc04_services/Kconfig
> > > @@ -1,6 +1,6 @@
> > > config BCM2708_VCHIQ
> > > tristate "Videocore VCHIQ"
> > > - depends on RASPBERRYPI_FIRMWARE && BROKEN
> > > + depends on RASPBERRYPI_FIRMWARE
> > > default y
> > > help
> > > Kernel to VideoCore communication interface for the
> >
> > I've dropped this patch from my branch as there are build errors on
> > arm64 systems still, and we don't want regressions like that.
> >
> > I've forwarded you the error messages, and I'll be glad to add this
> > patch back once these issues are fixed.
>
> I ask the author of this downstream pull request [1] to send the VHCIQ part as
> indiviual patches.
> He is interested to submit them upstream.
>
> [1] - https://github.com/raspberrypi/linux/pull/1611
Ok, but what does that mean for us here? The code should be all now
merged into our "upstream" trees, it just needs to be cleaned up
properly.
confused,
greg k-h
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-10-15 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2131339088.8778.d47a56f6-921e-4d6c-9a5c-2e77bfd5d281.open-xchange@email.1und1.de>
Am 15. Oktober 2016 10:59:41 MESZ, schrieb Stefan Wahren <stefan.wahren@i2se.com>:
>Hi J?rg,
>
>> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016 um
>10:46
>> geschrieben:
>>
>>
>> Thanks!
>>
>>
>> For the record:
>>
>> Note, this is the result for the wireless interface.
>>
>> I got one of my custom boards running the legacy Linux Kernel 2.6.35
>> officially supported from Freescale (NXP) and the bcmdhd driver from
>> the Wiced project, where I get >20Mbps TCP throughput. The firmware
>> version reported is:
>>
>> # wl ver
>> 5.90 RC115.2
>> wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
>>
>>
>> I got it also running with the Linux Kernel 4.1.15 from Freescale
>[2],
>> which is not officially supported for the i.MX28 target, with the
>> latest bcmdhd version where I get <7Mbps TCP throughput (which is
>much
>> the same I get with the brcmfmac driver). The firmware version
>reported
>> is:
>>
>> # wl ver
>> 1.107 RC5.0
>> wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
>>
>> So, probably something is missing in the newer Kernel version, which
>is
>> present in the legacy Kernel 2.6.35.
>>
>> [1]
>http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
>> imx_2.6.35_1.1.0
>> [2]
>http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
>> imx_4.1.15_1.0.0_ga
>
>during implementation of DDR mode for the mmc driver [1] i noticed a
>performance
>gap between the vendor kernel and mainline by a factor of 2. I expect
>that your
>wireless interface is connected via SDIO.
I wonder if this [2] might be related. As far as I can see it is not present in mainline.
>
>[1] -
>http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-3-mmc-mxs-mmc-implement-ddr-support
[2]
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_2.6.35_1.1.0&id=c105f3ef1d461aaeedbc6361941096b6684cc812
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-10-15 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2131339088.8778.d47a56f6-921e-4d6c-9a5c-2e77bfd5d281.open-xchange@email.1und1.de>
Hi Stefan,
Am 15. Oktober 2016 10:59:41 MESZ, schrieb Stefan Wahren <stefan.wahren@i2se.com>:
>Hi J?rg,
>
>> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016 um
>10:46
>> geschrieben:
>>
>>
>> Thanks!
>>
>>
>> For the record:
>>
>> Note, this is the result for the wireless interface.
>>
>> I got one of my custom boards running the legacy Linux Kernel 2.6.35
>> officially supported from Freescale (NXP) and the bcmdhd driver from
>> the Wiced project, where I get >20Mbps TCP throughput. The firmware
>> version reported is:
>>
>> # wl ver
>> 5.90 RC115.2
>> wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
>>
>>
>> I got it also running with the Linux Kernel 4.1.15 from Freescale
>[2],
>> which is not officially supported for the i.MX28 target, with the
>> latest bcmdhd version where I get <7Mbps TCP throughput (which is
>much
>> the same I get with the brcmfmac driver). The firmware version
>reported
>> is:
>>
>> # wl ver
>> 1.107 RC5.0
>> wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
>>
>> So, probably something is missing in the newer Kernel version, which
>is
>> present in the legacy Kernel 2.6.35.
>>
>> [1]
>http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
>> imx_2.6.35_1.1.0
>> [2]
>http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
>> imx_4.1.15_1.0.0_ga
>
>during implementation of DDR mode for the mmc driver [1] i noticed a
>performance
>gap between the vendor kernel and mainline by a factor of 2. I expect
>that your
>wireless interface is connected via SDIO.
Yes, it is. I had the suspicion that the MMC or the DMA driver is the bootleneck, too.
>
>[1] -
>http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-3-mmc-mxs-mmc-implement-ddr-support
Looks like the patches might help. Have you tried SDIO wifi so far?
J?rg
^ permalink raw reply
* [PATCH] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs
From: Ard Biesheuvel @ 2016-10-15 9:16 UTC (permalink / raw)
To: linux-arm-kernel
The symbol CRCs are emitted as ELF symbols, which allows us to easily
populate the kcrctab sections by relying on the linker to associate
each kcrctab slot with the correct value.
This has two downsides:
- given that the CRCs are treated as pointers, we waste 4 bytes for
each CRC on 64 bit architectures,
- on architectures that support runtime relocation, a relocation entry is
emitted for each CRC value, which may take up 24 bytes of __init space
(on ELF64 systems)
This comes down to a x8 overhead in [uncompressed] kernel size. In addition,
each relocation has to be reverted before the CRC value can be used, which
has resulted in an ugly workaround involving ARCH_RELOCATES_KCRCTAB, and an
even uglier workaround around the workaround involving the "TOC." symbol on
PPC64. This patch gets rid of all of that.
So switch to explicit 32 bit values on 64 bit architectures. This fixes
both issues, given that 32 bit values are not treated as runtime relocatable
quantities on ELF64 systems, even if they ultimately resolve to linker
supplied values. Also note that the only two architectures affected by the
runtime relocation issue are PPC and arm64, both of which rely on the
toolchain's PIE routines to create a runtime relocatable vmlinux. While x86
also implements CONFIG_RELOCATABLE, it relies on its own build tools, which
disregard kcrctab entries explicitly.
So redefine all CRC fields and variables as u32, and redefine the
__CRC_SYMBOL() macro for 64 bit builds to emit the CRC reference using
inline assembler (which is necessary since 64-bit C code cannot use
32-bit types to hold memory addresses, even if they are ultimately
resolved using values that do no exceed 0xffffffff).
Also remove the special handling for PPC64, this should no longer be
required.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
I received some feedback on draft versions of this patch from the kbuild
test robot, but none of it regarding the inline asm in this patch.
Hopefully, that means it works on all 64 bit architectures we support,
but I have not been able to test that exhaustively myself.
On an arm64 defconfig build with CONFIG_RELOCATABLE=y, this patch reduces
the CRC footprint by 24 KB for .rodata, and by 217 KB for .init
Before:
[ 9] __kcrctab PROGBITS ffff000008b992a8 00b292a8
0000000000009440 0000000000000000 A 0 0 8
[10] __kcrctab_gpl PROGBITS ffff000008ba26e8 00b326e8
0000000000008d40 0000000000000000 A 0 0 8
...
[22] .rela RELA ffff000008c96e20 00c26e20
00000000001cc758 0000000000000018 A 0 0 8
After:
[ 9] __kcrctab PROGBITS ffff000008b728a8 00b028a8
0000000000004a20 0000000000000000 A 0 0 1
[10] __kcrctab_gpl PROGBITS ffff000008b772c8 00b072c8
00000000000046a0 0000000000000000 A 0 0 1
...
[22] .rela RELA ffff000008c66e20 00bf6e20
00000000001962d8 0000000000000018 A 0 0 8
arch/powerpc/include/asm/module.h | 4 --
arch/powerpc/kernel/module_64.c | 8 ----
include/linux/export.h | 8 ++++
include/linux/module.h | 16 ++++----
kernel/module.c | 39 +++++++-------------
5 files changed, 30 insertions(+), 45 deletions(-)
diff --git a/arch/powerpc/include/asm/module.h b/arch/powerpc/include/asm/module.h
index cd4ffd86765f..94a7f7aa3ae8 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -94,9 +94,5 @@ struct exception_table_entry;
void sort_ex_table(struct exception_table_entry *start,
struct exception_table_entry *finish);
-#if defined(CONFIG_MODVERSIONS) && defined(CONFIG_PPC64)
-#define ARCH_RELOCATES_KCRCTAB
-#define reloc_start PHYSICAL_START
-#endif
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MODULE_H */
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 183368e008cf..be9b2d5ff846 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -286,14 +286,6 @@ static void dedotify_versions(struct modversion_info *vers,
for (end = (void *)vers + size; vers < end; vers++)
if (vers->name[0] == '.') {
memmove(vers->name, vers->name+1, strlen(vers->name));
-#ifdef ARCH_RELOCATES_KCRCTAB
- /* The TOC symbol has no CRC computed. To avoid CRC
- * check failing, we must force it to the expected
- * value (see CRC check in module.c).
- */
- if (!strcmp(vers->name, "TOC."))
- vers->crc = -(unsigned long)reloc_start;
-#endif
}
}
diff --git a/include/linux/export.h b/include/linux/export.h
index d7df4922da1d..1d2f841e8368 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -40,6 +40,7 @@ extern struct module __this_module;
#if defined(__KERNEL__) && !defined(__GENKSYMS__)
#ifdef CONFIG_MODVERSIONS
+#ifndef CONFIG_64BIT
/* Mark the CRC weak since genksyms apparently decides not to
* generate a checksums for some symbols */
#define __CRC_SYMBOL(sym, sec) \
@@ -49,6 +50,13 @@ extern struct module __this_module;
__attribute__((section("___kcrctab" sec "+" #sym), unused)) \
= (unsigned long) &__crc_##sym;
#else
+#define __CRC_SYMBOL(sym, sec) \
+ asm(" .section \"___kcrctab" sec "+" #sym "\", \"a\" \n" \
+ " .weak " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
+ " .word " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
+ " .previous \n");
+#endif
+#else
#define __CRC_SYMBOL(sym, sec)
#endif
diff --git a/include/linux/module.h b/include/linux/module.h
index 0c3207d26ac0..a51b70fcbc6b 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -33,7 +33,7 @@
#define MODULE_NAME_LEN MAX_PARAM_PREFIX_LEN
struct modversion_info {
- unsigned long crc;
+ u32 crc;
char name[MODULE_NAME_LEN];
};
@@ -346,7 +346,7 @@ struct module {
/* Exported symbols */
const struct kernel_symbol *syms;
- const unsigned long *crcs;
+ const u32 *crcs;
unsigned int num_syms;
/* Kernel parameters. */
@@ -359,18 +359,18 @@ struct module {
/* GPL-only exported symbols. */
unsigned int num_gpl_syms;
const struct kernel_symbol *gpl_syms;
- const unsigned long *gpl_crcs;
+ const u32 *gpl_crcs;
#ifdef CONFIG_UNUSED_SYMBOLS
/* unused exported symbols. */
const struct kernel_symbol *unused_syms;
- const unsigned long *unused_crcs;
+ const u32 *unused_crcs;
unsigned int num_unused_syms;
/* GPL-only, unused exported symbols. */
unsigned int num_unused_gpl_syms;
const struct kernel_symbol *unused_gpl_syms;
- const unsigned long *unused_gpl_crcs;
+ const u32 *unused_gpl_crcs;
#endif
#ifdef CONFIG_MODULE_SIG
@@ -382,7 +382,7 @@ struct module {
/* symbols that will be GPL-only in the near future. */
const struct kernel_symbol *gpl_future_syms;
- const unsigned long *gpl_future_crcs;
+ const u32 *gpl_future_crcs;
unsigned int num_gpl_future_syms;
/* Exception table */
@@ -523,7 +523,7 @@ struct module *find_module(const char *name);
struct symsearch {
const struct kernel_symbol *start, *stop;
- const unsigned long *crcs;
+ const u32 *crcs;
enum {
NOT_GPL_ONLY,
GPL_ONLY,
@@ -539,7 +539,7 @@ struct symsearch {
*/
const struct kernel_symbol *find_symbol(const char *name,
struct module **owner,
- const unsigned long **crc,
+ const u32 **crc,
bool gplok,
bool warn);
diff --git a/kernel/module.c b/kernel/module.c
index f57dd63186e6..f2d39148814a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -386,16 +386,16 @@ extern const struct kernel_symbol __start___ksymtab_gpl[];
extern const struct kernel_symbol __stop___ksymtab_gpl[];
extern const struct kernel_symbol __start___ksymtab_gpl_future[];
extern const struct kernel_symbol __stop___ksymtab_gpl_future[];
-extern const unsigned long __start___kcrctab[];
-extern const unsigned long __start___kcrctab_gpl[];
-extern const unsigned long __start___kcrctab_gpl_future[];
+extern const u32 __start___kcrctab[];
+extern const u32 __start___kcrctab_gpl[];
+extern const u32 __start___kcrctab_gpl_future[];
#ifdef CONFIG_UNUSED_SYMBOLS
extern const struct kernel_symbol __start___ksymtab_unused[];
extern const struct kernel_symbol __stop___ksymtab_unused[];
extern const struct kernel_symbol __start___ksymtab_unused_gpl[];
extern const struct kernel_symbol __stop___ksymtab_unused_gpl[];
-extern const unsigned long __start___kcrctab_unused[];
-extern const unsigned long __start___kcrctab_unused_gpl[];
+extern const u32 __start___kcrctab_unused[];
+extern const u32 __start___kcrctab_unused_gpl[];
#endif
#ifndef CONFIG_MODVERSIONS
@@ -494,7 +494,7 @@ struct find_symbol_arg {
/* Output */
struct module *owner;
- const unsigned long *crc;
+ const u32 *crc;
const struct kernel_symbol *sym;
};
@@ -560,7 +560,7 @@ static bool find_symbol_in_section(const struct symsearch *syms,
* (optional) module which owns it. Needs preempt disabled or module_mutex. */
const struct kernel_symbol *find_symbol(const char *name,
struct module **owner,
- const unsigned long **crc,
+ const u32 **crc,
bool gplok,
bool warn)
{
@@ -1257,22 +1257,11 @@ static int try_to_force_load(struct module *mod, const char *reason)
}
#ifdef CONFIG_MODVERSIONS
-/* If the arch applies (non-zero) relocations to kernel kcrctab, unapply it. */
-static unsigned long maybe_relocated(unsigned long crc,
- const struct module *crc_owner)
-{
-#ifdef ARCH_RELOCATES_KCRCTAB
- if (crc_owner == NULL)
- return crc - (unsigned long)reloc_start;
-#endif
- return crc;
-}
-
static int check_version(Elf_Shdr *sechdrs,
unsigned int versindex,
const char *symname,
struct module *mod,
- const unsigned long *crc,
+ const u32 *crc,
const struct module *crc_owner)
{
unsigned int i, num_versions;
@@ -1294,10 +1283,10 @@ static int check_version(Elf_Shdr *sechdrs,
if (strcmp(versions[i].name, symname) != 0)
continue;
- if (versions[i].crc == maybe_relocated(*crc, crc_owner))
+ if (versions[i].crc == *crc)
return 1;
- pr_debug("Found checksum %lX vs module %lX\n",
- maybe_relocated(*crc, crc_owner), versions[i].crc);
+ pr_debug("Found checksum %X vs module %X\n",
+ *crc, versions[i].crc);
goto bad_version;
}
@@ -1314,7 +1303,7 @@ static inline int check_modstruct_version(Elf_Shdr *sechdrs,
unsigned int versindex,
struct module *mod)
{
- const unsigned long *crc;
+ const u32 *crc;
/*
* Since this should be found in kernel (which can't be removed), no
@@ -1347,7 +1336,7 @@ static inline int check_version(Elf_Shdr *sechdrs,
unsigned int versindex,
const char *symname,
struct module *mod,
- const unsigned long *crc,
+ const u32 *crc,
const struct module *crc_owner)
{
return 1;
@@ -1375,7 +1364,7 @@ static const struct kernel_symbol *resolve_symbol(struct module *mod,
{
struct module *owner;
const struct kernel_symbol *sym;
- const unsigned long *crc;
+ const u32 *crc;
int err;
/*
--
2.7.4
^ permalink raw reply related
* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-10-15 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476521171.1670.2.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 15. Oktober 2016 um 10:46
> geschrieben:
>
>
> Thanks!
>
>
> For the record:
>
> Note, this is the result for the wireless interface.
>
> I got one of my custom boards running the legacy Linux Kernel 2.6.35
> officially supported from Freescale (NXP) and the bcmdhd driver from
> the Wiced project, where I get >20Mbps TCP throughput. The firmware
> version reported is:
>
> # wl ver
> 5.90 RC115.2
> wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
>
>
> I got it also running with the Linux Kernel 4.1.15 from Freescale [2],
> which is not officially supported for the i.MX28 target, with the
> latest bcmdhd version where I get <7Mbps TCP throughput (which is much
> the same I get with the brcmfmac driver). The firmware version reported
> is:
>
> # wl ver
> 1.107 RC5.0
> wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
>
> So, probably something is missing in the newer Kernel version, which is
> present in the legacy Kernel 2.6.35.
>
> [1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
> imx_2.6.35_1.1.0
> [2] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
> imx_4.1.15_1.0.0_ga
during implementation of DDR mode for the mmc driver [1] i noticed a performance
gap between the vendor kernel and mainline by a factor of 2. I expect that your
wireless interface is connected via SDIO.
Stefan
[1] -
http://linux-arm-kernel.infradead.narkive.com/GNkqjvo8/patch-rfc-0-3-mmc-mxs-mmc-implement-ddr-support
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-10-15 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161014081349.1afb22c6@ipc1.ka-ro>
On Fri, 2016-10-14 at 08:13 +0200, Lothar Wa?mann wrote:
> Hi,
>
> On Thu, 13 Oct 2016 21:43:00 +0200 J?rg Krause wrote:
> > Am 13. Oktober 2016 08:48:07 MESZ, schrieb "Lothar Wa?mann" <LW@KAR
> > O-electronics.de>:
> > > On Thu, 13 Oct 2016 01:09:13 +0200 J?rg Krause wrote:
>
> [...]
> > > This is the iperf output on a TX28 with current mainline kernel
> > > (4.8.0-rc5):
> > > ------------------------------------------------------------
> > > Client connecting to 192.168.100.1, TCP port 5001
> > > TCP window size: 43.8 KByte (default)
> > > ------------------------------------------------------------
> > > [??3] local 192.168.100.56 port 60325 connected with
> > > 192.168.100.1 port
> > > 5001
> > > [ ID] Interval???????Transfer?????Bandwidth
> > > [??3]??0.0-10.0 sec??57.5 MBytes??48.2 Mbits/sec
> > >
> > > You might check your kernel DEBUG configs (especially
> > > CONFIG_DEBUG_PAGEALLOC).
> >
> > Thanks for sharing the iperf output. What LAN transceiver does the
> > TX28 has assembled?
> >
>
> The ethernet PHY is an SMSC LAN8710A.
Thanks!
For the record:
Note, this is the result for the wireless interface.
I got one of my custom boards running the legacy Linux Kernel 2.6.35
officially supported from Freescale (NXP) and the bcmdhd driver from
the Wiced project, where I get >20Mbps TCP throughput. The firmware
version reported is:
# wl ver
5.90 RC115.2
wl0: Apr 24 2014 14:08:41 version 5.90.195.89.24 FWID 01-bc2d0891
I got it also running with the Linux Kernel 4.1.15 from Freescale [2],
which is not officially supported for the i.MX28 target, with the
latest bcmdhd version where I get <7Mbps TCP throughput (which is much
the same I get with the brcmfmac driver). The firmware version reported
is:
# wl ver
1.107 RC5.0
wl0: Aug??8 2016 02:17:48 version 5.90.232 FWID 01-0
So, probably something is missing in the newer Kernel version, which is
present in the legacy Kernel 2.6.35.
[1] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
imx_2.6.35_1.1.0
[2] http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=
imx_4.1.15_1.0.0_ga
^ permalink raw reply
* [PATCH 4/4] staging/vchi: Remove dependency on CONFIG_BROKEN.
From: Stefan Wahren @ 2016-10-15 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013070535.GA23147@kroah.com>
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> hat am 13. Oktober 2016 um
> 09:05 geschrieben:
>
>
> On Mon, Oct 03, 2016 at 11:52:09AM -0700, Eric Anholt wrote:
> > The driver builds now.
> >
> > Signed-off-by: Eric Anholt <eric@anholt.net>
> > ---
> > drivers/staging/vc04_services/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/vc04_services/Kconfig
> > b/drivers/staging/vc04_services/Kconfig
> > index 9676fb29075a..db8e1beb89f9 100644
> > --- a/drivers/staging/vc04_services/Kconfig
> > +++ b/drivers/staging/vc04_services/Kconfig
> > @@ -1,6 +1,6 @@
> > config BCM2708_VCHIQ
> > tristate "Videocore VCHIQ"
> > - depends on RASPBERRYPI_FIRMWARE && BROKEN
> > + depends on RASPBERRYPI_FIRMWARE
> > default y
> > help
> > Kernel to VideoCore communication interface for the
>
> I've dropped this patch from my branch as there are build errors on
> arm64 systems still, and we don't want regressions like that.
>
> I've forwarded you the error messages, and I'll be glad to add this
> patch back once these issues are fixed.
I ask the author of this downstream pull request [1] to send the VHCIQ part as
indiviual patches.
He is interested to submit them upstream.
[1] - https://github.com/raspberrypi/linux/pull/1611
>
> thanks,
>
> greg k-h
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
^ 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