* [PATCH 1/9] ARM: dts: imx1: Remove skeleton.dtsi
From: Shawn Guo @ 2016-11-07 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CUyZF5wXBxvcsJWSLt1NVzejpH0bZKedJfx3TfBPB2vQ@mail.gmail.com>
On Sat, Nov 05, 2016 at 05:35:50PM -0200, Fabio Estevam wrote:
> Hi Shawn,
>
> On Tue, Sep 6, 2016 at 12:53 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> > The inclusion of skeleton.dtsi causes the following build warning:
> >
> > Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
> >
> > Instead of fixing skeleton.dtsi, just add the top level definitions
> > for address-cells and size-cell and remove its inclusion.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
>
> Are you OK with this series?
Has the series cleaned up all i.MX dts files? I do not like to see so
many patches doing such small cleanups. Can we do it with 3 patches
maybe?
- one for skeleton.dtsi cleanup
- one for memory node
- one for cpu node
Each one covers all i.MX dts files.
Shawn
^ permalink raw reply
* [PATCH] drm/sun4i: Propagate error to the caller
From: Gustavo Padovan @ 2016-11-07 1:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104061352.12596-1-christophe.jaillet@wanadoo.fr>
Hi Christophe,
2016-11-04 Christophe JAILLET <christophe.jaillet@wanadoo.fr>:
> If 'sun4i_layers_init()' returns an error, propagate it instead of
> returning -EINVAL unconditionally.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Gustavo
^ permalink raw reply
* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Peter Chen @ 2016-11-07 1:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147829269430.21688.2345895151880009021@sboyd-linaro>
On Fri, Nov 04, 2016 at 01:51:34PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-24 18:16:32)
> > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
> > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
> > > > Hi,
> > > >
> > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > > > > The ULPI bus can be built as a module, and it will soon be
> > > > > calling these functions when it supports probing devices from DT.
> > > > > Export them so they can be used by the ULPI module.
> > > > >
> > > > > Acked-by: Rob Herring <robh@kernel.org>
> > > > > Cc: <devicetree@vger.kernel.org>
> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > > ---
> > > > > drivers/of/device.c | 2 ++
> > > > > 1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > > > index 8a22a253a830..6719ab35b62e 100644
> > > > > --- a/drivers/of/device.c
> > > > > +++ b/drivers/of/device.c
> > > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
> > > > >
> > > > > return tsize;
> > > > > }
> > > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
> > > > >
> > > > > int of_device_request_module(struct device *dev)
> > > > > {
> > > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > > > > }
> > > > > mutex_unlock(&of_mutex);
> > > > > }
> > > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
> > > >
> > > > This is trailing the wrong function.
> > > >
> > >
> > > Good catch. Must have been some bad rebase.
> > >
> > > Peter, can you fix it while applying or should I resend this patch?
> > >
> >
> > But, this is device tree patch. I can only get chipidea part and other
> > USB patches if Greg agrees.
> >
>
> Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
> Rob acked them so they could go through usb with the other changes.
I am just worried about possible merge error when linus pulls both OF
and USB tree. Greg, is it ok the OF patches through USB tree with OF
maintainer's ack?
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
From: Peter Chen @ 2016-11-07 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105083145.GF5597@dragon>
>On Mon, Oct 31, 2016 at 10:58:28AM +0800, Peter Chen wrote:
>> We need to change trimming value (as a percentage) of the 17.78mA TX
>> reference current for better signal quality. With this change, we can
>> patch the eye-diagram test on this board.
>
>s/patch/pass? I just want to confirm this is a typo, and can fix it up when applying.
>
Thanks, Shawn. It is a typo. Help me to change both of patches please.
Peter
^ permalink raw reply
* [PATCH v4 0/3] Add initial ZTE VOU DRM/KMS driver
From: Shawn Guo @ 2016-11-07 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477905445-4983-1-git-send-email-shawnguo@kernel.org>
Hi David, Daniel,
On Mon, Oct 31, 2016 at 05:17:22PM +0800, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> The series adds the initial ZTE VOU display controller DRM/KMS driver.
> There are still some features to be added, like overlay plane, scaling,
> and more output devices support. But it's already useful with dual
> CRTCs and HDMI display working.
After a few rounds of reviewing (thanks to all reviewers), it seems that
the series is ready for merging, I guess? If so, could you suggest how
we proceed? I can prepare a pull request if you like. Thanks.
Shawn
> Changes for v4:
> - Move the hardware setup done in zx_hdmi_hw_init() and clock enable
> into .enable hook of drm_encoder_helper_funcs.
> - Compare pipe to crtc->index instead of using our own index counter.
> - Save the pipe check in zx_vou_enable[disable]_vblank by putting frame
> interrupt bit into zx_crtc_bits.
> - Use DRM_DEV_* for log messages instead of old dev_* functions
> - Return directly in case of -ETIMEDOUT in zx_hdmi_i2c_read to simplify
> the code for error condition.
> - Shuffle things around to make the crtc and plane state check in
> zx_gl_plane_atomic_check a bit clearer
> - Move hardware register definitions into headers instead of disturbing
> C file reading.
> - Save the call to drm_connector_unregister(), so that
> drm_connector_cleanup can directly be used as drm_connector_funcs
> .destroy hook.
> - Move vblank notification from .atomic_begin hook to .atomic_flush,
> so that vblank event is sent to user space after planes are committed
> rather than before.
>
> Changes for v3:
> - Rebase to v4.9-rc1
> - Update bindings doc to use 'ranges' for address translation between
> parent and child devices.
> - Call drm_dev_register() last in bind function and drm_dev_unregister()
> first in unbind, so that drm_connector_regiser() can be saved from
> HDMI driver.
> - Instead of using open-coded drm_do_get_edid(), add an I2C adapter for
> HDMI DDC read and use drm_get_edid().
> - Improve the plane .atomic_check implementation by calling helper
> function drm_plane_helper_check_state().
> - Rename zx_crtc.c to zx_vou.c to avoid the confusion that the file
> implements crtc instance.
> - Store vou pointer in zx_crtc, so that we do not need to embed the
> pointer in zx_drm_private.
> - Create zx_readl/zx_writel/zx_writel_mask for register access.
> - Define a few macro helpers to ease the register bit setting, like
> SYNC_WIDE, BACK_PORCH and FRONT_PORCH.
> - Define main/aux channel specific register offset and bits in zx_crtc
> to save the use of is_main check
> - Sort include headers alphabetically
> - Removing encoder pointer out of the structure and constify struct
> vou_inf
> - Add log message for error conditions
> - Make the function calls in teardown path asymmetrical
> - A few coding style improvements like defining macro for sub-module
> address and changing code to save indentation level
> - Add a MAINTAINERS entry for ZTE ZX DRM driver
>
> Changes for v2:
> - Change device tree bindings to kill the virtual display-subsystem
> node make VOU the parent node.
>
> Shawn Guo (3):
> dt-bindings: add bindings doc for ZTE VOU display controller
> drm: zte: add initial vou drm driver
> MAINTAINERS: add an entry for ZTE ZX DRM driver
>
> .../devicetree/bindings/display/zte,vou.txt | 84 +++
> MAINTAINERS | 7 +
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/zte/Kconfig | 8 +
> drivers/gpu/drm/zte/Makefile | 7 +
> drivers/gpu/drm/zte/zx_drm_drv.c | 267 +++++++++
> drivers/gpu/drm/zte/zx_drm_drv.h | 36 ++
> drivers/gpu/drm/zte/zx_hdmi.c | 624 +++++++++++++++++++
> drivers/gpu/drm/zte/zx_hdmi_regs.h | 56 ++
> drivers/gpu/drm/zte/zx_plane.c | 299 ++++++++++
> drivers/gpu/drm/zte/zx_plane.h | 26 +
> drivers/gpu/drm/zte/zx_plane_regs.h | 91 +++
> drivers/gpu/drm/zte/zx_vou.c | 661 +++++++++++++++++++++
> drivers/gpu/drm/zte/zx_vou.h | 46 ++
> drivers/gpu/drm/zte/zx_vou_regs.h | 157 +++++
> 16 files changed, 2372 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/zte,vou.txt
> create mode 100644 drivers/gpu/drm/zte/Kconfig
> create mode 100644 drivers/gpu/drm/zte/Makefile
> create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.c
> create mode 100644 drivers/gpu/drm/zte/zx_drm_drv.h
> create mode 100644 drivers/gpu/drm/zte/zx_hdmi.c
> create mode 100644 drivers/gpu/drm/zte/zx_hdmi_regs.h
> create mode 100644 drivers/gpu/drm/zte/zx_plane.c
> create mode 100644 drivers/gpu/drm/zte/zx_plane.h
> create mode 100644 drivers/gpu/drm/zte/zx_plane_regs.h
> create mode 100644 drivers/gpu/drm/zte/zx_vou.c
> create mode 100644 drivers/gpu/drm/zte/zx_vou.h
> create mode 100644 drivers/gpu/drm/zte/zx_vou_regs.h
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] arm64: percpu: kill off final ACCESS_ONCE() uses
From: Dmitry Vyukov @ 2016-11-07 1:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478283426-6649-1-git-send-email-mark.rutland@arm.com>
On Fri, Nov 4, 2016 at 11:17 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> For several reasons it is preferable to use {READ,WRITE}_ONCE() rather than
> ACCESS_ONCE(). For example, these handle aggregate types, result in shorter
> source code, and better document the intended access (which may be useful for
> instrumentation features such as the upcoming KTSAN).
>
> Over a number of patches, most uses of ACCESS_ONCE() in arch/arm64 have been
> migrated to {READ,WRITE}_ONCE(). For consistency, and the above reasons, this
> patch migrates the final remaining uses.
Thanks!
Acked-by: Dmitry Vyukov <dvyukov@google.com>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/percpu.h | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
> index 5394c84..4afb6fc 100644
> --- a/arch/arm64/include/asm/percpu.h
> +++ b/arch/arm64/include/asm/percpu.h
> @@ -101,16 +101,16 @@ static inline unsigned long __percpu_read(void *ptr, int size)
>
> switch (size) {
> case 1:
> - ret = ACCESS_ONCE(*(u8 *)ptr);
> + ret = READ_ONCE(*(u8 *)ptr);
> break;
> case 2:
> - ret = ACCESS_ONCE(*(u16 *)ptr);
> + ret = READ_ONCE(*(u16 *)ptr);
> break;
> case 4:
> - ret = ACCESS_ONCE(*(u32 *)ptr);
> + ret = READ_ONCE(*(u32 *)ptr);
> break;
> case 8:
> - ret = ACCESS_ONCE(*(u64 *)ptr);
> + ret = READ_ONCE(*(u64 *)ptr);
> break;
> default:
> BUILD_BUG();
> @@ -123,16 +123,16 @@ static inline void __percpu_write(void *ptr, unsigned long val, int size)
> {
> switch (size) {
> case 1:
> - ACCESS_ONCE(*(u8 *)ptr) = (u8)val;
> + WRITE_ONCE(*(u8 *)ptr, (u8)val);
> break;
> case 2:
> - ACCESS_ONCE(*(u16 *)ptr) = (u16)val;
> + WRITE_ONCE(*(u16 *)ptr, (u16)val);
> break;
> case 4:
> - ACCESS_ONCE(*(u32 *)ptr) = (u32)val;
> + WRITE_ONCE(*(u32 *)ptr, (u32)val);
> break;
> case 8:
> - ACCESS_ONCE(*(u64 *)ptr) = (u64)val;
> + WRITE_ONCE(*(u64 *)ptr, (u64)val);
> break;
> default:
> BUILD_BUG();
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 06/14] ASoC: sun4i-codec: Add support for A31 playback through headphone output
From: Chen-Yu Tsai @ 2016-11-07 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106185715.tlvcakzqay2lamd5@lukather>
On Mon, Nov 7, 2016 at 2:57 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Fri, Nov 04, 2016 at 09:08:11AM +0800, Chen-Yu Tsai wrote:
>> On Fri, Nov 4, 2016 at 1:36 AM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > Hi,
>> >
>> > On Thu, Nov 03, 2016 at 03:55:48PM +0800, Chen-Yu Tsai wrote:
>> >> +/* headphone controls */
>> >> +static const char * const sun6i_codec_hp_src_enum_text[] = {
>> >> + "DAC", "Mixer",
>> >> +};
>> >> +
>> >> +static SOC_ENUM_DOUBLE_DECL(sun6i_codec_hp_src_enum,
>> >> + SUN6I_CODEC_OM_DACA_CTRL,
>> >> + SUN6I_CODEC_OM_DACA_CTRL_LHPIS,
>> >> + SUN6I_CODEC_OM_DACA_CTRL_RHPIS,
>> >> + sun6i_codec_hp_src_enum_text);
>> >> +
>> >> +static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
>> >> + SOC_DAPM_ENUM("Headphone Source Playback Route",
>> >> + sun6i_codec_hp_src_enum),
>> >> +};
>> >
>> > What is that route exactly? A muxer?
>>
>> Yup. The following is part of the widgets list later in the code:
>>
>> + /* Headphone output path */
>> + SND_SOC_DAPM_MUX("Headphone Source Playback Route",
>> + SND_SOC_NOPM, 0, 0, sun6i_codec_hp_src),
>
> Oh, right.
>
> You can add my Acked-by on this one and the other patches too.
Thanks. Mark already merged all the driver patches though.
ChenYu
^ permalink raw reply
* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Chen-Yu Tsai @ 2016-11-07 1:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107012920.GA10559@b29397-desktop>
On Mon, Nov 7, 2016 at 9:29 AM, Peter Chen <hzpeterchen@gmail.com> wrote:
> On Fri, Nov 04, 2016 at 01:51:34PM -0700, Stephen Boyd wrote:
>> Quoting Peter Chen (2016-10-24 18:16:32)
>> > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
>> > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
>> > > > Hi,
>> > > >
>> > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
>> > > > > The ULPI bus can be built as a module, and it will soon be
>> > > > > calling these functions when it supports probing devices from DT.
>> > > > > Export them so they can be used by the ULPI module.
>> > > > >
>> > > > > Acked-by: Rob Herring <robh@kernel.org>
>> > > > > Cc: <devicetree@vger.kernel.org>
>> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
>> > > > > ---
>> > > > > drivers/of/device.c | 2 ++
>> > > > > 1 file changed, 2 insertions(+)
>> > > > >
>> > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
>> > > > > index 8a22a253a830..6719ab35b62e 100644
>> > > > > --- a/drivers/of/device.c
>> > > > > +++ b/drivers/of/device.c
>> > > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
>> > > > >
>> > > > > return tsize;
>> > > > > }
>> > > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
>> > > > >
>> > > > > int of_device_request_module(struct device *dev)
>> > > > > {
>> > > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
>> > > > > }
>> > > > > mutex_unlock(&of_mutex);
>> > > > > }
>> > > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
>> > > >
>> > > > This is trailing the wrong function.
>> > > >
>> > >
>> > > Good catch. Must have been some bad rebase.
>> > >
>> > > Peter, can you fix it while applying or should I resend this patch?
>> > >
>> >
>> > But, this is device tree patch. I can only get chipidea part and other
>> > USB patches if Greg agrees.
>> >
>>
>> Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
>> Rob acked them so they could go through usb with the other changes.
>
> I am just worried about possible merge error when linus pulls both OF
> and USB tree. Greg, is it ok the OF patches through USB tree with OF
> maintainer's ack?
May I suggest putting the OF patches on an immutable branch so other
subsystems can pull them in without pulling in the USB patches? At
least I want to use them in the I2C subsystem, and in the sunxi-rsb
driver.
Regards
ChenYu
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6sx-sdb: update TX D_CAL for USBPHY
From: Shawn Guo @ 2016-11-07 2:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR04MB14556348390F18AF8D5A261D8BA70@VI1PR04MB1455.eurprd04.prod.outlook.com>
On Mon, Nov 07, 2016 at 01:32:29AM +0000, Peter Chen wrote:
>
> >On Mon, Oct 31, 2016 at 10:58:28AM +0800, Peter Chen wrote:
> >> We need to change trimming value (as a percentage) of the 17.78mA TX
> >> reference current for better signal quality. With this change, we can
> >> patch the eye-diagram test on this board.
> >
> >s/patch/pass? I just want to confirm this is a typo, and can fix it up when applying.
> >
>
> Thanks, Shawn. It is a typo. Help me to change both of patches please.
Applied both, thanks.
^ permalink raw reply
* [3/4] ARM: EXYNOS: Remove static mapping of SCU SFR
From: pankaj.dubey @ 2016-11-07 2:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <581C8C8F.5080100@samsung.com>
Hi Alim,
On Friday 04 November 2016 06:56 PM, Alim Akhtar wrote:
> Hi Pankaj,
>
> On 11/04/2016 09:09 AM, Pankaj Dubey wrote:
>> Lets remove static mapping of SCU SFR mainly used in CORTEX-A9 SoC
>> based boards.
>> Instead use mapping from device tree node of SCU.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>> arch/arm/mach-exynos/exynos.c | 22
>> ----------------------
>> arch/arm/mach-exynos/include/mach/map.h | 2 --
>> arch/arm/mach-exynos/platsmp.c | 18 +++++++++++-------
>> arch/arm/mach-exynos/pm.c | 14 +++++++++++---
>> arch/arm/mach-exynos/suspend.c | 15 +++++++++++----
>> arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
>> 6 files changed, 33 insertions(+), 42 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/exynos.c
>> b/arch/arm/mach-exynos/exynos.c
>> index 757fc11..fa08ef9 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -28,15 +28,6 @@
>>
>> #include "common.h"
>>
>> -static struct map_desc exynos4_iodesc[] __initdata = {
>> - {
>> - .virtual = (unsigned long)S5P_VA_COREPERI_BASE,
>> - .pfn = __phys_to_pfn(EXYNOS4_PA_COREPERI),
>> - .length = SZ_8K,
>> - .type = MT_DEVICE,
>> - },
>> -};
>> -
>> static struct platform_device exynos_cpuidle = {
>> .name = "exynos_cpuidle",
>> #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
>> @@ -99,17 +90,6 @@ static int __init exynos_fdt_map_chipid(unsigned
>> long node, const char *uname,
>> return 1;
>> }
>>
>> -/*
>> - * exynos_map_io
>> - *
>> - * register the standard cpu IO areas
>> - */
>> -static void __init exynos_map_io(void)
>> -{
>> - if (soc_is_exynos4())
>> - iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
>> -}
>> -
>> static void __init exynos_init_io(void)
>> {
>> debug_ll_io_init();
>> @@ -118,8 +98,6 @@ static void __init exynos_init_io(void)
>>
>> /* detect cpu id and rev. */
>> s5p_init_cpu(S5P_VA_CHIPID);
>> -
>> - exynos_map_io();
>> }
>>
>> /*
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h
>> b/arch/arm/mach-exynos/include/mach/map.h
>> index 5fb0040..0eef407 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -18,6 +18,4 @@
>>
>> #define EXYNOS_PA_CHIPID 0x10000000
>>
>> -#define EXYNOS4_PA_COREPERI 0x10500000
>> -
>> #endif /* __ASM_ARCH_MAP_H */
>> diff --git a/arch/arm/mach-exynos/platsmp.c
>> b/arch/arm/mach-exynos/platsmp.c
>> index a5d6841..553d0d9 100644
>> --- a/arch/arm/mach-exynos/platsmp.c
>> +++ b/arch/arm/mach-exynos/platsmp.c
>> @@ -224,11 +224,6 @@ static void write_pen_release(int val)
>> sync_cache_w(&pen_release);
>> }
>>
>> -static void __iomem *scu_base_addr(void)
>> -{
>> - return (void __iomem *)(S5P_VA_SCU);
>> -}
>> -
>> static DEFINE_SPINLOCK(boot_lock);
>>
>> static void exynos_secondary_init(unsigned int cpu)
>> @@ -387,14 +382,23 @@ fail:
>>
>> static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
>> {
>> + struct device_node *np;
>> + void __iomem *scu_base;
>> int i;
>>
>> exynos_sysram_init();
>>
>> exynos_set_delayed_reset_assertion(true);
>>
>> - if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
>> - scu_enable(scu_base_addr());
>> + if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
>> + np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
>
> what if of_find_compatible_node() fails? May be add a error check for
> the same?
Thanks for review.
You are right of_find_compatible_node() is bound to fail, but only in
case supplied compatible is missing in DT. In our case this piece of
code will execute only for Cortex-A9 based SoC (which in case of Exynos
SoC is applicable only for Exynos4 series) and we will for sure
providing "arm,cortex-a9-scu" in DT, so there is no chance of failure.
So I feel extra check on "np" for NULL will add no benefit here.
Thanks,
Pankaj Dubey
^ permalink raw reply
* [PATCH RFC 3/7] spi: s3c64xx: Do not use platform_data for DMA parameters
From: Andi Shyti @ 2016-11-07 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478276094-19135-5-git-send-email-s.nawrocki@samsung.com>
Hi Sylwester,
> All related platforms use either devicetree or the DMA slave
> map API for mapping DMA channels to DMA slaves so we can now
> stop using platform_data for passing DMA details.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Andi Shyti <andi.shyti@samsung.com>
Andi
^ permalink raw reply
* [PATCH 1/4] ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
From: pankaj.dubey @ 2016-11-07 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105154119.GA8183@kozik-lap>
Hi Krzysztof,
On Saturday 05 November 2016 09:11 PM, Krzysztof Kozlowski wrote:
> On Fri, Nov 04, 2016 at 09:09:21AM +0530, Pankaj Dubey wrote:
>> We can safely remove exynos_smp_init_cpus() hook from mach-exynos/platsmp.c,
>> as all SMP platforms in mach-exynos can rely on DT for CPU core description
>> instead of determining number of cores from the SCU.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>> arch/arm/mach-exynos/platsmp.c | 31 -------------------------------
>> 1 file changed, 31 deletions(-)
>>
>
>
> Thanks, applied. Somehow your patchset did not reach linux-samsung-soc's
> Parchwork. I don't have a clue why... It is on linux-arm-kernel's
> Patchwork.
>
Thanks for looking into this series.
I am also not sure why its not reflecting for you on linux-samsung-soc's
Patchwork, but I can see this series in linux-samsung-soc Patchwork at
below links:
[1/4]: https://patchwork.kernel.org/patch/9411787/
[2/4]: https://patchwork.kernel.org/patch/9411789/
[3/4]: https://patchwork.kernel.org/patch/9411791/
[4/4]: https://patchwork.kernel.org/patch/9411793/
Will you please review other two patches (3/4 and 4/4) in this series?
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
>
>
>
>
^ permalink raw reply
* [PATCH v2 0/9] ARM: DRA7: Add support for DRA718-evm
From: Lokesh Vutla @ 2016-11-07 3:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
Hi Tony,
On Friday 21 October 2016 04:08 PM, Lokesh Vutla wrote:
> This series does minor dts cleanup for dra72-evm and adds support for
> DRA718-evm.
Do you have any comments on this series?
Thanks and regards,
Lokesh
>
> Changes since v1:
> - Updated xxx-supply to xxx-in-supply in Documentation.
>
> Lokesh Vutla (7):
> ARM: dts: dra72-evm: Remove pinmux configurations for erratum i869
> ARM: dra72-evm: Fix modelling of regulators
> ARM: dts: dra72: Add separate dtsi for tps65917
> regulator: lp873x: Add support for populating input supply
> ARM: OMAP2+: board-generic: add support for DRA71x family
> ARM: omap2plus_defconfig: Enable REGULATOR_GPIO
> ARM: omap2plus_defconfig: Enable LP873X support
>
> Nishanth Menon (2):
> ARM: DRA7: hwmod: Do not register RTC on DRA71
> ARM: dts: Add support for dra718-evm
>
> .../devicetree/bindings/arm/omap/omap.txt | 6 +
> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 +
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/dra71-evm.dts | 230 ++++++++++++++
> arch/arm/boot/dts/dra72-evm-common.dtsi | 348 +++------------------
> arch/arm/boot/dts/dra72-evm-revc.dts | 21 +-
> arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 134 ++++++++
> arch/arm/boot/dts/dra72-evm.dts | 14 +-
> arch/arm/configs/omap2plus_defconfig | 3 +
> arch/arm/mach-omap2/board-generic.c | 1 +
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 +-
> drivers/regulator/lp873x-regulator.c | 1 +
> 12 files changed, 453 insertions(+), 326 deletions(-)
> create mode 100644 arch/arm/boot/dts/dra71-evm.dts
> create mode 100644 arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>
^ permalink raw reply
* [3/4] ARM: EXYNOS: Remove static mapping of SCU SFR
From: Alim Akhtar @ 2016-11-07 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <581FE87E.2040607@samsung.com>
Hi Pankaj,
On 11/07/2016 08:05 AM, pankaj.dubey wrote:
> Hi Alim,
>
> On Friday 04 November 2016 06:56 PM, Alim Akhtar wrote:
>> Hi Pankaj,
>>
>> On 11/04/2016 09:09 AM, Pankaj Dubey wrote:
>>> Lets remove static mapping of SCU SFR mainly used in CORTEX-A9 SoC
>>> based boards.
>>> Instead use mapping from device tree node of SCU.
>>>
>>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>>> ---
>>> arch/arm/mach-exynos/exynos.c | 22
>>> ----------------------
>>> arch/arm/mach-exynos/include/mach/map.h | 2 --
>>> arch/arm/mach-exynos/platsmp.c | 18 +++++++++++-------
>>> arch/arm/mach-exynos/pm.c | 14 +++++++++++---
>>> arch/arm/mach-exynos/suspend.c | 15 +++++++++++----
>>> arch/arm/plat-samsung/include/plat/map-s5p.h | 4 ----
>>> 6 files changed, 33 insertions(+), 42 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/exynos.c
>>> b/arch/arm/mach-exynos/exynos.c
>>> index 757fc11..fa08ef9 100644
>>> --- a/arch/arm/mach-exynos/exynos.c
>>> +++ b/arch/arm/mach-exynos/exynos.c
>>> @@ -28,15 +28,6 @@
>>>
>>> #include "common.h"
>>>
>>> -static struct map_desc exynos4_iodesc[] __initdata = {
>>> - {
>>> - .virtual = (unsigned long)S5P_VA_COREPERI_BASE,
>>> - .pfn = __phys_to_pfn(EXYNOS4_PA_COREPERI),
>>> - .length = SZ_8K,
>>> - .type = MT_DEVICE,
>>> - },
>>> -};
>>> -
>>> static struct platform_device exynos_cpuidle = {
>>> .name = "exynos_cpuidle",
>>> #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
>>> @@ -99,17 +90,6 @@ static int __init exynos_fdt_map_chipid(unsigned
>>> long node, const char *uname,
>>> return 1;
>>> }
>>>
>>> -/*
>>> - * exynos_map_io
>>> - *
>>> - * register the standard cpu IO areas
>>> - */
>>> -static void __init exynos_map_io(void)
>>> -{
>>> - if (soc_is_exynos4())
>>> - iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
>>> -}
>>> -
>>> static void __init exynos_init_io(void)
>>> {
>>> debug_ll_io_init();
>>> @@ -118,8 +98,6 @@ static void __init exynos_init_io(void)
>>>
>>> /* detect cpu id and rev. */
>>> s5p_init_cpu(S5P_VA_CHIPID);
>>> -
>>> - exynos_map_io();
>>> }
>>>
>>> /*
>>> diff --git a/arch/arm/mach-exynos/include/mach/map.h
>>> b/arch/arm/mach-exynos/include/mach/map.h
>>> index 5fb0040..0eef407 100644
>>> --- a/arch/arm/mach-exynos/include/mach/map.h
>>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>>> @@ -18,6 +18,4 @@
>>>
>>> #define EXYNOS_PA_CHIPID 0x10000000
>>>
>>> -#define EXYNOS4_PA_COREPERI 0x10500000
>>> -
>>> #endif /* __ASM_ARCH_MAP_H */
>>> diff --git a/arch/arm/mach-exynos/platsmp.c
>>> b/arch/arm/mach-exynos/platsmp.c
>>> index a5d6841..553d0d9 100644
>>> --- a/arch/arm/mach-exynos/platsmp.c
>>> +++ b/arch/arm/mach-exynos/platsmp.c
>>> @@ -224,11 +224,6 @@ static void write_pen_release(int val)
>>> sync_cache_w(&pen_release);
>>> }
>>>
>>> -static void __iomem *scu_base_addr(void)
>>> -{
>>> - return (void __iomem *)(S5P_VA_SCU);
>>> -}
>>> -
>>> static DEFINE_SPINLOCK(boot_lock);
>>>
>>> static void exynos_secondary_init(unsigned int cpu)
>>> @@ -387,14 +382,23 @@ fail:
>>>
>>> static void __init exynos_smp_prepare_cpus(unsigned int max_cpus)
>>> {
>>> + struct device_node *np;
>>> + void __iomem *scu_base;
>>> int i;
>>>
>>> exynos_sysram_init();
>>>
>>> exynos_set_delayed_reset_assertion(true);
>>>
>>> - if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
>>> - scu_enable(scu_base_addr());
>>> + if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
>>> + np = of_find_compatible_node(NULL, NULL, "arm,cortex-a9-scu");
>>
>> what if of_find_compatible_node() fails? May be add a error check for
>> the same?
>
> Thanks for review.
>
> You are right of_find_compatible_node() is bound to fail, but only in
> case supplied compatible is missing in DT. In our case this piece of
> code will execute only for Cortex-A9 based SoC (which in case of Exynos
> SoC is applicable only for Exynos4 series) and we will for sure
> providing "arm,cortex-a9-scu" in DT, so there is no chance of failure.
> So I feel extra check on "np" for NULL will add no benefit here.
>
Well I am not entirely convenience here, I still feel it better to have
those check, lets not assume anything about future, but when I see
of_find_compatible_node() uses elsewhere in kernel, both kind of uses
are there (with/without error check).
So, I leave it to you and maintainer to take a call on this, otherwise
this patch looks good.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
>
> Thanks,
> Pankaj Dubey
>
>
^ permalink raw reply
* [PATCH 1/3] driver: nvmem: Add ocotp driver support for imx6ul
From: Bai Ping @ 2016-11-07 5:41 UTC (permalink / raw)
To: linux-arm-kernel
i.MX6UL is an new SOC of i.MX6 family. Enable ocotp
driver support for this SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
drivers/nvmem/imx-ocotp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index ac27b9b..108e4bc 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -73,6 +73,7 @@ static const struct of_device_id imx_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx6q-ocotp", (void *)128 },
{ .compatible = "fsl,imx6sl-ocotp", (void *)32 },
{ .compatible = "fsl,imx6sx-ocotp", (void *)128 },
+ { .compatible = "fsl,imx6ul-ocotp", (void *)128 },
{ },
};
MODULE_DEVICE_TABLE(of, imx_ocotp_dt_ids);
--
2.8.2
^ permalink raw reply related
* [PATCH 2/3] devicetree: bindings: nvmem: Add compatible string for imx6ul
From: Bai Ping @ 2016-11-07 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478497281-5477-1-git-send-email-ping.bai@nxp.com>
Add new compatible string for i.MX6UL SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
index 383d588..a7ff65d 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
@@ -1,13 +1,14 @@
Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
This binding represents the on-chip eFuse OTP controller found on
-i.MX6Q/D, i.MX6DL/S, i.MX6SL, and i.MX6SX SoCs.
+i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs.
Required properties:
- compatible: should be one of
"fsl,imx6q-ocotp" (i.MX6Q/D/DL/S),
- "fsl,imx6sl-ocotp" (i.MX6SL), or
- "fsl,imx6sx-ocotp" (i.MX6SX), followed by "syscon".
+ "fsl,imx6sl-ocotp" (i.MX6SL),
+ "fsl,imx6sx-ocotp" (i.MX6SX), or
+ "fsl,imx6ul-ocotp" (i.MX6UL), followed by "syscon".
- reg: Should contain the register base and length.
- clocks: Should contain a phandle pointing to the gated peripheral clock.
--
2.8.2
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: imx: Add ocotp node for imx6ul
From: Bai Ping @ 2016-11-07 5:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478497281-5477-1-git-send-email-ping.bai@nxp.com>
Add ocotp node for i.MX6UL SOC.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index c5c05fd..c6f6613 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -849,6 +849,12 @@
reg = <0x021b0000 0x4000>;
};
+ ocotp: ocotp-ctrl at 021bc000 {
+ compatible = "fsl,imx6ul-ocotp", "syscon";
+ reg = <0x021bc000 0x4000>;
+ clocks = <&clks IMX6UL_CLK_OCOTP>;
+ };
+
lcdif: lcdif at 021c8000 {
compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
reg = <0x021c8000 0x4000>;
--
2.8.2
^ permalink raw reply related
* [RESEND PATCH v3 0/2] set specific ddr frequency when stop ddr dvfs
From: Lin Huang @ 2016-11-07 6:33 UTC (permalink / raw)
To: linux-arm-kernel
We need ddr run a specific frequency when ddr dvfs stop working. So we
implement get suspend frequency function in devfreq framework, and call
it in rk3399 dmc driver.
Lin Huang (2):
PM/devfreq: add suspend frequency support
PM/devfreq: rk3399: get devfreq suspend frequency
drivers/devfreq/devfreq.c | 18 ++++++++++++++++--
drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
drivers/devfreq/rk3399_dmc.c | 2 +-
include/linux/devfreq.h | 8 ++++++++
4 files changed, 34 insertions(+), 3 deletions(-)
--
1.9.1
^ permalink raw reply
* [RESEND PATCH v3 1/2] PM/devfreq: add suspend frequency support
From: Lin Huang @ 2016-11-07 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478500420-22045-1-git-send-email-hl@rock-chips.com>
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error
drivers/devfreq/devfreq.c | 18 ++++++++++++++++--
drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
include/linux/devfreq.h | 8 ++++++++
3 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..4c76e79 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,8 +359,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(&devfreq->lock);
return;
}
-
- devfreq_update_status(devfreq, devfreq->previous_freq);
+ if (devfreq->suspend_freq)
+ update_devfreq(devfreq);
+ else
+ devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(&devfreq->lock);
cancel_delayed_work_sync(&devfreq->work);
@@ -1254,6 +1256,18 @@ struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
}
EXPORT_SYMBOL(devfreq_recommended_opp);
+void devfreq_opp_get_suspend_opp(struct device *dev, struct devfreq *devfreq)
+{
+ struct dev_pm_opp *suspend_opp;
+
+ rcu_read_lock();
+ suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+ if (suspend_opp)
+ devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+ rcu_read_unlock();
+}
+EXPORT_SYMBOL(devfreq_opp_get_suspend_opp);
+
/**
* devfreq_register_opp_notifier() - Helper function to get devfreq notified
* for any changes in the OPP availability
diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..a3efee0 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ /*
+ * if devfreq in suspend status and have suspend_freq,
+ * the frequency need to set to suspend_freq
+ */
+ if (df->stop_polling && df->suspend_freq) {
+ *freq = df->suspend_freq;
+ return 0;
+ }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..1bdd5d3 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
unsigned long previous_freq;
+ unsigned long suspend_freq;
struct devfreq_dev_status last_status;
void *data; /* private data for governors */
@@ -214,6 +215,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
/* Helper functions for devfreq user device driver with OPP. */
extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
unsigned long *freq, u32 flags);
+extern void devfreq_opp_get_suspend_opp(struct device *dev,
+ struct devfreq *devfreq);
extern int devfreq_register_opp_notifier(struct device *dev,
struct devfreq *devfreq);
extern int devfreq_unregister_opp_notifier(struct device *dev,
@@ -315,6 +318,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
return ERR_PTR(-EINVAL);
}
+static inline void devfreq_opp_get_suspend_opp(struct device *dev,
+ struct devfreq *devfreq)
+{
+}
+
static inline int devfreq_register_opp_notifier(struct device *dev,
struct devfreq *devfreq)
{
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH v3 2/2] PM/devfreq: rk3399: get devfreq suspend frequency
From: Lin Huang @ 2016-11-07 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478500420-22045-1-git-send-email-hl@rock-chips.com>
We need ddr run a specific frequency when ddr dvfs stop
working. For example: if we enable two monitor, then we will
stop ddr dvfs, but we hope ddr can run in highest frequency
obviously.
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- None
Changes in v3:
- None
drivers/devfreq/rk3399_dmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 5a2da95..39f8e27 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -329,7 +329,7 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
if (IS_ERR(data->devfreq))
return PTR_ERR(data->devfreq);
devm_devfreq_register_opp_notifier(dev, data->devfreq);
-
+ devfreq_opp_get_suspend_opp(dev, data->devfreq);
data->dev = dev;
platform_set_drvdata(pdev, data);
pd_register_notify_to_dmc(data->devfreq);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
From: Krzysztof Kozlowski @ 2016-11-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <581FF706.3050502@samsung.com>
On Mon, Nov 7, 2016 at 5:37 AM, pankaj.dubey <pankaj.dubey@samsung.com> wrote:
> Hi Krzysztof,
>
> On Saturday 05 November 2016 09:11 PM, Krzysztof Kozlowski wrote:
>> On Fri, Nov 04, 2016 at 09:09:21AM +0530, Pankaj Dubey wrote:
>>> We can safely remove exynos_smp_init_cpus() hook from mach-exynos/platsmp.c,
>>> as all SMP platforms in mach-exynos can rely on DT for CPU core description
>>> instead of determining number of cores from the SCU.
>>>
>>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>>> ---
>>> arch/arm/mach-exynos/platsmp.c | 31 -------------------------------
>>> 1 file changed, 31 deletions(-)
>>>
>>
>>
>> Thanks, applied. Somehow your patchset did not reach linux-samsung-soc's
>> Parchwork. I don't have a clue why... It is on linux-arm-kernel's
>> Patchwork.
>>
>
> Thanks for looking into this series.
>
> I am also not sure why its not reflecting for you on linux-samsung-soc's
> Patchwork, but I can see this series in linux-samsung-soc Patchwork at
> below links:
Hmmm... it is weird. Why I didn't see them before? It seems that I
even updated their status. Confusing...
> Will you please review other two patches (3/4 and 4/4) in this series?
4/4 is okay but it depends on 3/4 which already has a valid comment -
what will happen when DT node is not present (which first of all will
happen because DTS is applied on separate branch... and anyway the
code must be prepared for different DTSes). Initially I thought there
will be NULL pointer exception on of_iomap() but after looking at the
code it might work, I mean fail in a reasonable way.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v7 1/2] soc: samsung: add exynos chipid driver support
From: Marek Szyprowski @ 2016-11-07 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478347427-28409-2-git-send-email-pankaj.dubey@samsung.com>
Hi Pankaj,
On 2016-11-05 13:03, Pankaj Dubey wrote:
> 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>
> ---
> drivers/soc/samsung/Kconfig | 5 ++
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-chipid.c | 148 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 154 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..9761e54
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -0,0 +1,148 @@
> +/*
> + * 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 EXYNOS3250_SOC_ID 0xE3472000
> +#define EXYNOS4210_SOC_ID 0x43210000
> +#define EXYNOS4212_SOC_ID 0x43220000
> +#define EXYNOS4412_SOC_ID 0xE4412000
> +#define EXYNOS4415_SOC_ID 0xE4415000
> +#define EXYNOS5250_SOC_ID 0x43520000
> +#define EXYNOS5260_SOC_ID 0xE5260000
> +#define EXYNOS5410_SOC_ID 0xE5410000
> +#define EXYNOS5420_SOC_ID 0xE5420000
> +#define EXYNOS5440_SOC_ID 0xE5440000
> +#define EXYNOS5800_SOC_ID 0xE5422000
> +
> +#define EXYNOS_SOC_MASK 0xFFFFF000
> +
> +#define EXYNOS4210_REV_0 0x0
> +#define EXYNOS4210_REV_1_0 0x10
> +#define EXYNOS4210_REV_1_1 0x11
EXYNOS4210_REV* defines are not used at all in this driver.
> +
> +#define EXYNOS_SUBREV_MASK (0xF << 4)
> +#define EXYNOS_MAINREV_MASK (0xF << 0)
> +#define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
> +
> +
> +static const char * __init product_id_to_soc_id(unsigned int product_id)
> +{
> + const char *soc_name;
> + unsigned int soc_id = product_id & EXYNOS_SOC_MASK;
> +
> + switch (soc_id) {
> + case EXYNOS3250_SOC_ID:
> + soc_name = "EXYNOS3250";
> + break;
> + case EXYNOS4210_SOC_ID:
> + soc_name = "EXYNOS4210";
> + break;
> + case EXYNOS4212_SOC_ID:
> + soc_name = "EXYNOS4212";
> + break;
> + case EXYNOS4412_SOC_ID:
> + soc_name = "EXYNOS4412";
> + break;
> + case EXYNOS4415_SOC_ID:
> + soc_name = "EXYNOS4415";
> + break;
> + case EXYNOS5250_SOC_ID:
> + soc_name = "EXYNOS5250";
> + break;
> + case EXYNOS5260_SOC_ID:
> + soc_name = "EXYNOS5260";
> + break;
> + case EXYNOS5420_SOC_ID:
> + soc_name = "EXYNOS5420";
> + break;
> + case EXYNOS5440_SOC_ID:
> + soc_name = "EXYNOS5440";
> + break;
> + case EXYNOS5800_SOC_ID:
> + soc_name = "EXYNOS5800";
> + break;
> + default:
> + soc_name = "UNKNOWN";
> + }
> + return soc_name;
> +}
This approach is a bit error prone. You have already missed Exynos5410
and early Exynos 4210 are not detected because of the incorrect SOC MASK.
IMHO you should replace above code and defines with a simple array,
where each ID is present only once, so it will be much easier to add
future SoCs:
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 },
{ "EXYNOS4415", 0xE4415000, 0xFFFE0000 },
{ "EXYNOS5250", 0x43520000, 0xFFFFF000 },
{ "EXYNOS5260", 0xE5260000, 0xFFFFF000 },
{ "EXYNOS5410", 0xE5410000, 0xFFFFF000 },
{ "EXYNOS5420", 0xE5420000, 0xFFFFF000 },
{ "EXYNOS5440", 0xE5440000, 0xFFFFF000 },
{ "EXYNOS5800", 0xE5422000, 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";
}
I'm also not sure about Exynos 4415, which has been scheduled for removal.
> +
> +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 = __raw_readl(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);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Martin Strbačka @ 2016-11-07 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105212748.vtdprlxxismy5xmk@perseus.defre.kleine-koenig.org>
On 5.11.2016 22:27, Uwe Kleine-K?nig wrote:
>>> Do I need to "register" turris in vendor-prefixes.txt for that?
>> >
>> > Yes please.
> OK, will wait for Martin to comment what we want there. cznic or turris.
Hello,
please use CZ.NIC in this case. Turris Omnia is a model name.
Thanks for your work!
Martin
--
Martin Strbacka CZ.NIC, z.s.p.o. tel. +420 604 217 854
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/cee2ad06/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] clk: sunxi-ng: Fix CPUX clock for the A23/A33
From: Maxime Ripard @ 2016-11-07 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106172932.39478-1-icenowy@aosc.xyz>
Hi,
On Mon, Nov 07, 2016 at 01:29:31AM +0800, Icenowy Zheng wrote:
> The CPUX clock of A23/33 CCU driver forgot to add CLK_SET_RATE_PARENT
> flag, which makes its frequency fail to change (as part of cpu thermal
> throttle).
>
> Fix it by add this flag.
Your commit title and log could be better.
The title usually is more about what is done in the patch itself,
something like "clk: sunxi-ng: Allow to change the parent rate for the
CPU clocks" in this case.
And your commit log should explain why it is an issue. Yours is even
wrong here, we could definitely change the rate of these clocks
already. The only thing that was not allowed was to change the rate of
its parents, which is what this patch fixes.
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> Patch 4.9-rc too.
I don't see why it should be part of 4.9. No one uses that code in 4.9.
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/20161107/46d235a8/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] clk: sunxi-ng: fix up PLL_CPUX adjusting for A23/A33
From: Maxime Ripard @ 2016-11-07 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106172932.39478-2-icenowy@aosc.xyz>
Hi,
Same remark for the commit title.
On Mon, Nov 07, 2016 at 01:29:32AM +0800, Icenowy Zheng wrote:
> When adjusting PLL_CPUX on A23/A33, the PLL is driven too high, and the
> system stucks.
>
> Add a notifier to avoid this situation.
>
> The code is ported from ccu-sun6i-a31.c.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> Patch 4.9-rc too.
> drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 ++++++++++
Have you checked that it was also needed on A23? Not all SoCs are in
this situation.
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/20161107/c6eb2990/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox