* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Kees Cook @ 2016-10-16 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161015143548.GA31114@MBP.local>
On Sat, Oct 15, 2016 at 7:35 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> 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.
Ah-ha! I misunderstood that to mean -rc2. :) Thanks for the update!
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* WARNING: SOMEONE RECEIVING THIS HAS BEEN HACKED (was: Re: [PATCH v2 0/4] PXA cpufreq conversion to clock API)
From: Russell King - ARM Linux @ 2016-10-15 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161015203421.GG1041@n2100.armlinux.org.uk>
Guys,
Looks like gmail's been hacked (or something). Within 50 minutes of
sending the reply below, I've received at least 10 replies with the
following headers:
In-Reply-To: <20161015203421.GG1041@n2100.armlinux.org.uk>
References: <1476561450-28407-1-git-send-email-robert.jarzmik@free.fr> <20161015203421.GG1041@n2100.armlinux.org.uk>
from various gmail.com addresses, each and every one containing some kind
of spam. Each reply is from a victim of spam - the replies themselves are
people replying to the spam that they have received. The quoted message
is allegedly from me, and even includes the line:
"On 15 Oct 2016, at 21:34, Russell King - ARM Linux <linux@armlinux.org.uk>
wrote:"
which is the time I sent the original message.
It's either that gmail has been hacked, or one of the mailing lists in
the recipients of this message has been hacked.
On Sat, Oct 15, 2016 at 09:34:21PM +0100, Russell King - ARM Linux wrote:
> On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
> > 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
>
> Have you tested whether this patch set results in functional cpufreq
> support - looking at drivers/clk/pxa, the CPU clock is read-only -
> it can't be used to change the clock rate. So, I very much doubt this
> has been functionally tested.
>
> Don't forget that changing the CPU clock rate needs other changes
> (like the memory clock rate) so all that code you're removing in
> patch 4 (which does the actual clock change) needs to go somewhere.
>
> --
> 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.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 0/4] PXA cpufreq conversion to clock API
From: Robert Jarzmik @ 2016-10-15 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161015203421.GG1041@n2100.armlinux.org.uk>
Russell King - ARM Linux <linux@armlinux.org.uk> writes:
> On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
>> 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
>
> Have you tested whether this patch set results in functional cpufreq
> support - looking at drivers/clk/pxa, the CPU clock is read-only -
> it can't be used to change the clock rate. So, I very much doubt this
> has been functionally tested.
Oh yes I did, on lubbock and mainstone ... but this requires another patchset
under review, here :
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1247123.html
> Don't forget that changing the CPU clock rate needs other changes
> (like the memory clock rate) so all that code you're removing in
> patch 4 (which does the actual clock change) needs to go somewhere.
Sure, here :
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1247130.html
I would have been wiser to quote these URLs instead of speaking of "clock
changes must be fully review and go in first as a prequisite".
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 3/3] ARM-OMAP2+: pm-debug: Use seq_putc() in two functions
From: SF Markus Elfring @ 2016-10-15 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e86a5ded-a6e9-1b40-be1a-98fffef0abb5@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 15 Oct 2016 22:30:44 +0200
A single character (line break) should be put into a sequence at the end.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-omap2/pm-debug.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 0b33986..003a6cb 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -114,8 +114,7 @@ static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm, void *user)
seq_printf(s, ",RET-MEMBANK%d-OFF:%d", i + 1,
pwrdm->ret_mem_off_counter[i]);
- seq_printf(s, "\n");
-
+ seq_putc(s, '\n');
return 0;
}
@@ -138,7 +137,7 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user)
seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
pwrdm->state_timer[i]);
- seq_printf(s, "\n");
+ seq_putc(s, '\n');
return 0;
}
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] ARM-OMAP2+: mux: Use seq_putc() in omap_mux_dbg_signal_show()
From: SF Markus Elfring @ 2016-10-15 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e86a5ded-a6e9-1b40-be1a-98fffef0abb5@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 15 Oct 2016 22:24:29 +0200
A single character (line break) should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-omap2/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 4bdfa3d..e1fa39e 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -661,7 +661,7 @@ static int omap_mux_dbg_signal_show(struct seq_file *s, void *unused)
m->balls[1] ? m->balls[1] : none);
seq_puts(s, "mode: ");
omap_mux_decode(s, val);
- seq_printf(s, "\n");
+ seq_putc(s, '\n');
seq_printf(s, "signals: %s | %s | %s | %s | %s | %s | %s | %s\n",
m->muxnames[0] ? m->muxnames[0] : none,
m->muxnames[1] ? m->muxnames[1] : none,
--
2.10.1
^ permalink raw reply related
* [PATCH 1/3] ARM-OMAP2+: mux: Replace three seq_printf() calls by seq_puts()
From: SF Markus Elfring @ 2016-10-15 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e86a5ded-a6e9-1b40-be1a-98fffef0abb5@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 15 Oct 2016 22:22:09 +0200
Strings which did not contain data format specification should be put into
a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
arch/arm/mach-omap2/mux.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 176eef6..4bdfa3d 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -561,7 +561,7 @@ static inline void omap_mux_decode(struct seq_file *s, u16 val)
do {
seq_printf(s, "%s", flags[i]);
if (i > 0)
- seq_printf(s, " | ");
+ seq_puts(s, " | ");
} while (i-- > 0);
}
@@ -602,7 +602,7 @@ static int omap_mux_dbg_board_show(struct seq_file *s, void *unused)
*/
seq_printf(s, "OMAP%d_MUX(%s, ", omap_gen, m0_def);
omap_mux_decode(s, val);
- seq_printf(s, "),\n");
+ seq_puts(s, "),\n");
}
return 0;
@@ -659,7 +659,7 @@ static int omap_mux_dbg_signal_show(struct seq_file *s, void *unused)
partition->phys + m->reg_offset, m->reg_offset, val,
m->balls[0] ? m->balls[0] : none,
m->balls[1] ? m->balls[1] : none);
- seq_printf(s, "mode: ");
+ seq_puts(s, "mode: ");
omap_mux_decode(s, val);
seq_printf(s, "\n");
seq_printf(s, "signals: %s | %s | %s | %s | %s | %s | %s | %s\n",
--
2.10.1
^ permalink raw reply related
* [PATCH 0/3] ARM-OMAP2+: Fine-tuning for five function implementations
From: SF Markus Elfring @ 2016-10-15 20:50 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 15 Oct 2016 22:44:22 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (3):
mux: Replace three seq_printf() calls by seq_puts()
mux: Use seq_putc() in omap_mux_dbg_signal_show()
pm-debug: Use seq_putc() in two functions
arch/arm/mach-omap2/mux.c | 8 ++++----
arch/arm/mach-omap2/pm-debug.c | 5 ++---
2 files changed, 6 insertions(+), 7 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH v2 0/4] PXA cpufreq conversion to clock API
From: Russell King - ARM Linux @ 2016-10-15 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476561450-28407-1-git-send-email-robert.jarzmik@free.fr>
On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
> 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
Have you tested whether this patch set results in functional cpufreq
support - looking at drivers/clk/pxa, the CPU clock is read-only -
it can't be used to change the clock rate. So, I very much doubt this
has been functionally tested.
Don't forget that changing the CPU clock rate needs other changes
(like the memory clock rate) so all that code you're removing in
patch 4 (which does the actual clock change) needs to go somewhere.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 4/4] cpufreq: pxa: convert to clock API
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>
As the clock settings have been introduced into the clock pxa drivers,
which are now available to change the CPU clock by themselves, remove
the clock handling from this driver, and rely on pxa clock drivers.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v1: added !OF Kconfig dependency
---
drivers/cpufreq/Kconfig.arm | 2 +-
drivers/cpufreq/pxa2xx-cpufreq.c | 191 ++++++++-------------------------------
2 files changed, 40 insertions(+), 153 deletions(-)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d89b8afe23b6..1a4f04351f98 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -236,7 +236,7 @@ config ARM_TEGRA124_CPUFREQ
config ARM_PXA2xx_CPUFREQ
tristate "Intel PXA2xx CPUfreq driver"
- depends on PXA27x || PXA25x
+ depends on (PXA27x || PXA25x) && !OF
help
This add the CPUFreq driver support for Intel PXA2xx SOCs.
diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index ce345bf34d5d..06b024a3e474 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -58,56 +58,40 @@ module_param(pxa27x_maxfreq, uint, 0);
MODULE_PARM_DESC(pxa27x_maxfreq, "Set the pxa27x maxfreq in MHz"
"(typically 624=>pxa270, 416=>pxa271, 520=>pxa272)");
+struct pxa_cpufreq_data {
+ struct clk *clk_core;
+};
+static struct pxa_cpufreq_data pxa_cpufreq_data;
+
struct pxa_freqs {
unsigned int khz;
- unsigned int membus;
- unsigned int cccr;
- unsigned int div2;
- unsigned int cclkcfg;
int vmin;
int vmax;
};
-/* Define the refresh period in mSec for the SDRAM and the number of rows */
-#define SDRAM_TREF 64 /* standard 64ms SDRAM */
-static unsigned int sdram_rows;
-
-#define CCLKCFG_TURBO 0x1
-#define CCLKCFG_FCS 0x2
-#define CCLKCFG_HALFTURBO 0x4
-#define CCLKCFG_FASTBUS 0x8
-#define MDREFR_DB2_MASK (MDREFR_K2DB2 | MDREFR_K1DB2)
-#define MDREFR_DRI_MASK 0xFFF
-
-#define MDCNFG_DRAC2(mdcnfg) (((mdcnfg) >> 21) & 0x3)
-#define MDCNFG_DRAC0(mdcnfg) (((mdcnfg) >> 5) & 0x3)
-
/*
* PXA255 definitions
*/
-/* Use the run mode frequencies for the CPUFREQ_POLICY_PERFORMANCE policy */
-#define CCLKCFG CCLKCFG_TURBO | CCLKCFG_FCS
-
static const struct pxa_freqs pxa255_run_freqs[] =
{
- /* CPU MEMBUS CCCR DIV2 CCLKCFG run turbo PXbus SDRAM */
- { 99500, 99500, 0x121, 1, CCLKCFG, -1, -1}, /* 99, 99, 50, 50 */
- {132700, 132700, 0x123, 1, CCLKCFG, -1, -1}, /* 133, 133, 66, 66 */
- {199100, 99500, 0x141, 0, CCLKCFG, -1, -1}, /* 199, 199, 99, 99 */
- {265400, 132700, 0x143, 1, CCLKCFG, -1, -1}, /* 265, 265, 133, 66 */
- {331800, 165900, 0x145, 1, CCLKCFG, -1, -1}, /* 331, 331, 166, 83 */
- {398100, 99500, 0x161, 0, CCLKCFG, -1, -1}, /* 398, 398, 196, 99 */
+ /* CPU MEMBUS run turbo PXbus SDRAM */
+ { 99500, -1, -1}, /* 99, 99, 50, 50 */
+ {132700, -1, -1}, /* 133, 133, 66, 66 */
+ {199100, -1, -1}, /* 199, 199, 99, 99 */
+ {265400, -1, -1}, /* 265, 265, 133, 66 */
+ {331800, -1, -1}, /* 331, 331, 166, 83 */
+ {398100, -1, -1}, /* 398, 398, 196, 99 */
};
/* Use the turbo mode frequencies for the CPUFREQ_POLICY_POWERSAVE policy */
static const struct pxa_freqs pxa255_turbo_freqs[] =
{
- /* CPU MEMBUS CCCR DIV2 CCLKCFG run turbo PXbus SDRAM */
- { 99500, 99500, 0x121, 1, CCLKCFG, -1, -1}, /* 99, 99, 50, 50 */
- {199100, 99500, 0x221, 0, CCLKCFG, -1, -1}, /* 99, 199, 50, 99 */
- {298500, 99500, 0x321, 0, CCLKCFG, -1, -1}, /* 99, 287, 50, 99 */
- {298600, 99500, 0x1c1, 0, CCLKCFG, -1, -1}, /* 199, 287, 99, 99 */
- {398100, 99500, 0x241, 0, CCLKCFG, -1, -1}, /* 199, 398, 99, 99 */
+ /* CPU run turbo PXbus SDRAM */
+ { 99500, -1, -1}, /* 99, 99, 50, 50 */
+ {199100, -1, -1}, /* 99, 199, 50, 99 */
+ {298500, -1, -1}, /* 99, 287, 50, 99 */
+ {298600, -1, -1}, /* 199, 287, 99, 99 */
+ {398100, -1, -1}, /* 199, 398, 99, 99 */
};
#define NUM_PXA25x_RUN_FREQS ARRAY_SIZE(pxa255_run_freqs)
@@ -122,47 +106,14 @@ static unsigned int pxa255_turbo_table;
module_param(pxa255_turbo_table, uint, 0);
MODULE_PARM_DESC(pxa255_turbo_table, "Selects the frequency table (0 = run table, !0 = turbo table)");
-/*
- * PXA270 definitions
- *
- * For the PXA27x:
- * Control variables are A, L, 2N for CCCR; B, HT, T for CLKCFG.
- *
- * A = 0 => memory controller clock from table 3-7,
- * A = 1 => memory controller clock = system bus clock
- * Run mode frequency = 13 MHz * L
- * Turbo mode frequency = 13 MHz * L * N
- * System bus frequency = 13 MHz * L / (B + 1)
- *
- * In CCCR:
- * A = 1
- * L = 16 oscillator to run mode ratio
- * 2N = 6 2 * (turbo mode to run mode ratio)
- *
- * In CCLKCFG:
- * B = 1 Fast bus mode
- * HT = 0 Half-Turbo mode
- * T = 1 Turbo mode
- *
- * For now, just support some of the combinations in table 3-7 of
- * PXA27x Processor Family Developer's Manual to simplify frequency
- * change sequences.
- */
-#define PXA27x_CCCR(A, L, N2) (A << 25 | N2 << 7 | L)
-#define CCLKCFG2(B, HT, T) \
- (CCLKCFG_FCS | \
- ((B) ? CCLKCFG_FASTBUS : 0) | \
- ((HT) ? CCLKCFG_HALFTURBO : 0) | \
- ((T) ? CCLKCFG_TURBO : 0))
-
static struct pxa_freqs pxa27x_freqs[] = {
- {104000, 104000, PXA27x_CCCR(1, 8, 2), 0, CCLKCFG2(1, 0, 1), 900000, 1705000 },
- {156000, 104000, PXA27x_CCCR(1, 8, 3), 0, CCLKCFG2(1, 0, 1), 1000000, 1705000 },
- {208000, 208000, PXA27x_CCCR(0, 16, 2), 1, CCLKCFG2(0, 0, 1), 1180000, 1705000 },
- {312000, 208000, PXA27x_CCCR(1, 16, 3), 1, CCLKCFG2(1, 0, 1), 1250000, 1705000 },
- {416000, 208000, PXA27x_CCCR(1, 16, 4), 1, CCLKCFG2(1, 0, 1), 1350000, 1705000 },
- {520000, 208000, PXA27x_CCCR(1, 16, 5), 1, CCLKCFG2(1, 0, 1), 1450000, 1705000 },
- {624000, 208000, PXA27x_CCCR(1, 16, 6), 1, CCLKCFG2(1, 0, 1), 1550000, 1705000 }
+ {104000, 900000, 1705000 },
+ {156000, 1000000, 1705000 },
+ {208000, 1180000, 1705000 },
+ {312000, 1250000, 1705000 },
+ {416000, 1350000, 1705000 },
+ {520000, 1450000, 1705000 },
+ {624000, 1550000, 1705000 }
};
#define NUM_PXA27x_FREQS ARRAY_SIZE(pxa27x_freqs)
@@ -241,51 +192,29 @@ static void pxa27x_guess_max_freq(void)
}
}
-static void init_sdram_rows(void)
-{
- uint32_t mdcnfg = __raw_readl(MDCNFG);
- unsigned int drac2 = 0, drac0 = 0;
-
- if (mdcnfg & (MDCNFG_DE2 | MDCNFG_DE3))
- drac2 = MDCNFG_DRAC2(mdcnfg);
-
- if (mdcnfg & (MDCNFG_DE0 | MDCNFG_DE1))
- drac0 = MDCNFG_DRAC0(mdcnfg);
-
- sdram_rows = 1 << (11 + max(drac0, drac2));
-}
-
-static u32 mdrefr_dri(unsigned int freq)
-{
- u32 interval = freq * SDRAM_TREF / sdram_rows;
-
- return (interval - (cpu_is_pxa27x() ? 31 : 0)) / 32;
-}
-
static unsigned int pxa_cpufreq_get(unsigned int cpu)
{
- return get_clk_frequency_khz(0);
+ struct pxa_cpufreq_data *data = cpufreq_get_driver_data();
+
+ return (unsigned int) clk_get_rate(data->clk_core) / 1000;
}
static int pxa_set_target(struct cpufreq_policy *policy, unsigned int idx)
{
struct cpufreq_frequency_table *pxa_freqs_table;
const struct pxa_freqs *pxa_freq_settings;
- unsigned long flags;
- unsigned int new_freq_cpu, new_freq_mem;
- unsigned int unused, preset_mdrefr, postset_mdrefr, cclkcfg;
+ struct pxa_cpufreq_data *data = cpufreq_get_driver_data();
+ unsigned int new_freq_cpu;
int ret = 0;
/* Get the current policy */
find_freq_tables(&pxa_freqs_table, &pxa_freq_settings);
new_freq_cpu = pxa_freq_settings[idx].khz;
- new_freq_mem = pxa_freq_settings[idx].membus;
if (freq_debug)
- pr_debug("Changing CPU frequency to %d Mhz, (SDRAM %d Mhz)\n",
- new_freq_cpu / 1000, (pxa_freq_settings[idx].div2) ?
- (new_freq_mem / 2000) : (new_freq_mem / 1000));
+ pr_debug("Changing CPU frequency from %d Mhz to %d Mhz\n",
+ policy->cur / 1000, new_freq_cpu / 1000);
if (vcc_core && new_freq_cpu > policy->cur) {
ret = pxa_cpufreq_change_voltage(&pxa_freq_settings[idx]);
@@ -293,53 +222,7 @@ static int pxa_set_target(struct cpufreq_policy *policy, unsigned int idx)
return ret;
}
- /* Calculate the next MDREFR. If we're slowing down the SDRAM clock
- * we need to preset the smaller DRI before the change. If we're
- * speeding up we need to set the larger DRI value after the change.
- */
- preset_mdrefr = postset_mdrefr = __raw_readl(MDREFR);
- if ((preset_mdrefr & MDREFR_DRI_MASK) > mdrefr_dri(new_freq_mem)) {
- preset_mdrefr = (preset_mdrefr & ~MDREFR_DRI_MASK);
- preset_mdrefr |= mdrefr_dri(new_freq_mem);
- }
- postset_mdrefr =
- (postset_mdrefr & ~MDREFR_DRI_MASK) | mdrefr_dri(new_freq_mem);
-
- /* If we're dividing the memory clock by two for the SDRAM clock, this
- * must be set prior to the change. Clearing the divide must be done
- * after the change.
- */
- if (pxa_freq_settings[idx].div2) {
- preset_mdrefr |= MDREFR_DB2_MASK;
- postset_mdrefr |= MDREFR_DB2_MASK;
- } else {
- postset_mdrefr &= ~MDREFR_DB2_MASK;
- }
-
- local_irq_save(flags);
-
- /* Set new the CCCR and prepare CCLKCFG */
- writel(pxa_freq_settings[idx].cccr, CCCR);
- cclkcfg = pxa_freq_settings[idx].cclkcfg;
-
- asm volatile(" \n\
- ldr r4, [%1] /* load MDREFR */ \n\
- b 2f \n\
- .align 5 \n\
-1: \n\
- str %3, [%1] /* preset the MDREFR */ \n\
- mcr p14, 0, %2, c6, c0, 0 /* set CCLKCFG[FCS] */ \n\
- str %4, [%1] /* postset the MDREFR */ \n\
- \n\
- b 3f \n\
-2: b 1b \n\
-3: nop \n\
- "
- : "=&r" (unused)
- : "r" (MDREFR), "r" (cclkcfg),
- "r" (preset_mdrefr), "r" (postset_mdrefr)
- : "r4", "r5");
- local_irq_restore(flags);
+ clk_set_rate(data->clk_core, new_freq_cpu * 1000);
/*
* Even if voltage setting fails, we don't report it, as the frequency
@@ -369,8 +252,6 @@ static int pxa_cpufreq_init(struct cpufreq_policy *policy)
pxa_cpufreq_init_voltages();
- init_sdram_rows();
-
/* set default policy and cpuinfo */
policy->cpuinfo.transition_latency = 1000; /* FIXME: 1 ms, assumed */
@@ -429,11 +310,17 @@ static struct cpufreq_driver pxa_cpufreq_driver = {
.init = pxa_cpufreq_init,
.get = pxa_cpufreq_get,
.name = "PXA2xx",
+ .driver_data = &pxa_cpufreq_data,
};
static int __init pxa_cpu_init(void)
{
int ret = -ENODEV;
+
+ pxa_cpufreq_data.clk_core = clk_get_sys(NULL, "core");
+ if (IS_ERR(pxa_cpufreq_data.clk_core))
+ return PTR_ERR(pxa_cpufreq_data.clk_core);
+
if (cpu_is_pxa25x() || cpu_is_pxa27x())
ret = cpufreq_register_driver(&pxa_cpufreq_driver);
return ret;
--
2.1.4
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: pxa: add pxa27x 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 PXA27x 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/pxa27x.dtsi | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 9e73dc6b3ed3..aef1186856bc 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -137,4 +137,44 @@
clocks = <&clks CLK_OSTIMER>;
status = "okay";
};
+
+ pxa270_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp at 104 {
+ opp-hz = /bits/ 64 <104000000>;
+ opp-microvolt = <900000 900000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 156 {
+ opp-hz = /bits/ 64 <156000000>;
+ opp-microvolt = <1000000 1000000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 208 {
+ opp-hz = /bits/ 64 <208000000>;
+ opp-microvolt = <1180000 1180000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 312 {
+ opp-hz = /bits/ 64 <312000000>;
+ opp-microvolt = <1250000 1250000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 416 {
+ opp-hz = /bits/ 64 <416000000>;
+ opp-microvolt = <1350000 1350000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 520 {
+ opp-hz = /bits/ 64 <520000000>;
+ opp-microvolt = <1450000 1450000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ opp at 624 {
+ opp-hz = /bits/ 64 <624000000>;
+ opp-microvolt = <1550000 1550000 1705000>;
+ clock-latency-ns = <20>;
+ };
+ };
};
--
2.1.4
^ permalink raw reply related
* [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
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