* [PATCH v2] clk: samsung: clk-exynos-audss: Fix module autoload
From: Javier Martinez Canillas @ 2016-10-16 13:45 UTC (permalink / raw)
To: linux-arm-kernel
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
Fixes: 4d252fd5719b ("clk: samsung: Allow modular build of the Audio Subsystem CLKCON driver")
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes in v2:
- Add fixes tag. Suggested by Krzysztof Kozlowski.
- Add Krzysztof Kozlowski's Reviewed-by and Tested-by tags.
drivers/clk/samsung/clk-exynos-audss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 51d152f735cc..17e68a724945 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -106,6 +106,7 @@ static const struct of_device_id exynos_audss_clk_of_match[] = {
},
{ },
};
+MODULE_DEVICE_TABLE(of, exynos_audss_clk_of_match);
static void exynos_audss_clk_teardown(void)
{
--
2.7.4
^ permalink raw reply related
* [PATCH] clk: samsung: clk-exynos-audss: Fix module autoload
From: Javier Martinez Canillas @ 2016-10-16 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161015172711.GA6465@kozik-lap>
Hello Krzysztof,
On 10/15/2016 02:27 PM, Krzysztof Kozlowski wrote:
> 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")
>
Indeed. I missed that, sorry. I'll post a v2 including this information.
> Anyway, this fixes the issue, so:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> Tested-by: Krzysztof Kozlowski <krzk@kernel.org>
>
Thanks!
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] arm64: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Masahiro Yamada @ 2016-10-16 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475893534-12198-1-git-send-email-yamada.masahiro@socionext.com>
2016-10-08 11:25 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> This is a counter-part of the following ARM-32bit variant:
> https://patchwork.kernel.org/patch/9341021/
>
> As discussed with Philipp, we go ARCH_HAS_RESET_CONTROLLER for now.
>
Patch applied.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] ARM: at91/dt: pullup dbgu rx instead of tx
From: Peter Rosin @ 2016-10-16 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20150924144753.GY4287@piout.net>
Hi again,
I forgot about this, and it's been a year. But isn't it time to
upstream those pull-up fixes that Sylvain provided?
Cheers,
Peter
On 2015-09-24 16:47, Alexandre Belloni wrote:
> Hi Peter,
>
> Thanks for the patch but you actually got beaten by Sylvain:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368426.html
>
> On 24/09/2015 at 16:44:15 +0200, Peter Rosin wrote :
>> From: Peter Rosin <peda@axentia.se>
>>
>> It seems pointless to pullup the tx line, but there is value in pulling
>> up the rx line.
>>
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> arch/arm/boot/dts/sama5d3.dtsi | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
>> index 9e2444b07bce..304a40c5552a 100644
>> --- a/arch/arm/boot/dts/sama5d3.dtsi
>> +++ b/arch/arm/boot/dts/sama5d3.dtsi
>> @@ -545,8 +545,8 @@
>> dbgu {
>> pinctrl_dbgu: dbgu-0 {
>> atmel,pins =
>> - <AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB30 periph A */
>> - AT91_PIOB 31 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>; /* PB31 periph A with pullup */
>> + <AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PB30 periph A with pullup */
>> + AT91_PIOB 31 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB31 periph A */
>> };
>> };
>>
>> --
>> 1.7.10.4
>>
>
^ permalink raw reply
* [PATCH] ARM/orion/gpio: Replace three seq_printf() calls by seq_puts() in orion_gpio_dbg_show()
From: SF Markus Elfring @ 2016-10-16 10:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 16 Oct 2016 12:30:48 +0200
Strings which did not contain data format specifications 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/plat-orion/gpio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-orion/gpio.c b/arch/arm/plat-orion/gpio.c
index f740693..26a531e 100644
--- a/arch/arm/plat-orion/gpio.c
+++ b/arch/arm/plat-orion/gpio.c
@@ -478,13 +478,13 @@ static void orion_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
(data_in ^ in_pol) & msk ? "hi" : "lo",
in_pol & msk ? "lo" : "hi");
if (!((edg_msk | lvl_msk) & msk)) {
- seq_printf(s, " disabled\n");
+ seq_puts(s, " disabled\n");
continue;
}
if (edg_msk & msk)
- seq_printf(s, " edge ");
+ seq_puts(s, " edge ");
if (lvl_msk & msk)
- seq_printf(s, " level");
+ seq_puts(s, " level");
seq_printf(s, " (%s)\n", cause & msk ? "pending" : "clear ");
}
}
--
2.10.1
^ permalink raw reply related
* [PATCH] ARM-mm-dump: Use seq_putc() in note_page()
From: SF Markus Elfring @ 2016-10-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 16 Oct 2016 12:00:26 +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/mm/dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 9fe8e24..4bd8f9a 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -241,7 +241,7 @@ static void note_page(struct pg_state *st, unsigned long addr, unsigned level, u
seq_printf(st->seq, "%9lu%c", delta, *unit);
if (pg_level[st->level].bits)
dump_prot(st, pg_level[st->level].bits, pg_level[st->level].num);
- seq_printf(st->seq, "\n");
+ seq_putc(st->seq, '\n');
}
if (addr >= st->marker[1].start_address) {
--
2.10.1
^ permalink raw reply related
* [arm-soc:to-build 23/23] drivers/net/ethernet/broadcom/bcm63xx_enet.c:1129:2: warning: 'phydev' may be used uninitialized in this function
From: kbuild test robot @ 2016-10-16 4:22 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git to-build
head: 0f460ef4d0b0e50f64b03962048dec6fa1d40d20
commit: 0f460ef4d0b0e50f64b03962048dec6fa1d40d20 [23/23] Revert "Disable "maybe-uninitialized" warning globally"
config: mips-bcm63xx_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0f460ef4d0b0e50f64b03962048dec6fa1d40d20
# save the attached .config to linux build tree
make.cross ARCH=mips
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/net/ethernet/broadcom/bcm63xx_enet.c: In function 'bcm_enet_open':
>> drivers/net/ethernet/broadcom/bcm63xx_enet.c:1129:2: warning: 'phydev' may be used uninitialized in this function [-Wmaybe-uninitialized]
phy_disconnect(phydev);
^~~~~~~~~~~~~~~~~~~~~~
vim +/phydev +1129 drivers/net/ethernet/broadcom/bcm63xx_enet.c
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1113 priv->tx_desc_cpu, priv->tx_desc_dma);
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1114
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1115 out_free_rx_ring:
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1116 dma_free_coherent(kdev, priv->rx_desc_alloc_size,
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1117 priv->rx_desc_cpu, priv->rx_desc_dma);
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1118
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1119 out_freeirq_tx:
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1120 free_irq(priv->irq_tx, dev);
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1121
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1122 out_freeirq_rx:
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1123 free_irq(priv->irq_rx, dev);
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1124
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1125 out_freeirq:
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1126 free_irq(dev->irq, dev);
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1127
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1128 out_phy_disconnect:
625eb866 drivers/net/ethernet/broadcom/bcm63xx_enet.c Philippe Reynes 2016-09-18 @1129 phy_disconnect(phydev);
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1130
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1131 return ret;
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1132 }
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1133
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1134 /*
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1135 * disable mac
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1136 */
9b1fc55a drivers/net/bcm63xx_enet.c Maxime Bizon 2009-08-18 1137 static void bcm_enet_disable_mac(struct bcm_enet_priv *priv)
:::::: The code at line 1129 was first introduced by commit
:::::: 625eb8667d6fcb22e474502133986b2d2838917d net: ethernet: broadcom: bcm63xx: use phydev from struct net_device
:::::: TO: Philippe Reynes <tremyfr@gmail.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 11955 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161016/d9375f3f/attachment.gz>
^ permalink raw reply
* [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
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