* [PATCH 0/2] fix issue: vblank interrupts are never disabled
From: Daniel Kurtz @ 2016-10-07 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475119789-64619-1-git-send-email-bibby.hsieh@mediatek.com>
On Thu, Sep 29, 2016 at 11:29 AM, Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
>
> Clean the interrupt status before enable interrupt
> and set the vblank_disable_allowed to fix the issue.
For the series:
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
>
> Bibby Hsieh (2):
> drm/mediatek: set vblank_disable_allowed to true
> drm/mediatek: clear IRQ status before enable OVL interrupt
>
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
> 2 files changed, 2 insertions(+)
>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v3 03/11] ARM: shmobile: r8a7743: basic SoC support
From: Geert Uytterhoeven @ 2016-10-07 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <836d9018-e8f4-27ef-bfff-06932184d59f@cogentembedded.com>
Hi Sergei,
On Fri, Oct 7, 2016 at 12:02 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 10/7/2016 11:33 AM, Laurent Pinchart wrote:
>>>> Add minimal support for the RZ/G1M (R8A7743) SoC.
>>>> Based on the original (and large) patch by Dmitry Shifrin
>>>> <dmitry.shifrin@cogentembedded.com>.
>>>>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>
>>>
>>> Thanks, I have queued this up.
>>
>>
>> I'd like to see this patch rebased on top of "[PATCH] ARM: shmobile:
>> Consolidate R8A779[234] machine definitions".
>
>
> R87743 is analogous to R8A7791, not R8A779[234], not sure how it is
> connected to your patch.
The comment
+ /*
+ * R8A7790 and R8A7791 can't be handled here as long as they need SMP
+ * initialization fallback.
+ */
is not about r8a7790/r8a7791 in se, but about backward compatibility support
for DTBs without APMU nodes and CPU enable-methods.
For new SoCs, we mandate the presence of these in the DTB.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/5] clk: add support for runtime pm
From: Ulf Hansson @ 2016-10-07 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474282525-30441-2-git-send-email-m.szyprowski@samsung.com>
On 19 September 2016 at 12:55, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Registers for some clocks might be located in the SOC area, which are under the
> power domain. To enable access to those registers respective domain has to be
> turned on. Additionally, registers for such clocks will usually loose its
> contents when power domain is turned off, so additional saving and restoring of
> them might be needed in the clock controller driver.
>
> This patch adds basic infrastructure in the clocks core to allow implementing
> driver for such clocks under power domains. Clock provider can supply a
> struct device pointer, which is the used by clock core for tracking and managing
> clock's controller runtime pm state. Each clk_prepare() operation
> will first call pm_runtime_get_sync() on the supplied device, while
> clk_unprepare() will do pm_runtime_put() at the end.
>
> Additional calls to pm_runtime_get/put functions are required to ensure that any
> register access (like calculating/changing clock rates and unpreparing/disabling
> unused clocks on boot) will be done with clock controller in runtime resumend
> state.
>
> When one wants to register clock controller, which make use of this feature, he
> has to:
> 1. Provide a struct device to the core when registering the provider and set
> CLK_RUNTIME_PM flags for its clocks.
> 2. It needs to enable runtime PM for that device.
> 3. It needs to make sure the runtime PM status of the controller device reflects
> the HW state.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/clk/clk.c | 107 +++++++++++++++++++++++++++++++++++++++----
> include/linux/clk-provider.h | 1 +
> 2 files changed, 98 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 820a939fb6bb..096a199b8e46 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -21,6 +21,7 @@
> #include <linux/of.h>
> #include <linux/device.h>
> #include <linux/init.h>
> +#include <linux/pm_runtime.h>
> #include <linux/sched.h>
> #include <linux/clkdev.h>
>
> @@ -46,6 +47,7 @@ struct clk_core {
> const struct clk_ops *ops;
> struct clk_hw *hw;
> struct module *owner;
> + struct device *dev;
> struct clk_core *parent;
> const char **parent_names;
> struct clk_core **parents;
> @@ -87,6 +89,26 @@ struct clk {
> struct hlist_node clks_node;
> };
>
> +/*** runtime pm ***/
> +static int clk_pm_runtime_get(struct clk_core *core)
> +{
> + int ret = 0;
> +
> + if (!core->dev)
> + return 0;
> +
> + ret = pm_runtime_get_sync(core->dev);
> + return ret < 0 ? ret : 0;
> +}
> +
> +static void clk_pm_runtime_put(struct clk_core *core)
> +{
> + if (!core->dev)
> + return;
> +
> + pm_runtime_put(core->dev);
> +}
> +
> /*** locking ***/
> static void clk_prepare_lock(void)
> {
> @@ -150,6 +172,8 @@ static void clk_enable_unlock(unsigned long flags)
>
> static bool clk_core_is_prepared(struct clk_core *core)
> {
> + bool status;
> +
> /*
> * .is_prepared is optional for clocks that can prepare
> * fall back to software usage counter if it is missing
> @@ -157,11 +181,17 @@ static bool clk_core_is_prepared(struct clk_core *core)
> if (!core->ops->is_prepared)
> return core->prepare_count;
>
> - return core->ops->is_prepared(core->hw);
> + clk_pm_runtime_get(core);
I guess you should assign status to the return code, and check it.
> + status = core->ops->is_prepared(core->hw);
> + clk_pm_runtime_put(core);
> +
> + return status;
> }
>
> static bool clk_core_is_enabled(struct clk_core *core)
> {
> + bool status;
> +
> /*
> * .is_enabled is only mandatory for clocks that gate
> * fall back to software usage counter if .is_enabled is missing
> @@ -169,7 +199,29 @@ static bool clk_core_is_enabled(struct clk_core *core)
> if (!core->ops->is_enabled)
> return core->enable_count;
>
> - return core->ops->is_enabled(core->hw);
> + /*
> + * Check if runtime pm is enabled before calling .is_enabled callback,
> + * if not assume that clock is disabled, because we might be called
> + * from atomic context, from which pm_runtime_get() is not allowed.
> + * This function is called mainly from clk_disable_unused_subtree,
> + * which ensures proper runtime pm activation of controller before
> + * taking enable spinlock, but the below check is needed if one tries
> + * to call it from other place.
> + */
> + if (core->dev) {
> + pm_runtime_get_noresume(core->dev);
> + if (pm_runtime_suspended(core->dev)) {
I think it's wrong to use pm_runtime_suspended().
What you should be checking, is whether the device is RPM_ACTIVE or if
runtime PM isn't enabled for device.
In other words, you should use pm_runtime_active() to find out whether
it's okay to invoke the ->is_enabled() ops or not.
Accordingly, I think the upper comment you added then needs to be a
rephrased a bit to reflect this.
> + status = false;
> + goto done;
> + }
> + }
> +
> + status = core->ops->is_enabled(core->hw);
> +done:
> + if (core->dev)
> + pm_runtime_put(core->dev);
> +
> + return status;
> }
>
> /*** helper functions ***/
> @@ -489,6 +541,8 @@ static void clk_core_unprepare(struct clk_core *core)
> if (core->ops->unprepare)
> core->ops->unprepare(core->hw);
>
> + clk_pm_runtime_put(core);
> +
> trace_clk_unprepare_complete(core);
> clk_core_unprepare(core->parent);
> }
> @@ -530,10 +584,14 @@ static int clk_core_prepare(struct clk_core *core)
> return 0;
>
> if (core->prepare_count == 0) {
> - ret = clk_core_prepare(core->parent);
> + ret = clk_pm_runtime_get(core);
> if (ret)
> return ret;
>
> + ret = clk_core_prepare(core->parent);
> + if (ret)
> + goto runtime_put;
> +
> trace_clk_prepare(core);
>
> if (core->ops->prepare)
> @@ -541,15 +599,18 @@ static int clk_core_prepare(struct clk_core *core)
>
> trace_clk_prepare_complete(core);
>
> - if (ret) {
> - clk_core_unprepare(core->parent);
> - return ret;
> - }
> + if (ret)
> + goto unprepare;
> }
>
> core->prepare_count++;
>
> return 0;
> +unprepare:
> + clk_core_unprepare(core->parent);
> +runtime_put:
> + clk_pm_runtime_put(core);
> + return ret;
> }
>
> static int clk_core_prepare_lock(struct clk_core *core)
> @@ -745,6 +806,9 @@ static void clk_unprepare_unused_subtree(struct clk_core *core)
> if (core->flags & CLK_IGNORE_UNUSED)
> return;
>
> + if (clk_pm_runtime_get(core) != 0)
You may simplify this:
if (clk_pm_runtime_get(core))
> + return;
> +
> if (clk_core_is_prepared(core)) {
> trace_clk_unprepare(core);
> if (core->ops->unprepare_unused)
> @@ -753,6 +817,8 @@ static void clk_unprepare_unused_subtree(struct clk_core *core)
> core->ops->unprepare(core->hw);
> trace_clk_unprepare_complete(core);
> }
> +
> + clk_pm_runtime_put(core);
> }
>
> static void clk_disable_unused_subtree(struct clk_core *core)
> @@ -768,6 +834,9 @@ static void clk_disable_unused_subtree(struct clk_core *core)
> if (core->flags & CLK_OPS_PARENT_ENABLE)
> clk_core_prepare_enable(core->parent);
>
> + if (clk_pm_runtime_get(core) != 0)
Is there any reason to why you haven't moved this further down in this
function, like just before calling clk_core_is_enabled()?
You may also simplify this:
if (clk_pm_runtime_get(core))
> + return;
> +
You need to restore the call made to clk_core_prepare_enable()
earlier, so please update the error handling to cope with this.
> flags = clk_enable_lock();
>
> if (core->enable_count)
> @@ -794,6 +863,8 @@ unlock_out:
> clk_enable_unlock(flags);
> if (core->flags & CLK_OPS_PARENT_ENABLE)
> clk_core_disable_unprepare(core->parent);
> +
> + clk_pm_runtime_put(core);
> }
>
> static bool clk_ignore_unused;
> @@ -1563,6 +1634,7 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
> {
> struct clk_core *top, *fail_clk;
> unsigned long rate = req_rate;
> + int ret = 0;
>
> if (!core)
> return 0;
> @@ -1579,21 +1651,28 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
> if (!top)
> return -EINVAL;
>
> + ret = clk_pm_runtime_get(core);
> + if (ret)
> + return ret;
> +
> /* notify that we are about to change rates */
> fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE);
> if (fail_clk) {
> pr_debug("%s: failed to set %s rate\n", __func__,
> fail_clk->name);
> clk_propagate_rate_change(top, ABORT_RATE_CHANGE);
> - return -EBUSY;
> + ret = -EBUSY;
> + goto err;
> }
>
> /* change the rates */
> clk_change_rate(top);
>
> core->req_rate = req_rate;
> +err:
> + clk_pm_runtime_put(core);
>
> - return 0;
> + return ret;
> }
>
> /**
> @@ -1824,12 +1903,16 @@ static int clk_core_set_parent(struct clk_core *core, struct clk_core *parent)
> p_rate = parent->rate;
> }
>
> + ret = clk_pm_runtime_get(core);
> + if (ret)
> + goto out;
> +
> /* propagate PRE_RATE_CHANGE notifications */
> ret = __clk_speculate_rates(core, p_rate);
>
> /* abort if a driver objects */
> if (ret & NOTIFY_STOP_MASK)
> - goto out;
> + goto runtime_put;
>
> /* do the re-parent */
> ret = __clk_set_parent(core, parent, p_index);
> @@ -1842,6 +1925,8 @@ static int clk_core_set_parent(struct clk_core *core, struct clk_core *parent)
> __clk_recalc_accuracies(core);
> }
>
> +runtime_put:
> + clk_pm_runtime_put(core);
> out:
> clk_prepare_unlock();
>
> @@ -2546,6 +2631,8 @@ struct clk *clk_register(struct device *dev, struct clk_hw *hw)
> goto fail_name;
> }
> core->ops = hw->init->ops;
> + if (dev && (hw->init->flags & CLK_RUNTIME_PM))
> + core->dev = dev;
I guess you need this to play safe, although I am really wondering if
we should try without.
Not that many clocks are currently being registered with a valid
struct device pointer. For the other cases why not try to use runtime
PM as per default?
Moreover we anyway rely on the clock provider to enable runtime PM for
the clock device, and when that isn't the case the runtime PM
deployment in the core should still be safe, right!?
> if (dev && dev->driver)
> core->owner = dev->driver->owner;
> core->hw = hw;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index a39c0c530778..8a131eb71fdf 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -35,6 +35,7 @@
> #define CLK_IS_CRITICAL BIT(11) /* do not gate, ever */
> /* parents need enable during gate/ungate, set rate and re-parent */
> #define CLK_OPS_PARENT_ENABLE BIT(12)
> +#define CLK_RUNTIME_PM BIT(13)
>
> struct clk;
> struct clk_hw;
> --
> 1.9.1
>
Kind regards
Uffe
^ permalink raw reply
* [PATCH v3 03/11] ARM: shmobile: r8a7743: basic SoC support
From: Sergei Shtylyov @ 2016-10-07 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2345971.ESZSzve5jF@avalon>
Hello.
On 10/7/2016 11:33 AM, Laurent Pinchart wrote:
>>> Add minimal support for the RZ/G1M (R8A7743) SoC.
>>>
>>> Based on the original (and large) patch by Dmitry Shifrin
>>> <dmitry.shifrin@cogentembedded.com>.
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> Thanks, I have queued this up.
>
> I'd like to see this patch rebased on top of "[PATCH] ARM: shmobile:
> Consolidate R8A779[234] machine definitions".
R87743 is analogous to R8A7791, not R8A779[234], not sure how it is
connected to your patch.
MBR, Sergei
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
From: Heiko Stuebner @ 2016-10-07 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
Am Freitag, 7. Oktober 2016, 10:29:48 CEST schrieb Shawn Lin:
> Hi Pawe? ,
>
> On 2016/10/7 1:38, Pawe? Jarosz wrote:
> > MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
> > - host and otg, micro sd card slot and onboard wifi RK901.
> >
> > Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
> > ---
> >
> > Changes in v2:
> > - included Heiko sugestion.
> >
> > Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/rk3066a-mk808.dts | 184
> > +++++++++++++++++++++ 3 files changed, 189 insertions(+)
> > create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
> >
> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > 55f388f..c09595b 100644
> > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
> >
> > Required root node properties:
> > - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
> >
> > +- Rikomagic MK808 v1 board:
> > + Required root node properties:
> > + - compatible = "rikomagic,mk808", "rockchip,rk3066a";
> > +
> >
> > - Radxa Rock board:
> > Required root node properties:
> > - compatible = "radxa,rock", "rockchip,rk3188";
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index befcd26..f19cc1d 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> >
> > rk3036-kylin.dtb \
> > rk3066a-bqcurie2.dtb \
> > rk3066a-marsboard.dtb \
> >
> > + rk3066a-mk808.dtb \
> >
> > rk3066a-rayeager.dtb \
> > rk3188-radxarock.dtb \
> > rk3228-evb.dtb \
> >
> > diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
> > b/arch/arm/boot/dts/rk3066a-mk808.dts new file mode 100644
> > index 0000000..2878562
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/rk3066a-mk808.dts
> > @@ -0,0 +1,184 @@
> > +/*
> > + * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691@gmail.com>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + * a) This file is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License, or (at your option) any later version.
> > + *
> > + * This file is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + * b) Permission is hereby granted, free of charge, to any person
> > + * obtaining a copy of this software and associated documentation
> > + * files (the "Software"), to deal in the Software without
> > + * restriction, including without limitation the rights to use,
> > + * copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following
> > + * conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > + * included in all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3066a.dtsi"
> > +
> > +/ {
> > + model = "Rikomagic MK808";
> > + compatible = "rikomagic,mk808", "rockchip,rk3066a";
> > +
> > + chosen {
> > + stdout-path = "serial2:115200n8";
> > + };
> > +
> > + memory at 60000000 {
> > + device_type = "memory";
> > + reg = <0x60000000 0x40000000>;
> > + };
> > +
> > + gpio-leds {
> > + compatible = "gpio-leds";
> > +
> > + blue {
> > + label = "mk808:blue:power";
> > + gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
> > + default-state = "off";
> > + linux,default-trigger = "default-on";
> > + };
> > + };
> > +
> > + mmc_pwrseq: mmc-pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&sdmmc_pwr>;
>
> sd slot does not contain a reset pin. So the power pin should be
> enough. just add sdmmc_pwr to mmc0's pinctrl-0 and let mmc driver
> control it should be enough. Typically pwrseq is for emmc and sdio.
> We don't need a pwerseq to control power for sd slot..
>
> But it seems sdmmc_pwr is a GPIO, but not functional port.
> So I am interesting that why MK808 board doesn't use the mmc
> controller's default power pin but chosing another gpio, so finally
> we have to add thses code for your DT.
Actually, we always model the sd-mmc pwr-pin as gpio-based regulator (see
sdmmc-regulator for example in the rk3066a-rayeager.dts), and specifiy this
regulator as vmmc. That way the mmc core really can control the power.
Heiko
^ permalink raw reply
* [PATCH v3 04/11] ARM: dts: r8a7743: initial SoC device tree
From: Sergei Shtylyov @ 2016-10-07 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161007030932.GH13721@verge.net.au>
On 10/7/2016 6:09 AM, Simon Horman wrote:
>> The initial R8A7743 SoC device tree including CPU cores, GIC, timer, SYSC,
>> CPG, and the required clock descriptions.
>>
>> Based on the original (and large) patch by Dmitry Shifrin
>> <dmitry.shifrin@cogentembedded.com>.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> I notice that this patch enables two CPUs. Have you tested SMP and:
> - CPU hotplug
> - Suspend to RAM
No, not really. I'll remove CPU1. :-<
MBR, Sergei
^ permalink raw reply
* [PATCH v3] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Ard Biesheuvel @ 2016-10-07 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473696925-26156-1-git-send-email-ard.biesheuvel@linaro.org>
On 12 September 2016 at 17:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Move the statically allocated zero page from the .bss section to right
> before swapper_pg_dir. This allows us to refer to its physical address
> by simply reading TTBR1_EL1 (which always points to swapper_pg_dir and
> always has its ASID field cleared), and subtracting PAGE_SIZE.
>
> To protect the zero page from inadvertent modification, carve out a
> segment that covers it as well as idmap_pg_dir[], and mark it read-only
> in both the primary and the linear mappings of the kernel.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
[...]
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 05615a3fdc6f..d2be62ff1ad3 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
[...]
> @@ -424,13 +430,19 @@ static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
> */
> static void __init map_kernel(pgd_t *pgd)
> {
> - static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_init, vmlinux_data;
> + static struct vm_struct vmlinux_text, vmlinux_rodata, vmlinux_init,
> + vmlinux_data, vmlinux_robss, vmlinux_swapper;
>
> map_kernel_segment(pgd, _text, _etext, PAGE_KERNEL_EXEC, &vmlinux_text);
> map_kernel_segment(pgd, __start_rodata, __init_begin, PAGE_KERNEL, &vmlinux_rodata);
> map_kernel_segment(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC,
> &vmlinux_init);
> - map_kernel_segment(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
> + map_kernel_segment(pgd, _data, __robss_start, PAGE_KERNEL,
> + &vmlinux_data);
> + map_kernel_segment(pgd, __robss_start, __robss_end, PAGE_KERNEL_RO,
> + &vmlinux_robss);
I realised it is actually unnecessary to map the idmap and the zero
page into the kernel mapping, so we could drop this line.
^ permalink raw reply
* [PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support
From: Laurent Pinchart @ 2016-10-07 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f39e907c-424f-7572-f88e-5dd0b6009631@codeaurora.org>
Hi Archit,
On Friday 07 Oct 2016 10:27:31 Archit Taneja wrote:
> On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
> > On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
> >> On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
> >>> On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
> >>>> On 10/06/2016 12:51 PM, Maxime Ripard wrote:
> >>>>> On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
> >>>>>> On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> >>>>>>> Some boards have an entirely passive RGB to VGA bridge, based on
> >>>>>>> either DACs or resistor ladders.
> >>>>>>>
> >>>>>>> Those might or might not have an i2c bus routed to the VGA connector
> >>>>>>> in order to access the screen EDIDs.
> >>>>>>>
> >>>>>>> Add a bridge that doesn't do anything but expose the modes available
> >>>>>>> on the screen, either based on the EDIDs if available, or based on
> >>>>>>> the XGA standards.
> >>>>>>>
> >>>>>>> Acked-by: Rob Herring <robh@kernel.org>
> >>>>>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>>>>>> ---
> >>>>>>> .../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
> >>>>>>> drivers/gpu/drm/bridge/Kconfig | 7 +
> >>>>>>> drivers/gpu/drm/bridge/Makefile | 1 +
> >>>>>>> drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++
> >>>>>>> 4 files changed, 285 insertions(+)
> >>>>>>> create mode 100644
> >>>>>>> Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.t
> >>>>>>> xt
> >>>>>>> create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> >>>>>>>
> >>>>>>> diff --git
> >>>>>>> a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge
> >>>>>>> .
> >>>>>>> txt
> >>>>>>> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge
> >>>>>>> .
> >>>>>>> txt
> >>>>>>> new file mode 100644
> >>>>>>> index 000000000000..a8375bc1f9cb
> >>>>>>> --- /dev/null
> >>>>>>> +++
> >>>>>>> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge
> >>>>>>> .
> >>>>>>> tx
> >>>>>>> t @@ -0,0 +1,48 @@
> >>>>>>> +Dumb RGB to VGA bridge
> >>>>>>> +----------------------
> >>>>>>> +
> >>>>>>> +This binding is aimed for dumb RGB to VGA bridges that do not
> >>>>>>> require
> >>>>>>> +any configuration.
> >>>>>>> +
> >>>>>>> +Required properties:
> >>>>>>> +
> >>>>>>> +- compatible: Must be "rgb-to-vga-bridge"
> >>>>>>
> >>>>>> I'd talked to Laurent on IRC if he's okay with this. And I guess you
> >>>>>> to had discussed it during XDC too. He's suggested that it'd be
> >>>>>> better
> >>>>>> to have the compatible string as "simple-vga-dac".
> >>>>>
> >>>>> I just wished this bikeshedding had taken place publicly and be
> >>>>> actually part of that discussion, but yeah, ok.
> >>>>
> >>>> Sorry about that. I'd pinged him for an Ack, the discussion went
> >>>> more than that :)
> >>>>
> >>>>>> Some of the reasons behind having this:
> >>>>>>
> >>>>>> - We don't need to specify "rgb" in the compatible string since most
> >>>>>> simple VGA DACs can only work with an RGB input.
> >>>>>
> >>>>> Ok.
> >>>>>
> >>>>>> - Also, with "dac" specified in the string, we don't need to
> >>>>>> specifically mention "bridge" in the string. Also, bridge is a drm
> >>>>>> specific term.
> >>>>>>
> >>>>>> - "simple" is considered because it's an unconfigurable bridge, and
> >>>>>> it might be misleading for other VGA DACs to not use "vga-dac".
> >>>>>
> >>>>> All those "simple" bindings are just the biggest lie we ever
> >>>>> told. It's simple when you introduce it, and then grows into something
> >>>>> much more complicated than a non-simple implementation.
> >>>>
> >>>> "simple" here is supposed to mean that it's an unconfigurable RGB to
> >>>> VGA DAC. This isn't supposed to follow the simple-panel model, where
> >>>> you add the "simple-panel" string in the compatible node, along with
> >>>> you chip specific compatible string.
> >>>
> >>> I agree with Maxime, I don't like the word "simple". My preference would
> >>> be "vga-dac" for a lack of a better qualifier than "simple" to describe
> >>> the fact that the device requires no configuration. My only concern with
> >>> "vga-dac" is that we would restrict usage of that compatible string for
> >>> a subset of VGA DACs, with more complex devices not being compatible
> >>> with "vga-dac" even though they are VGA DACs. That's a problem I can
> >>> live with though.
> >>
> >> While we're bikeshedding (feel free to ignore my input on this), I
> >> think Maxime's initial "dumb" qualifier was better than "simple".
> >
> > I think I agree.
> >
> >> I think "passive" also gets the point across better than "simple", which
> >> we've already established as something else in drm.
> >
> > To my electrical engineer's ear, passive refers to a component or
> > combination of components that is not capable of power gain. The
> > resistors ladder VGA DAC that Maxime is trying to support is a passive
> > system, but the ADV7123 VGA DAC that equally requires no configuration is
> > an active component.
>
> If no one has any more objections within the next day, I'll pull in
> Maxime's v5 RGB to VGA bridge driver,
I'm testing the patch with rcar-du-drm and will provide results today.
> and change the compatible to "dumb-vga-dac".
Feel free to ignore the bikeshedding, but "transparent" could be a candidate
to replace "dumb" (either as "vga-dac-transparent" or "transparent-vga-dac").
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-10-07 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f39e907c-424f-7572-f88e-5dd0b6009631@codeaurora.org>
On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
>
>
> On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
> >Hi Sean,
> >
> >On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
> >>On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
> >>>On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
> >>>>On 10/06/2016 12:51 PM, Maxime Ripard wrote:
> >>>>>On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
> >>>>>>On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> >>>>>>>Some boards have an entirely passive RGB to VGA bridge, based on
> >>>>>>>either DACs or resistor ladders.
> >>>>>>>
> >>>>>>>Those might or might not have an i2c bus routed to the VGA connector
> >>>>>>>in order to access the screen EDIDs.
> >>>>>>>
> >>>>>>>Add a bridge that doesn't do anything but expose the modes available
> >>>>>>>on the screen, either based on the EDIDs if available, or based on
> >>>>>>>the XGA standards.
> >>>>>>>
> >>>>>>>Acked-by: Rob Herring <robh@kernel.org>
> >>>>>>>Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>>>>>>---
> >>>>>>>.../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
> >>>>>>>drivers/gpu/drm/bridge/Kconfig | 7 +
> >>>>>>>drivers/gpu/drm/bridge/Makefile | 1 +
> >>>>>>>drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++
> >>>>>>>4 files changed, 285 insertions(+)
> >>>>>>>create mode 100644
> >>>>>>>Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.tx
> >>>>>>>t
> >>>>>>>create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> >>>>>>>
> >>>>>>>diff --git
> >>>>>>>a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> >>>>>>>txt
> >>>>>>>b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> >>>>>>>txt
> >>>>>>>new file mode 100644
> >>>>>>>index 000000000000..a8375bc1f9cb
> >>>>>>>--- /dev/null
> >>>>>>>+++
> >>>>>>>b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> >>>>>>>tx
> >>>>>>>t @@ -0,0 +1,48 @@
> >>>>>>>+Dumb RGB to VGA bridge
> >>>>>>>+----------------------
> >>>>>>>+
> >>>>>>>+This binding is aimed for dumb RGB to VGA bridges that do not
> >>>>>>>require
> >>>>>>>+any configuration.
> >>>>>>>+
> >>>>>>>+Required properties:
> >>>>>>>+
> >>>>>>>+- compatible: Must be "rgb-to-vga-bridge"
> >>>>>>
> >>>>>>I'd talked to Laurent on IRC if he's okay with this. And I guess you
> >>>>>>to had discussed it during XDC too. He's suggested that it'd be better
> >>>>>>to have the compatible string as "simple-vga-dac".
> >>>>>
> >>>>>I just wished this bikeshedding had taken place publicly and be
> >>>>>actually part of that discussion, but yeah, ok.
> >>>>
> >>>>Sorry about that. I'd pinged him for an Ack, the discussion went
> >>>>more than that :)
> >>>>
> >>>>>>Some of the reasons behind having this:
> >>>>>>
> >>>>>>- We don't need to specify "rgb" in the compatible string since most
> >>>>>>simple VGA DACs can only work with an RGB input.
> >>>>>
> >>>>>Ok.
> >>>>>
> >>>>>>- Also, with "dac" specified in the string, we don't need to
> >>>>>>specifically mention "bridge" in the string. Also, bridge is a drm
> >>>>>>specific term.
> >>>>>>
> >>>>>>- "simple" is considered because it's an unconfigurable bridge, and it
> >>>>>>might be misleading for other VGA DACs to not use "vga-dac".
> >>>>>
> >>>>>All those "simple" bindings are just the biggest lie we ever
> >>>>>told. It's simple when you introduce it, and then grows into something
> >>>>>much more complicated than a non-simple implementation.
> >>>>
> >>>>"simple" here is supposed to mean that it's an unconfigurable RGB to
> >>>>VGA DAC. This isn't supposed to follow the simple-panel model, where
> >>>>you add the "simple-panel" string in the compatible node, along with
> >>>>you chip specific compatible string.
> >>>
> >>>I agree with Maxime, I don't like the word "simple". My preference would
> >>>be "vga-dac" for a lack of a better qualifier than "simple" to describe
> >>>the fact that the device requires no configuration. My only concern with
> >>>"vga-dac" is that we would restrict usage of that compatible string for a
> >>>subset of VGA DACs, with more complex devices not being compatible with
> >>>"vga-dac" even though they are VGA DACs. That's a problem I can live with
> >>>though.
> >>
> >>While we're bikeshedding (feel free to ignore my input on this), I
> >>think Maxime's initial "dumb" qualifier was better than "simple".
> >
> >I think I agree.
> >
> >>I think "passive" also gets the point across better than "simple", which
> >>we've already established as something else in drm.
> >
> >To my electrical engineer's ear, passive refers to a component or combination
> >of components that is not capable of power gain. The resistors ladder VGA DAC
> >that Maxime is trying to support is a passive system, but the ADV7123 VGA DAC
> >that equally requires no configuration is an active component.
>
> If no one has any more objections within the next day, I'll pull in
> Maxime's v5 RGB to VGA bridge driver, and change the compatible to
> "dumb-vga-dac".
That works for me. You'll probably want to update the Kconfig and file
name to match though.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/cac9efa7/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 0/5] Add runtime PM support for clocks (on Exynos SoC example)
From: Marek Szyprowski @ 2016-10-07 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57F6926F.1070707@math.uni-bielefeld.de>
Hi Tobias,
On 2016-10-06 20:05, Tobias Jakobi wrote:
> Hello Marek,
>
> I'm using the patches from the v4.8-clocks-pm-v2 branch plus the ones
> from the v4.8-clocks-pm-v2 branch on top of 4.8.0.
>
> I see some warnings on boot coming from driver core. It appears that the
> warnings are actually meaningful, since IOMMUs stop working completly.
> E.g. if I modprobe s5p-mfc later, firmware loading fails because
> apparantly the IOMMU domain isn't online.
>
>> WARNING: CPU: 0 PID: 1 at drivers/base/core.c:356 device_links_driver_bound+0x124/0x12c
> I added some debug printk() to device_links_driver_bound(), to show the
> link status. Apparantly it is always DEVICE_LINK_AVAILABLE.
Please note that some additional patches are needed to get IOMMU working
properly with both runtime-pm patches and deferred probe, which feature
in turn is needed to get it working after adding clocks-pm changes. I
will send such patch soon (as a new version of IOMMU deferred probe
support patches were posted a few days ago).
> (...)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 7/9] ARM: sunxi: Remove useless allwinner,drive property
From: Maxime Ripard @ 2016-10-07 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65SmZqR-MJgNxa0RGUYyWgeLHQcQfa0b8U0XiEtp+RfBg@mail.gmail.com>
On Tue, Oct 04, 2016 at 10:34:39AM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 3, 2016 at 6:21 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The allwinner,drive property set to 10mA was really considered as our
> > default. Remove all those properties entirely to make that obvious.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Did you use sed or some other scripting tool to do this patch?
> Including the command should make it easier to verify the result,
> instead of having to go through the 93 files here.
Yeah, I used some dumb sed commands.
Unfortunately, it disappeared from my history, but given my sed-fu, it
was pretty trivial, just a succession of
sed -i 'd/SUN4I_PINCTRL_10_MA' *.dtsi
Something along those lines, and pretty much the same thing for the
next patches.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/4122b19e/attachment-0001.sig>
^ permalink raw reply
* [PATCH 6/9] dt-bindings: pinctrl: Deprecate sunxi pinctrl bindings
From: Maxime Ripard @ 2016-10-07 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67wk_DANTyzaxTM6Stgh-u2kZXn_kjb0vbWDYUd-DUxGA@mail.gmail.com>
On Tue, Oct 04, 2016 at 10:32:12AM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 3, 2016 at 6:21 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The generic pin configuration and multiplexing should be preferred now,
> > even though we still support the old one.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 5 +++++
> > 1 file changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > index 69617220c5d6..e8b7cf64fdf1 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > @@ -36,6 +36,11 @@ pins it needs, and how they should be configured, with regard to muxer
> > configuration, drive strength and pullups. If one of these options is
> > not set, its actual value will be unspecified.
> >
> > +This driver supports the generic pin multiplexing and configuration
> > +bindings.
>
> Should we list which options are supported? We don't support them all.
Yep, I'll add that.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/f1ab6c83/attachment.sig>
^ permalink raw reply
* [PATCH 4/9] pinctrl: sunxi: Deal with configless pins
From: Maxime Ripard @ 2016-10-07 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v654vv3B-OhHPgdLjsEOf0zPP=Ky1_+o=8mf9dZHMFjR-w@mail.gmail.com>
Hi,
On Tue, Oct 04, 2016 at 10:28:18AM +0800, Chen-Yu Tsai wrote:
> > if (sunxi_pctrl_has_drive_prop(node)) {
> > int drive = sunxi_pctrl_parse_drive_prop(node);
> > - if (drive < 0)
> > + if (drive < 0) {
> > + ret = -EINVAL;
>
> Why not just pass the error code returned from the parse function?
Yep, I'll change that.
> > - (*map)[i].type = PIN_MAP_TYPE_CONFIGS_GROUP;
> > - (*map)[i].data.configs.group_or_pin = group;
> > - (*map)[i].data.configs.configs = pinconfig;
> > - (*map)[i].data.configs.num_configs = configlen;
> > -
> > - i++;
> > + if (pinconfig) {
> > + (*map)[i].type = PIN_MAP_TYPE_CONFIGS_GROUP;
> > + (*map)[i].data.configs.group_or_pin = group;
> > + (*map)[i].data.configs.configs = pinconfig;
> > + (*map)[i].data.configs.num_configs = configlen;
> > + i++;
> > + }
> > }
> >
> > - *num_maps = nmaps;
> > + *num_maps = i;
>
> Thought: should we do a krealloc to shrink the array?
Yep, I'll make an additional patch to fix that.
>
> >
> > return 0;
> >
> > @@ -342,8 +357,13 @@ static void sunxi_pctrl_dt_free_map(struct pinctrl_dev *pctldev,
> > struct pinctrl_map *map,
> > unsigned num_maps)
> > {
> > + unsigned long *pinconfig;
> > +
> > /* All the maps have the same pin config, free only the first one */
> > - kfree(map[0].data.configs.configs);
> > + pinconfig = map[0].data.configs.configs;
> > + if (pinconfig)
> > + kfree(pinconfig);
>
> Passing NULL to kfree is allowed. (It becomes a no-op.)
> So you could leave this function alone.
And I'll change that as well.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/081df1b2/attachment.sig>
^ permalink raw reply
* [PATCH 6/9] ARM: dts: sun6i: Sort pinmux setting nodes
From: Maxime Ripard @ 2016-10-07 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-7-wens@csie.org>
On Fri, Oct 07, 2016 at 12:06:26AM +0800, Chen-Yu Tsai wrote:
> The pinmux setting nodes for the A31 were added out of alphabetical
> order. Sort them.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, 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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/6ea12fe3/attachment.sig>
^ permalink raw reply
* [PATCH 4/9] drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
From: Maxime Ripard @ 2016-10-07 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-5-wens@csie.org>
Hi,
On Fri, Oct 07, 2016 at 12:06:24AM +0800, Chen-Yu Tsai wrote:
> The A31 TCON has mux controls for how TCON outputs are routed to the
> HDMI and MIPI DSI blocks.
>
> Since the A31s does not have MIPI DSI, it only has a mux for the HDMI
> controller input.
>
> This patch only adds support for the compatible strings. Actual support
> for the mux controls should be added with HDMI and MIPI DSI support.
Then let's add those fields then, having dead code and useless
variables is never a good option :)
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/265db26f/attachment-0001.sig>
^ permalink raw reply
* [PATCH 3/9] drm/sun4i: Put dotclock range into tcon quirks and check against them
From: Maxime Ripard @ 2016-10-07 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-4-wens@csie.org>
On Fri, Oct 07, 2016 at 12:06:23AM +0800, Chen-Yu Tsai wrote:
> In commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate") the
> driver was rounding the requested clock rate and then checking the
> result against the original requested rate.
>
> This does not work well for a number of reasons:
>
> - The pixel clock does not have enough resolution to be able to
> provide all sub-MHz clock rates. This makes it filter out most modes
> found in simple-panel.
>
> - When first introduced, the main limiting factors were the video PLL
> clock range (27 ~ 381 MHz) and the lowest divider (6). On sun6i and
> later, the valid PLL clock range is extended to 30 ~ 600 MHz. The
> PLL's multiplier and divider can make it go much higher out of range,
> but the clock driver currently has no checks for it.
>
> Since the limits are well known, we can hard code the range into the
> tcon driver, and check against them. And we really only care about the
> upper limit, which affects the highest resolutions we can support.
We already discussed this, but this is really the wrong way to fix
that issue.
clk_round_rate already gives you the maximum clock rate that can be
handled in a generic and abstracted way, disregarding the current
state of the clock driver.
However, the issue that you're trying to solve is that panels might
have a pixel clock requirement that is not aligned on the resolution
on the pixel clock we can generate.
And this can actually happen at any rate, you could very well have a
display that requires a pixel clock of 63501kHz that you would reject,
while using the 63,5 MHz clock rate would be just fine.
On the other hand, (totally made up example) some panel that requires
a pixel clock of 43MHz, with a +- 1MHz tolerance, that we wouldn't be
able to generate since we would only generate 41 or 45 MHz.
And on yet another hand, the panel might be requesting a pixel clock
well below what we can generate, which is also something that we want
to reject.
I can see two way of fixing this so far, the second being a solution
if the first one fails:
- Look to a decent amount of panels and bridges datasheet to see
what their usual tolerance on the pixel clock rate is, then use
that to make a decision.
- If there's not really a common tolerance that we can find out,
extend the panel and bridges API to be able for the panel to
provide its tolerance on the timings, and make a function that we
can call to see if a given rate is within boundaries.
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/a94a036f/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
From: Shawn Lin @ 2016-10-07 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18c0552c-10fa-a749-9777-9a99da9f275f@gmail.com>
? 2016/10/7 16:40, Pawe? Jarosz ??:
> Hi Shawn,
>
>
>>> +&mmc0 {
>>> + bus-width = <4>;
>>> + cap-mmc-highspeed;
>>> + cap-sd-highspeed;
>>> + mmc-pwrseq = <&mmc_pwrseq>;
>>
>> Removed this could make SD works?
>
> Yes but disabling bus-width causes sd performance decrease(defaults to
> 1?) so i'll leave this one.
I just pointed to the mmc-pwrseq, not for others properties :)
>
> Other sugestions will be included in v3.
>
> Thanks
>
> Pawe?.
>
>
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH] ARM: dts: fix the SD card on the Snowball
From: Linus Walleij @ 2016-10-07 8:52 UTC (permalink / raw)
To: linux-arm-kernel
This fixes a very annoying regression on the Snowball SD card
that has been around for a while. It turns out that the device
tree does not configure the direction pins properly, nor sets
up the pins for the voltage converter properly at boot. Unless
all things are correctly set up, the feedback clock will not
work, and makes the driver spew messages in the console (but
it works, very slowly):
root at Ux500:/ mount /dev/mmcblk0p2 /mnt/
[ 9.953460] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[ 9.960296] mmcblk0: error -110 sending status command, retrying
[ 9.966461] mmcblk0: error -110 sending status command, retrying
[ 9.972534] mmcblk0: error -110 sending status command, aborting
Fix this by rectifying the device tree to correspond to that of
the Ux500 HREF boards plus the DAT31DIR setting that is unique for
the Snowball, and things start working smoothly. Add in the SDR12
and SDR25 modes which this host can do without any problems.
I don't know if this has ever been correct, sadly. It works after
this patch.
Cc: stable at vger.kernel.org
Reported-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please apply this directly for fixes.
---
arch/arm/boot/dts/ste-snowball.dts | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ste-snowball.dts b/arch/arm/boot/dts/ste-snowball.dts
index b3df1c60d465..386eee6de232 100644
--- a/arch/arm/boot/dts/ste-snowball.dts
+++ b/arch/arm/boot/dts/ste-snowball.dts
@@ -239,14 +239,25 @@
arm,primecell-periphid = <0x10480180>;
max-frequency = <100000000>;
bus-width = <4>;
+ cap-sd-highspeed;
cap-mmc-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ /* All direction control is used */
+ st,sig-dir-cmd;
+ st,sig-dir-dat0;
+ st,sig-dir-dat2;
+ st,sig-dir-dat31;
+ st,sig-pin-fbclk;
+ full-pwr-cycle;
vmmc-supply = <&ab8500_ldo_aux3_reg>;
vqmmc-supply = <&vmmci>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&sdi0_default_mode>;
pinctrl-1 = <&sdi0_sleep_mode>;
- cd-gpios = <&gpio6 26 GPIO_ACTIVE_LOW>; // 218
+ /* GPIO218 MMC_CD */
+ cd-gpios = <&gpio6 26 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -549,7 +560,7 @@
/* VMMCI level-shifter enable */
snowball_cfg3 {
pins = "GPIO217_AH12";
- ste,config = <&gpio_out_lo>;
+ ste,config = <&gpio_out_hi>;
};
/* VMMCI level-shifter voltage select */
snowball_cfg4 {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
From: Paweł Jarosz @ 2016-10-07 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
Hi Shawn,
>> +&mmc0 {
>> + bus-width = <4>;
>> + cap-mmc-highspeed;
>> + cap-sd-highspeed;
>> + mmc-pwrseq = <&mmc_pwrseq>;
>
> Removed this could make SD works?
Yes but disabling bus-width causes sd performance decrease(defaults to
1?) so i'll leave this one.
Other sugestions will be included in v3.
Thanks
Pawe?.
^ permalink raw reply
* [PATCH 1/8] PM / Domains: Make genpd state allocation dynamic
From: Ulf Hansson @ 2016-10-07 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006205724.GA41480@linaro.org>
On 6 October 2016 at 22:57, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Thu, Oct 06 2016 at 13:45 -0600, Ulf Hansson wrote:
>>
>> On 6 October 2016 at 17:40, Lina Iyer <lina.iyer@linaro.org> wrote:
>>>
>>> On Thu, Oct 06 2016 at 02:37 -0600, Ulf Hansson wrote:
>>>>
>>>>
>>>> On 5 October 2016 at 22:31, Lina Iyer <lina.iyer@linaro.org> wrote:
>>>>>
>>>>>
>>>>> Allow PM Domain states to be defined dynamically by the drivers. This
>>>>> removes the limitation on the maximum number of states possible for a
>>>>> domain.
>>>>>
>>>>> Cc: Axel Haslam <ahaslam+renesas@baylibre.com>
>>>>> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>>
>>>
>>> <...>
>>>>>
>>>>>
>>>>> -#define GENPD_MAX_NUM_STATES 8 /* Number of possible low power
>>>>> states
>>>>> */
>>>>> -
>>>>> enum gpd_status {
>>>>> GPD_STATE_ACTIVE = 0, /* PM domain is active */
>>>>> GPD_STATE_POWER_OFF, /* PM domain is off */
>>>>> @@ -70,7 +68,7 @@ struct generic_pm_domain {
>>>>> void (*detach_dev)(struct generic_pm_domain *domain,
>>>>> struct device *dev);
>>>>> unsigned int flags; /* Bit field of configs for
>>>>> genpd
>>>>> */
>>>>> - struct genpd_power_state states[GENPD_MAX_NUM_STATES];
>>>>> + struct genpd_power_state *states;
>>>>> unsigned int state_count; /* number of states */
>>>>> unsigned int state_idx; /* state that genpd will go to when off
>>>>> */
>>>>>
>>>>> --
>>>>> 2.7.4
>>>>>
>>>>
>>>> In general I like the improvement, but..
>>>>
>>>> This change implies that ->states may very well be NULL. This isn't
>>>> validated by genpd's internal logic when power off/on the domain
>>>> (genpd_power_on|off(), __default_power_down_ok()). You need to fix
>>>> this, somehow.
>>>>
>>> Good point.
>>>
>>>> Perhaps the easiest solutions is, when pm_genpd_init() finds that
>>>> ->state is NULL, that we allocate a struct genpd_power_state with
>>>> array size of 1 and assign it to ->states. Although, doing this also
>>>> means you need to track that genpd was responsible for the the
>>>> allocation, so it must also free the data from within genpd_remove().
>>>>
>>>> Unless you have other ideas!?
>>>>
>>> I can think of some hacks, but they are uglier than the problem we are
>>> trying to solve. We could drop this patch. Real world situations would
>>> not have more than 8 states and if there is one, we can think about it
>>> then.
>>
>>
>> The problem with the current approach is that we waste some memory as
>> we always have an array of 8 states per genpd. In the worst case,
>> which currently is the most common case, only 1 out of 8 states is
>> being used.
>>
>> So, let's not be lazy here and instead take the opportunity to fix
>> this, and especially I think this makes sense, before we go on and add
>> the DT parsing of the domain-idle-states.
>>
> Hmm.. We are not wasting much memory in comparison, but if you insist,
> sure.
>
>> The more sophisticated method would probably be to use kobject/kref,
>> but let's not go there for now. Instead let's try an easy method of
>> just tracking whether the allocations had been made internally by
>> genpd, via adding a "bool state_allocated to the struct
>> generic_pm_domain. Would that work?
>>
> It would work.
>
> i.
> How about an additional static state by default in the domain structure,
> if the platform does not provide a state then the default structure is
> used. That way we dont have to track it. But it does waste memory
> eqivalent to a state, when there are states provided by the platform.
I thought about this, but I think it could be a bit messy as well.
Better to do an allocation when needed.
>
> ii.
> I could add a void *free to the domain structure and save the memory
> allocated by default in the *free. At domain remove, we just do a kfree
> on free.
>
> iii.
> Use a boolean flag.
Both ii) and iii) works for me!
Kind regards
Uffe
>
> Thanks,
> Lina
>
^ permalink raw reply
* [PATCH 2/9] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
From: Maxime Ripard @ 2016-10-07 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-3-wens@csie.org>
Hi,
On Fri, Oct 07, 2016 at 12:06:22AM +0800, Chen-Yu Tsai wrote:
> +struct sun4i_tcon_quirks {
> + bool is_sun5i; /* sun5i has undocumented mux */
> + bool has_channel_1; /* a33 does not have channel 1 */
> + bool has_bypass_src; /* has separate input bypassing CEU */
> + bool has_dma_src; /* has DMA input */
> +};
> +
I'd really prefer to keep the has_mux quirk name. is_sun5i doesn't
really relate to what we're doing there, is redundant with the
compatible, and render the other quirks name useless, since we could
just have is_sun.i quirks and deal with that (which is essentially
what we were doing before).
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: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/ea01852f/attachment.sig>
^ permalink raw reply
* [PATCH 00/14] ASoc: sunxi: Add Allwinner A33 codec driver
From: Icenowy Zheng @ 2016-10-07 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1475569400.git.mylene.josserand@free-electrons.com>
On Tue, 4 Oct 2016 11:46:13 +0200
Myl?ne Josserand <mylene.josserand@free-electrons.com> wrote:
> Hi everyone,
>
>
> This patchset add the audio codec for Allwinner A33 (sun8i) SoC.
>
> It adds different drivers:
> - sun8i-codec-analog (patch 4): This driver implements the analog
> part of the audio codec. The analog part is handled in PRCM registers
> so this driver must be added as prcm's subnode (patch 5).
> - sun8i-codec (patch 6): This driver implements the digital part
> of the A33 codec.
> - sun8i (patch 7): This driver implements a sound card for A33.
> It links the DAI and the audio codec. The analog codec driver is
> handled as an "aux_device".
>
> The DAI for this codec is the same than for A20: "sun4i-i2s".
> The digital codec code is coming from Allwinner's BSP (after some
> cleanup and DAPM conversion) [1]
> The analog codec driver is coming from Chen-Yu Tsai's driver [2]
> with some modifications (such as read/write regmap functions).
>
> Currently, all the drivers handle only the playback feature.
> The other ones (such as capture) and all other interfaces except
> headphone are not supported.
>
> These drivers are functional except for one issue. When playing a
> sound for the first time, a short delay can be noticed. On a second
> play (right after), the sound is played correctly. If we wait a short
> time (~5 sec), the delay is back.
> There is the same behavior for left/right channel. On the first
> time, a left sound is played on the left channel but in the second
> time, the sound will be played on wrong channel.
>
> These issues will be fixed in a second time. Is someone have
> suggestions about it?
>
> Examples of amixer commands:
> amixer set 'Headphone' 75%
> amixer set 'Headphone' on
> amixer set 'DAC' on
> amixer set 'Right DAC Mixer RSlot 0' on
> amixer set 'Left DAC Mixer LSlot 0' on
> amixer set 'DAC Reversed Right' on
> amixer set 'DAC Reversed Left' on
>
> It was tested on Parrot and Sinlinx board where device tree's
> modifications are added (patch 11 to 14).
I tested it on my iNet D978 Rev2 board (dts available in linux-next now)
Directly output audio from mpg123 to the audio codec failed, with
noises appear in the earphone. (And the mpg123 process terminated very
fast, seems that the bitrate become wrong)
However, paplay works well with the decoded wav file, and ```mpg123 -o
pulse``` works properly.
>
> Thank you in advance,
> Best regards,
>
> [1]:
> https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/audiocodec/sun8iw5_sndcodec.c
> [2]: https://github.com/wens/linux/tree/a31-audio
>
> Myl?ne Josserand (14):
> dma: sun6i-dma: Add burst case of 4
> clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig
> ASoC: sun4i-i2s: Add apb reset
> ASoC: Add sun8i analog codec driver
> mfd: sun6i-prcm: Add sun8i analog codec as subnode
> ASoC: Add sun8i digital audio codec
> ASoC: Add sun8i audio card
> dt-bindings: sound: Add sun8i analog codec documentation
> dt-bindings: sound: Add sun8i codec documentation
> dt-bindings: sound: Add sun8i audio card documentation
> ARM: dts: sun8i: Add analog codec on prcm node
> ARM: dts: sun8i: Add audio codec, dai and card for A33
> ARM: dts: sun8i: parrot: Enable audio nodes
> ARM: dts: sun8i: sinlinx: Enable audio nodes
>
> .../devicetree/bindings/sound/sun8i-audio.txt | 17 +
> .../bindings/sound/sun8i-codec-analog.txt | 20 +
> .../devicetree/bindings/sound/sun8i-codec.txt | 24 +
> arch/arm/boot/dts/sun8i-a23-a33.dtsi | 7 +
> arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 8 +
> arch/arm/boot/dts/sun8i-a33.dtsi | 33 ++
> arch/arm/boot/dts/sun8i-r16-parrot.dts | 8 +
> drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +-
> drivers/dma/sun6i-dma.c | 2 +
> drivers/mfd/sun6i-prcm.c | 16 +
> sound/soc/sunxi/Kconfig | 30 ++
> sound/soc/sunxi/Makefile | 3 +
> sound/soc/sunxi/sun4i-i2s.c | 16 +-
> sound/soc/sunxi/sun8i-codec-analog.c | 305
> +++++++++++++ sound/soc/sunxi/sun8i-codec.c |
> 492 +++++++++++++++++++++
> sound/soc/sunxi/sun8i.c | 101 +++++ 16
> files changed, 1082 insertions(+), 2 deletions(-) create mode 100644
> Documentation/devicetree/bindings/sound/sun8i-audio.txt create mode
> 100644 Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
> create mode 100644
> Documentation/devicetree/bindings/sound/sun8i-codec.txt create mode
> 100644 sound/soc/sunxi/sun8i-codec-analog.c create mode 100644
> sound/soc/sunxi/sun8i-codec.c create mode 100644
> sound/soc/sunxi/sun8i.c
>
^ permalink raw reply
* [PATCH v3 03/11] ARM: shmobile: r8a7743: basic SoC support
From: Laurent Pinchart @ 2016-10-07 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161007031537.GK13721@verge.net.au>
Hi Simon,
On Friday 07 Oct 2016 12:15:37 Simon Horman wrote:
> On Thu, Oct 06, 2016 at 12:37:08AM +0300, Sergei Shtylyov wrote:
> > Add minimal support for the RZ/G1M (R8A7743) SoC.
> >
> > Based on the original (and large) patch by Dmitry Shifrin
> > <dmitry.shifrin@cogentembedded.com>.
> >
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks, I have queued this up.
I'd like to see this patch rebased on top of "[PATCH] ARM: shmobile:
Consolidate R8A779[234] machine definitions".
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] ARM: shmobile: Consolidate R8A779[234] machine definitions
From: Laurent Pinchart @ 2016-10-07 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVVE2N20zmCddy6Y2mMBf4zk0u=WfQ3Sa1e_ASOf5zO_Q@mail.gmail.com>
Hi Geert,
On Friday 07 Oct 2016 09:43:53 Geert Uytterhoeven wrote:
> On Wed, Oct 5, 2016 at 12:31 PM, Laurent Pinchart wrote:
> > The three SoCs use the exact same machine definition, consolidate them
> > into a single one.
>
> Thanks for your patch!
>
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks.
> I'm wondering if we can improve upon...
I think we can. Your points below are valid, patches are welcome ;-)
> > --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> > +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> > @@ -203,3 +204,22 @@ void __init rcar_gen2_reserve(void)
> > }
> > #endif
> > }
> > +
> > +static const char * const rcar_gen2_boards_compat_dt[] __initconst = {
> > + /*
> > + * R8A7790 and R8A7791 can't be handled here as long as they need
> > SMP
> > + * initialization fallback.
> > + */
> > + "renesas,r8a7792",
> > + "renesas,r8a7793",
> > + "renesas,r8a7794",
> > + NULL,
> > +};
> > +
> > +DT_MACHINE_START(RCAR_GEN2_DT, "Generic Gen2 (Flattened Device Tree)")
> > + .init_early = shmobile_init_delay,
>
> shmobile_init_delay() is not really Renesas-specific, but ARM-specific.
> This is just to avoid calibrating the delay loop?
>
> > + .init_late = shmobile_init_late,
>
> This calls only into shmobile_suspend_init(), which is also not
> Renesas-specific.
>
> > + .init_time = rcar_gen2_timer_init,
>
> This is about fixing up the ARM Arch timer, and initializing clocks as we
> need to pass the mode pin state (ugh, will hopefully go away soon).
>
> > + .reserve = rcar_gen2_reserve,
>
> Reserving a block for CMA DMA is also not really Renesas-specific.
>
> > + .dt_compat = rcar_gen2_boards_compat_dt,
> > +MACHINE_END
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
Enable the sun8i-emac driver in the multi_v7 default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 5845910..f44d633 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
CONFIG_VIRTIO_NET=y
CONFIG_HIX5HD2_GMAC=y
CONFIG_SUN4I_EMAC=y
+CONFIG_SUN8I_EMAC=y
CONFIG_MACB=y
CONFIG_BCMGENET=m
CONFIG_SYSTEMPORT=m
--
2.7.3
^ 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