* [PATCH v3 04/10] Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting.
From: Mark Rutland @ 2017-01-10 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483339777-23973-1-git-send-email-anurup.m@huawei.com>
On Mon, Jan 02, 2017 at 01:49:37AM -0500, Anurup M wrote:
> +The Hisilicon SoC HiP05/06/07 chips consist of various independent system
> +device PMU's such as L3 cache(L3C) and Miscellaneous Nodes(MN).
> +These PMU devices are independent and have hardware logic to gather
> +statistics and performance information.
> +
> +HiP0x chips are encapsulated by multiple CPU and IO die's. The CPU die is
> +called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
> +Each SCCL has 1 L3 cache and 1 MN units.
Are there systems with multiple SCCLs? Or is there only one SCCL per
system?
> +The L3 cache is shared by all CPU cores in a CPU die. The L3C has four banks
> +(or instances). Each bank or instance of L3C has Eight 32-bit counter
> +registers and also event control registers. The HiP05/06 chip L3 cache has
> +22 statistics events. The HiP07 chip has 66 statistics events. These events
> +are very useful for debugging.
Is an L3C associated with a subset of physical memory (as with the ARM
CCN's L3C), or is it associated with a set of CPUs (e.g. only those in
a single SCCL) covering all physical memory (as with each CPU's L1 &
L2)?
Thanks,
Mark.
^ permalink raw reply
* [PATCH] ARM: defconfig: include QCOM_EBI2 in multi_v7
From: Olof Johansson @ 2017-01-10 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110100931.15791-1-linus.walleij@linaro.org>
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?
I.e. is it ever really likely that we'll want it off?
-Olof
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Bartlomiej Zolnierkiewicz @ 2017-01-10 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgQ4Nxyq5itu62qdz18d4xvTu-e3P3ZXK2acLWtzexaaCA@mail.gmail.com>
Hi,
On Tuesday, January 10, 2017 11:23:38 PM Anand Moon wrote:
> Hi Shuah,
>
> On 10 January 2017 at 21:58, Shuah Khan <shuahkh@osg.samsung.com> wrote:
> > On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
> >>
> >> Hi,
> >>
> >> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
> >>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
> >>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
> >>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
> >>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
> >>>>>> error path only when susp_clk has been set from remove and probe error
> >>>>>> paths.
> >>>>>
> >>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
> >>>>> for NULL clock. Also your patch changes susp_clk handling while
> >>>>> leaves axius_clk handling (which also can be NULL) untouched.
> >>>>>
> >>>>> Do you actually see some runtime problem with the current code?
> >>>>>
> >>>>> If not then the patch should probably be dropped.
> >>>>>
> >>>>> Best regards,
> >>>>> --
> >>>>> Bartlomiej Zolnierkiewicz
> >>>>> Samsung R&D Institute Poland
> >>>>> Samsung Electronics
> >>>>
> >>>> Hi Bartlomiej,
> >>>>
> >>>> I am seeing the "no suspend clk specified" message in dmesg.
> >>>> After that it sets the exynos->susp_clk = NULL and starts
> >>>> calling clk_prepare_enable(exynos->susp_clk);
> >>>>
> >>>> That can't be good. If you see the logic right above this
> >>>> one for exynos->clk, it returns error and fails the probe.
> >>>> This this case it doesn't, but tries to use null susp_clk.
> >>
> >> exynos->susp_clk is optional, exynos->clk is not.
> >
> > Right. That is clear since we don't fail the probe.
> >
> >>
> >>>> I believe this patch is necessary.
> >>>
> >>> Let me clarify this a bit further. Since we already know
> >>> susp_clk is null, with this patch we can avoid extra calls
> >>> to clk_prepare_enable() and clk_disable_unprepare().
> >>>
> >>> One can say, it also adds extra checks, hence I will let you
> >>> decide one way or the other. :)
> >>
> >> I would prefer to leave the things as they are currently.
> >>
> >> The code in question is not performance sensitive so extra
> >> calls are not a problem. No extra checks means less code.
> >>
> >> Also the current code seems to be more in line with the rest
> >> of the kernel.
> >
> > What functionality is missing without the suspend clock? Would
> > it make sense to change the info. message to include what it
> > means. At the moment it doesn't anything more than "no suspend
> > clock" which is a very cryptic user visible message. It would be
> > helpful for it to also include what functionality is impacted.
> >
>
> Both usbdrd30_susp_clk and usbdrd30_axius_clk are used by exynos5433 platform
Can you point me to the use of usbdrd30_axius_clk?
I cannot find in the upstream code.
> so moving the clk under compatible string "samsung,exynos7-dwusb3" make sense.
This is not so simple and we would probably need a new compatible for
Exynos5433 (it is currently using "samsung,exynos5250-dwusb3" one and
is not using axius_clk).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Best Regards
> -Anand
>
> > thanks,
> > -- Shuah
> >
> >>
> >> Best regards,
> >> --
> >> Bartlomiej Zolnierkiewicz
> >> Samsung R&D Institute Poland
> >> Samsung Electronics
> >>
> >>> thanks,
> >>> -- Shuah
> >>>
> >>>>
> >>>> thanks,
> >>>> -- Shuah
> >>>>
> >>>>>
> >>>>>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
> >>>>>> ---
> >>>>>> drivers/usb/dwc3/dwc3-exynos.c | 10 ++++++----
> >>>>>> 1 file changed, 6 insertions(+), 4 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> >>>>>> index e27899b..f97a3d7 100644
> >>>>>> --- a/drivers/usb/dwc3/dwc3-exynos.c
> >>>>>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> >>>>>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
> >>>>>> if (IS_ERR(exynos->susp_clk)) {
> >>>>>> dev_info(dev, "no suspend clk specified\n");
> >>>>>> exynos->susp_clk = NULL;
> >>>>>> - }
> >>>>>> - clk_prepare_enable(exynos->susp_clk);
> >>>>>> + } else
> >>>>>> + clk_prepare_enable(exynos->susp_clk);
> >>>>>>
> >>>>>> if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
> >>>>>> exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
> >>>>>> @@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
> >>>>>> regulator_disable(exynos->vdd33);
> >>>>>> err2:
> >>>>>> clk_disable_unprepare(exynos->axius_clk);
> >>>>>> - clk_disable_unprepare(exynos->susp_clk);
> >>>>>> + if (exynos->susp_clk)
> >>>>>> + clk_disable_unprepare(exynos->susp_clk);
> >>>>>> clk_disable_unprepare(exynos->clk);
> >>>>>> return ret;
> >>>>>> }
> >>>>>> @@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
> >>>>>> platform_device_unregister(exynos->usb3_phy);
> >>>>>>
> >>>>>> clk_disable_unprepare(exynos->axius_clk);
> >>>>>> - clk_disable_unprepare(exynos->susp_clk);
> >>>>>> + if (exynos->susp_clk)
> >>>>>> + clk_disable_unprepare(exynos->susp_clk);
> >>>>>> clk_disable_unprepare(exynos->clk);
> >>>>>>
> >>>>>> regulator_disable(exynos->vdd33);
^ permalink raw reply
* [PATCH 1/5] arm: sunxi: add support for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103151629.19447-2-icenowy@aosc.xyz>
On Tue, Jan 03, 2017 at 11:16:25PM +0800, Icenowy Zheng wrote:
> Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
> integrated DRAM, and several peripherals.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> Documentation/arm/sunxi/README | 4 ++++
> arch/arm/mach-sunxi/sunxi.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index cd0243302bc1..91ec8f2055be 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -67,6 +67,10 @@ SunXi family
> + Datasheet
> http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
>
> + - Allwinner V3s (sun8i)
> + + Datasheet
> + https://www.goprawn.com/forum/allwinner-cams/783-allwinner-v3s-soc-datasheet
> +
Please don't put random links in there, but at least something that we
know will be there in a couple of weeks/monthes/years
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/20170110/74d107b3/attachment.sig>
^ permalink raw reply
* [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Maxime Ripard @ 2017-01-10 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103151629.19447-3-icenowy@aosc.xyz>
On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
> V3s has a similar but cut-down CCU to H3.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
It looks like there's nothing different but the clocks that you
register with the H3, please just use the H3 driver.
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/20170110/8a227678/attachment-0001.sig>
^ permalink raw reply
* [PATCH] pwm: constify pwm_ops structures
From: Bhumika Goyal @ 2017-01-10 18:12 UTC (permalink / raw)
To: linux-arm-kernel
Declare pwm_ops structures as const as they are only stored in the ops
field of a pwm_chip structure. This field is of type const struct pwm_ops
*, so pwm_ops structures having this property can be declared as const.
Done using Coccinelle:
@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct pwm_ops i at p={...};
@ok1@
identifier r1.i;
position p;
struct pxa_pwm_chip pwm;
struct bfin_pwm_chip bwm;
struct vt8500_chip vp;
struct imx_chip icp;
@@
(
pwm.chip.ops=&i at p
|
bwm.chip.ops=&i at p
|
vp.chip.ops=&i at p
|
icp.chip.ops=&i at p
)
@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i at p
@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct pwm_ops i;
File size details:
text data bss dec hex filename
1646 328 0 1974 7b6 drivers/pwm/pwm-imx.o
1742 224 0 1966 7ae drivers/pwm/pwm-imx.o
1941 296 0 2237 8bd drivers/pwm/pwm-pxa.o
2037 192 0 2229 8b5 drivers/pwm/pwm-pxa.o
1946 296 0 2242 8c2 drivers/pwm/pwm-vt8500.o
2050 192 0 2242 8c2 drivers/pwm/pwm-vt8500.o
The drivers/pwm/pwm-bfin.o file did not compile.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
File: drivers/pwm/pwm-bfin.c is not tested
drivers/pwm/pwm-bfin.c | 2 +-
drivers/pwm/pwm-imx.c | 2 +-
drivers/pwm/pwm-pxa.c | 2 +-
drivers/pwm/pwm-vt8500.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-bfin.c b/drivers/pwm/pwm-bfin.c
index 7631ef1..d2ed0a2 100644
--- a/drivers/pwm/pwm-bfin.c
+++ b/drivers/pwm/pwm-bfin.c
@@ -103,7 +103,7 @@ static void bfin_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
disable_gptimer(priv->pin);
}
-static struct pwm_ops bfin_pwm_ops = {
+static const struct pwm_ops bfin_pwm_ops = {
.request = bfin_pwm_request,
.free = bfin_pwm_free,
.config = bfin_pwm_config,
diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
index d600fd5..177fb81 100644
--- a/drivers/pwm/pwm-imx.c
+++ b/drivers/pwm/pwm-imx.c
@@ -240,7 +240,7 @@ static void imx_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
clk_disable_unprepare(imx->clk_per);
}
-static struct pwm_ops imx_pwm_ops = {
+static const struct pwm_ops imx_pwm_ops = {
.enable = imx_pwm_enable,
.disable = imx_pwm_disable,
.config = imx_pwm_config,
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index 58b709f..4143a46 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -118,7 +118,7 @@ static void pxa_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
clk_disable_unprepare(pc->clk);
}
-static struct pwm_ops pxa_pwm_ops = {
+static const struct pwm_ops pxa_pwm_ops = {
.config = pxa_pwm_config,
.enable = pxa_pwm_enable,
.disable = pxa_pwm_disable,
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index cdb58fd..8141a49 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -184,7 +184,7 @@ static int vt8500_pwm_set_polarity(struct pwm_chip *chip,
return 0;
}
-static struct pwm_ops vt8500_pwm_ops = {
+static const struct pwm_ops vt8500_pwm_ops = {
.enable = vt8500_pwm_enable,
.disable = vt8500_pwm_disable,
.config = vt8500_pwm_config,
--
1.9.1
^ permalink raw reply related
* next-20170110 build: 1 failures 4 warnings (next-20170110)
From: Mark Brown @ 2017-01-10 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cQqkO-0005XB-2K@optimist>
On Tue, Jan 10, 2017 at 07:21:32AM +0000, Build bot for Mark Brown wrote:
Today's -next fails to build an arm allmodconfig due to:
> arm-allmodconfig
> ../drivers/net/ethernet/ti/netcp_core.c:1951:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
caused by 6a8162e99ef344 (net: netcp: store network statistics in 64
bits). It's assigning the function
static struct rtnl_link_stats64 *
netcp_get_stats(struct net_device *ndev, struct rtnl_link_stats64 *stats)
to ndo_get_stats64 which expects a function returning void.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170110/7194228e/attachment.sig>
^ permalink raw reply
* [PATCH v2 4/6] ARM: davinci: add skeleton for pdata-quirks
From: Kevin Hilman @ 2017-01-10 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5300e77b-0e76-245d-8f80-689865d471b8@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> On Tuesday 10 January 2017 03:56 PM, Sekhar Nori wrote:
>> On Tuesday 10 January 2017 02:25 AM, Kevin Hilman wrote:
>>> Add skeleton pdata-quirks for for davinci.
>>
>> s/for for/for
>>
>>>
>>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>>
>> Applied to v4.11/soc
>
> After reviewing 5/6, I think some parts of that patch should actually
> be part of basic pdata-quirks support addition. I have moved them here.
> Here is the updated patch. Let me know if it looks fine.
It looks fine. I hesitated with that part, but I'm OK either way.
Kevin
^ permalink raw reply
* [PATCH 3/5] pinctrl: sunxi: add driver for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103151629.19447-4-icenowy@aosc.xyz>
On Tue, Jan 03, 2017 at 11:16:27PM +0800, Icenowy Zheng wrote:
> V3s SoC features only a pin controller (for the lack of CPUs part).
>
> Add a driver for this controller.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
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/20170110/fcd3dda2/attachment.sig>
^ permalink raw reply
* [PATCH 4/5] ARM: dts: sunxi: add dtsi file for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103151629.19447-5-icenowy@aosc.xyz>
On Tue, Jan 03, 2017 at 11:16:28PM +0800, Icenowy Zheng wrote:
> + uart0_pins_a: uart0 at 0 {
> + pins = "PB8", "PB9";
> + function = "uart0";
> + bias-pull-up;
Why do you need a pullup here?
Looks good otherwise.
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/20170110/381e01e3/attachment.sig>
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Bartlomiej Zolnierkiewicz @ 2017-01-10 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2265318.ybtxfiNn3d@amdc3058>
On Tuesday, January 10, 2017 07:03:57 PM Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday, January 10, 2017 11:23:38 PM Anand Moon wrote:
> > Hi Shuah,
> >
> > On 10 January 2017 at 21:58, Shuah Khan <shuahkh@osg.samsung.com> wrote:
> > > On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
> > >>
> > >> Hi,
> > >>
> > >> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
> > >>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
> > >>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
> > >>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
> > >>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
> > >>>>>> error path only when susp_clk has been set from remove and probe error
> > >>>>>> paths.
> > >>>>>
> > >>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
> > >>>>> for NULL clock. Also your patch changes susp_clk handling while
> > >>>>> leaves axius_clk handling (which also can be NULL) untouched.
> > >>>>>
> > >>>>> Do you actually see some runtime problem with the current code?
> > >>>>>
> > >>>>> If not then the patch should probably be dropped.
> > >>>>>
> > >>>>> Best regards,
> > >>>>> --
> > >>>>> Bartlomiej Zolnierkiewicz
> > >>>>> Samsung R&D Institute Poland
> > >>>>> Samsung Electronics
> > >>>>
> > >>>> Hi Bartlomiej,
> > >>>>
> > >>>> I am seeing the "no suspend clk specified" message in dmesg.
> > >>>> After that it sets the exynos->susp_clk = NULL and starts
> > >>>> calling clk_prepare_enable(exynos->susp_clk);
> > >>>>
> > >>>> That can't be good. If you see the logic right above this
> > >>>> one for exynos->clk, it returns error and fails the probe.
> > >>>> This this case it doesn't, but tries to use null susp_clk.
> > >>
> > >> exynos->susp_clk is optional, exynos->clk is not.
> > >
> > > Right. That is clear since we don't fail the probe.
> > >
> > >>
> > >>>> I believe this patch is necessary.
> > >>>
> > >>> Let me clarify this a bit further. Since we already know
> > >>> susp_clk is null, with this patch we can avoid extra calls
> > >>> to clk_prepare_enable() and clk_disable_unprepare().
> > >>>
> > >>> One can say, it also adds extra checks, hence I will let you
> > >>> decide one way or the other. :)
> > >>
> > >> I would prefer to leave the things as they are currently.
> > >>
> > >> The code in question is not performance sensitive so extra
> > >> calls are not a problem. No extra checks means less code.
> > >>
> > >> Also the current code seems to be more in line with the rest
> > >> of the kernel.
> > >
> > > What functionality is missing without the suspend clock? Would
> > > it make sense to change the info. message to include what it
> > > means. At the moment it doesn't anything more than "no suspend
> > > clock" which is a very cryptic user visible message. It would be
> > > helpful for it to also include what functionality is impacted.
> > >
> >
> > Both usbdrd30_susp_clk and usbdrd30_axius_clk are used by exynos5433 platform
>
> Can you point me to the use of usbdrd30_axius_clk?
>
> I cannot find in the upstream code.
>
> > so moving the clk under compatible string "samsung,exynos7-dwusb3" make sense.
>
> This is not so simple and we would probably need a new compatible for
> Exynos5433 (it is currently using "samsung,exynos5250-dwusb3" one and
> is not using axius_clk).
I also think that regardless of what is decided on making susp_clk
non-optional for some Exynos SoCs we should probably remove the debug
message as it doesn't bring useful information and may be confusing.
Shuah, can you take care of this?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6: Specify 'anatop-enable-bit' where appropriate
From: Andrey Smirnov @ 2017-01-10 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CnwrPcney0qzQgex_aFXCrksmEocZ28nf54Kvcm2dq-w@mail.gmail.com>
On Tue, Jan 10, 2017 at 9:28 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Jan 10, 2017 at 2:30 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>> ENABLE_LINREG bit is implemented by 3P0, 1P1 and 2P5 regulators on
>> i.MX6. This property is present in similar code in Fresscale BSP and
>> made its way upstream in imx6ul.dtsi, so this patch adds this property
>> to the rest of i.MX6 family for completness.
>
> Please see:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/arch/arm/boot/dts/imx6ul.dtsi?id=27958ccdf29e9971732e02494b48be54b0691269
Fabio:
I submitted a patch implementing this property to LKML as well, see
https://www.spinics.net/lists/kernel/msg2418471.html
All of these patches are a part of a broader attempt to add PCIe
support for i.MX7, and on that platform this is a part of a 1P0D
regulator which supplies PCIe PHY.
I can rebase this patch set to take your commit into account, or else
let's discuss the best way to allow setting ENABLE_LINREG.
Thanks,
Andrey Smirnov
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Krzysztof Kozlowski @ 2017-01-10 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5156028.4V9iLD3Qkj@amdc3058>
On Tue, Jan 10, 2017 at 06:09:40PM +0100, Bartlomiej Zolnierkiewicz wrote:
> BTW What is interesting is that the Exynos7 dts patch [2] has never
> made it into upstream for some reason. In the meantime however
> Exynos5433 (similar to Exynos7 to some degree) became the user of
> susp_clk.
>
> [1] https://lkml.org/lkml/2014/11/21/247
> [2] https://patchwork.kernel.org/patch/5355161/
>
+Cc Alim and Pankaj,
Anyone would like to resend [2] after rebasing and testing? Interrupt
flags would have to be fixed and status=disabled added.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 2/2] dt-bindings: clk: add rockchip, grf property for RK3399
From: Doug Anderson @ 2017-01-10 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484028930-20305-3-git-send-email-zhengxing@rock-chips.com>
Hi,
On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v4:
> - update the decription for rockchip,grf property
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Anand Moon @ 2017-01-10 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2265318.ybtxfiNn3d@amdc3058>
Hi Bartlomiej,
On 10 January 2017 at 23:33, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
>
> Hi,
>
> On Tuesday, January 10, 2017 11:23:38 PM Anand Moon wrote:
>> Hi Shuah,
>>
>> On 10 January 2017 at 21:58, Shuah Khan <shuahkh@osg.samsung.com> wrote:
>> > On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
>> >>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
>> >>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>> >>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>> >>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>> >>>>>> error path only when susp_clk has been set from remove and probe error
>> >>>>>> paths.
>> >>>>>
>> >>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>> >>>>> for NULL clock. Also your patch changes susp_clk handling while
>> >>>>> leaves axius_clk handling (which also can be NULL) untouched.
>> >>>>>
>> >>>>> Do you actually see some runtime problem with the current code?
>> >>>>>
>> >>>>> If not then the patch should probably be dropped.
>> >>>>>
>> >>>>> Best regards,
>> >>>>> --
>> >>>>> Bartlomiej Zolnierkiewicz
>> >>>>> Samsung R&D Institute Poland
>> >>>>> Samsung Electronics
>> >>>>
>> >>>> Hi Bartlomiej,
>> >>>>
>> >>>> I am seeing the "no suspend clk specified" message in dmesg.
>> >>>> After that it sets the exynos->susp_clk = NULL and starts
>> >>>> calling clk_prepare_enable(exynos->susp_clk);
>> >>>>
>> >>>> That can't be good. If you see the logic right above this
>> >>>> one for exynos->clk, it returns error and fails the probe.
>> >>>> This this case it doesn't, but tries to use null susp_clk.
>> >>
>> >> exynos->susp_clk is optional, exynos->clk is not.
>> >
>> > Right. That is clear since we don't fail the probe.
>> >
>> >>
>> >>>> I believe this patch is necessary.
>> >>>
>> >>> Let me clarify this a bit further. Since we already know
>> >>> susp_clk is null, with this patch we can avoid extra calls
>> >>> to clk_prepare_enable() and clk_disable_unprepare().
>> >>>
>> >>> One can say, it also adds extra checks, hence I will let you
>> >>> decide one way or the other. :)
>> >>
>> >> I would prefer to leave the things as they are currently.
>> >>
>> >> The code in question is not performance sensitive so extra
>> >> calls are not a problem. No extra checks means less code.
>> >>
>> >> Also the current code seems to be more in line with the rest
>> >> of the kernel.
>> >
>> > What functionality is missing without the suspend clock? Would
>> > it make sense to change the info. message to include what it
>> > means. At the moment it doesn't anything more than "no suspend
>> > clock" which is a very cryptic user visible message. It would be
>> > helpful for it to also include what functionality is impacted.
>> >
>>
>> Both usbdrd30_susp_clk and usbdrd30_axius_clk are used by exynos5433 platform
>
> Can you point me to the use of usbdrd30_axius_clk?
>
> I cannot find in the upstream code.
>
>> so moving the clk under compatible string "samsung,exynos7-dwusb3" make sense.
>
> This is not so simple and we would probably need a new compatible for
> Exynos5433 (it is currently using "samsung,exynos5250-dwusb3" one and
> is not using axius_clk).
Opps: sorry for the noise, my result was based on simple grep.
Best Regards
-Anand
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
>> Best Regards
>> -Anand
>>
>> > thanks,
>> > -- Shuah
>> >
>> >>
>> >> Best regards,
>> >> --
>> >> Bartlomiej Zolnierkiewicz
>> >> Samsung R&D Institute Poland
>> >> Samsung Electronics
>> >>
>> >>> thanks,
>> >>> -- Shuah
>> >>>
>> >>>>
>> >>>> thanks,
>> >>>> -- Shuah
>> >>>>
>> >>>>>
>> >>>>>> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>> >>>>>> ---
>> >>>>>> drivers/usb/dwc3/dwc3-exynos.c | 10 ++++++----
>> >>>>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>> >>>>>>
>> >>>>>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> >>>>>> index e27899b..f97a3d7 100644
>> >>>>>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> >>>>>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> >>>>>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>> >>>>>> if (IS_ERR(exynos->susp_clk)) {
>> >>>>>> dev_info(dev, "no suspend clk specified\n");
>> >>>>>> exynos->susp_clk = NULL;
>> >>>>>> - }
>> >>>>>> - clk_prepare_enable(exynos->susp_clk);
>> >>>>>> + } else
>> >>>>>> + clk_prepare_enable(exynos->susp_clk);
>> >>>>>>
>> >>>>>> if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
>> >>>>>> exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
>> >>>>>> @@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
>> >>>>>> regulator_disable(exynos->vdd33);
>> >>>>>> err2:
>> >>>>>> clk_disable_unprepare(exynos->axius_clk);
>> >>>>>> - clk_disable_unprepare(exynos->susp_clk);
>> >>>>>> + if (exynos->susp_clk)
>> >>>>>> + clk_disable_unprepare(exynos->susp_clk);
>> >>>>>> clk_disable_unprepare(exynos->clk);
>> >>>>>> return ret;
>> >>>>>> }
>> >>>>>> @@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
>> >>>>>> platform_device_unregister(exynos->usb3_phy);
>> >>>>>>
>> >>>>>> clk_disable_unprepare(exynos->axius_clk);
>> >>>>>> - clk_disable_unprepare(exynos->susp_clk);
>> >>>>>> + if (exynos->susp_clk)
>> >>>>>> + clk_disable_unprepare(exynos->susp_clk);
>> >>>>>> clk_disable_unprepare(exynos->clk);
>> >>>>>>
>> >>>>>> regulator_disable(exynos->vdd33);
>
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Shuah Khan @ 2017-01-10 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1659345.4CcVdVckN5@amdc3058>
On 01/10/2017 11:23 AM, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday, January 10, 2017 07:03:57 PM Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Tuesday, January 10, 2017 11:23:38 PM Anand Moon wrote:
>>> Hi Shuah,
>>>
>>> On 10 January 2017 at 21:58, Shuah Khan <shuahkh@osg.samsung.com> wrote:
>>>> On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
>>>>>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
>>>>>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>>>>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>>>>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>>>>>>>> error path only when susp_clk has been set from remove and probe error
>>>>>>>>> paths.
>>>>>>>>
>>>>>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>>>>>>>> for NULL clock. Also your patch changes susp_clk handling while
>>>>>>>> leaves axius_clk handling (which also can be NULL) untouched.
>>>>>>>>
>>>>>>>> Do you actually see some runtime problem with the current code?
>>>>>>>>
>>>>>>>> If not then the patch should probably be dropped.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> --
>>>>>>>> Bartlomiej Zolnierkiewicz
>>>>>>>> Samsung R&D Institute Poland
>>>>>>>> Samsung Electronics
>>>>>>>
>>>>>>> Hi Bartlomiej,
>>>>>>>
>>>>>>> I am seeing the "no suspend clk specified" message in dmesg.
>>>>>>> After that it sets the exynos->susp_clk = NULL and starts
>>>>>>> calling clk_prepare_enable(exynos->susp_clk);
>>>>>>>
>>>>>>> That can't be good. If you see the logic right above this
>>>>>>> one for exynos->clk, it returns error and fails the probe.
>>>>>>> This this case it doesn't, but tries to use null susp_clk.
>>>>>
>>>>> exynos->susp_clk is optional, exynos->clk is not.
>>>>
>>>> Right. That is clear since we don't fail the probe.
>>>>
>>>>>
>>>>>>> I believe this patch is necessary.
>>>>>>
>>>>>> Let me clarify this a bit further. Since we already know
>>>>>> susp_clk is null, with this patch we can avoid extra calls
>>>>>> to clk_prepare_enable() and clk_disable_unprepare().
>>>>>>
>>>>>> One can say, it also adds extra checks, hence I will let you
>>>>>> decide one way or the other. :)
>>>>>
>>>>> I would prefer to leave the things as they are currently.
>>>>>
>>>>> The code in question is not performance sensitive so extra
>>>>> calls are not a problem. No extra checks means less code.
>>>>>
>>>>> Also the current code seems to be more in line with the rest
>>>>> of the kernel.
>>>>
>>>> What functionality is missing without the suspend clock? Would
>>>> it make sense to change the info. message to include what it
>>>> means. At the moment it doesn't anything more than "no suspend
>>>> clock" which is a very cryptic user visible message. It would be
>>>> helpful for it to also include what functionality is impacted.
>>>>
>>>
>>> Both usbdrd30_susp_clk and usbdrd30_axius_clk are used by exynos5433 platform
>>
>> Can you point me to the use of usbdrd30_axius_clk?
>>
>> I cannot find in the upstream code.
>>
>>> so moving the clk under compatible string "samsung,exynos7-dwusb3" make sense.
>>
>> This is not so simple and we would probably need a new compatible for
>> Exynos5433 (it is currently using "samsung,exynos5250-dwusb3" one and
>> is not using axius_clk).
>
> I also think that regardless of what is decided on making susp_clk
> non-optional for some Exynos SoCs we should probably remove the debug
> message as it doesn't bring useful information and may be confusing.
>
> Shuah, can you take care of this?
Yes. This message as it reads now is not only confusing, but also can
lead users to think something is wrong.
I can get rid of it or I could change it from info to debug and change
it to read:
"Optional Suspend clock isn't found. Diver operation isn't impacted"
thanks,
-- Shuah
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
^ permalink raw reply
* [PATCH v2 0/3] arm64: dts: exynos: Fix DTC warnings for Exynos boards
From: Krzysztof Kozlowski @ 2017-01-10 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:29PM -0300, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> This trivial series contains fixes for DTC warnings caused by mismatches
> between unit names and reg properties in device tree nodes.
>
> The patches shouldn't cause a functional change but have been just build
> tested. I compared the generated DTB though to make sure that only these
> nodes changed.
>
> Best regards,
> Javier
>
> Changes since v1:
> - Fix subject line since I forgot the "exynos" prefix.
Thanks :)
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Doug Anderson @ 2017-01-10 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484028930-20305-2-git-send-email-zhengxing@rock-chips.com>
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.
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.
-Doug
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
From: Krzysztof Kozlowski @ 2017-01-10 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484069912-6534-2-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:30PM -0300, Javier Martinez Canillas wrote:
> This patch fixes the following DTC warning about a mismatch
> between a device node reg property and its unit name:
>
> Node /soc has a reg or ranges property, but no unit name
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index 80aa60e38237..0d2fedc6ac2f 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -69,7 +69,7 @@
> method = "smc";
> };
>
> - soc: soc {
> + soc: soc at 0 {
This looks unnatural, like a fix just to silence the DTC. Mostly de do
not enumerate soc node, although there are few exceptions.
I would prefer ignore the warning... however I am happy to hear other opinions.
Best regards,
Krzysztof
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> --
> 2.7.4
>
^ permalink raw reply
* [RFC 7/8] KVM: arm/arm64: Set up a background timer for the physical timer emulation
From: Jintack Lim @ 2017-01-10 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109121326.GE4348@cbox>
Hi Christoffer,
thanks for the review!
On Mon, Jan 9, 2017 at 7:13 AM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Mon, Dec 26, 2016 at 12:12:05PM -0500, Jintack Lim wrote:
>> Set a background timer for the EL1 physical timer emulation while VMs are
>> running, so that VMs get interrupts for the physical timer in a timely
>> manner.
>>
>> We still use just one background timer. When a VM is runnable, we use
>> the background timer for the physical timer emulation. When the VM is
>> about to be blocked, we use the background timer to wake up the vcpu at
>> the earliest timer expiration among timers the VM is using.
>>
>> As a result, the assumption that the background timer is not armed while
>> VMs are running does not hold any more. So, remove BUG_ON()s and
>> WARN_ON()s accordingly.
>>
>> Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
>> ---
>> virt/kvm/arm/arch_timer.c | 42 +++++++++++++++++++++++++++++++-----------
>> 1 file changed, 31 insertions(+), 11 deletions(-)
>>
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index aa7e243..be8d953 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -91,9 +91,6 @@ static void kvm_timer_inject_irq_work(struct work_struct *work)
>> vcpu = container_of(work, struct kvm_vcpu, arch.timer_cpu.expired);
>> vcpu->arch.timer_cpu.armed = false;
>>
>> - WARN_ON(!kvm_timer_should_fire(vcpu, vcpu_vtimer(vcpu)) &&
>> - !kvm_timer_should_fire(vcpu, vcpu_ptimer(vcpu)));
>> -
>
> This seems misplaced and has been addressed here:
> https://lists.cs.columbia.edu/pipermail/kvmarm/2017-January/022933.html
>
> When you respin you can benefit from basing on that (assuming it gets
> acked and goes int).
Ok, I got it.
>
>> /*
>> * If the vcpu is blocked we want to wake it up so that it will see
>> * the timer has expired when entering the guest.
>> @@ -139,7 +136,6 @@ static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx)
>>
>> /*
>> * Returns minimal timer expiration time in ns among guest timers.
>> - * Note that it will return inf time if none of timers can fire.
>> */
>> static u64 kvm_timer_min_block(struct kvm_vcpu *vcpu)
>> {
>> @@ -153,7 +149,9 @@ static u64 kvm_timer_min_block(struct kvm_vcpu *vcpu)
>> if (kvm_timer_irq_can_fire(ptimer))
>> min_phys = kvm_timer_compute_delta(vcpu, ptimer);
>>
>> - WARN_ON((min_virt == ULLONG_MAX) && (min_phys == ULLONG_MAX));
>> + /* If none of timers can fire, then return 0 */
>> + if ((min_virt == ULLONG_MAX) && (min_phys == ULLONG_MAX))
>> + return 0;
>
> Why didn't you have this semantics in the previous patch?
I should have put this in the previous patch, and I'll do that.
Just let you know, WARN_ON() in the previous patch was there because I
thought that the caller of this function is sure that one of the
timers are able to fire. But I think that's beyond the scope of this
function.
>
>>
>> return min(min_virt, min_phys);
>> }
>> @@ -257,6 +255,26 @@ static int kvm_timer_update_state(struct kvm_vcpu *vcpu)
>> }
>>
>> /*
>> + * Schedule the background timer for the emulated timer. The background timer
>> + * runs whenever vcpu is runnable and the timer is not expired.
>> + */
>> +static void kvm_timer_emulate(struct kvm_vcpu *vcpu,
>> + struct arch_timer_context *timer_ctx)
>> +{
>> + struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +
>> + if (kvm_timer_should_fire(vcpu, timer_ctx))
>> + return;
>> +
>> + if (!kvm_timer_irq_can_fire(timer_ctx))
>> + return;
>> +
>> + /* The timer has not yet expired, schedule a background timer */
>> + timer_disarm(timer);
>> + timer_arm(timer, kvm_timer_compute_delta(vcpu, timer_ctx));
>
> I'm wondering what the effect of this thing really is. Isn't the soft
> timer programmed in timer_arm() based on Linux's own timekeeping
> schedule, such that the physical timer will be programmed to the next
> tick, regardless of what you program here, so all you have to do is
> check if you need to inject the phys timer on entry to the VM?
>
> On the other hand, if this can cause Linux to program the phys timer to
> expire sooner, then I guess it makes sense. Thinking about it, would
> that be the case on a tickless system?
I don't have a good answer for this, so I'll get back to you!
>
>> +}
>> +
>> +/*
>> * Schedule the background timer before calling kvm_vcpu_block, so that this
>> * thread is removed from its waitqueue and made runnable when there's a timer
>> * interrupt to handle.
>> @@ -267,8 +285,6 @@ void kvm_timer_schedule(struct kvm_vcpu *vcpu)
>> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>>
>> - BUG_ON(timer_is_armed(timer));
>> -
>> /*
>> * No need to schedule a background timer if any guest timer has
>> * already expired, because kvm_vcpu_block will return before putting
>> @@ -290,13 +306,21 @@ void kvm_timer_schedule(struct kvm_vcpu *vcpu)
>> * The guest timers have not yet expired, schedule a background timer.
>> * Pick smaller expiration time between phys and virt timer.
>> */
>> + timer_disarm(timer);
>> timer_arm(timer, kvm_timer_min_block(vcpu));
>> }
>>
>> void kvm_timer_unschedule(struct kvm_vcpu *vcpu)
>> {
>> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +
>> timer_disarm(timer);
>> +
>> + /*
>> + * Now we return from the blocking. If we have any timer to emulate,
>> + * and it's not expired, set the background timer for it.
>> + */
>> + kvm_timer_emulate(vcpu, vcpu_ptimer(vcpu));
>
> hmm, this is only called when returning from the kvm_vcpu_block() path.
> What about when you do vcpu_load/put, don't you need to schedule/cancel
> it there too?
We can do that, but I think that's not necessary. Firing the physical
timer while a vcpu is unloaded doesn't affect the task scheduling. Or
is it awkward to do so?
>
> Maybe it's simpler to just program the soft timer during flush_hwstate
> and cancel the timer during sync_hwstate. Does that work?
As far as I remember, it worked. I agree that it's simpler.
But as I mentioned in the patch [8/8] reply this *may* cause more overhead.
>
>> }
>>
>> /**
>> @@ -375,10 +399,6 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
>> */
>> void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>> {
>> - struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> -
>> - BUG_ON(timer_is_armed(timer));
>> -
>> /*
>> * The guest could have modified the timer registers or the timer
>> * could have expired, update the timer state.
>> --
>> 1.9.1
>>
>>
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
From: Krzysztof Kozlowski @ 2017-01-10 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484069912-6534-4-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:32PM -0300, Javier Martinez Canillas wrote:
> The "samsung,exynos5433-mipi-video-phy" and "samsung,exynos5250-dwusb3"
> DT bindings don't specify a reg property for these nodes, so having a
> unit name leads to the following DTC warnings:
>
> Node /soc/video-phy at 105c0710 has a unit name, but no reg property
> Node /soc/usb at 15400000 has a unit name, but no reg property
> Node /soc/usb at 15a00000 has a unit name, but no reg property
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 3695ddaf2e04..17e5dafd392c 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -706,7 +706,7 @@
> interrupts = <GIC_PPI 9 0xf04>;
> };
>
> - mipi_phy: video-phy at 105c0710 {
> + mipi_phy: video-phy {
> compatible = "samsung,exynos5433-mipi-video-phy";
> #phy-cells = <1>;
> samsung,pmu-syscon = <&pmu_system_controller>;
> @@ -1285,7 +1285,7 @@
> status = "disabled";
> };
>
> - usbdrd30: usb at 15400000 {
> + usbdrd30: usb-0 {
How about "usbdrd" instead of "usb-0"? It would be still quite a generic
description of a class.
> compatible = "samsung,exynos5250-dwusb3";
> clocks = <&cmu_fsys CLK_ACLK_USBDRD30>,
> <&cmu_fsys CLK_SCLK_USBDRD30>;
> @@ -1332,7 +1332,7 @@
> status = "disabled";
> };
>
> - usbhost30: usb at 15a00000 {
> + usbhost30: usb-1 {
usbhost?
Best regards,
Krzysztof
> compatible = "samsung,exynos5250-dwusb3";
> clocks = <&cmu_fsys CLK_ACLK_USBHOST30>,
> <&cmu_fsys CLK_SCLK_USBHOST30>;
> --
> 2.7.4
>
^ permalink raw reply
* System/uncore PMUs and unit aggregation
From: Will Deacon @ 2017-01-10 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2cb0eb12-979c-7eff-7c51-ce9e06b3740c@codeaurora.org>
Hi Neil, Anurup, Jan,
On Thu, Nov 17, 2016 at 10:16:46PM -0500, Leeder, Neil wrote:
> Thanks for opening up the discussion on this Will.
>
> For the Qualcomm L2 driver, one objection I had to exposing each unit is
> that there are so many of them - the minimum starting point is a dozen, so
> trying to start 9 counters on each means a perf command line specifying 100+
> events. Future chips are only likely to increase that.
>
> There is a single CPU node so from an end-user perspective it would seems to
> make sense to also have a single L2 node. perf already has the ability to
> create events on multiple units using cpumask, aggregate the results, and
> split them out per unit with perf stat -a -A, so the user can get that
> granularity. Exposing separate units would make userspace duplicate a lot of
> that functionality. This may rely on each uncore unit being associated with
> a CPU, which is the case with L2.
>
> I agree with your comments regarding groups and I can see that a standard
> way of representing topology could be useful - in this case, which CPUs are
> within the same L2 cluster. Perhaps a list of cpumasks, one per L2 unit.
Mark and I had a chat about this earlier today and I think we largely agree
with you. That is, for composite PMUs with a notion of CPU affinity for
their component units, it makes sense to use the event affinity as a means
to address these units, rather than e.g. create separate PMU instances.
However, for PMUs that don't have this notion of affinity, the units should
either be exposed individually or, in the case that there is something like
shared control logic, they should be addressed through the config fields
(e.g. the hisilicon cache with the bank=NN option).
I think this fits with your driver, so please post an updated version
addressing Mark's unrelated review comments.
> On 11/17/2016 1:17 PM, Will Deacon wrote:
> [...]
> > 3. Summing the counters across units is only permitted if the units
> > can all be started and stopped atomically. Otherwise, the counters
> > should be exposed individually. It's up to the driver author to
> > decide what makes sense to sum.
>
> If I understand your your point 3 correctly, I'm not sure about the need to
> start and stop them all atomically. That seems to be a tighter requirement
> than we require for CPU PMUs. For them, perf stat -a creates events/groups
> on each CPU, then starts and stops them sequentially and sums the results.
> If that model is acceptable for the CPU to collect and aggregate counts,
> that should be the same bar that uncore PMUs need to reach. In the L2 case,
> the driver isn't summing the results, it's still perf doing it, so I may be
> misinterpreting your comment about where the summation is permitted.
My concern with summation is more that I don't want to expose high-level
"meta" events from the driver which in fact end up being a bunch of
different events in a bunch of different counters that can't be read
atomically. Userspace is free to do that, but the driver shouldn't claim
that it can support the event, if you see what I mean?
Will
^ permalink raw reply
* System/uncore PMUs and unit aggregation
From: Will Deacon @ 2017-01-10 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582EB89B.5050708@gmail.com>
On Fri, Nov 18, 2016 at 01:45:23PM +0530, Anurup M wrote:
> On Thursday 17 November 2016 11:47 PM, Will Deacon wrote:
> >We currently have support for three arm64 system PMUs in flight:
> >
> > [Cavium ThunderX] http://lkml.kernel.org/r/cover.1477741719.git.jglauber at cavium.com
> > [Hisilicon Hip0x] http://lkml.kernel.org/r/1478151727-20250-1-git-send-email-anurup.m at huawei.com
> > [Qualcomm L2] http://lkml.kernel.org/r/1477687813-11412-1-git-send-email-nleeder at codeaurora.org
> >
> >Each of which have to deal with multiple underlying hardware units in one
> >way or another. Mark and I recently expressed a desire to expose these
> >units to userspace as individual PMU instances, since this can allow:
> >
> > * Fine-grained control of events from userspace, when you want to see
> > individual numbers as opposed to a summed total
> >
> > * Potentially ease migration to new SoC revisions, where the units
> > are laid out slightly differently
> >
> > * Easier handling of cases where the units aren't quite identical
> >
> >however, this received pushback from all of the patch authors, so there's
> >clearly a problem with this approach. I'm hoping we can try to resolve
> >this here.
> >
> >Speaking to Mark earlier today, we came up with the following rough rules
> >for drivers that present multiple hardware units as a single PMU:
> >
> > 1. If the units share some part of the programming interface (e.g. control
> > registers or interrupts), then they must be handled by the same PMU.
> > Otherwise, they should be treated independently as separate PMU
> > instances.
> The Hisilicon Hip0x chip has units like L3 cache, Miscellaneous nodes, DDR
> controller etc.
> There are such units in multiple CPU die's in the chip.
>
> The L3 cache is further divided as banks which have separate set of
> interface (control registers, interrupts etc..).
> As per the suggestion, each L3 cache banks will be exposed as a individual
> PMU instance.
> So for e.g. in a board using Hip0x chip with 2 sockets and each socket
> consists of 2 CPU die,
> There will be a total of 16 L3 cache PMU's which will be exposed.
>
> My doubt here is
> Each L3 cache PMU has total 22 statistics events. So if registered as a
> separate PMU, will it not
> create multiple entries (with same event names) in event listing for
> multiple L3 cache PMU's.
> Is there a way to avoid this? or this is acceptable?
>
> Just a thought, If we can group them as single PMU and add a config
> parameter in the event listing to
> identify the L3 cache bank(sub unit). e.g: event name will appear as
> "hisi_l3c2/read_allocate,bank=?/".
> And user can choose count from bank 0x01 as -e
> "hisi_l3c2/read_allocate,bank=0x01/".
> And for aggregate count, bank=0xff.
> Does it over complicate? Please share your comments.
Adding a bank field to the config looks fine to me. I'm assuming the banks
aren't CPU affine?
Will
^ permalink raw reply
* [PATCH] ARM: dts: udoo_neo: Add UDOO Neo USB OTG1 and OTG2 support
From: Breno Lima @ 2017-01-10 18:59 UTC (permalink / raw)
To: linux-arm-kernel
Add support for micro USB (OTG1) and USB Host (OTG2) for UDOO Neo board.
Tested on a UDOO Neo Full board by mounting a mass storage device
on both ports.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
---
arch/arm/boot/dts/imx6sx-udoo-neo.dtsi | 60 ++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
index 2b65d26..827ace1 100644
--- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -75,6 +75,28 @@
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
+
+ reg_usb_otg1_vbus: usb-otg1-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_otg1_reg>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usb_otg2_vbus: usb-otg2-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_otg2_reg>;
+ regulator-name = "usb_otg2_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 12 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
&cpu0 {
@@ -241,6 +263,28 @@
<MX6SX_PAD_CSI_DATA07__UART6_CTS_B 0x1b0b1>;
};
+ pinctrl_otg1_reg: otg1grp {
+ fsl,pins =
+ <MX6SX_PAD_GPIO1_IO09__GPIO1_IO_9 0x10b0>;
+ };
+
+
+ pinctrl_otg2_reg: otg2grp {
+ fsl,pins =
+ <MX6SX_PAD_NAND_RE_B__GPIO4_IO_12 0x10b0>;
+ };
+
+ pinctrl_usb_otg1: usbotg1grp {
+ fsl,pins =
+ <MX6SX_PAD_GPIO1_IO10__ANATOP_OTG1_ID 0x17059>,
+ <MX6SX_PAD_GPIO1_IO08__USB_OTG1_OC 0x10b0>;
+ };
+
+ pinctrl_usb_otg2: usbot2ggrp {
+ fsl,pins =
+ <MX6SX_PAD_QSPI1A_DATA0__USB_OTG2_OC 0x10b0>;
+ };
+
pinctrl_usdhc2: usdhc2grp {
fsl,pins =
<MX6SX_PAD_SD2_CMD__USDHC2_CMD 0x17059>,
@@ -280,6 +324,22 @@
status = "disabled";
};
+&usbotg1 { /* J2 micro USB port */
+ vbus-supply = <®_usb_otg1_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg1>;
+ imx6-usb-charger-detection;
+ status = "okay";
+};
+
+&usbotg2 { /* J3 host USB port */
+ vbus-supply = <®_usb_otg2_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg2>;
+ dr_mode = "host";
+ status = "okay";
+};
+
&usdhc2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2>;
--
2.7.4
^ permalink raw reply related
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Krzysztof Kozlowski @ 2017-01-10 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23cf318d-b83f-55e6-e980-13133f0ceb8b@osg.samsung.com>
On Tue, Jan 10, 2017 at 11:37:24AM -0700, Shuah Khan wrote:
> On 01/10/2017 11:23 AM, Bartlomiej Zolnierkiewicz wrote:
> > I also think that regardless of what is decided on making susp_clk
> > non-optional for some Exynos SoCs we should probably remove the debug
> > message as it doesn't bring useful information and may be confusing.
> >
> > Shuah, can you take care of this?
>
> Yes. This message as it reads now is not only confusing, but also can
> lead users to think something is wrong.
>
> I can get rid of it or I could change it from info to debug and change
> it to read:
>
> "Optional Suspend clock isn't found. Diver operation isn't impacted"
It is even more confusing. If the clock is required (by binding, by
hardware) - make it an error. If it is completely not important - do not
print anything. If it is optional but helpful (enabling clock gives
someything) then print something... but it is not that case.
Best regards,
Krzysztof
^ 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