* [PATCH 0/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Vladimir Zapolskiy @ 2017-01-12 0:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYv87Tmp6i-vccVmtVD5NDk2y1=62sgP7VQgWctC+t3Tg@mail.gmail.com>
On 01/11/2017 05:16 PM, Linus Walleij wrote:
> On Tue, Jan 10, 2017 at 2:47 PM, Vladimir Murzin
> <vladimir.murzin@arm.com> wrote:
>
>> In another thread Benjamin pointed at patch [1] in drm/kms part for noMMU.
>>
>> [1] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=62a0d98a188cc4ebd8ea54b37d274ec20465e464
>
> Problem solved?
>
> Vladimir: I do not require in any way that you create a CLCD driver for DRM,
> I just think it would be very very nice...
>
I have no other option, this series is unreviewed and thus unlikely it will
be applied, still a panel PCB on my board needs power management support.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Andy Shevchenko @ 2017-01-12 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <94c4d5c0-f639-eab1-6706-335977690e88@roeck-us.net>
On Wed, Jan 11, 2017 at 12:52 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
> Not really. It would just make it more complicated to replace the
> call with devm_clk_prepare_enable(), should it ever find its way
> into the light of day.
Actually what is the status to the patch series which brings devm_clk
stuff like prepare_enable()? It was submitted 2(?) years ago.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 44/62] watchdog: pnx4008_wdt: Convert to use device managed functions
From: Vladimir Zapolskiy @ 2017-01-12 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484095516-12720-14-git-send-email-linux@roeck-us.net>
Hi Guenter,
On 01/11/2017 02:44 AM, Guenter Roeck wrote:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
>
> The conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts used
> to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Use devm_add_action_or_reset() for calls to clk_disable_unprepare
> - Replace 'goto l; ... l: return e;' with 'return e;'
> - Drop remove function
> - Use devm_watchdog_register_driver() to register watchdog device
>
> Cc: Vladimir Zapolskiy <vz@mleia.com>
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Thank you for the cleanup.
> Cc: Sylvain Lemieux <slemieux.tyco@gmail.com>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs
From: Stephen Boyd @ 2017-01-12 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103065318.GB14542@b29397-desktop>
Quoting Peter Chen (2017-01-02 22:53:19)
> On Wed, Dec 28, 2016 at 02:57:09PM -0800, Stephen Boyd wrote:
> > If the phy supports it, call phy_set_mode() to pull up D+ when
> > required by setting the mode to PHY_MODE_USB_DEVICE. If we want
> > to remove the pullup, set the mode to PHY_MODE_USB_HOST.
> >
[..]
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 0d532a724d48..6d61fa0689b0 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1609,10 +1610,15 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int is_on)
> > return 0;
> >
> > pm_runtime_get_sync(&ci->gadget.dev);
> > - if (is_on)
> > + if (is_on) {
> > + if (ci->phy)
> > + phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
> > hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > - else
> > + } else {
> > hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > + if (ci->phy)
> > + phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
> > + }
> > pm_runtime_put_sync(&ci->gadget.dev);
> >
> > return 0;
>
> Would you describe the use case for it? Why not adding it at
> role switch routine?
>
This is about pulling up D+. The phy I have requires that we manually
pull up D+ by writing a ULPI register before we set the run/stop bit. I
thought it would be appropriate to do so in ci_udc_pullup(), where we're
supposed to put that pullup code, unless I'm mistaken?
It's not exactly about putting the phy into device or host mode, so
phy_set_mode() may not actually be the best API to use. Perhaps we need
some sort of phy_pullup_usb() API here?
^ permalink raw reply
* [PATCH] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS
From: Abel Vesa @ 2017-01-12 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110155112.GB14894@pathway.suse.cz>
On Tue, Jan 10, 2017 at 04:51:12PM +0100, Petr Mladek wrote:
> On Thu 2016-12-08 22:46:55, Abel Vesa wrote:
> > On Thu, Dec 08, 2016 at 09:46:35PM +0000, Abel Vesa wrote:
> > > From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> > >
> > > From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> >
> > >From statement twice in the commit message. Will resend.
> > >
> > > The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace
> > > operation to specify if registers need to saved/restored by the ftrace handler.
> > > This is needed by kgraft and possibly other ftrace-based tools, and the ARM
> > > architecture is currently lacking this feature. It would also be the first step
> > > to support the "Kprobes-on-ftrace" optimization on ARM.
> > >
> > > This patch introduces a new ftrace handler that stores the registers on the
> > > stack before calling the next stage. The registers are restored from the stack
> > > before going back to the instrumented function.
> > >
> > > A side-effect of this patch is to activate the support for ftrace_modify_call()
> > > as it defines ARCH_SUPPORTS_FTRACE_OPS for the ARM architecture
> > >
> > > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> > > Signed-off-by: Abel Vesa <abelvesa@linux.com>
> > > ---
> > > arch/arm/Kconfig | 2 ++
> > > arch/arm/include/asm/ftrace.h | 4 +++
> > > arch/arm/kernel/entry-ftrace.S | 78 ++++++++++++++++++++++++++++++++++++++++++
> > > arch/arm/kernel/ftrace.c | 33 ++++++++++++++++++
> > > 4 files changed, 117 insertions(+)
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index b5d529f..87f1a9f 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -50,6 +50,7 @@ config ARM
> > > select HAVE_DMA_API_DEBUG
> > > select HAVE_DMA_CONTIGUOUS if MMU
> > > select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) && !CPU_ENDIAN_BE32 && MMU
> > > + select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
> > > select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && MMU
> > > select HAVE_EXIT_THREAD
> > > select HAVE_FTRACE_MCOUNT_RECORD if (!XIP_KERNEL)
> > > @@ -90,6 +91,7 @@ config ARM
> > > select PERF_USE_VMALLOC
> > > select RTC_LIB
> > > select SYS_SUPPORTS_APM_EMULATION
> > > + select FRAME_POINTER if DYNAMIC_FTRACE_WITH_REGS && FUNCTION_GRAPH_TRACER
Hi Petr,
>
> FRAME_POINTER is not for free. It takes space on the stack. Also there
> is a performance penalty. Do we really need to depend on it? If so,
> it might be worth a note in the commit message.
I was trying to create my own patch when I found this work done by
Jean-Jacques, so I haven't looked specifically for the FRAME_POINTER
part. I looked now at it and you seem to be right, FRAME_POINTER is
not needed.
I will get rid of the FRAME_POINTER part, change the authorship and
send it again in the following days.
>
> I made only a quick look at the patch. It looks reasonable. But I do
> not have enough knowledge about the arm architecture, assembly, and
> ftrace-specifics. Also I cannot test it easily. So issues might
> be hidden to my eyes.
>
> Best Regards,
> Petr
Thanks,
Abel
^ permalink raw reply
* [PATCH v6 11/25] usb: chipidea: vbus event may exist before starting gadget
From: Stephen Boyd @ 2017-01-12 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103080031.GC14542@b29397-desktop>
Quoting Peter Chen (2017-01-03 00:00:31)
> On Wed, Dec 28, 2016 at 02:56:57PM -0800, Stephen Boyd wrote:
> > From: Peter Chen <peter.chen@nxp.com>
> >
> > At some situations, the vbus may already be there before starting
> > gadget. So we need to check vbus event after switch to gadget in
> > order to handle missing vbus event. The typical use cases are plugging
> > vbus cable before driver load or the vbus has already been there
> > after stopping host but before starting gadget.
> >
> > Signed-off-by: Peter Chen <peter.chen@nxp.com>
> > Tested-by: Stephen Boyd <stephen.boyd@linaro.org>
> > Reviewed-by: Stephen Boyd <stephen.boyd@linaro.org>
> > [sboyd at codeaurora.org: Modify comment text per list discussion]
> > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > ---
> > drivers/usb/chipidea/core.c | 4 ----
> > drivers/usb/chipidea/otg.c | 14 +++++++++-----
> > drivers/usb/chipidea/udc.c | 2 ++
> > 3 files changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 8a020ebbbe2f..37f888e31f10 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -979,10 +979,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> > }
> >
> > if (!ci_otg_is_fsm_mode(ci)) {
> > - /* only update vbus status for peripheral */
> > - if (ci->role == CI_ROLE_GADGET)
> > - ci_handle_vbus_change(ci);
> > -
> > ret = ci_role_start(ci, ci->role);
> > if (ret) {
> > dev_err(dev, "can't start %s role\n",
> > diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> > index 695f3fe3ae21..c972ed23b8ec 100644
> > --- a/drivers/usb/chipidea/otg.c
> > +++ b/drivers/usb/chipidea/otg.c
> > @@ -134,9 +134,9 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
> > if (!ci->is_otg)
> > return;
> >
> > - if (hw_read_otgsc(ci, OTGSC_BSV))
> > + if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active)
> > usb_gadget_vbus_connect(&ci->gadget);
> > - else
> > + else if (!hw_read_otgsc(ci, OTGSC_BSV) && ci->vbus_active)
> > usb_gadget_vbus_disconnect(&ci->gadget);
> > }
> >
> > @@ -175,10 +175,14 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
> >
> > ci_role_stop(ci);
> >
> > - if (role == CI_ROLE_GADGET)
> > + if (role == CI_ROLE_GADGET &&
> > + IS_ERR(ci->platdata->vbus_extcon.edev))
> > /*
> > - * wait vbus lower than OTGSC_BSV before connecting
> > - * to host
> > + * wait vbus lower than OTGSC_BSV before connecting to
> > + * host. If connecting status is from an external
> > + * connector instead of register, we don't need to care
> > + * vbus on the board, since it will not affect external
> > + * connector status.
> > */
> > hw_wait_vbus_lower_bsv(ci);
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 732b281485de..0db56fb7e9e9 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1961,6 +1961,8 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci)
> > /* Clear and enable BSV irq */
> > hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
> > OTGSC_BSVIS | OTGSC_BSVIE);
> > + /* vbus change may has already been occurred */
> > + ci_handle_vbus_change(ci);
> >
> > return 0;
>
> After thinking more, the above change will affect OTG FSM which calls
> this API too, but handle vbus change later, see ci_otg_start_host and
> ci_otg_start_gadget. How about changing patch like below:
Ok. I'll give it a spin but I think that should work too. I don't have
any hardware to test the OTG FSM to make sure things don't break.
^ permalink raw reply
* [RFC PATCH] arm64: defconfig: enable SMMUv3 config
From: Zhou Wang @ 2017-01-12 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483962646-33767-1-git-send-email-wangzhou1@hisilicon.com>
On 2017/1/9 19:50, Zhou Wang wrote:
> Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 869dded..3520c50 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -440,6 +440,7 @@ CONFIG_PLATFORM_MHU=y
> CONFIG_BCM2835_MBOX=y
> CONFIG_HI6220_MBOX=y
> CONFIG_ARM_SMMU=y
> +CONFIG_ARM_SMMU_V3=y
> CONFIG_RASPBERRYPI_POWER=y
> CONFIG_QCOM_SMEM=y
> CONFIG_QCOM_SMD=y
>
Hi Catalin, Will and Arnd,
I just happened to find there is no SMMUv3 config in arm64 defconfig.
Maybe we should add it in defconfig or I miss something.
Thanks,
Zhou
.
^ permalink raw reply
* [PATCH v2 1/3] dt: bindings: add documentation for zx2967 family thermal sensor
From: Shawn Guo @ 2017-01-12 0:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484129651-17531-1-git-send-email-baoyou.xie@linaro.org>
On Wed, Jan 11, 2017 at 06:14:09PM +0800, Baoyou Xie wrote:
> This patch adds dt-binding documentation for zx2967 family thermal sensor.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
Rob already gave his ACK on v1. Since v2 is just an improved version of
v1 (without significant rewriting), you should add his ACK tag, so that
thermal maintainers know that the bindings has been ACK-ed by DT
maintainer.
Shawn
^ permalink raw reply
* [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Doug Anderson @ 2017-01-12 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523574.hS8CXi1tTP@diego>
Hi,
On Tue, Jan 10, 2017 at 11:58 AM, Heiko St?bner <heiko@sntech.de> wrote:
> Hi Doug,
>
> Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko St?bner:
>> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
>> > Hi,
>> >
>> > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com>
>>
>> wrote:
>> > > The structure rockchip_clk_provider needs to refer the GRF regmap
>> > > in somewhere, if the CRU node has not "rockchip,grf" property,
>> > > calling syscon_regmap_lookup_by_phandle will return an invalid GRF
>> > > regmap, and the MUXGRF type clock will be not supported.
>> > >
>> > > Therefore, we need to add them.
>> > >
>> > > Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
>> > > ---
>> > >
>> > > Changes in v4:
>> > > - separte the binding patch
>> > >
>> > > Changes in v3:
>> > > - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
>> > >
>> > > Changes in v2:
>> > > - referring pmugrf for PMUGRU
>> > > - fix the typo "invaild" in COMMIT message
>> > >
>> > > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
>> > > 1 file changed, 2 insertions(+)
>> >
>> > This seems fine to me, so:
>> >
>> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
>> >
>> > ...but I will say that before you actually add any real "MUXGRF"
>> > clocks on rk3399 you _might_ need to rework the code to make things
>> > truly "optional". If it turns out that any existing clocks that
>> > already exist today already go through one of these muxes in the GRF
>> > and we've always been assuming one setting of the mux, we'll need to
>> > make sure we keep assuming that setting of the mux even if the "grf"
>> > isn't specified.
>>
>> I guess I see that a bit more relaxed :-) .
>>
>> I.e. the GRF being optional is a remnant of syscons not being available when
>> the clocks get set up- so were coming in later or not at all. For the
>> rk3288 I converted, there we never really had the case of the GRF missing.
>>
>> And the GRF mux for the vcodec now present is not being used by anything yet
>> (neither driver nor binding), so no old devicetree can break.
>>
>> > As I understand it, your motivation for this patch is to eventually be
>> > able to model the EDP reference clock which can either be xin24 or
>> > "edp osc". Presumably the eDP "reference clock" isn't related to any
>> > of the pre-existing eDP clocks so that one should be safe.
>>
>> Same here, so far we don't even have edp or even any other graphical output
>> on the rk3399, so again there is no old devicetree that could break when
>> the grf is not specified.
>
> reading all of the above again, it feels like you essentially also said
> similar things already in your original reply and I misread some of it.
>
> But again, I don't see the need for any more code right now, as hopefully the
> simple stuff we currently only support does not have any grf-based muxes in
> it. Xing + Rockchip people, please correct me if I'm wrong here :-)
Right. I have no objection to Xing's patch. I just want to make sure
that if it's listed as "Optional" that it's really optional.
I was worried that we would introduce some GRF-based mux in the
_middle_ of some existing clock tree because we simply didn't model
the mux before and assumed one particular setting. If nothing like
that ever happens then we're fine.
Sorry to be so confusing.
-Doug
^ permalink raw reply
* [PATCH] ARM: defconfig: include QCOM_EBI2 in multi_v7
From: Stephen Boyd @ 2017-01-12 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdacU0X1NH5HRwTvt1Wtn=9iqEs0MYQ_vt4UsGV67S4kBA@mail.gmail.com>
On 01/11/2017 07:22 AM, Linus Walleij wrote:
> On Tue, Jan 10, 2017 at 7:02 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Tue, Jan 10, 2017 at 2:09 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> This adds the Qualcomm External Bus Interface 2 to the multi_v7
>>> defconfig: it is hard for users to realize that this is a
>>> required driver for getting things like ethernet, and a necessary
>>> prerequisite to get the external bus discoverable on the
>>> MSM8660/APQ8060 machines.
>> Is it the kind of option that should really be selected through
>> Kconfig instead for those platforms?
> Stephen Boyd question.
>
> AFAIK the ambition is to go with the platform to have zero
> stuff in mach-qcom/* and thus it all becomes a defconfig
> thing.
It could be made a 'default ARCH_QCOM' type of thing. Then the config
doesn't need an update unless you want to turn it off. I imagine people
would want to turn it off if they're using a board with a qcom SoC that
isn't 8660, which is probably going to stay the majority forever.
It's true I've been pushing to get rid of the ARCH_MSM* configs in
mach-qcom/Kconfig as they lead to confusion about what qcom SoCs are
supported in mainline and cause config options to become outdated each
time a new SoC comes out that supports some particular driver. I'll go
repush those changes.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family
From: Shawn Guo @ 2017-01-12 1:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484129651-17531-3-git-send-email-baoyou.xie@linaro.org>
On Wed, Jan 11, 2017 at 06:14:11PM +0800, Baoyou Xie wrote:
> This patch adds thermal driver for ZTE's zx2967 family.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Looks fine to me, except a few minor comments below.
> ---
> drivers/thermal/Kconfig | 6 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/zx2967_thermal.c | 247 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 254 insertions(+)
> create mode 100644 drivers/thermal/zx2967_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 18f2de6..0dd597e 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -445,3 +445,9 @@ config BCM2835_THERMAL
> Support for thermal sensors on Broadcom bcm2835 SoCs.
>
> endif
> +
> +config ZX2967_THERMAL
> + tristate "Thermal sensors on zx2967 SoC"
> + depends on ARCH_ZX
> + help
> + Support for thermal sensors on ZTE zx2967 SoCs.
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 677c6d9..c00c05e 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -57,3 +57,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
> obj-$(CONFIG_MTK_THERMAL) += mtk_thermal.o
> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
> obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
> +obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
> diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_thermal.c
> new file mode 100644
> index 0000000..bdd2d5e
> --- /dev/null
> +++ b/drivers/thermal/zx2967_thermal.c
> @@ -0,0 +1,247 @@
> +/*
> + * ZTE's zx2967 family thermal sensor driver
> + *
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +/* Power Mode: 0->low 1->high */
> +#define ZX2967_THERMAL_POWER_MODE (0)
Unnecessary parenthesis.
> +
> +/* DCF Control Register */
> +#define ZX2967_THERMAL_DCF 0x4
> +
> +/* Selection Register */
> +#define ZX2967_THERMAL_SEL 0x8
> +
> +/* Control Register */
> +#define ZX2967_THERMAL_CTRL 0x10
> +
> +#define ZX2967_THERMAL_READY (0x1000)
> +#define ZX2967_THERMAL_TEMP_MASK (0xfff)
> +#define ZX2967_THERMAL_ID_MASK (0x18)
> +#define ZX2967_THERMAL_ID0 (0x8)
> +#define ZX2967_THERMAL_ID1 (0x10)
Ditto
> +
> +struct zx2967_thermal_sensor {
> + struct zx2967_thermal_priv *priv;
> + struct thermal_zone_device *tzd;
> + int id;
> +};
> +
> +#define NUM_SENSORS 1
> +
> +struct zx2967_thermal_priv {
> + struct zx2967_thermal_sensor sensors[NUM_SENSORS];
> + struct mutex lock;
> + struct clk *clk_gate;
> + struct clk *pclk;
> + void __iomem *regs;
> +};
> +
> +static int zx2967_thermal_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
> +
> + if (priv && priv->pclk)
> + clk_disable_unprepare(priv->pclk);
> +
> + if (priv && priv->clk_gate)
> + clk_disable_unprepare(priv->clk_gate);
> +
> + return 0;
> +}
> +
> +static int zx2967_thermal_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
> + int error;
> +
> + error = clk_prepare_enable(priv->clk_gate);
> + if (error)
> + return error;
> +
> + error = clk_prepare_enable(priv->pclk);
> + if (error) {
> + clk_disable_unprepare(priv->clk_gate);
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static int zx2967_thermal_get_temp(void *data, int *temp)
> +{
> + void __iomem *regs;
> + struct zx2967_thermal_sensor *sensor = data;
> + struct zx2967_thermal_priv *priv = sensor->priv;
> + unsigned long timeout = jiffies + msecs_to_jiffies(100);
> + u32 val, sel_id;
> +
> + regs = priv->regs;
> + mutex_lock(&priv->lock);
> +
> + writel_relaxed(0, regs + ZX2967_THERMAL_POWER_MODE);
> + writel_relaxed(2, regs + ZX2967_THERMAL_DCF);
> +
> + val = readl_relaxed(regs + ZX2967_THERMAL_SEL);
> + val &= ~ZX2967_THERMAL_ID_MASK;
> + sel_id = sensor->id ? ZX2967_THERMAL_ID0 : ZX2967_THERMAL_ID1;
> + val |= sel_id;
> + writel_relaxed(val, regs + ZX2967_THERMAL_SEL);
> +
> + usleep_range(100, 300);
> + val = readl_relaxed(regs + ZX2967_THERMAL_CTRL);
> + while (!(val & ZX2967_THERMAL_READY)) {
> + if (time_after(jiffies, timeout)) {
> + pr_err("Thermal sensor %d data timeout\n",
> + sensor->id);
Again, dev_err() should be used in the driver consistently to make sure
the error messages coming from the driver are in the same format. You
can embed a device pointer in zx2967_thermal_priv for use here, I guess.
> + mutex_unlock(&priv->lock);
> + return -ETIMEDOUT;
> + }
> + val = readl_relaxed(regs + ZX2967_THERMAL_CTRL);
> + }
> +
> + writel_relaxed(3, regs + ZX2967_THERMAL_DCF);
> + val = readl_relaxed(regs + ZX2967_THERMAL_CTRL)
> + & ZX2967_THERMAL_TEMP_MASK;
> + writel_relaxed(1, regs + ZX2967_THERMAL_POWER_MODE);
> +
> + /** Calculate temperature */
/* ... */
> + *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);
We should probably either have defines for these magic numbers or add
some comments for the formula?
Shawn
> +
> + mutex_unlock(&priv->lock);
> +
> + return 0;
> +}
> +
> +static struct thermal_zone_of_device_ops zx2967_of_thermal_ops = {
> + .get_temp = zx2967_thermal_get_temp,
> +};
> +
> +static int zx2967_thermal_probe(struct platform_device *pdev)
> +{
> + struct zx2967_thermal_priv *priv;
> + struct resource *res;
> + int ret, i;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv->regs))
> + return PTR_ERR(priv->regs);
> +
> + priv->clk_gate = devm_clk_get(&pdev->dev, "gate");
> + if (IS_ERR(priv->clk_gate)) {
> + ret = PTR_ERR(priv->clk_gate);
> + dev_err(&pdev->dev, "failed to get clock gate: %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(priv->clk_gate);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
> + ret);
> + return ret;
> + }
> +
> + priv->pclk = devm_clk_get(&pdev->dev, "pclk");
> + if (IS_ERR(priv->pclk)) {
> + ret = PTR_ERR(priv->pclk);
> + dev_err(&pdev->dev, "failed to get apb clock: %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(priv->pclk);
> + if (ret) {
> + clk_disable_unprepare(priv->clk_gate);
> + dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
> + ret);
> + return ret;
> + }
> +
> + mutex_init(&priv->lock);
> + for (i = 0; i < NUM_SENSORS; i++) {
> + struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
> +
> + sensor->priv = priv;
> + sensor->id = i;
> + sensor->tzd = thermal_zone_of_sensor_register(&pdev->dev,
> + i, sensor, &zx2967_of_thermal_ops);
> + if (IS_ERR(sensor->tzd)) {
> + ret = PTR_ERR(sensor->tzd);
> + dev_err(&pdev->dev, "failed to register sensor %d: %d\n",
> + i, ret);
> + goto remove_ts;
> + }
> + }
> + platform_set_drvdata(pdev, priv);
> +
> + return 0;
> +
> +remove_ts:
> + clk_disable_unprepare(priv->clk_gate);
> + clk_disable_unprepare(priv->pclk);
> + for (i--; i >= 0; i--)
> + thermal_zone_of_sensor_unregister(&pdev->dev,
> + priv->sensors[i].tzd);
> +
> + return ret;
> +}
> +
> +static int zx2967_thermal_exit(struct platform_device *pdev)
> +{
> + struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
> + int i;
> +
> + for (i = 0; i < NUM_SENSORS; i++) {
> + struct zx2967_thermal_sensor *sensor = &priv->sensors[i];
> +
> + thermal_zone_of_sensor_unregister(&pdev->dev, sensor->tzd);
> + }
> + clk_disable_unprepare(priv->pclk);
> + clk_disable_unprepare(priv->clk_gate);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id zx2967_thermal_id_table[] = {
> + { .compatible = "zte,zx296718-thermal" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, zx2967_thermal_id_table);
> +
> +static SIMPLE_DEV_PM_OPS(zx2967_thermal_pm_ops,
> + zx2967_thermal_suspend, zx2967_thermal_resume);
> +
> +static struct platform_driver zx2967_thermal_driver = {
> + .probe = zx2967_thermal_probe,
> + .remove = zx2967_thermal_exit,
> + .driver = {
> + .name = "zx2967_thermal",
> + .of_match_table = zx2967_thermal_id_table,
> + .pm = &zx2967_thermal_pm_ops,
> + },
> +};
> +module_platform_driver(zx2967_thermal_driver);
> +
> +MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
> +MODULE_DESCRIPTION("ZTE zx2967 thermal driver");
> +MODULE_LICENSE("GPL");
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Suman Anna @ 2017-01-12 1:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109192814.26811-1-s-anna@ti.com>
Fix couple of typos in the example given in the TI syscon reset
binding. The ti,reset-bits used for DSP0 are corrected to match
the values that will be used in the actual DT node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: Address Rob Herring's comment to change the reset node name
from "psc-reset" to "reset-controller"
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
index 164c7f34c451..c516d24959f2 100644
--- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
+++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
@@ -63,7 +63,7 @@ Example:
--------
The following example demonstrates a syscon node, the reset controller node
using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
-Edison SoC.
+66AK2E SoC.
/ {
soc {
@@ -71,13 +71,13 @@ Edison SoC.
compatible = "syscon", "simple-mfd";
reg = <0x02350000 0x1000>;
- pscrst: psc-reset {
+ pscrst: reset-controller {
compatible = "ti,k2e-pscrst", "ti,syscon-reset";
#reset-cells = <1>;
ti,reset-bits = <
- 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_SET|DEASSERT_CLEAR|STATUS_SET) /* 0: pcrst-dsp0 */
- 0xa40 5 0xa44 3 0 0 (ASSERT_SET|DEASSERT_CLEAR|STATUS_NONE) /* 1: pcrst-example */
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 5 0xa44 3 0 0 (ASSERT_SET | DEASSERT_CLEAR | STATUS_NONE) /* 1: example */
>;
};
};
--
2.10.2
^ permalink raw reply related
* [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
From: Wenyou.Yang at microchip.com @ 2017-01-12 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111111814.GJ14217@n2100.armlinux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at armlinux.org.uk]
> Sent: 2017?1?11? 19:18
> To: Jean-Jacques Hiblot <jjhiblot@gmail.com>
> Cc: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>; Alexandre Belloni
> <alexandre.belloni@free-electrons.com>; Mark Rutland <mark.rutland@arm.com>;
> devicetree <devicetree@vger.kernel.org>; Nicolas Ferre
> <nicolas.ferre@atmel.com>; Linux Kernel Mailing List <linux-
> kernel at vger.kernel.org>; robh+dt <robh+dt@kernel.org>; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
>
> On Wed, Jan 11, 2017 at 12:05:05PM +0100, Jean-Jacques Hiblot wrote:
> > 2017-01-11 9:15 GMT+01:00 <Wenyou.Yang@microchip.com>:
> > > Hi Jean-Jacques,
> > >
> > >> -----Original Message-----
> > >> From: Jean-Jacques Hiblot [mailto:jjhiblot at gmail.com]
> > >> Sent: 2017?1?11? 0:51
> > >> To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > >> Cc: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>; Mark Rutland
> > >> <mark.rutland@arm.com>; devicetree <devicetree@vger.kernel.org>;
> > >> Russell King <linux@arm.linux.org.uk>; Wenyou Yang - A41535
> > >> <Wenyou.Yang@microchip.com>; Nicolas Ferre
> > >> <nicolas.ferre@atmel.com>; Linux Kernel Mailing List
> > >> <linux-kernel@vger.kernel.org>; Rob Herring <robh+dt@kernel.org>;
> > >> linux-arm-kernel at lists.infradead.org
> > >> Subject: Re: [PATCH 1/3] ARM: at91: flush the L2 cache before
> > >> entering cpu idle
> > >>
> > >> 2017-01-10 17:18 GMT+01:00 Alexandre Belloni
> > >> <alexandre.belloni@free-electrons.com>:
> > >> > I though a bit more about it, and I don't really like the new
> > >> > compatible string. I don't feel this should be necessary.
> > >> >
> > >> > What about the following:
> > >> >
> > >> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> > >> > index
> > >> > b4332b727e9c..0333aca63e44 100644
> > >> > --- a/arch/arm/mach-at91/pm.c
> > >> > +++ b/arch/arm/mach-at91/pm.c
> > >> > @@ -53,6 +53,7 @@ extern void at91_pinctrl_gpio_resume(void);
> > >> > static struct {
> > >> > unsigned long uhp_udp_mask;
> > >> > int memctrl;
> > >> > + bool has_l2_cache;
> > >> > } at91_pm_data;
> > >> >
> > >> > void __iomem *at91_ramc_base[2]; @@ -267,6 +268,11 @@ static
> > >> > void at91_ddr_standby(void)
> > >> > u32 lpr0, lpr1 = 0;
> > >> > u32 saved_lpr0, saved_lpr1 = 0;
> > >> >
> > >>
> > >> > + if (at91_pm_data.has_l2_cache) {
> > >> > + flush_cache_all();
> > >> what is the point of calling flush_cache_all() here ? Do we really
> > >> care that dirty data in L1 is written to DDR ? I may be missing
> > >> something but to me it's just extra latency.
> > >
> > > Are you mean use outer_flush_all() to flush all cache lines in the outer cache
> only?
> >
> > Yes that's what I meant. You see, you don't flush the cache for
> > sama5d3 so it shouldn't be required either for sam5d4. You should be
> > able to test it quickly and see if L1 flush is indeed required by
> > replacing flush_cache_all() with outer_flush_all(). BTW is highly
> > probable that L2 cache flush is done in outer_disable() so calling
> > outer_flush_all() is probably no required.
>
> Please don't. Read the comments in the code, and understand the APIs that
> you're suggesting people use _before_ making the suggestion:
>
> /**
> * outer_flush_all - clean and invalidate all cache lines in the outer cache
> *
> * Note: depending on implementation, this may not be atomic - it must
> * only be called with interrupts disabled and no other active outer
> * cache masters.
> *
> * It is intended that this function is only used by implementations
> * needing to override the outer_cache.disable() method due to security.
> * (Some implementations perform this as a clean followed by an invalidate.) */
>
> So, outer_flush_all() should not be called except from L2 cache code
> implementing the outer_disable() function - it's not intended for platforms to use.
>
> There are, however, sadly three users of outer_flush_all() which have crept in
> through arm-soc, that should be outer_disable() instead.
Here, outer_flush_all() should not be called, calling outer_disable() is enough. Is it right?
In the implementation of l2c_disable(void) of in mm/cache-l2x0.c, the outer_cache.flush_all() is called.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
Best Regards,
Wenyou Yang
^ permalink raw reply
* [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Heiko Stuebner @ 2017-01-12 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=WMQ22G67YoQx2t7J6_ZuB3sUjVjXh-0KhPEO_6zbiyUQ@mail.gmail.com>
Am Mittwoch, 11. Januar 2017, 16:50:10 CET schrieb Doug Anderson:
> Hi,
>
> On Tue, Jan 10, 2017 at 11:58 AM, Heiko St?bner <heiko@sntech.de> wrote:
> > Hi Doug,
> >
> > Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko St?bner:
> >> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> >> > Hi,
> >> >
> >> > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com>
> >>
> >> wrote:
> >> > > The structure rockchip_clk_provider needs to refer the GRF regmap
> >> > > in somewhere, if the CRU node has not "rockchip,grf" property,
> >> > > calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> >> > > regmap, and the MUXGRF type clock will be not supported.
> >> > >
> >> > > Therefore, we need to add them.
> >> > >
> >> > > Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> >> > > ---
> >> > >
> >> > > Changes in v4:
> >> > > - separte the binding patch
> >> > >
> >> > > Changes in v3:
> >> > > - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
> >> > >
> >> > > Changes in v2:
> >> > > - referring pmugrf for PMUGRU
> >> > > - fix the typo "invaild" in COMMIT message
> >> > >
> >> > > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> >> > > 1 file changed, 2 insertions(+)
> >> >
> >> > This seems fine to me, so:
> >> >
> >> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> >> >
> >> > ...but I will say that before you actually add any real "MUXGRF"
> >> > clocks on rk3399 you _might_ need to rework the code to make things
> >> > truly "optional". If it turns out that any existing clocks that
> >> > already exist today already go through one of these muxes in the GRF
> >> > and we've always been assuming one setting of the mux, we'll need to
> >> > make sure we keep assuming that setting of the mux even if the "grf"
> >> > isn't specified.
> >>
> >> I guess I see that a bit more relaxed :-) .
> >>
> >> I.e. the GRF being optional is a remnant of syscons not being available
> >> when the clocks get set up- so were coming in later or not at all. For
> >> the rk3288 I converted, there we never really had the case of the GRF
> >> missing.
> >>
> >> And the GRF mux for the vcodec now present is not being used by anything
> >> yet (neither driver nor binding), so no old devicetree can break.
> >>
> >> > As I understand it, your motivation for this patch is to eventually be
> >> > able to model the EDP reference clock which can either be xin24 or
> >> > "edp osc". Presumably the eDP "reference clock" isn't related to any
> >> > of the pre-existing eDP clocks so that one should be safe.
> >>
> >> Same here, so far we don't even have edp or even any other graphical
> >> output
> >> on the rk3399, so again there is no old devicetree that could break when
> >> the grf is not specified.
> >
> > reading all of the above again, it feels like you essentially also said
> > similar things already in your original reply and I misread some of it.
> >
> > But again, I don't see the need for any more code right now, as hopefully
> > the simple stuff we currently only support does not have any grf-based
> > muxes in it. Xing + Rockchip people, please correct me if I'm wrong here
> > :-)
> Right. I have no objection to Xing's patch. I just want to make sure
> that if it's listed as "Optional" that it's really optional.
>
> I was worried that we would introduce some GRF-based mux in the
> _middle_ of some existing clock tree because we simply didn't model
> the mux before and assumed one particular setting. If nothing like
> that ever happens then we're fine.
Thankfully the clock diagrams on the old socs were pretty verbose, listing all
grf-based clocks as well. For example the rk3288 seems to have two and it
seems I've been carrying dummy definitions for those from the time I did the
initial clock tree [0].
And thankfully grf-based clocks somehow always only get used for more
"esotheric" components like vcodec and iep on the rk3288 :-) .
Heiko
[0] https://github.com/mmind/linux-rockchip/blob/devel/workbench/drivers/clk/rockchip/clk-rk3288.c
lines 371 and 799 .. looks like I'll need to add the iep clock as well
at some point.
^ permalink raw reply
* [PATCH 56/62] watchdog: tangox_wdt: Convert to use device managed functions
From: Guenter Roeck @ 2017-01-12 1:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VfUUJaCLXgZ+jNj18ZEMXSNnaw6UvEZcuP7J22apojPYQ@mail.gmail.com>
On 01/11/2017 04:12 PM, Andy Shevchenko wrote:
> On Wed, Jan 11, 2017 at 12:52 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> On 01/11/2017 01:07 AM, Marc Gonzalez wrote:
>> Not really. It would just make it more complicated to replace the
>> call with devm_clk_prepare_enable(), should it ever find its way
>> into the light of day.
> Actually what is the status to the patch series which brings devm_clk
> stuff like prepare_enable()? It was submitted 2(?) years ago.
>
It stalled.
Guenter
^ permalink raw reply
* [PATCH v2 0/5] Reset Controller Nodes for TI Keystone platforms
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
This is a slightly updated patch series for the reset controller nodes for
TI Keystone2 SoCs. The only change is to rename the reset controller nodes
from "psc-reset-controller" to just "reset-controller" following Rob Herring's
comment on the Documentation update patch [1]. There are no changes to the first
2 patches. I have already posted a v2 for the Documentation update as well.
Please pick this up instead of the v1 series [2].
regards
Suman
[1] https://www.spinics.net/lists/arm-kernel/msg553646.html
[2] https://www.spinics.net/lists/arm-kernel/msg552911.html
Suman Anna (5):
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
ARM: dts: keystone: Add PSC node
ARM: dts: keystone-k2hk: Add PSC reset controller node
ARM: dts: keystone-k2l: Add PSC reset controller node
ARM: dts: keystone-k2e: Add PSC reset controller node
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/keystone.dtsi | 5 +++++
arch/arm/mach-keystone/Kconfig | 1 +
5 files changed, 55 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/5] ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Keystone 2 family of SoCs will use various Reset Controller
drivers for managing the resets of remote processor devices like
DSPs on the SoC, so select the ARCH_HAS_RESET_CONTROLLER option
by default to enable the Reset framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
v2: No changes
arch/arm/mach-keystone/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 24bd64dabdfc..554357035f30 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -4,6 +4,7 @@ config ARCH_KEYSTONE
select ARM_GIC
select HAVE_ARM_ARCH_TIMER
select KEYSTONE_TIMER
+ select ARCH_HAS_RESET_CONTROLLER
select ARM_ERRATA_798181 if SMP
select COMMON_CLK_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/5] ARM: dts: keystone: Add PSC node
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module is responsible
for the power and clock management for each of the peripherals
present on the SoC. Represent this as a syscon node so that
multiple users can leverage it for various functionalities.
Signed-off-by: Suman Anna <s-anna@ti.com>
[afd at ti.com: add simple-mfd compatible]
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v2: No changes
arch/arm/boot/dts/keystone.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba2d4f4..ec203d0a673d 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -83,6 +83,11 @@
reg = <0x02310000 0x200>;
};
+ psc: power-sleep-controller at 02350000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x02350000 0x1000>;
+ };
+
devctrl: device-state-control at 02620000 {
compatible = "ti,keystone-devctrl", "syscon";
reg = <0x02620000 0x1000>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/5] ARM: dts: keystone-k2hk: Add PSC reset controller node
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2H SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: change reset node name from psc-reset-controller to reset-controller
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2hk.dtsi b/arch/arm/boot/dts/keystone-k2hk.dtsi
index e0780f111537..69d449430511 100644
--- a/arch/arm/boot/dts/keystone-k2hk.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2hk", "ti,keystone";
model = "Texas Instruments Keystone 2 Kepler/Hawking SoC";
@@ -58,6 +60,24 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: reset-controller {
+ compatible = "ti,k2hk-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ 0xa4c 8 0xa4c 8 0x84c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 4: dsp4 */
+ 0xa50 8 0xa50 8 0x850 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 5: dsp5 */
+ 0xa54 8 0xa54 8 0x854 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 6: dsp6 */
+ 0xa58 8 0xa58 8 0x858 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 7: dsp7 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: keystone-k2l: Add PSC reset controller node
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2L SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: change reset node name from psc-reset-controller to reset-controller
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index b58015737a35..15392d32c572 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2l", "ti,keystone";
model = "Texas Instruments Keystone 2 Lamarr SoC";
@@ -216,6 +218,20 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: reset-controller {
+ compatible = "ti,k2l-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 5/5] ARM: dts: keystone-k2e: Add PSC reset controller node
From: Suman Anna @ 2017-01-12 1:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2E SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: change reset node name from psc-reset-controller to reset-controller
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi b/arch/arm/boot/dts/keystone-k2e.dtsi
index 9d1d8a64d10e..0dd4cdd6d40c 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2e", "ti,keystone";
model = "Texas Instruments Keystone 2 Edison SoC";
@@ -94,6 +96,17 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: reset-controller {
+ compatible = "ti,k2e-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [QUESTION] Arm64: Query L3 cache info via DT
From: Tan Xiaojun @ 2017-01-12 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <913e50ac-5040-8a91-539b-136ed7cde1e3@arm.com>
On 2017/1/10 19:50, Sudeep Holla wrote:
>
>
> On 10/01/17 10:54, Tan Xiaojun wrote:
>> On 2017/1/10 18:01, Sudeep Holla wrote:
>>>
>>>
>>> On 10/01/17 08:50, Tan Xiaojun wrote:
>>>> I add this patch, and test in Hisilicon D02/D03. It can work well.
>>>>
>>>> I'm sorry to reply so late. I took some time to debug, because I am not familiar with the code.
>>>>
>>>>> + if (level < of_level) {
>>>>> + /*
>>>>> + * some external caches not specified in CLIDR_EL1
>>>>> + * the information may be available in the device tree
>>>>> + * only unified external caches are considered here
>>>>> + */
>>>>> + level = of_level;
>>>>> + leaves += (of_level - level);
>>>>
>>>> The above two lines need to exchange the location.
>>>>
>>>
>>> Ah crap, sorry for such a silly mistake.
>>> I will post proper patch(es) soon.
>>>
>>
>> OK. Wait for your new patch. ^_^
>>
>
> Thanks, I have posted the patches[1] and Cc-ed you on them. It would be
> good to get Tested-by once you check.
>
OK. I'm glad to do this.
Thanks.
Xiaojun.
^ permalink raw reply
* [PATCH v2 0/5] Reset Controller Nodes for TI Keystone platforms
From: santosh.shilimkar at oracle.com @ 2017-01-12 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170112014843.19569-1-s-anna@ti.com>
On 1/11/17 5:48 PM, Suman Anna wrote:
> Hi Santosh,
>
> This is a slightly updated patch series for the reset controller nodes for
> TI Keystone2 SoCs. The only change is to rename the reset controller nodes
> from "psc-reset-controller" to just "reset-controller" following Rob Herring's
> comment on the Documentation update patch [1]. There are no changes to the first
> 2 patches. I have already posted a v2 for the Documentation update as well.
> Please pick this up instead of the v1 series [2].
>
I haven't picked up V1 so no worries. Even V2 I won't apply for another
week to give some more time if there are any more comments on the
bindings.
Thanks for following up.
Regards,
Santosh
^ permalink raw reply
* [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Jacky Bai @ 2017-01-12 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYTpEHyzBY-mA4YUsj=xt46Pibka3-4VHwUXosfgbgp1Q@mail.gmail.com>
> Subject: Re: [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc
> for imx6sll
>
> On Mon, Jan 9, 2017 at 3:32 AM, Jacky Bai <ping.bai@nxp.com> wrote:
>
> > I have look into the above commit on using generic binding. But I
> > think the generic pinconf is not very easy to add in imx pinctrl Driver. imx
> pinctrl use a different way to parse the pin configure.
>
> OK atleast I need an indication from one of the i.MX maintainers how they
> want to proceed.
>
> > Each fsl,pin entry looks like <PIN_FUNC_ID CONFIG> in dts, the
> > CONFIG is the pad setting value like pull-up, open-drain, drive strength etc.
> The above config bit definition is specific to each SOC in the PAD CTL register.
> >
> > If we want set the pin config to enable hysteresis, 47KOhm Pull Up,
> > 50Mhz speed, 80Ohm driver strength and Fast Slew Rate, then the CONFIG
> value should be 0x17059( ORs corresponding bit definition).
>
> Hysteresis is an input property and does not make sense on something that
> need drive strength and slew rate configuration which are output properties.
> (I guess you mean 80mA drive strength.)
>
For some bi-direction pins, like SD DATA pin, we may need to enable the hysteresis configuration.
> Actually such oxymoronic settings is a good reason to migrate to generic
> bindings because when you describe stuff with generic strings you see better
> what is going on, and we can add sanity checks to cases like this in the generic
> code where it would indeed be valid to ask why this combination of settings is
> being made.
>
Another thing is that we can use a pins-tool program developed by NXP to generate the pinctrl configuration code that can
be used directly in dts. This tiny program can avoid pin function conflict. As on i.MX, there are so may pins, each pin can be used
for up 8 function. Configuring the pins is a time-consuming work. This tools is very useful for customer to generate the dts code.
Using generic pinconf is another option, but it may need more time to add it and more work to do. For now, I think we can still keep the legacy method?
> > This value will be set in
> > PAD CTL register to config the corresponding pin.
>
> Yes? That is common. It looks like that in DT:
>
> {
> input-schmitt-enable;
> bias-pull-up = <47000>;
> slew-rate = <50000000>;
> drive-strength = <80000>;
> };
>
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH v3 00/24] i.MX Media Driver
From: Steve Longerbeam @ 2017-01-12 3:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU2zU++Xam_UpDPfmSQhauhhS3_z8L-+ww6o-D9brWhiwA@mail.gmail.com>
Hi Tim,
On 01/11/2017 03:14 PM, Tim Harvey wrote:
>
> <snip>
>
> Hi Steve,
>
> I took a stab at testing this today on a gw51xx which has an adv7180
> hooked up as follows:
> - i2c3 at 0x20
> - 8bit data bus from DAT12 to DAT19, HSYNC, VSYNC, PIXCLK on CSI0 pads
> (CSI0_IPU1)
> - PWRDWN# on MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20
> - IRQ# on MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23
> - all three analog inputs available to off-board connector
>
> My patch to the imx6qdl-gw51xx dtsi is:
As long as you used the patch to imx6qdl-sabreauto.dtsti that adds
the adv7180 support as a guide, you should be ok here.
> <snip>
>
>
>
> On an IMX6Q I'm getting the following when the adv7180 module loads:
> [ 12.862477] adv7180 2-0020: chip found @ 0x20 (21a8000.i2c)
> [ 12.907767] imx-media: Registered subdev adv7180 2-0020
> [ 12.907793] imx-media soc:media at 0: Entity type for entity adv7180
> 2-0020 was not initialized!
> [ 12.907867] imx-media: imx_media_create_link: adv7180 2-0020:0 ->
> ipu1_csi0_mux:1
>
> Is the warning that adv7180 was not initialized expected and or an issue?
Yeah it's still a bug in the adv7180 driver, needs fixing.
>
> Now that your driver is hooking into the current media framework, I'm
> not at all clear on how to link and configure the media entities.
It's all documented at Documentation/media/v4l-drivers/imx.rst.
Follow the SabreAuto pipeline setup example.
> <snip>
>
>
> Additionally I've found that on an IMX6S/IMX6DL we crash while
> registering the media-ic subdev's:
> [ 3.975473] imx-media: Registered subdev ipu1_csi1_mux
> [ 3.980921] imx-media: Registered subdev ipu1_csi0_mux
> [ 4.003205] imx-media: Registered subdev ipu1_ic_prpenc
> [ 4.025373] imx-media: Registered subdev ipu1_ic_prpvf
> [ 4.037944] ------------[ cut here ]------------
> [ 4.042571] Kernel BUG at c06717dc [verbose debug info unavailable]
> [ 4.048845] Internal error: Oops - BUG: 0 [#1] SMP ARM
> [ 4.053990] Modules linked in:
> [ 4.057076] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 4.9.0-rc6-00524-g84dad6e-dirty #446
> [ 4.065260] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> ...
> [ 4.296250] [<c0671780>] (v4l2_subdev_init) from [<c06fb02c>]
> (imx_ic_probe+0x94/0x1ac)
> [ 4.304271] [<c06faf98>] (imx_ic_probe) from [<c05173d8>]
> (platform_drv_probe+0x54/0xb8)
> [ 4.312373] r9:c0d5e858 r8:00000000 r7:fffffdfb r6:c0e5dbf8
> r5:da603810 r4:c16738d8
> [ 4.320129] [<c0517384>] (platform_drv_probe) from [<c0515978>]
> (driver_probe_device+0x20c/0x2c0)
> [ 4.329010] r7:c0e5dbf8 r6:00000000 r5:da603810 r4:c16738d8
> [ 4.334681] [<c051576c>] (driver_probe_device) from [<c0515af4>]
> (__driver_attach+0xc8/0xcc)
> [ 4.343129] r9:c0d5e858 r8:00000000 r7:00000000 r6:da603844
> r5:c0e5dbf8 r4:da603810
> [ 4.350889] [<c0515a2c>] (__driver_attach) from [<c0513adc>]
> (bus_for_each_dev+0x74/0xa8)
> [ 4.359078] r7:00000000 r6:c0515a2c r5:c0e5dbf8 r4:00000000
> [ 4.364753] [<c0513a68>] (bus_for_each_dev) from [<c05151d4>]
> (driver_attach+0x20/0x28)
>
> I assume there is an iteration that needs a test on a missing pointer
> only available on chips with both IPU's or PRP
Yep, I only have quad boards here so I haven't gotten around to
testing on S/DL.
But it looks like I forgot to clear out the csi subdev pointer array before
passing it to imx_media_of_parse(). I think that might explain the OOPS
above. Try this patch:
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index 357654d..0cf2d61 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -379,7 +379,7 @@ static int imx_media_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *node = dev->of_node;
- struct imx_media_subdev *csi[4];
+ struct imx_media_subdev *csi[4] = {0};
struct imx_media_dev *imxmd;
int ret;
Steve
^ 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