* [PATCH 1/1] arm64: mm: add config options for page table configuration
From: Scott Branden @ 2016-12-10 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209105722.GD11767@arm.com>
Hi Will,
On 16-12-09 02:57 AM, Will Deacon wrote:
> On Thu, Dec 08, 2016 at 11:33:39AM -0800, Scott Branden wrote:
>> Since I currently have your attention: I do think there is fundamental bug
>> in the ARM64 mm implementation. If you look at /sys/devices/system/memory
>> it only shows the last memoryX section created after init.
>
> That directory doesn't seem to exist on my arm64 systems. Do I have to
> enable something specific in the .config?
I looked in the /sys/devices/system/memory at it doesn't look like it
appears until memory hotplug is enabled in the system. This is another
patch I'm trying to work through at the same time:
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1284943.html
The internals of the memory management subsystem is not something I'm
too familiar with at this point.
>
> Will
>
Regards,
Scott
^ permalink raw reply
* [RFC PATCH] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT
From: zhongjiang @ 2016-12-10 7:04 UTC (permalink / raw)
To: linux-arm-kernel
From: zhong jiang <zhongjiang@huawei.com>
I think that CONT_PTE_SHIFT is more reasonable even if they are some
value. and the patch is not any functional change.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/mm/hugetlbpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 2e49bd2..0a4c97b 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -323,7 +323,7 @@ static __init int setup_hugepagesz(char *opt)
static __init int add_default_hugepagesz(void)
{
if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
- hugetlb_add_hstate(CONT_PMD_SHIFT);
+ hugetlb_add_hstate(CONT_PTE_SHIFT);
return 0;
}
arch_initcall(add_default_hugepagesz);
--
1.8.3.1
^ permalink raw reply related
* [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Pavel Machek @ 2016-12-10 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480078151.381.4@smtp.gmail.com>
Hi!
> >Yes. That is fine. It is just unusual. Most boards have gpio-led and
> >gpio-keys, which are easy to add. That is why i asked. Adding an LED
> >driver which talks to this M0 can be added later.
>
> Actually the WiP driver for MCU LED interface, that we use in our
> kernel is here: https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
>
> It definitely needs some cleanup and it adds non-standard features
> (main PWM for all LEDs, autonomous blink mode, colors) via custom
> /sys files, which I suspect that is not going to be acceptable for
> upstream. Let's keep it for the next iteration.
Actually, LEDs that can do PWM intensity on their own are common and
supported.
LEDs that can do PWM pretty advanced patterns are common in the cellphones,
as is the color. Unfortunately, good support in kernel is missing. It
would be good to change that.
In n900, I have a LED that can compute prime numbers then blink them,
autonomously. We probably don't need to support _that_, but common
support for patterns would be good.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [Question] New mmap64 syscall?
From: Pavel Machek @ 2016-12-10 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12011325.PfzMMUCfyS@wuerfel>
Hi!
> > Most of these advantages should eventually go away, when struct-reorg makes
> > it way into the compiler. That said, it?s a marginal (but real) improvement for a
> > subset of SPEC.
> >
> > In the real world, the importance of ILP32 as an aid to transition legacy code
> > that is not 64bit clean? and this should drive the ILP32 discussion. That we
> > get a boost in our SPEC scores is just a nice extra that we get from it
>
> To bring this back from the philosophical questions of ABI design
> to the specific point of what file offset width you want for mmap()
> on 32-bit architectures.
>
> For all I can tell, using mmap() to access a file that is many thousand
> times larger than your virtual address space is completely crazy.
Dunno. Wanting to mmap part of a partition does not seem too crazy... I'm pretty
sure there's some tool out there that uses mmap(), just because mmap() was nicer
to use then read(). And when the partition is big, the offset may be big.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH V1] pinctrl:pxa:pinctrl-pxa2xx:- No need of devm functions
From: Robert Jarzmik @ 2016-12-10 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481207730-6332-1-git-send-email-arvind.yadav.cs@gmail.com>
Arvind Yadav <arvind.yadav.cs@gmail.com> writes:
Hi Arvind,
> In functions pxa2xx_build_functions, the memory allocated for
> 'functions' is live within the function only. After the
> allocation it is immediately freed with devm_kfree. There is
> no need to allocate memory for 'functions' with devm function
> so replace devm_kcalloc with kcalloc and devm_kfree with kfree.
That's not very true : the "need" is to spare the "manual" kfree you're adding
in your patch for one, and make it consistent with pxa2xx_build_groups() and
pxa2xx_build_state() for two.
Therefore I'm not very thrilled by this patch and unless it fixes a defect in
the driver I'd rather not have it in.
Cheers.
--
Robert
^ permalink raw reply
* [Question] New mmap64 syscall?
From: Pavel Machek @ 2016-12-10 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210091001.GA17896@xo-6d-61-c0.localdomain>
On Sat 2016-12-10 10:10:01, Pavel Machek wrote:
> Hi!
>
> > > Most of these advantages should eventually go away, when struct-reorg makes
> > > it way into the compiler. That said, it?s a marginal (but real) improvement for a
> > > subset of SPEC.
> > >
> > > In the real world, the importance of ILP32 as an aid to transition legacy code
> > > that is not 64bit clean? and this should drive the ILP32 discussion. That we
> > > get a boost in our SPEC scores is just a nice extra that we get from it
> >
> > To bring this back from the philosophical questions of ABI design
> > to the specific point of what file offset width you want for mmap()
> > on 32-bit architectures.
> >
> > For all I can tell, using mmap() to access a file that is many thousand
> > times larger than your virtual address space is completely crazy.
>
> Dunno. Wanting to mmap part of a partition does not seem too crazy... I'm pretty
> sure there's some tool out there that uses mmap(), just because mmap() was nicer
> to use then read(). And when the partition is big, the offset may be big.
Actually, if I wrote something like jpegrecover, I'd use mmap() for that (because
otherwise I'd be keeping copy of disk in anonymous memory, increasing memory pressure).
jpegrecover definitely makes sense on partitions...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v8 3/3] iio: adc: add support for Allwinner SoCs ADC
From: Maxime Ripard @ 2016-12-10 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209102236.17655-4-quentin.schulz@free-electrons.com>
Hi,
Just some minor comments.
On Fri, Dec 09, 2016 at 11:22:36AM +0100, Quentin Schulz wrote:
> + /*
> + * Since the thermal sensor needs the IP to be in touchscreen mode and
> + * there is no register to know if the IP has finished its transition
> + * between the two modes, a delay is required when switching modes. This
> + * slows down ADC readings while the latter are critical data to the
The latter between what and what?
> + * user. Disabling CONFIG_THERMAL_OF in kernel configuration allows the
> + * user to avoid registering the thermal sensor (thus unavailable) and
Isn't it obvious that it's not going to be available if you do not
register it?
> + * does not switch between modes thus "quicken" the ADC readings.
> + * The thermal sensor should be enabled by default since the SoC
> + * temperature is usually more critical than ADC readings.
This last sentence should be in the Kconfig help. You cannot expect
that all your users will read all the source code they want to compile
:)
Overall, I think this comment is kind of missing the point, maybe
something like:
/*
* Since the controller needs to be in touchscreen mode for its
* thermal sensor to operate properly, and that switching between the
* two modes needs a delay, always registering in the thermal
* framework will significantly slow down the conversion rate of the
* ADCs.
*
* Therefore, instead of depending on THERMAL_OF in Kconfig, we only
* register the sensor if that option is enabled, eventually leaving
* that choice to the user.
*/
Would be much clearer.
> + */
> +
> + if (IS_ENABLED(CONFIG_THERMAL_OF)) {
> + /*
> + * This driver is a child of an MFD which has a node in the DT but not
> + * its children. Therefore, the resulting devices of this driver do not
Wrong indentation for the comment, and saying why the MFD children
don't have a node in the DT (backward compatibility) would be nice.
> + * have an of_node variable.
> + * However, its parent (the MFD driver) has an of_node variable and
> + * since devm_thermal_zone_of_sensor_register uses its first argument to
> + * match the phandle defined in the node of the thermal driver with the
> + * of_node of the device passed as first argument and the third argument
> + * to call ops from thermal_zone_of_device_ops, the solution is to use
> + * the parent device as first argument to match the phandle with its
> + * of_node, and the device from this driver as third argument to return
> + * the temperature.
> + */
> + tzd = devm_thermal_zone_of_sensor_register(pdev->dev.parent, 0,
> + info,
> + &sun4i_ts_tz_ops);
I don't think tzd is used anywhere else in your function, it can be
made local to this block.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161210/bd1b17fb/attachment.sig>
^ permalink raw reply
* [RFC PATCH 15/23] arm: use kconfig fragments for ARCH_PXA defconfigs (part 1)
From: Robert Jarzmik @ 2016-12-10 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481027938-31831-16-git-send-email-b.zolnierkie@samsung.com>
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> writes:
> Replace [lpd270,lubbock,mainstone,pxa255-idp]_defconfig-s with
> a Makefile target using merge_config.
>
> The patch was verified with doing:
>
> $ make [lpd270,...]_defconfig
> $ make savedefconfig
>
> and comparing resulting defconfig files (before/after the patch).
>
> Cc: Daniel Mack <daniel@zonque.org>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: Robert Jarzmik <robert.jarzmik@free.fr>
> Cc: Cyril Bur <cyrilbur@gmail.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Hi Bartolomiej,
It's a bit hard to judge without any context for me, especially I'm receiving
patches 11 to 21 but not the others. I suppose the advantage of defconfig
fragments was already discussed somewhere, could you point me to that please ?
One small thing that could be improved is the "pxa_basic*" names.
I think pxa_basic1 is "pxa_refboards" or something like that, as these are the
initial reference designs as far as I know from Intel and validation vehicles
rather that form factors.
In the same way, pxa_basic2 is rather "pxa_sharpsl" as these are sharp designs.
And pxa_basic3 looks like Motorola platforms, so "pxa_motorola" perhaps ?
I noticed imote2.config ended up based on pxa_basic3, while I would have
expected it to be based on pxa_basic1 as it looks like a reference board to me
...
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ASoC: samsung: Remove tests of member address
From: Krzysztof Kozlowski @ 2016-12-10 9:51 UTC (permalink / raw)
To: linux-arm-kernel
The driver was checking for non-NULL address of struct's members:
- s3c_audio_pdata->type (union),
- s3c_audio_pdata->type.i2s (embedded struct).
This is pointless as these will be always non-NULL. The 's3c_audio_pdata'
is always initialized in static memory so it will be zeroed.
Additionally the 'type' member was an union with only one member.
It is safe to reorganize the structures to get rid of useless union and
checks for addresses to fix the coccinelle warning:
>> sound/soc/samsung/i2s.c:1270:2-4: ERROR: test of a variable/field address
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested on the hardware.
---
arch/arm/mach-s3c64xx/dev-audio.c | 4 +---
include/linux/platform_data/asoc-s3c.h | 6 ++----
sound/soc/samsung/i2s.c | 10 ++--------
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
index b57783371d52..247dcc0b691e 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -106,9 +106,7 @@ static struct s3c_audio_pdata i2sv4_pdata = {
.dma_playback = DMACH_HSI_I2SV40_TX,
.dma_capture = DMACH_HSI_I2SV40_RX,
.type = {
- .i2s = {
- .quirks = QUIRK_PRI_6CHAN,
- },
+ .quirks = QUIRK_PRI_6CHAN,
},
};
diff --git a/include/linux/platform_data/asoc-s3c.h b/include/linux/platform_data/asoc-s3c.h
index 15bf56ee8af7..90641a5daaf0 100644
--- a/include/linux/platform_data/asoc-s3c.h
+++ b/include/linux/platform_data/asoc-s3c.h
@@ -18,7 +18,7 @@
extern void s3c64xx_ac97_setup_gpio(int);
-struct samsung_i2s {
+struct samsung_i2s_type {
/* If the Primary DAI has 5.1 Channels */
#define QUIRK_PRI_6CHAN (1 << 0)
/* If the I2S block has a Stereo Overlay Channel */
@@ -47,7 +47,5 @@ struct s3c_audio_pdata {
void *dma_capture;
void *dma_play_sec;
void *dma_capture_mic;
- union {
- struct samsung_i2s i2s;
- } type;
+ struct samsung_i2s_type type;
};
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index e00974bc5616..d55326289a4a 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1218,7 +1218,6 @@ static int samsung_i2s_probe(struct platform_device *pdev)
{
struct i2s_dai *pri_dai, *sec_dai = NULL;
struct s3c_audio_pdata *i2s_pdata = pdev->dev.platform_data;
- struct samsung_i2s *i2s_cfg = NULL;
struct resource *res;
u32 regs_base, quirks = 0, idma_addr = 0;
struct device_node *np = pdev->dev.of_node;
@@ -1267,13 +1266,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
pri_dai->dma_capture.filter_data = i2s_pdata->dma_capture;
pri_dai->filter = i2s_pdata->dma_filter;
- if (&i2s_pdata->type)
- i2s_cfg = &i2s_pdata->type.i2s;
-
- if (i2s_cfg) {
- quirks = i2s_cfg->quirks;
- idma_addr = i2s_cfg->idma_addr;
- }
+ quirks = i2s_pdata->type.quirks;
+ idma_addr = i2s_pdata->type.idma_addr;
} else {
quirks = i2s_dai_data->quirks;
if (of_property_read_u32(np, "samsung,idma-addr",
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: add cmpxchg64 helper for ARMv7-M
From: Arnd Bergmann @ 2016-12-10 10:36 UTC (permalink / raw)
To: linux-arm-kernel
A change to the netfilter code in net-next introduced the first caller of
cmpxchg64 that can get built on ARMv7-M, leading to an error from the
assembler that points out the lack of 64-bit atomics on this architecture:
/tmp/ccMe7djj.s: Assembler messages:
/tmp/ccMe7djj.s:367: Error: selected processor does not support `ldrexd r0,r1,[lr]' in Thumb mode
/tmp/ccMe7djj.s:371: Error: selected processor does not support `strexd ip,r2,r3,[lr]' in Thumb mode
/tmp/ccMe7djj.s:389: Error: selected processor does not support `ldrexd r8,r9,[r7]' in Thumb mode
/tmp/ccMe7djj.s:393: Error: selected processor does not support `strexd lr,r0,r1,[r7]' in Thumb mode
scripts/Makefile.build:299: recipe for target 'net/netfilter/nft_counter.o' failed
This makes ARMv7-M use the same emulation from asm-generic/cmpxchg-local.h
that we use on architectures earlier than ARMv6K, to fix the build. The
32-bit atomics are available on ARMv7-M and we keep using them there.
This ARM specific change is probably something we should do regardless
of the netfilter code.
However, looking at the new nft_counter_reset() function in nft_counter.c,
this looks incorrect to me not just on ARMv7-M but also on other
architectures, with at least the following possible race:
CPU A CPU B
u64_stats_fetch_begin_irq
u64_stats_update_begin
fetch(upper 32 bits)
fetch(old)
cmpxchg64(counter, old, 0);
fetch(lower 32 bits)
u64_stats_fetch_retry_irq == true
store(upper 32 bits)
fetch(old)
cmpxchg64(counter, old, 0);
store(lower 32 bits)
u64_stats_update_end
u64_stats_fetch_retry_irq == true
fetch(old)
cmpxchg64(counter, old, 0);
u64_stats_fetch_retry_irq == false
In this example, the data returned by __nft_counter_reset() is zero
as we overwrite the per-cpu counter value during the retries.
Fixes: 43da04a593d8 ("netfilter: nf_tables: atomic dump and reset for stateful objects")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/include/asm/cmpxchg.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
index 97882f9bad12..12215515ba02 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -240,6 +240,7 @@ static inline unsigned long __cmpxchg_local(volatile void *ptr,
sizeof(*(ptr))); \
})
+#ifndef CONFIG_CPU_V7M
static inline unsigned long long __cmpxchg64(unsigned long long *ptr,
unsigned long long old,
unsigned long long new)
@@ -273,6 +274,18 @@ static inline unsigned long long __cmpxchg64(unsigned long long *ptr,
#define cmpxchg64_local(ptr, o, n) cmpxchg64_relaxed((ptr), (o), (n))
+#else
+
+/* ARMv7-M has 32-bit ldrex/strex but no ldrexd/strexd */
+
+#define cmpxchg64(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
+#define cmpxchg64_relaxed(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
+#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
+
+#include <asm-generic/cmpxchg-local.h>
+
+#endif
+
#endif /* __LINUX_ARM_ARCH__ >= 6 */
#endif /* __ASM_ARM_CMPXCHG_H */
--
2.9.0
^ permalink raw reply related
* [PATCH v2 0/3] Add enable method support for Exynos SoCs
From: Pankaj Dubey @ 2016-12-10 10:45 UTC (permalink / raw)
To: linux-arm-kernel
Lets use CPU_METHOD_OF_DECLARE() for smp_ops instead of using it
via machine descriptor. To keep compatibility of older DTBs lets not
remove smp_ops hooks from machnine_descriptor.
Changes since v1:
- Dropped code removing smp_ops hooks from exynos.c
- Separated patch into three patches separating change in .c, .dtsi
and updated binding Documentation.
Pankaj Dubey (3):
Documentation: bindings: Add binding doc for exynos enable method
ARM: EXYNOS: dts: add enable-method property for cpus node
ARM: EXYNOS: add CPU_METHOD_OF_DECLARE for exynos SoCs
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/exynos3250.dtsi | 1 +
arch/arm/boot/dts/exynos4210.dtsi | 1 +
arch/arm/boot/dts/exynos4212.dtsi | 1 +
arch/arm/boot/dts/exynos4412.dtsi | 1 +
arch/arm/boot/dts/exynos5250.dtsi | 1 +
arch/arm/boot/dts/exynos5260.dtsi | 1 +
arch/arm/boot/dts/exynos5410.dtsi | 1 +
arch/arm/boot/dts/exynos5420-cpus.dtsi | 1 +
arch/arm/boot/dts/exynos5422-cpus.dtsi | 1 +
arch/arm/boot/dts/exynos5440.dtsi | 1 +
arch/arm/mach-exynos/platsmp.c | 2 ++
12 files changed, 13 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/3] Documentation: bindings: Add binding doc for exynos enable method
From: Pankaj Dubey @ 2016-12-10 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481366762-26413-1-git-send-email-pankaj.dubey@samsung.com>
Add "samsung,exynos-smp" as enable-method for Samsung's Exynos SoC.
CC: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index e6782d5..12730c8 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -209,6 +209,7 @@ nodes to be present and contain the properties described below.
"renesas,apmu"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
+ "samsung,exynos-smp"
"ste,dbx500-smp"
- cpu-release-addr
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] ARM: EXYNOS: dts: add enable-method property for cpus node
From: Pankaj Dubey @ 2016-12-10 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481366762-26413-1-git-send-email-pankaj.dubey@samsung.com>
Add the enable-method property for the cpu node on various exynosMMMM.dtsi.
This is used for CPU_METHOD_OF_DECLARE to use to enable the secondary core.
CC: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/boot/dts/exynos3250.dtsi | 1 +
arch/arm/boot/dts/exynos4210.dtsi | 1 +
arch/arm/boot/dts/exynos4212.dtsi | 1 +
arch/arm/boot/dts/exynos4412.dtsi | 1 +
arch/arm/boot/dts/exynos5250.dtsi | 1 +
arch/arm/boot/dts/exynos5260.dtsi | 1 +
arch/arm/boot/dts/exynos5410.dtsi | 1 +
arch/arm/boot/dts/exynos5420-cpus.dtsi | 1 +
arch/arm/boot/dts/exynos5422-cpus.dtsi | 1 +
arch/arm/boot/dts/exynos5440.dtsi | 1 +
10 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index ba17ee1..f28f669 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -53,6 +53,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 7f3a18c..6dfd98d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -35,6 +35,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 900 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
index 5389011..3e8982e 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -25,6 +25,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at A00 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 40beede..faf2fb8 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -25,6 +25,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at A00 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index b6d7444..580897c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -52,6 +52,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
index 5818718..1af6e76 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -32,6 +32,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index 2b6adaf..b092cdc 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -33,6 +33,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index 5c052d7..a587704 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -24,6 +24,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index bf3c6f1..7fcdfd0 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -23,6 +23,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu at 100 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 2a2e570..0a958e8 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -50,6 +50,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu at 0 {
device_type = "cpu";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] ARM: EXYNOS: add CPU_METHOD_OF_DECLARE for exynos SoCs
From: Pankaj Dubey @ 2016-12-10 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481366762-26413-1-git-send-email-pankaj.dubey@samsung.com>
Add CPU_METHOD_OF_DECLARE to use enable_method property of
cpus node. To keep compatibility with older DTBs lets keep
older method of registering smp_ops via machine_descriptor.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-exynos/platsmp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 94405c7..43eec10 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -474,3 +474,5 @@ const struct smp_operations exynos_smp_ops __initconst = {
.cpu_die = exynos_cpu_die,
#endif
};
+
+CPU_METHOD_OF_DECLARE(exynos_smp, "samsung,exynos-smp", &exynos_smp_ops);
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: move exynos_pm_init into pm.c and remove init_late hook
From: Krzysztof Kozlowski @ 2016-12-10 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481279477-16463-1-git-send-email-pankaj.dubey@samsung.com>
On Fri, Dec 09, 2016 at 04:01:17PM +0530, Pankaj Dubey wrote:
> We can safely move exynos_pm_init into pm.c as late_initcall and remove
> init_late hook from exynos.c. This will remove extern declarations from
> common.h and move PM specific operations in pm.c rather being scattered
> across many files.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-exynos/common.h | 6 ------
> arch/arm/mach-exynos/exynos.c | 10 ----------
> arch/arm/mach-exynos/suspend.c | 13 ++++++++++---
> 3 files changed, 10 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index fb12d11..cfd55ba 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -134,12 +134,6 @@ void exynos_clear_boot_flag(unsigned int cpu, unsigned int mode);
>
> extern u32 exynos_get_eint_wake_mask(void);
>
> -#ifdef CONFIG_PM_SLEEP
> -extern void __init exynos_pm_init(void);
> -#else
> -static inline void exynos_pm_init(void) {}
> -#endif
> -
> extern void exynos_cpu_resume(void);
> extern void exynos_cpu_resume_ns(void);
>
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index fa08ef9..040ea66 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -58,15 +58,6 @@ void __init exynos_sysram_init(void)
> }
> }
>
> -static void __init exynos_init_late(void)
> -{
> - if (of_machine_is_compatible("samsung,exynos5440"))
> - /* to be supported later */
> - return;
> -
> - exynos_pm_init();
> -}
> -
> static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
> int depth, void *data)
> {
> @@ -216,7 +207,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
> .init_early = exynos_firmware_init,
> .init_irq = exynos_init_irq,
> .init_machine = exynos_dt_machine_init,
> - .init_late = exynos_init_late,
> .dt_compat = exynos_dt_compat,
> .dt_fixup = exynos_dt_fixup,
> MACHINE_END
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index 73df9f3..f318b08 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -698,21 +698,25 @@ static const struct of_device_id exynos_pmu_of_device_ids[] __initconst = {
>
> static struct syscore_ops exynos_pm_syscore_ops;
>
> -void __init exynos_pm_init(void)
> +static int __init exynos_pm_init(void)
> {
> const struct of_device_id *match;
> struct device_node *np;
> u32 tmp;
>
> + if (of_machine_is_compatible("samsung,exynos5440"))
> + /* to be supported later */
> + return 0;
> +
> np = of_find_matching_node_and_match(NULL, exynos_pmu_of_device_ids, &match);
> if (!np) {
> pr_err("Failed to find PMU node\n");
> - return;
> + return -ENODEV;
> }
>
> if (WARN_ON(!of_find_property(np, "interrupt-controller", NULL))) {
> pr_warn("Outdated DT detected, suspend/resume will NOT work\n");
> - return;
> + return -ENODEV;
> }
>
> pm_data = (const struct exynos_pm_data *) match->data;
> @@ -727,4 +731,7 @@ void __init exynos_pm_init(void)
>
> register_syscore_ops(&exynos_pm_syscore_ops);
> suspend_set_ops(&exynos_suspend_ops);
> +
> + return 0;
> }
> +late_initcall(exynos_pm_init);
No. This does not look like multiplatform friendly. Also, basically you are
reverting 559ba237999d7 without clear explanation of revert itself.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 3/3] ARM: EXYNOS: add CPU_METHOD_OF_DECLARE for exynos SoCs
From: Krzysztof Kozlowski @ 2016-12-10 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481366762-26413-4-git-send-email-pankaj.dubey@samsung.com>
On Sat, Dec 10, 2016 at 04:16:02PM +0530, Pankaj Dubey wrote:
> Add CPU_METHOD_OF_DECLARE to use enable_method property of
> cpus node. To keep compatibility with older DTBs lets keep
> older method of registering smp_ops via machine_descriptor.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-exynos/platsmp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
> index 94405c7..43eec10 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -474,3 +474,5 @@ const struct smp_operations exynos_smp_ops __initconst = {
> .cpu_die = exynos_cpu_die,
> #endif
> };
> +
> +CPU_METHOD_OF_DECLARE(exynos_smp, "samsung,exynos-smp", &exynos_smp_ops);
Are you sure that smp_ops from DT will be set after mdesc->smp? The
arm_dt_init_cpu_maps() is called before smp_set_ops(mdesc->smp)... Have
you actually tried this?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: EXYNOS: move exynos_pm_init into pm.c and remove init_late hook
From: pankaj.dubey @ 2016-12-10 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210105507.GA24432@kozik-lap>
Hi Krzysztof,
On Saturday 10 December 2016 04:25 PM, Krzysztof Kozlowski wrote:
> On Fri, Dec 09, 2016 at 04:01:17PM +0530, Pankaj Dubey wrote:
>> We can safely move exynos_pm_init into pm.c as late_initcall and remove
>> init_late hook from exynos.c. This will remove extern declarations from
>> common.h and move PM specific operations in pm.c rather being scattered
>> across many files.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>> arch/arm/mach-exynos/common.h | 6 ------
>> arch/arm/mach-exynos/exynos.c | 10 ----------
>> arch/arm/mach-exynos/suspend.c | 13 ++++++++++---
>> 3 files changed, 10 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>> index fb12d11..cfd55ba 100644
>> --- a/arch/arm/mach-exynos/common.h
>> +++ b/arch/arm/mach-exynos/common.h
>> @@ -134,12 +134,6 @@ void exynos_clear_boot_flag(unsigned int cpu, unsigned int mode);
>>
>> extern u32 exynos_get_eint_wake_mask(void);
>>
>> -#ifdef CONFIG_PM_SLEEP
>> -extern void __init exynos_pm_init(void);
>> -#else
>> -static inline void exynos_pm_init(void) {}
>> -#endif
>> -
>> extern void exynos_cpu_resume(void);
>> extern void exynos_cpu_resume_ns(void);
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index fa08ef9..040ea66 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -58,15 +58,6 @@ void __init exynos_sysram_init(void)
>> }
>> }
>>
>> -static void __init exynos_init_late(void)
>> -{
>> - if (of_machine_is_compatible("samsung,exynos5440"))
>> - /* to be supported later */
>> - return;
>> -
>> - exynos_pm_init();
>> -}
>> -
>> static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
>> int depth, void *data)
>> {
>> @@ -216,7 +207,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
>> .init_early = exynos_firmware_init,
>> .init_irq = exynos_init_irq,
>> .init_machine = exynos_dt_machine_init,
>> - .init_late = exynos_init_late,
>> .dt_compat = exynos_dt_compat,
>> .dt_fixup = exynos_dt_fixup,
>> MACHINE_END
>> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
>> index 73df9f3..f318b08 100644
>> --- a/arch/arm/mach-exynos/suspend.c
>> +++ b/arch/arm/mach-exynos/suspend.c
>> @@ -698,21 +698,25 @@ static const struct of_device_id exynos_pmu_of_device_ids[] __initconst = {
>>
>> static struct syscore_ops exynos_pm_syscore_ops;
>>
>> -void __init exynos_pm_init(void)
>> +static int __init exynos_pm_init(void)
>> {
>> const struct of_device_id *match;
>> struct device_node *np;
>> u32 tmp;
>>
>> + if (of_machine_is_compatible("samsung,exynos5440"))
>> + /* to be supported later */
>> + return 0;
>> +
>> np = of_find_matching_node_and_match(NULL, exynos_pmu_of_device_ids, &match);
>> if (!np) {
>> pr_err("Failed to find PMU node\n");
>> - return;
>> + return -ENODEV;
>> }
>>
>> if (WARN_ON(!of_find_property(np, "interrupt-controller", NULL))) {
>> pr_warn("Outdated DT detected, suspend/resume will NOT work\n");
>> - return;
>> + return -ENODEV;
>> }
>>
>> pm_data = (const struct exynos_pm_data *) match->data;
>> @@ -727,4 +731,7 @@ void __init exynos_pm_init(void)
>>
>> register_syscore_ops(&exynos_pm_syscore_ops);
>> suspend_set_ops(&exynos_suspend_ops);
>> +
>> + return 0;
>> }
>> +late_initcall(exynos_pm_init);
>
> No. This does not look like multiplatform friendly. Also, basically you are
> reverting 559ba237999d7 without clear explanation of revert itself.
>
Thanks for review.
I could not understand why this change is not multi-platform friendly,
would you please elaborate more on this.
Well I missed to check history of this file before sending this patch,
as I could not sense any issue as such, we are calling exynos_pm_init
from exynos_init_late which is infact gets called as part of
late_initcall itself. I have tested this with multi_v7_defconfig.
When Thomasz submitted this patch 559ba237999d7 basically there were two
arch_initcalls as "exynos_pm_drvinit" and "exynos_pm_drvinit", the
second one he renamed to exynos_pm_init. At the same time he removed
arch_initcall and made provision so that it can be called from
exynos_init_late. Probably he did because there were two arch_initcalls.
Still I am not sure why he did not opt to convert one of them from
arch_initcall to late_initcall.. how this change affects multiplatform?
As far as intention of this patch, slowly I wanted to reduce dependency
of common.h from pm.c and suspend.c so that one day all these
functionalities which are tightly coupled with machine files can be
loosen and these files can reside along with pmu driver in
"drivers/soc/samsung/".
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* [RFC PATCH] arm64: make WANT_HUGE_PMD_SHARE depends on HUGETLB_PAGE
From: zhongjiang @ 2016-12-10 11:29 UTC (permalink / raw)
To: linux-arm-kernel
From: zhong jiang <zhongjiang@huawei.com>
when HUGETLB_PAGE is disable, WANT_HUGE_PMD_SHARE contains the
fuctions should not be use. therefore, we add the dependency.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..694ca73 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -640,6 +640,7 @@ config SYS_SUPPORTS_HUGETLBFS
config ARCH_WANT_HUGE_PMD_SHARE
def_bool y if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+ depends on HUGETLB_PAGE
config ARCH_HAS_CACHE_LINE_SIZE
def_bool y
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: move exynos_pm_init into pm.c and remove init_late hook
From: Krzysztof Kozlowski @ 2016-12-10 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7f79c71e-3094-842e-4fba-af367999d01d@samsung.com>
On Sat, Dec 10, 2016 at 04:57:55PM +0530, pankaj.dubey wrote:
> Hi Krzysztof,
>
> On Saturday 10 December 2016 04:25 PM, Krzysztof Kozlowski wrote:
> > On Fri, Dec 09, 2016 at 04:01:17PM +0530, Pankaj Dubey wrote:
> >> We can safely move exynos_pm_init into pm.c as late_initcall and remove
> >> init_late hook from exynos.c. This will remove extern declarations from
> >> common.h and move PM specific operations in pm.c rather being scattered
> >> across many files.
> >>
> >> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> >> ---
> >> arch/arm/mach-exynos/common.h | 6 ------
> >> arch/arm/mach-exynos/exynos.c | 10 ----------
> >> arch/arm/mach-exynos/suspend.c | 13 ++++++++++---
> >> 3 files changed, 10 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> >> index fb12d11..cfd55ba 100644
> >> --- a/arch/arm/mach-exynos/common.h
> >> +++ b/arch/arm/mach-exynos/common.h
> >> @@ -134,12 +134,6 @@ void exynos_clear_boot_flag(unsigned int cpu, unsigned int mode);
> >>
> >> extern u32 exynos_get_eint_wake_mask(void);
> >>
> >> -#ifdef CONFIG_PM_SLEEP
> >> -extern void __init exynos_pm_init(void);
> >> -#else
> >> -static inline void exynos_pm_init(void) {}
> >> -#endif
> >> -
> >> extern void exynos_cpu_resume(void);
> >> extern void exynos_cpu_resume_ns(void);
> >>
> >> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> >> index fa08ef9..040ea66 100644
> >> --- a/arch/arm/mach-exynos/exynos.c
> >> +++ b/arch/arm/mach-exynos/exynos.c
> >> @@ -58,15 +58,6 @@ void __init exynos_sysram_init(void)
> >> }
> >> }
> >>
> >> -static void __init exynos_init_late(void)
> >> -{
> >> - if (of_machine_is_compatible("samsung,exynos5440"))
> >> - /* to be supported later */
> >> - return;
> >> -
> >> - exynos_pm_init();
> >> -}
> >> -
> >> static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
> >> int depth, void *data)
> >> {
> >> @@ -216,7 +207,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
> >> .init_early = exynos_firmware_init,
> >> .init_irq = exynos_init_irq,
> >> .init_machine = exynos_dt_machine_init,
> >> - .init_late = exynos_init_late,
> >> .dt_compat = exynos_dt_compat,
> >> .dt_fixup = exynos_dt_fixup,
> >> MACHINE_END
> >> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> >> index 73df9f3..f318b08 100644
> >> --- a/arch/arm/mach-exynos/suspend.c
> >> +++ b/arch/arm/mach-exynos/suspend.c
> >> @@ -698,21 +698,25 @@ static const struct of_device_id exynos_pmu_of_device_ids[] __initconst = {
> >>
> >> static struct syscore_ops exynos_pm_syscore_ops;
> >>
> >> -void __init exynos_pm_init(void)
> >> +static int __init exynos_pm_init(void)
> >> {
> >> const struct of_device_id *match;
> >> struct device_node *np;
> >> u32 tmp;
> >>
> >> + if (of_machine_is_compatible("samsung,exynos5440"))
> >> + /* to be supported later */
> >> + return 0;
> >> +
> >> np = of_find_matching_node_and_match(NULL, exynos_pmu_of_device_ids, &match);
> >> if (!np) {
> >> pr_err("Failed to find PMU node\n");
> >> - return;
> >> + return -ENODEV;
> >> }
> >>
> >> if (WARN_ON(!of_find_property(np, "interrupt-controller", NULL))) {
> >> pr_warn("Outdated DT detected, suspend/resume will NOT work\n");
> >> - return;
> >> + return -ENODEV;
> >> }
> >>
> >> pm_data = (const struct exynos_pm_data *) match->data;
> >> @@ -727,4 +731,7 @@ void __init exynos_pm_init(void)
> >>
> >> register_syscore_ops(&exynos_pm_syscore_ops);
> >> suspend_set_ops(&exynos_suspend_ops);
> >> +
> >> + return 0;
> >> }
> >> +late_initcall(exynos_pm_init);
> >
> > No. This does not look like multiplatform friendly. Also, basically you are
> > reverting 559ba237999d7 without clear explanation of revert itself.
> >
>
> Thanks for review.
>
> I could not understand why this change is not multi-platform friendly,
> would you please elaborate more on this.
This late_initcall will be executed on every platform, including
non-exynos one. There is a of_find_matching_node_and_match() check so it
should be safe but all other platforms will see this ugly error "Failed
to find PMU node".
> Well I missed to check history of this file before sending this patch,
> as I could not sense any issue as such, we are calling exynos_pm_init
> from exynos_init_late which is infact gets called as part of
> late_initcall itself. I have tested this with multi_v7_defconfig.
>
> When Thomasz submitted this patch 559ba237999d7 basically there were two
> arch_initcalls as "exynos_pm_drvinit" and "exynos_pm_drvinit", the
> second one he renamed to exynos_pm_init. At the same time he removed
> arch_initcall and made provision so that it can be called from
> exynos_init_late. Probably he did because there were two arch_initcalls.
> Still I am not sure why he did not opt to convert one of them from
> arch_initcall to late_initcall.. how this change affects multiplatform?
>
> As far as intention of this patch, slowly I wanted to reduce dependency
> of common.h from pm.c and suspend.c so that one day all these
> functionalities which are tightly coupled with machine files can be
> loosen and these files can reside along with pmu driver in
> "drivers/soc/samsung/".
I fully support such goal.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: add cmpxchg64 helper for ARMv7-M
From: Pablo Neira Ayuso @ 2016-12-10 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210103646.1407256-1-arnd@arndb.de>
Hi Arnd,
On Sat, Dec 10, 2016 at 11:36:34AM +0100, Arnd Bergmann wrote:
> A change to the netfilter code in net-next introduced the first caller of
> cmpxchg64 that can get built on ARMv7-M, leading to an error from the
> assembler that points out the lack of 64-bit atomics on this architecture:
>
> /tmp/ccMe7djj.s: Assembler messages:
> /tmp/ccMe7djj.s:367: Error: selected processor does not support `ldrexd r0,r1,[lr]' in Thumb mode
> /tmp/ccMe7djj.s:371: Error: selected processor does not support `strexd ip,r2,r3,[lr]' in Thumb mode
> /tmp/ccMe7djj.s:389: Error: selected processor does not support `ldrexd r8,r9,[r7]' in Thumb mode
> /tmp/ccMe7djj.s:393: Error: selected processor does not support `strexd lr,r0,r1,[r7]' in Thumb mode
> scripts/Makefile.build:299: recipe for target 'net/netfilter/nft_counter.o' failed
>
> This makes ARMv7-M use the same emulation from asm-generic/cmpxchg-local.h
> that we use on architectures earlier than ARMv6K, to fix the build. The
> 32-bit atomics are available on ARMv7-M and we keep using them there.
> This ARM specific change is probably something we should do regardless
> of the netfilter code.
>
> However, looking at the new nft_counter_reset() function in nft_counter.c,
> this looks incorrect to me not just on ARMv7-M but also on other
> architectures, with at least the following possible race:
Right, Eric Dumazet already spotted this problem. I'm preparing a
patch that doesn't require cmpxchg64(). Will keep you on Cc. Thanks.
^ permalink raw reply
* [PATCH v8 0/8] Introducing Exynos ChipId driver
From: Pankaj Dubey @ 2016-12-10 13:08 UTC (permalink / raw)
To: linux-arm-kernel
Each Exynos SoC has ChipID block which can give information about SoC's
product Id and revision number.
This patch series introduces Exynos Chipid SoC driver. At the same time
it reduces dependency of mach-exynos files from plat-samsung, by removing
soc_is_exynosMMMM and samsung_rev API. Instead of it now we can use
soc_device_match API proposed by Arnd and getting discussed in thread [1].
Until now we are using static mapping of Exynos Chipid and using this static
mapping to know about SoC name and revision via soc_is_exynosMMMM macro. This
is quite cumbersome and every time new ARMv7 based Exynos SoC supports lands in
mainline a bunch of such new macros needs to be added. Quite long back during
support of Exynos5260 it has been discussed to solve this problem.
To solve this issue this patchset replaces use of soc_is_exynosMMMM by either
of_machine_is_compatible or soc_device_match depending upon usecase.
I have tested this patch series on Exynos4210 based Origen board for normal SMP
boot.
Although I submitted this series as a whole of 8 patchsets, following are dependency
details among the patches.
Patch 1/8 can be taken without any dependency on other patches.
Patch 2/8 and 3/8 has dependency on 1/8 and can be taken along with 1/8.
Patch 4/8 has no dependency and can be taken without chipid driver patch 1/8.
Patch 5/8 has depency on 1/8
Patch 6/8 has no dependency and can be taken without any other patches.
Patch 7/8 has dependency on 6/8 and 1/8
Patch 8/8 has dependency on rest of patches
[1]: https://patchwork.kernel.org/patch/9361389/
Revision 7 and it's discussion can be found here:
- https://www.spinics.net/lists/arm-kernel/msg540790.html
Revision 6 and it's discussion can be found here:
- https://lkml.org/lkml/2016/5/25/101
Revision 5 and it's discussion can be found here:
- http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310046.html
Revision 4 and it's discussion can be found here:
- https://lkml.org/lkml/2014/12/3/115
Changes since v7:
- Added ARM64 based Exynos7 and Exynos5433 support in chipid driver.
- Removed Exynos4415 support from chipid driver, as exynos4415 has been removed from tree
- Added patch to enable chipid driver for ARM64 based Exynos platform
- Addressed review comments from Arnd for firmware.c, platsmp.c and pm.c files/
- Splitted changes in firmware.c, platsmp.c and pm.c in separate patches
for better code review
- Included suggested code improvement in exynos-chipid.c from Marek Szyprowski
Chances since v6:
- Removed platform driver from chipid, instead use early_init to register soc_device
- Removed export functions from exynos chipid driver
- Replace soc_is_exynosMMMM via either of_machine_is_compatible or soc_device_match in
files in arm/mach-exynos folder
- This patchset depends on the following patch series by Geert Uytterhoeven. This series
includes patch which introduces soc_device_match.
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1261739.html
- Rebased on latest krzk/for-next branch and retested.
Change since v5:
- Addressed Rob's review comments.
- Rebased on latest krzk/for-next branch and retested.
Changes since v4:
- Removed custom sysfs entries as they were not providing any new information
as pointed out by Arnd.
- Removed functions exporting product_id and revision, instead we will export
exynos_chipid_info structure. It will be helpfull when we need to provide more
fields of chipid outside of chipid, as commented by Yadwinder
- Converted all funcions as __init.
Change since v3:
- This patch set contains 5/6 and 6/6 patch from v3 series.
- Made EXYNOS_CHIPID config option non-user selectable,
as suggested by Tomasz Figa.
- Made uniform macro for EXYNOS4/5_SOC_MASK as EXYNOS_SOC_MASK as
suggested by Tomasz Figa.
- Made local variables static in chipid driver.
- Added existing SoC's product id's.
- Added platform driver support.
Changes since v2:
- Reorganized patches as suggested by Tomasz Figa.
- Addressed review comments of Tomasz Figa in i2c-s3c2410.c file.
Pankaj Dubey (8):
soc: samsung: add exynos chipid driver support
ARM: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
ARM64: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
ARM: EXYNOS: refactor firmware specific routines
ARM: EXYNOS: refactor power management specific routines
ARM: EXYNOS: remove secondary startup initialization from
smp_prepare_cpus
ARM: EXYNOS: refactor smp specific code and routines
ARM: EXYNOS: refactor of mach-exynos to use chipid information
arch/arm/mach-exynos/Kconfig | 1 +
arch/arm/mach-exynos/common.h | 92 ---------
arch/arm/mach-exynos/exynos.c | 38 ----
arch/arm/mach-exynos/firmware.c | 100 +++++++---
arch/arm/mach-exynos/include/mach/map.h | 21 ---
arch/arm/mach-exynos/platsmp.c | 267 +++++++++++++++++++++------
arch/arm/mach-exynos/pm.c | 185 ++++++++++++++++---
arch/arm/plat-samsung/cpu.c | 14 --
arch/arm/plat-samsung/include/plat/cpu.h | 2 -
arch/arm/plat-samsung/include/plat/map-s5p.h | 2 -
arch/arm64/Kconfig.platforms | 1 +
drivers/soc/samsung/Kconfig | 5 +
drivers/soc/samsung/Makefile | 1 +
drivers/soc/samsung/exynos-chipid.c | 116 ++++++++++++
14 files changed, 563 insertions(+), 282 deletions(-)
delete mode 100644 arch/arm/mach-exynos/include/mach/map.h
create mode 100644 drivers/soc/samsung/exynos-chipid.c
--
2.7.4
^ permalink raw reply
* [PATCH v8 1/8] soc: samsung: add exynos chipid driver support
From: Pankaj Dubey @ 2016-12-10 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-1-git-send-email-pankaj.dubey@samsung.com>
Exynos SoCs have Chipid, for identification of product IDs and SoC revisions.
This patch intends to provide initialization code for all these functionalities,
at the same time it provides some sysfs entries for accessing these information
to user-space.
This driver uses existing binding for exynos-chipid.
CC: Grant Likely <grant.likely@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
[m.szyprowski: for suggestion and code snippet of product_id_to_soc_id]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/soc/samsung/Kconfig | 5 ++
drivers/soc/samsung/Makefile | 1 +
drivers/soc/samsung/exynos-chipid.c | 116 ++++++++++++++++++++++++++++++++++++
3 files changed, 122 insertions(+)
create mode 100644 drivers/soc/samsung/exynos-chipid.c
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2455339..f9ab858 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -14,4 +14,9 @@ config EXYNOS_PM_DOMAINS
bool "Exynos PM domains" if COMPILE_TEST
depends on PM_GENERIC_DOMAINS || COMPILE_TEST
+config EXYNOS_CHIPID
+ bool "Exynos Chipid controller driver" if COMPILE_TEST
+ depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
+ select SOC_BUS
+
endif
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 3619f2e..2a8a85e 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
exynos5250-pmu.o exynos5420-pmu.o
obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
+obj-$(CONFIG_EXYNOS_CHIPID) += exynos-chipid.o
diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
new file mode 100644
index 0000000..cf0128b
--- /dev/null
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -0,0 +1,116 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS - CHIP ID support
+ * Author: Pankaj Dubey <pankaj.dubey@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
+
+#define EXYNOS_SUBREV_MASK (0xF << 4)
+#define EXYNOS_MAINREV_MASK (0xF << 0)
+#define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
+
+static const struct exynos_soc_id {
+ const char *name;
+ unsigned int id;
+ unsigned int mask;
+} soc_ids[] = {
+ { "EXYNOS3250", 0xE3472000, 0xFFFFF000 },
+ { "EXYNOS4210", 0x43200000, 0xFFFE0000 },
+ { "EXYNOS4212", 0x43220000, 0xFFFE0000 },
+ { "EXYNOS4412", 0xE4412000, 0xFFFE0000 },
+ { "EXYNOS5250", 0x43520000, 0xFFFFF000 },
+ { "EXYNOS5260", 0xE5260000, 0xFFFFF000 },
+ { "EXYNOS5410", 0xE5410000, 0xFFFFF000 },
+ { "EXYNOS5420", 0xE5420000, 0xFFFFF000 },
+ { "EXYNOS5440", 0xE5440000, 0xFFFFF000 },
+ { "EXYNOS5800", 0xE5422000, 0xFFFFF000 },
+ { "EXYNOS7420", 0xE7420000, 0xFFFFF000 },
+ { "EXYNOS5433", 0xE5433000, 0xFFFFF000 },
+};
+
+static const char * __init product_id_to_soc_id(unsigned int product_id)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(soc_ids); i++)
+ if ((product_id & soc_ids[i].mask) == soc_ids[i].id)
+ return soc_ids[i].name;
+ return "UNKNOWN";
+}
+
+static const struct of_device_id of_exynos_chipid_ids[] = {
+ {
+ .compatible = "samsung,exynos4210-chipid",
+ },
+ {},
+};
+
+/**
+ * exynos_chipid_early_init: Early chipid initialization
+ */
+int __init exynos_chipid_early_init(void)
+{
+ struct soc_device_attribute *soc_dev_attr;
+ struct soc_device *soc_dev;
+ struct device_node *root;
+ struct device_node *np;
+ void __iomem *exynos_chipid_base;
+ const struct of_device_id *match;
+ u32 product_id;
+ u32 revision;
+
+ np = of_find_matching_node_and_match(NULL,
+ of_exynos_chipid_ids, &match);
+ if (!np)
+ return -ENODEV;
+
+ exynos_chipid_base = of_iomap(np, 0);
+
+ if (!exynos_chipid_base)
+ return PTR_ERR(exynos_chipid_base);
+
+ product_id = readl_relaxed(exynos_chipid_base);
+ revision = product_id & EXYNOS_REV_MASK;
+ iounmap(exynos_chipid_base);
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENODEV;
+
+ soc_dev_attr->family = "Samsung Exynos";
+
+ root = of_find_node_by_path("/");
+ of_property_read_string(root, "model", &soc_dev_attr->machine);
+ of_node_put(root);
+
+ soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x", revision);
+ soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
+
+
+ pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
+ product_id_to_soc_id(product_id), revision);
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ kfree(soc_dev_attr->revision);
+ kfree_const(soc_dev_attr->soc_id);
+ kfree(soc_dev_attr);
+ return PTR_ERR(soc_dev);
+ }
+
+ return 0;
+}
+early_initcall(exynos_chipid_early_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v8 2/8] ARM: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
From: Pankaj Dubey @ 2016-12-10 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-1-git-send-email-pankaj.dubey@samsung.com>
As now we have chipid driver to initialize SoC related information
lets include it in build by default.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-exynos/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 0bb63b8..29065c5 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,6 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_AMBA
select ARM_GIC
select COMMON_CLK_SAMSUNG
+ select EXYNOS_CHIPID
select EXYNOS_THERMAL
select EXYNOS_PMU
select EXYNOS_SROM
--
2.7.4
^ permalink raw reply related
* [PATCH v8 3/8] ARM64: EXYNOS: enable exynos_chipid for ARCH_EXYNOS
From: Pankaj Dubey @ 2016-12-10 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-1-git-send-email-pankaj.dubey@samsung.com>
This patch enables exynos_chipid driver for ARCH_EXYNOS
based SoC.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 72f4eac..e6aa5c2 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -53,6 +53,7 @@ config ARCH_BRCMSTB
config ARCH_EXYNOS
bool "ARMv8 based Samsung Exynos SoC family"
+ select EXYNOS_CHIPID
select COMMON_CLK_SAMSUNG
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
--
2.7.4
^ permalink raw reply related
* [PATCH v8 4/8] ARM: EXYNOS: refactor firmware specific routines
From: Pankaj Dubey @ 2016-12-10 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-1-git-send-email-pankaj.dubey@samsung.com>
To remove dependency on soc_is_exynosMMMM macros and remove multiple
checks for such macros lets refactor code in firmware.c file.
SoC specific firmware_ops are separated and registered during
exynos_firmware_init based on matching machine compatible.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
---
arch/arm/mach-exynos/firmware.c | 100 ++++++++++++++++++++++++++++++----------
1 file changed, 75 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index fd6da54..525fbd9 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -35,6 +35,25 @@ static void exynos_save_cp15(void)
: : "cc");
}
+static int exynos3250_do_idle(unsigned long mode)
+{
+ switch (mode) {
+ case FW_DO_IDLE_AFTR:
+ writel_relaxed(virt_to_phys(exynos_cpu_resume_ns),
+ sysram_ns_base_addr + 0x24);
+ writel_relaxed(EXYNOS_AFTR_MAGIC, sysram_ns_base_addr + 0x20);
+ flush_cache_all();
+ exynos_smc(SMC_CMD_SAVE, OP_TYPE_CORE,
+ SMC_POWERSTATE_IDLE, 0);
+ exynos_smc(SMC_CMD_SHUTDOWN, OP_TYPE_CLUSTER,
+ SMC_POWERSTATE_IDLE, 0);
+ break;
+ case FW_DO_IDLE_SLEEP:
+ exynos_smc(SMC_CMD_SLEEP, 0, 0, 0);
+ }
+ return 0;
+}
+
static int exynos_do_idle(unsigned long mode)
{
switch (mode) {
@@ -44,14 +63,7 @@ static int exynos_do_idle(unsigned long mode)
writel_relaxed(virt_to_phys(exynos_cpu_resume_ns),
sysram_ns_base_addr + 0x24);
writel_relaxed(EXYNOS_AFTR_MAGIC, sysram_ns_base_addr + 0x20);
- if (soc_is_exynos3250()) {
- flush_cache_all();
- exynos_smc(SMC_CMD_SAVE, OP_TYPE_CORE,
- SMC_POWERSTATE_IDLE, 0);
- exynos_smc(SMC_CMD_SHUTDOWN, OP_TYPE_CLUSTER,
- SMC_POWERSTATE_IDLE, 0);
- } else
- exynos_smc(SMC_CMD_CPU0AFTR, 0, 0, 0);
+ exynos_smc(SMC_CMD_CPU0AFTR, 0, 0, 0);
break;
case FW_DO_IDLE_SLEEP:
exynos_smc(SMC_CMD_SLEEP, 0, 0, 0);
@@ -59,28 +71,25 @@ static int exynos_do_idle(unsigned long mode)
return 0;
}
-static int exynos_cpu_boot(int cpu)
+static int exynos4412_cpu_boot(int cpu)
{
/*
- * Exynos3250 doesn't need to send smc command for secondary CPU boot
- * because Exynos3250 removes WFE in secure mode.
- */
- if (soc_is_exynos3250())
- return 0;
-
- /*
* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
* But, Exynos4212 has only one secondary CPU so second parameter
* isn't used for informing secure firmware about CPU id.
*/
- if (soc_is_exynos4212())
- cpu = 0;
+ cpu = 0;
+ exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
+ return 0;
+}
+static int exynos_cpu_boot(int cpu)
+{
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
}
-static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
+static int exynos4412_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
{
void __iomem *boot_reg;
@@ -94,14 +103,24 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
* additional offset for every CPU, with Exynos4412 being the only
* exception.
*/
- if (soc_is_exynos4412())
- boot_reg += 4 * cpu;
+ boot_reg += 4 * cpu;
+ writel_relaxed(boot_addr, boot_reg);
+ return 0;
+}
+
+static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
+{
+ void __iomem *boot_reg;
+ if (!sysram_ns_base_addr)
+ return -ENODEV;
+
+ boot_reg = sysram_ns_base_addr + 0x1c;
writel_relaxed(boot_addr, boot_reg);
return 0;
}
-static int exynos_get_cpu_boot_addr(int cpu, unsigned long *boot_addr)
+static int exynos4412_get_cpu_boot_addr(int cpu, unsigned long *boot_addr)
{
void __iomem *boot_reg;
@@ -109,10 +128,19 @@ static int exynos_get_cpu_boot_addr(int cpu, unsigned long *boot_addr)
return -ENODEV;
boot_reg = sysram_ns_base_addr + 0x1c;
+ boot_reg += 4 * cpu;
+ *boot_addr = readl_relaxed(boot_reg);
+ return 0;
+}
+
+static int exynos_get_cpu_boot_addr(int cpu, unsigned long *boot_addr)
+{
+ void __iomem *boot_reg;
- if (soc_is_exynos4412())
- boot_reg += 4 * cpu;
+ if (!sysram_ns_base_addr)
+ return -ENODEV;
+ boot_reg = sysram_ns_base_addr + 0x1c;
*boot_addr = readl_relaxed(boot_reg);
return 0;
}
@@ -148,6 +176,23 @@ static int exynos_resume(void)
return 0;
}
+static const struct firmware_ops exynos3250_firmware_ops = {
+ .do_idle = IS_ENABLED(CONFIG_EXYNOS_CPU_SUSPEND) ? exynos3250_do_idle : NULL,
+ .set_cpu_boot_addr = exynos_set_cpu_boot_addr,
+ .get_cpu_boot_addr = exynos_get_cpu_boot_addr,
+ .suspend = IS_ENABLED(CONFIG_PM_SLEEP) ? exynos_suspend : NULL,
+ .resume = IS_ENABLED(CONFIG_EXYNOS_CPU_SUSPEND) ? exynos_resume : NULL,
+};
+
+static const struct firmware_ops exynos4412_firmware_ops = {
+ .do_idle = IS_ENABLED(CONFIG_EXYNOS_CPU_SUSPEND) ? exynos_do_idle : NULL,
+ .set_cpu_boot_addr = exynos4412_set_cpu_boot_addr,
+ .get_cpu_boot_addr = exynos4412_get_cpu_boot_addr,
+ .cpu_boot = exynos4412_cpu_boot,
+ .suspend = IS_ENABLED(CONFIG_PM_SLEEP) ? exynos_suspend : NULL,
+ .resume = IS_ENABLED(CONFIG_EXYNOS_CPU_SUSPEND) ? exynos_resume : NULL,
+};
+
static const struct firmware_ops exynos_firmware_ops = {
.do_idle = IS_ENABLED(CONFIG_EXYNOS_CPU_SUSPEND) ? exynos_do_idle : NULL,
.set_cpu_boot_addr = exynos_set_cpu_boot_addr,
@@ -212,7 +257,12 @@ void __init exynos_firmware_init(void)
pr_info("Running under secure firmware.\n");
- register_firmware_ops(&exynos_firmware_ops);
+ if (of_machine_is_compatible("samsung,exynos3250"))
+ register_firmware_ops(&exynos3250_firmware_ops);
+ else if (of_machine_is_compatible("samsung,exynos4412"))
+ register_firmware_ops(&exynos4412_firmware_ops);
+ else
+ register_firmware_ops(&exynos_firmware_ops);
/*
* Exynos 4 SoCs (based on Cortex A9 and equipped with L2C-310),
--
2.7.4
^ permalink raw reply related
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