Re: [PATCH v9 6/6] clk: samsung: remove unused clock aliases and update clock flags
Quoting Thomas Abraham (2014-07-30 01:07:43)
> With some of the Exynos SoCs switched over to use the generic CPUfreq drivers,
> the unused clock aliases can be removed. In addition to this, the individual
> clock blocks which are now encapsulated with the consolidate CPU clock type
> can now be marked with read-only flags.
>
> Cc: Tomasz Figa
> Signed-off-by: Thomas Abraham
Acked-by: Mike Turquette
> ---
> drivers/clk/samsung/clk-exynos4.c| 48
> +-
> drivers/clk/samsung/clk-exynos5250.c | 19 --
> drivers/clk/samsung/clk-exynos5420.c | 27 ---
> 3 files changed, 53 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c
> b/drivers/clk/samsung/clk-exynos4.c
> index 101f549..04619a1 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -578,7 +578,8 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
> __initdata = {
> MUX(0, "mout_fimd1", group1_p4210, E4210_SRC_LCD1, 0, 4),
> MUX(0, "mout_mipi1", group1_p4210, E4210_SRC_LCD1, 12, 4),
> MUX(CLK_SCLK_MPLL, "sclk_mpll", mout_mpll_p, SRC_CPU, 8, 1),
> - MUX(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1),
> + MUX_F(CLK_MOUT_CORE, "mout_core", mout_core_p4210, SRC_CPU, 16, 1, 0,
> + CLK_MUX_READ_ONLY),
> MUX(0, "mout_hpm", mout_core_p4210, SRC_CPU, 20, 1),
> MUX(CLK_SCLK_VPLL, "sclk_vpll", sclk_vpll_p4210, SRC_TOP0, 8, 1),
> MUX(CLK_MOUT_FIMC0, "mout_fimc0", group1_p4210, SRC_CAM, 0, 4),
> @@ -714,15 +715,24 @@ static struct samsung_div_clock exynos4_div_clks[]
> __initdata = {
> DIV(0, "div_clkout_rightbus", "mout_clkout_rightbus",
> CLKOUT_CMU_RIGHTBUS, 8, 6),
>
> - DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
> - DIV(0, "div_corem0", "div_core2", DIV_CPU0, 4, 3),
> - DIV(0, "div_corem1", "div_core2", DIV_CPU0, 8, 3),
> - DIV(0, "div_periph", "div_core2", DIV_CPU0, 12, 3),
> - DIV(0, "div_atb", "mout_core", DIV_CPU0, 16, 3),
> - DIV(0, "div_pclk_dbg", "div_atb", DIV_CPU0, 20, 3),
> - DIV(CLK_ARM_CLK, "div_core2", "div_core", DIV_CPU0, 28, 3),
> - DIV(0, "div_copy", "mout_hpm", DIV_CPU1, 0, 3),
> - DIV(0, "div_hpm", "div_copy", DIV_CPU1, 4, 3),
> + DIV_F(0, "div_core", "mout_core", DIV_CPU0, 0, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(0, "div_corem0", "div_core2", DIV_CPU0, 4, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(0, "div_corem1", "div_core2", DIV_CPU0, 8, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(0, "div_periph", "div_core2", DIV_CPU0, 12, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(0, "div_atb", "mout_core", DIV_CPU0, 16, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(0, "div_pclk_dbg", "div_atb", DIV_CPU0, 20, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(CLK_ARM_CLK, "div_core2", "div_core", DIV_CPU0, 28, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(0, "div_copy", "mout_hpm", DIV_CPU1, 0, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> + DIV_F(0, "div_hpm", "div_copy", DIV_CPU1, 4, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> DIV(0, "div_clkout_cpu", "mout_clkout_cpu", CLKOUT_CMU_CPU, 8, 6),
>
> DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
> @@ -770,7 +780,8 @@ static struct samsung_div_clock exynos4_div_clks[]
> __initdata = {
> DIV(0, "div_spi_pre2", "div_spi2", DIV_PERIL2, 8, 8),
> DIV(0, "div_audio1", "mout_audio1", DIV_PERIL4, 0, 4),
> DIV(0, "div_audio2", "mout_audio2", DIV_PERIL4, 16, 4),
> - DIV(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
> + DIV_F(CLK_SCLK_APLL, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3,
> + CLK_GET_RATE_NOCACHE, CLK_DIVIDER_READ_ONLY),
> DIV_F(0, "div_mipi_pre0", "div_mipi0", DIV_LCD0, 20, 4,
> CLK_SET_RATE_PARENT, 0),
> DIV_F(0, "div_mmc_pre0", "div_mmc0", DIV_FSYS1, 8, 8,
> @@ -1187,17 +1198,10 @@ static struct samsung_gate_clock
> exynos4x12_gate_clks[] __initdata = {
> 0),
> };
>
> -static struct samsung_clock_alias exynos4_aliases[] __initdata = {
> +static struct samsung_clock_alias exynos4x12_aliases[] __initdata = {
> ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
> ALIAS(CLK_ARM_CLK, NULL, "armclk"),
> ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
> -};
> -
> -static struct samsung_clock_alias exynos4210_aliases[] __initdata = {
> - ALIAS(CLK_SCLK_MPLL, NULL, "mout_mpll"),
> -};
> -
> -static struct samsung_clock
Re: [PATCH v9 2/6] clk: samsung: add cpu clock configuration data and instantiate cpu clock
Quoting Thomas Abraham (2014-07-30 01:07:39)
> With the addition of the new Samsung specific cpu-clock type, the
> arm clock can be represented as a cpu-clock type. Add the CPU clock
> configuration data and instantiate the CPU clock type for Exynos4210,
> Exynos5250 and Exynos5420.
>
> Cc: Tomasz Figa
> Signed-off-by: Thomas Abraham
Acked-by: Mike Turquette
> ---
> drivers/clk/samsung/clk-exynos4.c | 15 +++
> drivers/clk/samsung/clk-exynos5250.c | 25 ++
> drivers/clk/samsung/clk-exynos5420.c | 45
>
> include/dt-bindings/clock/exynos5250.h |1 +
> include/dt-bindings/clock/exynos5420.h |2 ++
> 5 files changed, 88 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c
> b/drivers/clk/samsung/clk-exynos4.c
> index 8617f49..101f549 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -19,6 +19,7 @@
> #include
>
> #include "clk.h"
> +#include "clk-cpu.h"
>
> /* Exynos4 clock controller register offsets */
> #define SRC_LEFTBUS0x4200
> @@ -1355,6 +1356,16 @@ static struct samsung_pll_clock
> exynos4x12_plls[nr_plls] __initdata = {
> VPLL_LOCK, VPLL_CON0, NULL),
> };
>
> +static const struct exynos_cpuclk_cfg_data e4210_armclk_d[] __initconst = {
> + { 120, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 5), },
> + { 100, E4210_CPU_DIV0(7, 1, 4, 3, 7, 3), E4210_CPU_DIV1(0, 4), },
> + { 80, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
> + { 50, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
> + { 40, E4210_CPU_DIV0(7, 1, 3, 3, 7, 3), E4210_CPU_DIV1(0, 3), },
> + { 20, E4210_CPU_DIV0(0, 1, 1, 1, 3, 1), E4210_CPU_DIV1(0, 3), },
> + { 0 },
> +};
> +
> static void __init exynos4_core_down_clock(enum exynos4_soc soc)
> {
> unsigned int tmp;
> @@ -1458,6 +1469,10 @@ static void __init exynos4_clk_init(struct device_node
> *np,
> samsung_clk_register_fixed_factor(ctx,
> exynos4210_fixed_factor_clks,
> ARRAY_SIZE(exynos4210_fixed_factor_clks));
> + exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
> + mout_core_p4210[0], mout_core_p4210[1], 0x14200,
> + e4210_armclk_d, ARRAY_SIZE(e4210_armclk_d),
> + CLK_CPU_NEEDS_DEBUG_ALT_DIV | CLK_CPU_HAS_DIV1);
> } else {
> samsung_clk_register_mux(ctx, exynos4x12_mux_clks,
> ARRAY_SIZE(exynos4x12_mux_clks));
> diff --git a/drivers/clk/samsung/clk-exynos5250.c
> b/drivers/clk/samsung/clk-exynos5250.c
> index 70ec3d2..e19e365 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -19,6 +19,7 @@
> #include
>
> #include "clk.h"
> +#include "clk-cpu.h"
>
> #define APLL_LOCK 0x0
> #define APLL_CON0 0x100
> @@ -748,6 +749,26 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls]
> __initdata = {
> VPLL_LOCK, VPLL_CON0, NULL),
> };
>
> +static const struct exynos_cpuclk_cfg_data exynos5250_armclk_d[] __initconst
> = {
> + { 170, E5250_CPU_DIV0(5, 3, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
> + { 160, E5250_CPU_DIV0(4, 1, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
> + { 150, E5250_CPU_DIV0(4, 1, 7, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
> + { 140, E5250_CPU_DIV0(4, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
> + { 130, E5250_CPU_DIV0(3, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
> + { 120, E5250_CPU_DIV0(3, 1, 5, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
> + { 110, E5250_CPU_DIV0(3, 1, 5, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
> + { 100, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 90, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 80, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 70, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 60, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 50, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 40, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 30, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 20, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
> + { 0 },
> +};
> +
> static const struct of_device_id ext_clk_match[] __initconst = {
> { .compatible = "samsung,clock-xxti", .data = (void *)0, },
> { },
> @@ -797,6 +818,10 @@ static void __init exynos5250_clk_init(struct
> device_node *np)
> ARRAY_SIZE(exynos5250_div_clks));
> samsung_clk_register_gate(ctx, exynos5250_gate_clks,
> ARRAY
Re: [PATCH v9 1/6] clk: samsung: add infrastructure to register cpu clocks
Quoting Thomas Abraham (2014-07-30 01:07:38)
> The CPU clock provider supplies the clock to the CPU clock domain. The
> composition and organization of the CPU clock provider could vary among
> Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
> and gates. This patch defines a new clock type for CPU clock provider and
> adds infrastructure to register the CPU clock providers for Samsung
> platforms.
>
> Signed-off-by: Thomas Abraham
> Reviewed-by: Tomasz Figa
Acked-by: Mike Turquette
> ---
> drivers/clk/samsung/Makefile |2 +-
> drivers/clk/samsung/clk-cpu.c | 335
> +
> drivers/clk/samsung/clk-cpu.h | 91 +++
> 3 files changed, 427 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/samsung/clk-cpu.c
> create mode 100644 drivers/clk/samsung/clk-cpu.h
>
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index 6fb4bc6..8909c93 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -2,7 +2,7 @@
> # Samsung Clock specific Makefile
> #
>
> -obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
> +obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o clk-cpu.o
> obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o
> obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
> diff --git a/drivers/clk/samsung/clk-cpu.c b/drivers/clk/samsung/clk-cpu.c
> new file mode 100644
> index 000..009a21b
> --- /dev/null
> +++ b/drivers/clk/samsung/clk-cpu.c
> @@ -0,0 +1,335 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * Author: Thomas Abraham
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This file contains the utility function to register CPU clock for Samsung
> + * Exynos platforms. A CPU clock is defined as a clock supplied to a CPU or a
> + * group of CPUs. The CPU clock is typically derived from a hierarchy of
> clock
> + * blocks which includes mux and divider blocks. There are a number of other
> + * auxiliary clocks supplied to the CPU domain such as the debug blocks and
> AXI
> + * clock for CPU domain. The rates of these auxiliary clocks are related to
> the
> + * CPU clock rate and this relation is usually specified in the hardware
> manual
> + * of the SoC or supplied after the SoC characterization.
> + *
> + * The below implementation of the CPU clock allows the rate changes of the
> CPU
> + * clock and the corresponding rate changes of the auxillary clocks of the
> CPU
> + * domain. The platform clock driver provides a clock register configuration
> + * for each configurable rate which is then used to program the clock
> hardware
> + * registers to acheive a fast co-oridinated rate change for all the CPU
> domain
> + * clocks.
> + *
> + * On a rate change request for the CPU clock, the rate change is propagated
> + * upto the PLL supplying the clock to the CPU domain clock blocks. While the
> + * CPU domain PLL is reconfigured, the CPU domain clocks are driven using an
> + * alternate clock source. If required, the alternate clock source is divided
> + * down in order to keep the output clock rate within the previous OPP
> limits.
> +*/
> +
> +#include
> +#include "clk-cpu.h"
> +
> +#define E4210_SRC_CPU 0x0
> +#define E4210_STAT_CPU 0x200
> +#define E4210_DIV_CPU0 0x300
> +#define E4210_DIV_CPU1 0x304
> +#define E4210_DIV_STAT_CPU00x400
> +#define E4210_DIV_STAT_CPU10x404
> +
> +#define E4210_DIV0_RATIO0_MASK 0x7
> +#define E4210_DIV1_HPM_MASK(0x7 << 4)
> +#define E4210_DIV1_COPY_MASK (0x7 << 0)
> +#define E4210_MUX_HPM_MASK (1 << 20)
> +#define E4210_DIV0_ATB_SHIFT 16
> +#define E4210_DIV0_ATB_MASK(DIV_MASK << E4210_DIV0_ATB_SHIFT)
> +
> +#define MAX_DIV8
> +#define DIV_MASK 7
> +#define DIV_MASK_ALL 0x
> +#define MUX_MASK 7
> +
> +/*
> + * Helper function to wait until divider(s) have stabilized after the divider
> + * value has changed.
> + */
> +static void wait_until_divider_stable(void __iomem *div_reg, unsigned long
> mask)
> +{
> + unsigned long timeout = jiffies + msecs_to_jiffies(10);
> +
> + do {
> + if (!(readl(div_reg) & mask))
> + return;
> + } while (time_before(jiffies, timeout));
> +
> + pr_err("%s: timeout in divider stablization\n", __func__);
> +}
> +
> +/*
> + * Helper function to wait until mux has stabilized after the mux selection
> + * value was changed.
> + */
> +static void wait_until_mux_stable(void __iomem *mux_reg, u32 mux_pos,
> + unsigned long mux_value)
> +{
> + unsigned long timeout = jiffies + msecs_to_jiffies(10);
> +
> + do {
> + i
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Monday 01 September 2014 17:04:26 Lee Jones wrote:
> On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > Maybe I'm misreading the patch, but I don't see how it creates a
> > migration path. What I want to end up with is infrastructure that
> > lets anybody call syscon_regmap_lookup_by_pdevname or
> > syscon_regmap_lookup_by_compatible (if they really need to)
> > without needing the platform_driver for syscon. That should not
> > require any form of compatibility layer because to the driver
> > using it there is no API change.
>
> Somehow I think the likelyhood is that I am misreading the patch.
>
> I thought that before this patch drivers we had to register a syscon
> device to bind to this driver, which was fine for the first use-cases
> of syscon as it wasn't required too early during boot. However, now
> there are use-cases where systems require access to syscon registers
> eariler in boot we require a means to obtain access prior to device
> probing. I thought this patch not only provides that possibilty, but
> also leaves in the ability to register direct from DT.
Right, it does provide the ability to have syscon before devices
are registered, I missed that part.
> > In contrast, this patch introduces a new of_syscon_{un,}register()
> > interface that would get removed after the the above has
> > been implemented, causing extra churn for any driver that also
> > wants to provide a regmap-like interface.
>
> When will we ever not have to register syscon?
The idea is that we implicitly register the syscon block when someone
calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle
and then return a reference to that new syscon. When another driver
looks up the same device node, we just pass a reference to the existing
syscon.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> On Monday 01 September 2014 12:25:49 Lee Jones wrote:
> > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > > On Monday 01 September 2014 08:49:18 Lee Jones wrote:
> > > > On Fri, 22 Aug 2014, Pankaj Dubey wrote:
> > > >
> > > > > From: Tomasz Figa
> > > > >
> > > > > Currently a syscon entity can be only registered directly through a
> > > > > platform device that binds to a dedicated driver. However in certain
> > > > > use
> > > > > cases it is desirable to make a device used with another driver a
> > > > > syscon
> > > > > interface provider. For example, certain SoCs (e.g. Exynos) contain
> > > > > system controller blocks which perform various functions such as power
> > > > > domain control, CPU power management, low power mode control, but in
> > > > > addition contain certain IP integration glue, such as various signal
> > > > > masks, coprocessor power control, etc. In such case, there is a need
> > > > > to
> > > > > have a dedicated driver for such system controller but also share
> > > > > registers with other drivers. The latter is where the syscon interface
> > > > > is helpful.
> > > > >
> > > > > This patch decouples syscon object from syscon driver, so that it can
> > > > > be
> > > > > registered from any driver in addition to the original "syscon"
> > > > > platform
> > > > > driver.
> > > > >
> > > > > Signed-off-by: Tomasz Figa
> > > > > Signed-off-by: Pankaj Dubey
> > > > > ---
> > > > >
> > > > > RFC patch [1] was posted by Tomasz Figa. This patch addresses some of
> > > > > comments given by Arnd to RFC patch, and further decouples syscon from
> > > > > device model. It also gives flexibility of registering with syscon at
> > > > > early stage using device_node object.
> > > >
> > > > It would be helpful if Arnd gave this revision his blessing (Ack).
> > >
> > > I never saw a reason why we don't take this all the way as discussed
> > > a few times: Completely remove the dependency of syscon on having
> > > a platform driver for it, and make it possible to just call
> > > syscon_regmap_lookup_by_phandle() without having to register
> > > it first.
> >
> > I think this sounds like a good end-state. Migrating over by
> > supporting both methods in this way does sound like the correct thing
> > to do though. Doing so is likely to dramatically reduce the effect on
> > current users.
>
> Maybe I'm misreading the patch, but I don't see how it creates a
> migration path. What I want to end up with is infrastructure that
> lets anybody call syscon_regmap_lookup_by_pdevname or
> syscon_regmap_lookup_by_compatible (if they really need to)
> without needing the platform_driver for syscon. That should not
> require any form of compatibility layer because to the driver
> using it there is no API change.
Somehow I think the likelyhood is that I am misreading the patch.
I thought that before this patch drivers we had to register a syscon
device to bind to this driver, which was fine for the first use-cases
of syscon as it wasn't required too early during boot. However, now
there are use-cases where systems require access to syscon registers
eariler in boot we require a means to obtain access prior to device
probing. I thought this patch not only provides that possibilty, but
also leaves in the ability to register direct from DT.
> In contrast, this patch introduces a new of_syscon_{un,}register()
> interface that would get removed after the the above has
> been implemented, causing extra churn for any driver that also
> wants to provide a regmap-like interface.
When will we ever not have to register syscon?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: Tomasz has moved
Quoting Linus Walleij (2014-08-29 05:18:15) > On Tue, Aug 26, 2014 at 4:30 PM, Tomasz Figa wrote: > > > I am leaving Samsung, so my current e-mail address is not going to work > > any longer. Replace it with my private one. In addition, Sylwester > > Nawrocki is being added as co-maintainer for Samsung clock drivers to > > take some of the responsibilities, as I will be doing my part in my spare > > time. > > > > Signed-off-by: Tomasz Figa > > OK I'm taking this patch through pinctrl fixes. Not much controversy > here, Mike you need not worry about it. Ack. Regards, Mike > > Patch applied. > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] dt-bindings: clk: samsung: Document the DMC domain of Exynos3250 CMU
Document the new compatible for clock ins DMC (Dynamic Memory
Controller) domain of Exynos3250 Clock Management Unit (CMU).
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/clock/exynos3250-clock.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
index aadc9c59e2d1..f57d9dd9ea85 100644
--- a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -7,6 +7,8 @@ Required Properties:
- compatible: should be one of the following.
- "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
+ - "samsung,exynos3250-cmu-dmc" - controller compatible with
+Exynos3250 SoC for Dynamic Memory Controller domain.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -20,7 +22,7 @@ All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos3250.h header and can be used in device
tree sources.
-Example 1: An example of a clock controller node is listed below.
+Example 1: Examples of clock controller nodes are listed below.
cmu: clock-controller@1003 {
compatible = "samsung,exynos3250-cmu";
@@ -28,6 +30,12 @@ Example 1: An example of a clock controller node is listed
below.
#clock-cells = <1>;
};
+ cmu_dmc: clock-controller@105C {
+ compatible = "samsung,exynos3250-cmu-dmc";
+ reg = <0x105C 0x2000>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: exynos3250: Add CMU node for DMC domain clocks
Add CMU (Clock Management Unit) node for DMC (Dynamic Memory Controller)
domain clocks on Exynos3250.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 429a6c6cfcf9..8c3a9cc0a4d1 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -163,6 +163,12 @@
#clock-cells = <1>;
};
+ cmu_dmc: clock-controller@105C {
+ compatible = "samsung,exynos3250-cmu-dmc";
+ reg = <0x105C 0x2000>;
+ #clock-cells = <1>;
+ };
+
rtc: rtc@1007 {
compatible = "samsung,exynos3250-rtc";
reg = <0x1007 0x100>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] clk: samsung: exynos3250: Register DMC clk provider
Add clock provider for clocks in DMC domain including EPLL and BPLL. The
DMC clocks are necessary for Exynos3 devfreq driver.
The DMC clock domain uses different address space (0x105C) than
standard clock domain (0x1003 - 0x1005). The difference is huge
enough to add new DT node for the clock provider, rather than extending
existing address space.
Signed-off-by: Krzysztof Kozlowski
---
drivers/clk/samsung/clk-exynos3250.c | 194 +
include/dt-bindings/clock/exynos3250.h | 27 +
2 files changed, 221 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index dc85f8e7a2d7..6cda52031b30 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -110,6 +110,12 @@ enum exynos3250_plls {
nr_plls
};
+/* list of PLLs in DMC block to be registered */
+enum exynos3250_dmc_plls {
+ bpll, epll,
+ nr_dmc_plls
+};
+
static void __iomem *reg_base;
/*
@@ -724,6 +730,25 @@ static struct samsung_pll_rate_table
exynos3250_pll_rates[] = {
{ /* sentinel */ }
};
+/* EPLL */
+static struct samsung_pll_rate_table exynos3250_epll_rates[] = {
+ PLL_36XX_RATE(8, 200, 3, 1, 0),
+ PLL_36XX_RATE(28800, 96, 2, 2, 0),
+ PLL_36XX_RATE(19200, 128, 2, 3, 0),
+ PLL_36XX_RATE(14400, 96, 2, 3, 0),
+ PLL_36XX_RATE( 9600, 128, 2, 4, 0),
+ PLL_36XX_RATE( 8400, 112, 2, 4, 0),
+ PLL_36XX_RATE( 8004, 106, 2, 4, 43691),
+ PLL_36XX_RATE( 73728000, 98, 2, 4, 19923),
+ PLL_36XX_RATE( 67737598, 270, 3, 5, 62285),
+ PLL_36XX_RATE( 65535999, 174, 2, 5, 49982),
+ PLL_36XX_RATE( 5000, 200, 3, 5, 0),
+ PLL_36XX_RATE( 49152002, 131, 2, 5, 4719),
+ PLL_36XX_RATE( 4800, 128, 2, 5, 0),
+ PLL_36XX_RATE( 45158401, 180, 3, 5, 41524),
+ { /* sentinel */ }
+};
+
/* VPLL */
static struct samsung_pll_rate_table exynos3250_vpll_rates[] = {
PLL_36XX_RATE(6, 100, 2, 1, 0),
@@ -821,3 +846,172 @@ static void __init exynos3250_cmu_init(struct device_node
*np)
samsung_clk_of_add_provider(np, ctx);
}
CLK_OF_DECLARE(exynos3250_cmu, "samsung,exynos3250-cmu", exynos3250_cmu_init);
+
+/*
+ * CMU DMC
+ */
+
+#define BPLL_LOCK 0x0118
+#define BPLL_CON0 0x0218
+#define BPLL_CON1 0x021c
+#define BPLL_CON2 0x0220
+#define SRC_DMC0x0300
+#define DIV_DMC1 0x0504
+#define GATE_BUS_DMC0 0x0700
+#define GATE_BUS_DMC1 0x0704
+#define GATE_BUS_DMC2 0x0708
+#define GATE_BUS_DMC3 0x070c
+#define GATE_SCLK_DMC 0x0800
+#define GATE_IP_DMC0 0x0900
+#define GATE_IP_DMC1 0x0904
+#define EPLL_LOCK 0x1110
+#define EPLL_CON0 0x1114
+#define EPLL_CON1 0x1118
+#define EPLL_CON2 0x111c
+#define SRC_EPLL 0x1120
+
+/*
+ * Support for CMU save/restore across system suspends
+ */
+#ifdef CONFIG_PM_SLEEP
+static struct samsung_clk_reg_dump *exynos3250_dmc_clk_regs;
+
+static unsigned long exynos3250_cmu_dmc_clk_regs[] __initdata = {
+ BPLL_LOCK,
+ BPLL_CON0,
+ BPLL_CON1,
+ BPLL_CON2,
+ SRC_DMC,
+ DIV_DMC1,
+ GATE_BUS_DMC0,
+ GATE_BUS_DMC1,
+ GATE_BUS_DMC2,
+ GATE_BUS_DMC3,
+ GATE_SCLK_DMC,
+ GATE_IP_DMC0,
+ GATE_IP_DMC1,
+ EPLL_LOCK,
+ EPLL_CON0,
+ EPLL_CON1,
+ EPLL_CON2,
+ SRC_EPLL,
+};
+
+static int exynos3250_dmc_clk_suspend(void)
+{
+ samsung_clk_save(reg_base, exynos3250_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+ return 0;
+}
+
+static void exynos3250_dmc_clk_resume(void)
+{
+ samsung_clk_restore(reg_base, exynos3250_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+}
+
+static struct syscore_ops exynos3250_dmc_clk_syscore_ops = {
+ .suspend = exynos3250_dmc_clk_suspend,
+ .resume = exynos3250_dmc_clk_resume,
+};
+
+static void exynos3250_dmc_clk_sleep_init(void)
+{
+ exynos3250_dmc_clk_regs =
+ samsung_clk_alloc_reg_dump(exynos3250_cmu_dmc_clk_regs,
+ ARRAY_SIZE(exynos3250_cmu_dmc_clk_regs));
+ if (!exynos3250_dmc_clk_regs) {
+ pr_warn("%s: Failed to allocate sleep save data\n", __func__);
+ goto err;
+ }
+
+ register_syscore_ops(&exynos3250_dmc_clk_syscore_ops);
+ return;
+err:
+ kfree(exynos3250_dmc_clk_regs);
+}
+#else
+static inline void exynos3250_dmc_clk_sleep_init(void) { }
+#endif
+
+PNAME(mout_epll_p) = { "fin_pll", "fout_epll", };
+PNAME(mout_bpll_p) = { "fin_pll", "fout_bpll", };
+PNAME(mout_mpll_mif_p) = { "fin_pll", "sclk_mpll_mif", };
+PNAME(mout_dphy_p) = { "mo
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Monday 01 September 2014 12:25:49 Lee Jones wrote:
> On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > On Monday 01 September 2014 08:49:18 Lee Jones wrote:
> > > On Fri, 22 Aug 2014, Pankaj Dubey wrote:
> > >
> > > > From: Tomasz Figa
> > > >
> > > > Currently a syscon entity can be only registered directly through a
> > > > platform device that binds to a dedicated driver. However in certain use
> > > > cases it is desirable to make a device used with another driver a syscon
> > > > interface provider. For example, certain SoCs (e.g. Exynos) contain
> > > > system controller blocks which perform various functions such as power
> > > > domain control, CPU power management, low power mode control, but in
> > > > addition contain certain IP integration glue, such as various signal
> > > > masks, coprocessor power control, etc. In such case, there is a need to
> > > > have a dedicated driver for such system controller but also share
> > > > registers with other drivers. The latter is where the syscon interface
> > > > is helpful.
> > > >
> > > > This patch decouples syscon object from syscon driver, so that it can be
> > > > registered from any driver in addition to the original "syscon" platform
> > > > driver.
> > > >
> > > > Signed-off-by: Tomasz Figa
> > > > Signed-off-by: Pankaj Dubey
> > > > ---
> > > >
> > > > RFC patch [1] was posted by Tomasz Figa. This patch addresses some of
> > > > comments given by Arnd to RFC patch, and further decouples syscon from
> > > > device model. It also gives flexibility of registering with syscon at
> > > > early stage using device_node object.
> > >
> > > It would be helpful if Arnd gave this revision his blessing (Ack).
> >
> > I never saw a reason why we don't take this all the way as discussed
> > a few times: Completely remove the dependency of syscon on having
> > a platform driver for it, and make it possible to just call
> > syscon_regmap_lookup_by_phandle() without having to register
> > it first.
>
> I think this sounds like a good end-state. Migrating over by
> supporting both methods in this way does sound like the correct thing
> to do though. Doing so is likely to dramatically reduce the effect on
> current users.
Maybe I'm misreading the patch, but I don't see how it creates a
migration path. What I want to end up with is infrastructure that
lets anybody call syscon_regmap_lookup_by_pdevname or
syscon_regmap_lookup_by_compatible (if they really need to)
without needing the platform_driver for syscon. That should not
require any form of compatibility layer because to the driver
using it there is no API change.
In contrast, this patch introduces a new of_syscon_{un,}register()
interface that would get removed after the the above has
been implemented, causing extra churn for any driver that also
wants to provide a regmap-like interface.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Monday 01 September 2014 17:05:33 Pankaj Dubey wrote: > > Please have a look at this thread [1], where we discussed the need of syscon > as platform device. > Looks like still there are users of syscon_regmap_lookup_by_pdevname > (clps711x.c). > So we can't make it completely independent of platform_device. > > [1] > https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35708.html I think the clps711x platform will soon stop using it, we already have patches for migrating to DT. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/29] DRM: Exynos: fix window clear code
Hi Marek,
On 2014년 08월 05일 19:47, Marek Szyprowski wrote:
> To correctly disable hardware window during driver init, both enable bits
> (WINCONx_ENWIN in WINCON and SHADOWCON_CHx_ENABLE in SHADOWCON) must be
> cleared, otherwise hardware fails to re-enable such window later.
>
> While touching this function, also temporarily disable ctx->suspended flag
> to let fimd_wait_for_vblank function really to do its job.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 41904df..7a363d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -165,27 +165,38 @@ static void fimd_wait_for_vblank(struct
> exynos_drm_manager *mgr)
> DRM_DEBUG_KMS("vblank wait timed out.\n");
> }
>
> -
> static void fimd_clear_channel(struct exynos_drm_manager *mgr)
> {
> struct fimd_context *ctx = mgr->ctx;
> - int win, ch_enabled = 0;
> + int state, win, ch_enabled = 0;
It doesn't need to declare state variable here because this variable is
used only when ch_enabled is 1.
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> /* Check if any channel is enabled. */
> for (win = 0; win < WINDOWS_NR; win++) {
> - u32 val = readl(ctx->regs + SHADOWCON);
> - if (val & SHADOWCON_CHx_ENABLE(win)) {
> - val &= ~SHADOWCON_CHx_ENABLE(win);
> - writel(val, ctx->regs + SHADOWCON);
> + u32 val = readl(ctx->regs + WINCON(win));
WARNING: Missing a blank line after declarations
> + if (val & WINCONx_ENWIN) {
> + /* wincon */
> + val &= ~WINCONx_ENWIN;
> + writel(val, ctx->regs + WINCON(win));
> +
> + /* unprotect windows */
> + if (ctx->driver_data->has_shadowcon) {
> + val = readl(ctx->regs + SHADOWCON);
> + val &= ~SHADOWCON_CHx_ENABLE(win);
> + writel(val, ctx->regs + SHADOWCON);
> + }
> ch_enabled = 1;
> }
> }
>
> /* Wait for vsync, as disable channel takes effect at next vsync */
> - if (ch_enabled)
> + if (ch_enabled) {
> + state = ctx->suspended;
int state = ctx->suspended;
> + ctx->suspended = 0;
> fimd_wait_for_vblank(mgr);
> + ctx->suspended = state;
> + }
> }
>
> static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
>
Above is trivial so I fixed them. Picked it up.
Thanks,
Inki Dae
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
On Monday 01 September 2014 14:07:34 Marek Szyprowski wrote: > On 2014-09-01 13:56, Arnd Bergmann wrote: > > On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote: > >>> Who do you think needs to set this flag, and who needs to read it? > >> In the proposed solution Exynos IOMMU driver creates a separate IO > >> address space > >> for every client device in a system and binds it to the default > >> dma-mapping space > >> for the given device. When drivers are doing its own management of IO > >> address > >> space, instead of relying on what is available by default with dma-mapping > >> interface, this will require releasing of the previously created default > >> structures and resources. So this flag is set by the driver doing its own > >> management of io address space. The flags is then checked by Exynos > >> IOMMU driver > >> to avoid creating the default dma-mapping address space for devices > >> which driver > >> does its own management. > > I don't completely understand it yet. I would assume the device > > to be added to the default domain at device creation time > > (of_platform_populate), way before we know which device driver > > is going to be used. How can this prevent the iommu driver > > from doing the association with the domain? > > of_platform_populate() is too early to do the association, because that > time the > exynos iommu driver is even not yet probed. Please have a look at the "Introduce automatic DMA configuration for IOMMU masters" series that Will Deacon sent out the other day. The idea is that we are changing the probe order so that the iommu gets initialized early enough for all IOMMU association to be done there. > The association with default dma-mapping domain is done in > IOMMU_GROUP_NOTIFY_BIND_DRIVER notifier, just before binding the driver > to the > given device. This way iommu driver can check dev->driver->flags and > skip creating > default dma-mapping domain if driver announces that it wants to handle it by > itself. I really want to kill off those notifiers. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: update to use component match support
Update Exynos's DRM driver to use component match support rater than
add_components.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 40 ++-
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index feee991..dae62c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -503,16 +503,15 @@ static int compare_of(struct device *dev, void *data)
return dev == (struct device *)data;
}
-static int exynos_drm_add_components(struct device *dev, struct master *m)
+static struct component_match *exynos_drm_match_add(struct device *dev)
{
+ struct component_match *match = NULL;
struct component_dev *cdev;
unsigned int attach_cnt = 0;
mutex_lock(&drm_component_lock);
list_for_each_entry(cdev, &drm_component_list, list) {
- int ret;
-
/*
* Add components to master only in case that crtc and
* encoder/connector device objects exist.
@@ -527,16 +526,10 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
/*
* fimd and dpi modules have same device object so add
* only crtc device object in this case.
-*
-* TODO. if dpi module follows driver-model driver then
-* below codes can be removed.
*/
if (cdev->crtc_dev == cdev->conn_dev) {
- ret = component_master_add_child(m, compare_of,
- cdev->crtc_dev);
- if (ret < 0)
- return ret;
-
+ component_match_add(dev, &match, compare_of,
+ cdev->crtc_dev);
goto out_lock;
}
@@ -546,11 +539,8 @@ static int exynos_drm_add_components(struct device *dev,
struct master *m)
* connector/encoder need pipe number of crtc when they
* are created.
*/
- ret = component_master_add_child(m, compare_of, cdev->crtc_dev);
- ret |= component_master_add_child(m, compare_of,
- cdev->conn_dev);
- if (ret < 0)
- return ret;
+ component_match_add(dev, &match, compare_of, cdev->crtc_dev);
+ component_match_add(dev, &match, compare_of, cdev->conn_dev);
out_lock:
mutex_lock(&drm_component_lock);
@@ -558,7 +548,7 @@ out_lock:
mutex_unlock(&drm_component_lock);
- return attach_cnt ? 0 : -ENODEV;
+ return attach_cnt ? match : ERR_PTR(-EPROBE_DEFER);
}
static int exynos_drm_bind(struct device *dev)
@@ -572,13 +562,13 @@ static void exynos_drm_unbind(struct device *dev)
}
static const struct component_master_ops exynos_drm_ops = {
- .add_components = exynos_drm_add_components,
.bind = exynos_drm_bind,
.unbind = exynos_drm_unbind,
};
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
+ struct component_match *match;
int ret;
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
@@ -645,13 +635,19 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
goto err_unregister_ipp_drv;
#endif
- ret = component_master_add(&pdev->dev, &exynos_drm_ops);
- if (ret < 0)
- DRM_DEBUG_KMS("re-tried by last sub driver probed later.\n");
+ match = exynos_drm_match_add(&pdev->dev);
+ if (IS_ERR(match)) {
+ ret = PTR_ERR(match);
+ goto err_unregister_ipp_dev;
+ }
- return 0;
+ return component_master_add_with_match(&pdev->dev, &exynos_drm_ops,
+ match);
+
+err_unregister_ipp_dev:
#ifdef CONFIG_DRM_EXYNOS_IPP
+ exynos_platform_device_ipp_unregister();
err_unregister_ipp_drv:
platform_driver_unregister(&ipp_driver);
err_unregister_gsc_drv:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
Hello, On 2014-09-01 13:56, Arnd Bergmann wrote: On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote: Who do you think needs to set this flag, and who needs to read it? In the proposed solution Exynos IOMMU driver creates a separate IO address space for every client device in a system and binds it to the default dma-mapping space for the given device. When drivers are doing its own management of IO address space, instead of relying on what is available by default with dma-mapping interface, this will require releasing of the previously created default structures and resources. So this flag is set by the driver doing its own management of io address space. The flags is then checked by Exynos IOMMU driver to avoid creating the default dma-mapping address space for devices which driver does its own management. I don't completely understand it yet. I would assume the device to be added to the default domain at device creation time (of_platform_populate), way before we know which device driver is going to be used. How can this prevent the iommu driver from doing the association with the domain? of_platform_populate() is too early to do the association, because that time the exynos iommu driver is even not yet probed. The association with default dma-mapping domain is done in IOMMU_GROUP_NOTIFY_BIND_DRIVER notifier, just before binding the driver to the given device. This way iommu driver can check dev->driver->flags and skip creating default dma-mapping domain if driver announces that it wants to handle it by itself. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
On Monday 01 September 2014 12:47:08 Marek Szyprowski wrote: > > Who do you think needs to set this flag, and who needs to read it? > > In the proposed solution Exynos IOMMU driver creates a separate IO > address space > for every client device in a system and binds it to the default > dma-mapping space > for the given device. When drivers are doing its own management of IO > address > space, instead of relying on what is available by default with dma-mapping > interface, this will require releasing of the previously created default > structures and resources. So this flag is set by the driver doing its own > management of io address space. The flags is then checked by Exynos > IOMMU driver > to avoid creating the default dma-mapping address space for devices > which driver > does its own management. I don't completely understand it yet. I would assume the device to be added to the default domain at device creation time (of_platform_populate), way before we know which device driver is going to be used. How can this prevent the iommu driver from doing the association with the domain? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
Hi Arnd, > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Monday, September 01, 2014 4:07 PM > To: Lee Jones > Cc: Pankaj Dubey; linux-arm-ker...@lists.infradead.org; linux-samsung- > s...@vger.kernel.org; linux-ker...@vger.kernel.org; kgene@samsung.com; > li...@arm.linux.org.uk; vikas.saj...@samsung.com; jo...@samsung.com; > naus...@samsung.com; thomas...@samsung.com; chow@samsung.com; > Tomasz Figa; broo...@kernel.org > Subject: Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices > > On Monday 01 September 2014 08:49:18 Lee Jones wrote: > > On Fri, 22 Aug 2014, Pankaj Dubey wrote: > > > > > From: Tomasz Figa > > > > > > Currently a syscon entity can be only registered directly through a > > > platform device that binds to a dedicated driver. However in certain > > > use cases it is desirable to make a device used with another driver > > > a syscon interface provider. For example, certain SoCs (e.g. Exynos) > > > contain system controller blocks which perform various functions > > > such as power domain control, CPU power management, low power mode > > > control, but in addition contain certain IP integration glue, such > > > as various signal masks, coprocessor power control, etc. In such > > > case, there is a need to have a dedicated driver for such system > > > controller but also share registers with other drivers. The latter > > > is where the syscon interface is helpful. > > > > > > This patch decouples syscon object from syscon driver, so that it > > > can be registered from any driver in addition to the original > > > "syscon" platform driver. > > > > > > Signed-off-by: Tomasz Figa > > > Signed-off-by: Pankaj Dubey > > > --- > > > > > > RFC patch [1] was posted by Tomasz Figa. This patch addresses some > > > of comments given by Arnd to RFC patch, and further decouples syscon > > > from device model. It also gives flexibility of registering with > > > syscon at early stage using device_node object. > > > > It would be helpful if Arnd gave this revision his blessing (Ack). > > I never saw a reason why we don't take this all the way as discussed a few times: > Completely remove the dependency of syscon on having a platform driver for it, and > make it possible to just call > syscon_regmap_lookup_by_phandle() without having to register it first. > Please have a look at this thread [1], where we discussed the need of syscon as platform device. Looks like still there are users of syscon_regmap_lookup_by_pdevname (clps711x.c). So we can't make it completely independent of platform_device. [1] https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35708.html > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Mon, 01 Sep 2014, Arnd Bergmann wrote: > On Monday 01 September 2014 08:49:18 Lee Jones wrote: > > On Fri, 22 Aug 2014, Pankaj Dubey wrote: > > > > > From: Tomasz Figa > > > > > > Currently a syscon entity can be only registered directly through a > > > platform device that binds to a dedicated driver. However in certain use > > > cases it is desirable to make a device used with another driver a syscon > > > interface provider. For example, certain SoCs (e.g. Exynos) contain > > > system controller blocks which perform various functions such as power > > > domain control, CPU power management, low power mode control, but in > > > addition contain certain IP integration glue, such as various signal > > > masks, coprocessor power control, etc. In such case, there is a need to > > > have a dedicated driver for such system controller but also share > > > registers with other drivers. The latter is where the syscon interface > > > is helpful. > > > > > > This patch decouples syscon object from syscon driver, so that it can be > > > registered from any driver in addition to the original "syscon" platform > > > driver. > > > > > > Signed-off-by: Tomasz Figa > > > Signed-off-by: Pankaj Dubey > > > --- > > > > > > RFC patch [1] was posted by Tomasz Figa. This patch addresses some of > > > comments given by Arnd to RFC patch, and further decouples syscon from > > > device model. It also gives flexibility of registering with syscon at > > > early stage using device_node object. > > > > It would be helpful if Arnd gave this revision his blessing (Ack). > > I never saw a reason why we don't take this all the way as discussed > a few times: Completely remove the dependency of syscon on having > a platform driver for it, and make it possible to just call > syscon_regmap_lookup_by_phandle() without having to register > it first. I think this sounds like a good end-state. Migrating over by supporting both methods in this way does sound like the correct thing to do though. Doing so is likely to dramatically reduce the effect on current users. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/8] thermal: exynos: various cleanups
Amit On Mon, Sep 1, 2014 at 6:53 AM, amit daniel kachhap wrote: > On Thu, Aug 28, 2014 at 8:19 PM, Eduardo Valentin wrote: >> Amit, >> >> On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote: >>> Hi, >>> >>> This patch series contains various cleanups for EXYNOS thermal >>> driver. Overall it decreases driver's LOC by 9%. It is based >>> on next-20140731 kernel. It should not cause any functionality >>> changes. >>> >> >> Did you have the time to test this series? > > Hi Eduardo/Bartlomiej, > > For the whole series tested on exynos5250 based arndale board. > Tested-by: Amit Daniel Kachhap > Thanks! I will pull the series on my tree. > Sorry for the delay as I was busy in some internal work. > > Thanks, > Amit D >> >>> Changes since v2 (https://lkml.org/lkml/2014/6/17/436): >>> - synced patches against next-20140731 >>> - dropped patch "thermal: exynos: remove dead code for >>> TYPE_TWO_POINT_TRIMMING calibration" (newly added Exynos3250 >>> SoC support uses TYPE_TWO_POINT_TRIMMING calibration) >>> - updated patch description for patch #2 >>> - dropped Reviewed-by from Amit from patch #8 (due to changed >>> scope of the patch) >>> >>> Changes since v1 (https://lkml.org/lkml/2014/5/5/194): >>> - synced patches against next-20140617 >>> - merged patch "thermal: exynos: remove unused defines" into >>> "thermal: exynos: remove unused struct exynos_tmu_registers >>> entries" one (per request from Eduardo) >>> - improved patch descriptions for patches #1-5 >>> - fixed documentation for pdata->gain and pdata->reference_voltage >>> - added Reviewed-by from Amit to patches #6, #7 and #10 >>> - added missing Acked-by from Kyungmin Park >>> >>> Best regards, >>> -- >>> Bartlomiej Zolnierkiewicz >>> Samsung R&D Institute Poland >>> Samsung Electronics >>> >>> >>> Bartlomiej Zolnierkiewicz (8): >>> thermal: exynos: remove unused struct exynos_tmu_registers entries >>> thermal: exynos: remove dead code for HW_MODE calibration >>> thermal: exynos: remove redundant pdata checks from >>> exynos_tmu_initialize() >>> thermal: exynos: remove redundant threshold_code checks from >>> exynos_tmu_initialize() >>> thermal: exynos: simplify temp_to_code() and code_to_temp() >>> thermal: exynos: cache non_hw_trigger_levels in pdata >>> thermal: exynos: remove redundant pdata checks from >>> exynos_tmu_control() >>> thermal: exynos: remove identical values from exynos*_tmu_registers >>> structures >>> >>> drivers/thermal/samsung/exynos_thermal_common.h | 1 - >>> drivers/thermal/samsung/exynos_tmu.c| 126 >>> +--- >>> drivers/thermal/samsung/exynos_tmu.h| 74 +- >>> drivers/thermal/samsung/exynos_tmu_data.c | 56 ++- >>> drivers/thermal/samsung/exynos_tmu_data.h | 31 +- >>> 5 files changed, 35 insertions(+), 253 deletions(-) >>> >>> -- >>> 1.8.2.3 >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Eduardo Bezerra Valentin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/8] thermal: exynos: various cleanups
On Thu, Aug 28, 2014 at 8:19 PM, Eduardo Valentin wrote: > Amit, > > On Thu, Jul 31, 2014 at 07:10:58PM +0200, Bartlomiej Zolnierkiewicz wrote: >> Hi, >> >> This patch series contains various cleanups for EXYNOS thermal >> driver. Overall it decreases driver's LOC by 9%. It is based >> on next-20140731 kernel. It should not cause any functionality >> changes. >> > > Did you have the time to test this series? Hi Eduardo/Bartlomiej, For the whole series tested on exynos5250 based arndale board. Tested-by: Amit Daniel Kachhap Sorry for the delay as I was busy in some internal work. Thanks, Amit D > >> Changes since v2 (https://lkml.org/lkml/2014/6/17/436): >> - synced patches against next-20140731 >> - dropped patch "thermal: exynos: remove dead code for >> TYPE_TWO_POINT_TRIMMING calibration" (newly added Exynos3250 >> SoC support uses TYPE_TWO_POINT_TRIMMING calibration) >> - updated patch description for patch #2 >> - dropped Reviewed-by from Amit from patch #8 (due to changed >> scope of the patch) >> >> Changes since v1 (https://lkml.org/lkml/2014/5/5/194): >> - synced patches against next-20140617 >> - merged patch "thermal: exynos: remove unused defines" into >> "thermal: exynos: remove unused struct exynos_tmu_registers >> entries" one (per request from Eduardo) >> - improved patch descriptions for patches #1-5 >> - fixed documentation for pdata->gain and pdata->reference_voltage >> - added Reviewed-by from Amit to patches #6, #7 and #10 >> - added missing Acked-by from Kyungmin Park >> >> Best regards, >> -- >> Bartlomiej Zolnierkiewicz >> Samsung R&D Institute Poland >> Samsung Electronics >> >> >> Bartlomiej Zolnierkiewicz (8): >> thermal: exynos: remove unused struct exynos_tmu_registers entries >> thermal: exynos: remove dead code for HW_MODE calibration >> thermal: exynos: remove redundant pdata checks from >> exynos_tmu_initialize() >> thermal: exynos: remove redundant threshold_code checks from >> exynos_tmu_initialize() >> thermal: exynos: simplify temp_to_code() and code_to_temp() >> thermal: exynos: cache non_hw_trigger_levels in pdata >> thermal: exynos: remove redundant pdata checks from >> exynos_tmu_control() >> thermal: exynos: remove identical values from exynos*_tmu_registers >> structures >> >> drivers/thermal/samsung/exynos_thermal_common.h | 1 - >> drivers/thermal/samsung/exynos_tmu.c| 126 >> +--- >> drivers/thermal/samsung/exynos_tmu.h| 74 +- >> drivers/thermal/samsung/exynos_tmu_data.c | 56 ++- >> drivers/thermal/samsung/exynos_tmu_data.h | 31 +- >> 5 files changed, 35 insertions(+), 253 deletions(-) >> >> -- >> 1.8.2.3 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pm" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
Hello,
On 2014-09-01 11:38, Arnd Bergmann wrote:
On Monday 01 September 2014 09:53:29 Marek Szyprowski wrote:
On 2014-09-01 09:07, Thierry Reding wrote:
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
Hi Greg,
On 2014-08-05 12:47, Marek Szyprowski wrote:
This patch adds a new flags for device drivers. This flag instructs
kernel that the device driver does it own management of IOMMU assisted
IO address space translations, so no default dma-mapping structures
should be initialized.
Signed-off-by: Marek Szyprowski
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 5f4ff02..2e62371 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -253,6 +253,8 @@ struct device_driver {
/* disables bind/unbind via sysfs */
#define DRIVER_SUPPRESS_BIND_ATTRS (1 << 0)
+/* driver uses own methods to manage IO address space */
+#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 << 1)
extern int __must_check driver_register(struct device_driver *drv);
extern void driver_unregister(struct device_driver *drv);
Could you comment if the approach of using flags in the struct driver
could be accepted? I've converted suppress_bind_attrs entry to flags to
avoid extending the structure, please see patch "[PATCH 05/29] drivers:
convert suppress_bind_attrs parameter into flags".
Is this really necessary? What I did as part of an RFC series for Tegra
IOMMU support is keep this knowledge within the IOMMU driver rather than
export it to the driver core.i
The problem with embedding the list of drivers that you would need to update
it everytime when you modify or extend iommu support in the other drivers.
I've tried also other approach, like adding respective notifiers to
individual
drivers to initialize custom iommu support (or disable default iommu
mapping)
before iommu driver gets initialized, but such solution is in my opinion too
complex and hard to understand if one is not familiar will all this stuff.
All in all it turned out that the simplest and most generic way is to simply
add the flag to the driver core. Flags might be also used in the future
to model other kinds of dependencies between device drivers and/or driver
core.
I don't get it yet. I would expect that a driver doing its own management
of the iommu gets to use the linux/iommu.h interfaces, while a driver
using the default iommu setup uses linux/dma-mapping.h.
You are right.
Who do you think needs to set this flag, and who needs to read it?
In the proposed solution Exynos IOMMU driver creates a separate IO
address space
for every client device in a system and binds it to the default
dma-mapping space
for the given device. When drivers are doing its own management of IO
address
space, instead of relying on what is available by default with dma-mapping
interface, this will require releasing of the previously created default
structures and resources. So this flag is set by the driver doing its own
management of io address space. The flags is then checked by Exynos
IOMMU driver
to avoid creating the default dma-mapping address space for devices
which driver
does its own management.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/2] ARM: dts: Add DT changes for display on peach_pit
Add DT nodes for ps8622 bridge chip and panel.
Add backlight power supply for pwm-backlight.
Also add bridge phandle needed by dp to enable display on peach_pit.
Signed-off-by: Ajay Kumar
---
Changes since V1:
-- Remove "simple-panel" compatible string.
-- Use GPIO_ACTIVE_HIGH instead of 0.
-- Change panel node naming from "panel-simple" to "panel".
Changes since V2:
-- Use proper compatible string: "auo,b116xw03"
arch/arm/boot/dts/exynos5420-peach-pit.dts | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 228a6b1..1070a31 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -30,11 +30,12 @@
i2c20 = "/spi@12d4/cros-ec@0/i2c-tunnel";
};
- backlight {
+ backlight: backlight {
compatible = "pwm-backlight";
pwms = <&pwm 0 100 0>;
brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
default-brightness-level = <7>;
+ power-supply = <&tps65090_fet1>;
pinctrl-0 = <&pwm0_out>;
pinctrl-names = "default";
};
@@ -100,6 +101,12 @@
regulator-boot-on;
regulator-always-on;
};
+
+ panel: panel {
+ compatible = "auo,b116xw03";
+ power-supply = <&tps65090_fet6>;
+ backlight = <&backlight>;
+ };
};
&dp {
@@ -113,22 +120,7 @@
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
samsung,hpd-gpio = <&gpx2 6 0>;
-
- display-timings {
- native-mode = <&timing1>;
-
- timing1: timing@1 {
- clock-frequency = <70589280>;
- hactive = <1366>;
- vactive = <768>;
- hfront-porch = <40>;
- hback-porch = <40>;
- hsync-len = <32>;
- vback-porch = <10>;
- vfront-porch = <12>;
- vsync-len = <6>;
- };
- };
+ bridge = <&ps8625>;
};
&fimd {
@@ -155,6 +147,16 @@
pinctrl-names = "default";
pinctrl-0 = <&max98090_irq>;
};
+
+ ps8625: lvds-bridge@48 {
+ compatible = "parade,ps8625";
+ reg = <0x48>;
+ sleep-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpy7 7 GPIO_ACTIVE_HIGH>;
+ lane-count = <2>;
+ panel = <&panel>;
+ use-external-pwm;
+ };
};
&hsi2c_9 {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/2] ARM: dts: Add DT changes for display on snow
Add DT nodes for ptn3460 bridge chip and panel.
Add backlight enable pin and backlight power supply for pwm-backlight.
Also add bridge phandle needed by dp to enable display on snow.
Signed-off-by: Ajay Kumar
---
Changes since V1:
-- Remove "simple-panel" compatible string.
-- Use GPIO_ACTIVE_HIGH instead of 0.
-- Change panel node naming from "panel-simple" to "panel".
Changes since V2:
-- Use proper compatible string: "auo,b116xw03"
arch/arm/boot/dts/exynos5250-snow.dts | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index f2b8c41..1ac9709 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -9,6 +9,7 @@
*/
/dts-v1/;
+#include
#include "exynos5250.dtsi"
#include "exynos5250-cros-common.dtsi"
@@ -181,7 +182,7 @@
dcdc3 {
ti,enable-ext-control;
};
- fet1 {
+ fet1: fet1 {
regulator-name = "vcd_led";
ti,overcurrent-wait = <3>;
};
@@ -204,7 +205,7 @@
regulator-always-on;
ti,overcurrent-wait = <3>;
};
- fet6 {
+ fet6: fet6 {
regulator-name = "lcd_vdd";
ti,overcurrent-wait = <3>;
};
@@ -253,6 +254,15 @@
pinctrl-0 = <&max98095_en>;
pinctrl-names = "default";
};
+
+ ptn3460: lvds-bridge@20 {
+ compatible = "nxp,ptn3460";
+ reg = <0x20>;
+ powerdown-gpios = <&gpy2 5 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpx1 5 GPIO_ACTIVE_HIGH>;
+ edid-emulation = <5>;
+ panel = <&panel>;
+ };
};
i2s0: i2s@0383 {
@@ -300,11 +310,13 @@
vdd_pll-supply = <&ldo8_reg>;
};
- backlight {
+ backlight: backlight {
compatible = "pwm-backlight";
pwms = <&pwm 0 100 0>;
brightness-levels = <0 100 500 1000 1500 2000 2500 2800>;
default-brightness-level = <7>;
+ enable-gpios = <&gpx3 0 GPIO_ACTIVE_HIGH>;
+ power-supply = <&fet1>;
pinctrl-0 = <&pwm0_out>;
pinctrl-names = "default";
};
@@ -314,6 +326,12 @@
samsung,invert-vclk;
};
+ panel: panel {
+ compatible = "auo,b116xw03";
+ power-supply = <&fet6>;
+ backlight = <&backlight>;
+ };
+
dp-controller@145B {
status = "okay";
pinctrl-names = "default";
@@ -325,22 +343,7 @@
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
samsung,hpd-gpio = <&gpx0 7 0>;
-
- display-timings {
- native-mode = <&timing1>;
-
- timing1: timing@1 {
- clock-frequency = <70589280>;
- hactive = <1366>;
- vactive = <768>;
- hfront-porch = <40>;
- hback-porch = <40>;
- hsync-len = <32>;
- vback-porch = <10>;
- vfront-porch = <12>;
- vsync-len = <6>;
- };
- };
+ bridge = <&ptn3460>;
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Monday 01 September 2014 08:49:18 Lee Jones wrote: > On Fri, 22 Aug 2014, Pankaj Dubey wrote: > > > From: Tomasz Figa > > > > Currently a syscon entity can be only registered directly through a > > platform device that binds to a dedicated driver. However in certain use > > cases it is desirable to make a device used with another driver a syscon > > interface provider. For example, certain SoCs (e.g. Exynos) contain > > system controller blocks which perform various functions such as power > > domain control, CPU power management, low power mode control, but in > > addition contain certain IP integration glue, such as various signal > > masks, coprocessor power control, etc. In such case, there is a need to > > have a dedicated driver for such system controller but also share > > registers with other drivers. The latter is where the syscon interface > > is helpful. > > > > This patch decouples syscon object from syscon driver, so that it can be > > registered from any driver in addition to the original "syscon" platform > > driver. > > > > Signed-off-by: Tomasz Figa > > Signed-off-by: Pankaj Dubey > > --- > > > > RFC patch [1] was posted by Tomasz Figa. This patch addresses some of > > comments given by Arnd to RFC patch, and further decouples syscon from > > device model. It also gives flexibility of registering with syscon at > > early stage using device_node object. > > It would be helpful if Arnd gave this revision his blessing (Ack). I never saw a reason why we don't take this all the way as discussed a few times: Completely remove the dependency of syscon on having a platform driver for it, and make it possible to just call syscon_regmap_lookup_by_phandle() without having to register it first. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/panel: simple: Add AUO B116XW03 panel support
The AUO B116XW03 is a 11.6" HD TFT LCD panel connecting to a LVDS
interface and with an integrated LED backlight unit.
This panel is used on the Samsung Chromebook(XE303C12).
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/panel/auo,b116xw03.txt |7 ++
drivers/gpu/drm/panel/panel-simple.c | 25
2 files changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b116xw03.txt
diff --git a/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
new file mode 100644
index 000..690d0a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel
+
+Required properties:
+- compatible: should be "auo,b116xw03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4ce1db0..51566e0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -352,6 +352,28 @@ static const struct panel_desc auo_b101aw03 = {
},
};
+static const struct drm_display_mode auo_b116xw03_mode = {
+ .clock = 70589,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 40,
+ .hsync_end = 1366 + 40 + 40,
+ .htotal = 1366 + 40 + 40 + 32,
+ .vdisplay = 768,
+ .vsync_start = 768 + 10,
+ .vsync_end = 768 + 10 + 12,
+ .vtotal = 768 + 10 + 12 + 6,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b116xw03 = {
+ .modes = &auo_b116xw03_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 256,
+ .height = 144,
+ },
+};
+
static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -616,6 +638,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = &auo_b101aw03,
}, {
+ .compatible = "auo,b116xw03",
+ .data = &auo_b116xw03,
+ }, {
.compatible = "auo,b133htn01",
.data = &auo_b133htn01,
}, {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: exynos: remove usb_phy_generic support
Hi,
On Friday, August 29, 2014 11:33:04 AM Greg Kroah-Hartman wrote:
> On Fri, Aug 29, 2014 at 11:02:52AM +0200, Bartlomiej Zolnierkiewicz wrote:
> > On Thursday, August 28, 2014 12:29:52 PM Greg Kroah-Hartman wrote:
> > > On Thu, Aug 28, 2014 at 08:11:04PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > [ added Alan and Greg to cc: ]
> > > >
> > > > Hi,
> > > >
> > > > On Wednesday, August 27, 2014 11:42:25 PM Vivek Gautam wrote:
> > > > > Hi Baltlomiej,
> > > > >
> > > > >
> > > > > On Wed, Aug 27, 2014 at 1:22 PM, Bartlomiej Zolnierkiewicz
> > > > > wrote:
> > > > > > dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver
> > > > > > (PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by
> > > > > > looking at the following commits:
> > > > > >
> > > > > > 7a4cf0fde054 ("ARM: dts: Update DWC3 usb controller to use new
> > > > > > phy driver for exynos5250")
> > > > > >
> > > > > > f070267b5fc1 ("ARM: dts: Enable support for DWC3 controller for
> > > > > > exynos5420")
> > > > > >
> > > > > > Thus remove unused usb_phy_generic support from dwc3 Exynos glue
> > > > > > layer.
> > > > > >
> > > > > > [ The code that is being removed is harmful in the context of
> > > > > > multi_v7_defconfig and enabling "EHCI support for Samsung
> > > > > > S5P/EXYNOS SoC Series" (USB_EHCI_EXYNOS) + "OHCI support for
> > > > > > Samsung S5P/EXYNOS SoC Series" (USB_OHCI_EXYNOS) because "EHCI
> > > > > > support for OMAP3 and later chips" (USB_EHCI_HCD_OMAP) selects
> > > > > > "NOP USB Transceiver Driver" (NOP_USB_XCEIV). NOP USB driver
> > > > > > attaches itself to usb_phy_generic platform devices created by
> > > > > > dwc3 Exynos glue layer and later causes Exynos EHCI driver to
> > > > > > fail probe and Exynos OHCI driver to hang on probe (as observed
> > > > > > on Exynos5250 Arndale board). ]
> > > > >
> > > > > The issue with EHCI and OHCI on exynos platforms is that until now
> > > > > they also request
> > > > > usb-phy and only later if they don't find one, they go ahead and get a
> > > > > 'phy' generic.
> > > > >
> > > > > Fortunately we missed this issue with exynos_defconfig, and as you
> > > > > rightly
> > > > > mentioned with multi_v7_defconfig, the NOP_USB_XCEIV gets enabled and
> > > > > EHCI and OHCI exynos get no-op usb-phy, which actually blocks
> > > > > EHCI/OHCI from
> > > > > initializing the real PHYs.
> > > > >
> > > > > This issue is resolved with patches:
> > > > > [PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy
> > > > > support
> > > > > [PATCH v2 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy
> > > > > support
> > > > > wherein we are completely removing the usb-phy support from
> > > > > ehci/ohci-exynos.
> > > > > So with these patches we should not see the issue mentioned by you.
> > > >
> > > > Indeed, your patches fix the issue.
> > > >
> > > > Greg, could these two patches ([1] & [2]) get merged quickly, pretty
> > > > please
> > > > (they were already acked by Alan)? They are not a mere cleanups because
> > > > they fix the actual problem with using multi_v7_defconfig which in turn
> > > > has
> > > > been blocking Olof's defconfig update patch [3] for quite some time now.
> > > > Moreover these patches are limited to Exynos host drivers so they
> > > > should be
> > > > pretty safe when it comes to potential regressions.
> > > >
> > > > [1] http://www.spinics.net/lists/linux-usb/msg112294.html
> > > > [2] http://www.spinics.net/lists/linux-usb/msg112293.html
> > > > [3] http://www.spinics.net/lists/arm-kernel/msg349654.html
> > >
> > > merged for 3.18-rc1, or do you "need" them for 3.17-final?
> >
> > If it is not too much trouble please push them to 3.17-final.
>
> They don't meet the "regression or bugfix" rule at all, so I can't do
> this, sorry. I'll queue them up for 3.18.
These patches fix a real problem of boot hang when enabling Exynos USB
host drivers and using ARM multiplatform config so IMHO they fall into
bugfix category.
> > > I already reverted one patch for exynos for 3.17-final that is sitting
> > > in my tree to go to Linus soon as you all didn't seem to want it
> > > anymore, so I'm getting really confused here...
> >
> > These two patches are a replacement for the one reverted and
> > they just remove the old code instead of keeping it as fallback.
> > This means that the reverted patch was not breaking anything and
> > these two new patches could have been also done as incremental
> > ones. Sorry for the confusion.
>
> As they came in too late for 3.17-rc1, they will have to wait for
> 3.18-rc1.
Okay..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
On Monday 01 September 2014 09:53:29 Marek Szyprowski wrote:
> On 2014-09-01 09:07, Thierry Reding wrote:
> > On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
> >> Hi Greg,
> >>
> >> On 2014-08-05 12:47, Marek Szyprowski wrote:
> >>> This patch adds a new flags for device drivers. This flag instructs
> >>> kernel that the device driver does it own management of IOMMU assisted
> >>> IO address space translations, so no default dma-mapping structures
> >>> should be initialized.
> >>>
> >>> Signed-off-by: Marek Szyprowski
> >>> ---
> >>>include/linux/device.h | 2 ++
> >>>1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/include/linux/device.h b/include/linux/device.h
> >>> index 5f4ff02..2e62371 100644
> >>> --- a/include/linux/device.h
> >>> +++ b/include/linux/device.h
> >>> @@ -253,6 +253,8 @@ struct device_driver {
> >>>
> >>>/* disables bind/unbind via sysfs */
> >>>#define DRIVER_SUPPRESS_BIND_ATTRS (1 << 0)
> >>> +/* driver uses own methods to manage IO address space */
> >>> +#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 << 1)
> >>>
> >>>extern int __must_check driver_register(struct device_driver *drv);
> >>>extern void driver_unregister(struct device_driver *drv);
> >> Could you comment if the approach of using flags in the struct driver
> >> could be accepted? I've converted suppress_bind_attrs entry to flags to
> >> avoid extending the structure, please see patch "[PATCH 05/29] drivers:
> >> convert suppress_bind_attrs parameter into flags".
> > Is this really necessary? What I did as part of an RFC series for Tegra
> > IOMMU support is keep this knowledge within the IOMMU driver rather than
> > export it to the driver core.i
>
> The problem with embedding the list of drivers that you would need to update
> it everytime when you modify or extend iommu support in the other drivers.
> I've tried also other approach, like adding respective notifiers to
> individual
> drivers to initialize custom iommu support (or disable default iommu
> mapping)
> before iommu driver gets initialized, but such solution is in my opinion too
> complex and hard to understand if one is not familiar will all this stuff.
>
> All in all it turned out that the simplest and most generic way is to simply
> add the flag to the driver core. Flags might be also used in the future
> to model other kinds of dependencies between device drivers and/or driver
> core.
I don't get it yet. I would expect that a driver doing its own management
of the iommu gets to use the linux/iommu.h interfaces, while a driver
using the default iommu setup uses linux/dma-mapping.h. Who do you think
needs to set this flag, and who needs to read it?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin, On Fri, Aug 29, 2014 at 8:33 PM, Kevin Hilman wrote: > Hi Thomas, > > On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham wrote: >> Hi Kevin, >> >> On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman wrote: >>> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman wrote: On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap wrote: >>> >>> [...] >>> >> >> Can you clarify how you're setting the voltages to ensure stability? > > below is the diff : wip/exynos/integ Thanks. I've applied your patch, and bootup shows vdd_arm and vdd_kfc at 1500mV, but still when booting with cpuidle enabled (bL switcher disabled), I'm seeing lockups with no kernel output. With CPUidle disabled, things are pretty stable. What tree are you using to test this out on 5420? I'm using mainline v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my wip/exynos/integ branch at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. >>> >>> I mis-stated this. Actually my tree is based on the v3.17-rc1 branch >>> of the exynos-reference tree[1] + the above mentioned patches for >>> cpuidle and cpufreq. >>> >>> Also, I've narrowed down the instability a bit, and it's not related >>> to CPUidle. I can now trigger a boot hang even without CPUidle >>> enabled. Here's a quick way to cause a boot lockup. With the switcher >>> disabled, I enable CPUfreq and set the default governor to >>> performance. As soon as cpufreq driver loads, it tries to use the top >>> frequences for both clusters, and it hangs. >>> >>> Selectively disabling frequencies, I narrowed it down to the 1.3GHz >>> and 1.2GHz frequencies of the little cluster. With these commented >>> out in the DT, it will fully boot with the performance governor >>> enabled. >>> >>> So that leads to the question. Are all of the operating points in >>> exynos5420.dtsi valid for exynos5800, and have they been validated? >> >> I tried to recreate the boot lockup issue using the same steps you >> listed above for the Exynos5800 peach-pi platform (Chromebook2), but I >> do not see any issues. I can see both clusters with max clock speed >> after boot (1.8GHz and 1.3GHz). >> >> I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support >> patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 >> voltage to 1.3V. > > Can you share your branch and temp hack(s) as well as your defconfig? > > I'm using the v3.17-rc1 branch from the exynos tree (which includes > the max77802 series) but also has a bunch of other stuff which may be > causing the issue. > > It would be good if I can reproduce your exact tree/branch and see if > I still have the same problem. The branch with the patches that have been used to test cpufreq on Exynos5800 is available at https://github.com/exynos-reference/kernel/tree/exynos5-v3.17-rc3-temp-cpufreq Please let me know if this works or if there are any issues. Thanks, Thomas. > > Thanks for looking into this, > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: EXYNOS: Do not calculate boot address twice
On pią, 2014-07-04 at 17:41 +0900, Kukjin Kim wrote:
> Krzysztof Kozlowski wrote:
> >
> > Commit b3205dea8fbf ("ARM: EXYNOS: Map SYSRAM through generic DT
> > bindings") introduced local variable boot_reg where boot address from
> > cpu_boot_reg() call is stored. Re-use it instead calling cpu_boot_reg()
> > again.
> >
> > Signed-off-by: Krzysztof Kozlowski
> > ---
> > arch/arm/mach-exynos/platsmp.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
> > index 1c8d31e39520..55ed2e6729c5 100644
> > --- a/arch/arm/mach-exynos/platsmp.c
> > +++ b/arch/arm/mach-exynos/platsmp.c
> > @@ -155,7 +155,7 @@ static int exynos_boot_secondary(unsigned int cpu,
> > struct task_struct *idle)
> > ret = PTR_ERR(boot_reg);
> > goto fail;
> > }
> > - __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
> > + __raw_writel(boot_addr, boot_reg);
> > }
> >
> > call_firmware_op(cpu_boot, phys_cpu);
> > @@ -242,7 +242,7 @@ static void __init exynos_smp_prepare_cpus(unsigned int
> > max_cpus)
> >
> > if (IS_ERR(boot_reg))
> > break;
> > - __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
> > + __raw_writel(boot_addr, boot_reg);
> > }
> > }
> > }
> > --
> > 1.9.1
>
> Oh, good catch. will apply :-)
Hi Kukjin,
I cannot find this patch in your tree or in next. Did you applied this?
Best regards,
Krzysztof
> Thanks,
> Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: mfd: exynos-pmu: Add support for Exynos7
On Mon, 01 Sep 2014, Abhilash Kesavan wrote: > Add intial PMU settings for exynos7. This is required for > future suspend-to-ram and cpuidle support. > > Signed-off-by: Eunseok Choi > Signed-off-by: Abhilash Kesavan > --- > This patch has been tested on an Exynos7 espresso board and is based > on Kgene's tree (for-next branch). > > Following are the dependencies: > 1) Support 64bit Cortex A57 based Exynos7 SoC > http://www.spinics.net/lists/arm-kernel/msg357380.html > 2) mfd: syscon: Decouple syscon interface from syscon devices > http://www.spinics.net/lists/linux-samsung-soc/msg35906.html > 3) ARM: EXYNOS: Add platform driver support for Exynos PMU > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/275675.html > 4) ARM: EXYNOS: Move PMU specific definitions from common.h > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270655.html > 5) ARM: EXYNOS: Move pmu specific header files under "linux/mfd/samsung" > https://lkml.org/lkml/2014/4/28/217 > 6) drivers: mfd: Add support for Exynos PMU driver > https://lkml.org/lkml/2014/4/28/332 > > NOTE: The above dependencies are not final yet, especially the > movement of exynos pmu driver to the mfd directory. I will re-work > this patch when the final location for exynos PMU driver is decided. Let me know when this patch is ready to go in and I'll review. > .../devicetree/bindings/arm/samsung/pmu.txt|1 + > arch/arm64/boot/dts/exynos7.dtsi |5 + > drivers/mfd/exynos-pmu.c | 285 > > include/linux/mfd/samsung/exynos-regs-pmu.h| 212 +++ > 4 files changed, 503 insertions(+) This all needs to be broken up into seperate patches. Also, see: Documentation/devicetree/bindings/submitting-patches.txt. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
On Thu, Aug 28, 2014 at 8:36 PM, Daniele Forsi wrote: > 2014-08-28 10:02 GMT+02:00 Vivek Gautam: > >> This USB 3.0 PHY controller is also present on Exynos7 >> platform, so adding the dependency on ARCH_EXYNOS7 for this driver. > >> +++ b/drivers/phy/Kconfig >> @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 >> >> config PHY_EXYNOS5_USBDRD >> tristate "Exynos5 SoC series USB DRD PHY driver" >> - depends on ARCH_EXYNOS5 && OF >> + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF > > shouldn't that prompt and its help text be updated to mention also Exynos7? Right, even that has to be updated accordingly. Will update the same in next version of the patch. Thanks for pointing this. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
Hi Felipe,
On Fri, Aug 29, 2014 at 12:46 AM, Felipe Balbi wrote:
> hi,
>
> On Thu, Aug 28, 2014 at 01:31:58PM +0530, Vivek Gautam wrote:
>> @@ -457,11 +458,19 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
>> clk_prepare_enable(phy_drd->ref_clk);
>>
>> /* Enable VBUS supply */
>> + if (phy_drd->vbus_boost) {
>> + ret = regulator_enable(phy_drd->vbus_boost);
>> + if (ret) {
>> + dev_err(phy_drd->dev,
>> + "Failed to enable VBUS boost supply\n");
>> + goto fail_vbus;
>> + }
>> + }
>
> really this is nitpicking, but can you add a blank line here just make
> my inner child happy ? :-)
Sure will add an extra line here and similar instances of this change.
>
>> @@ -470,6 +479,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
>>
>> return 0;
>>
>> +fail_vbus_boost:
>> + if (phy_drd->vbus_boost)
>> + regulator_disable(phy_drd->vbus_boost);
>
> same here
>
> --
> balbi
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
Hello,
On 2014-09-01 09:07, Thierry Reding wrote:
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
Hi Greg,
On 2014-08-05 12:47, Marek Szyprowski wrote:
This patch adds a new flags for device drivers. This flag instructs
kernel that the device driver does it own management of IOMMU assisted
IO address space translations, so no default dma-mapping structures
should be initialized.
Signed-off-by: Marek Szyprowski
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 5f4ff02..2e62371 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -253,6 +253,8 @@ struct device_driver {
/* disables bind/unbind via sysfs */
#define DRIVER_SUPPRESS_BIND_ATTRS (1 << 0)
+/* driver uses own methods to manage IO address space */
+#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 << 1)
extern int __must_check driver_register(struct device_driver *drv);
extern void driver_unregister(struct device_driver *drv);
Could you comment if the approach of using flags in the struct driver
could be accepted? I've converted suppress_bind_attrs entry to flags to
avoid extending the structure, please see patch "[PATCH 05/29] drivers:
convert suppress_bind_attrs parameter into flags".
Is this really necessary? What I did as part of an RFC series for Tegra
IOMMU support is keep this knowledge within the IOMMU driver rather than
export it to the driver core.i
The problem with embedding the list of drivers that you would need to update
it everytime when you modify or extend iommu support in the other drivers.
I've tried also other approach, like adding respective notifiers to
individual
drivers to initialize custom iommu support (or disable default iommu
mapping)
before iommu driver gets initialized, but such solution is in my opinion too
complex and hard to understand if one is not familiar will all this stuff.
All in all it turned out that the simplest and most generic way is to simply
add the flag to the driver core. Flags might be also used in the future
to model other kinds of dependencies between device drivers and/or driver
core.
The idea being that the IOMMU driver wouldn't create an ARM DMA/IOMMU
mapping by default but rather allow individual drivers to be marked as
"kernel-internal" and use the DMA/IOMMU glue in that case. Drivers such
as DRM would use the IOMMU API directly.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Fri, 22 Aug 2014, Pankaj Dubey wrote:
> From: Tomasz Figa
>
> Currently a syscon entity can be only registered directly through a
> platform device that binds to a dedicated driver. However in certain use
> cases it is desirable to make a device used with another driver a syscon
> interface provider. For example, certain SoCs (e.g. Exynos) contain
> system controller blocks which perform various functions such as power
> domain control, CPU power management, low power mode control, but in
> addition contain certain IP integration glue, such as various signal
> masks, coprocessor power control, etc. In such case, there is a need to
> have a dedicated driver for such system controller but also share
> registers with other drivers. The latter is where the syscon interface
> is helpful.
>
> This patch decouples syscon object from syscon driver, so that it can be
> registered from any driver in addition to the original "syscon" platform
> driver.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Pankaj Dubey
> ---
>
> RFC patch [1] was posted by Tomasz Figa. This patch addresses some of
> comments given by Arnd to RFC patch, and further decouples syscon from
> device model. It also gives flexibility of registering with syscon at
> early stage using device_node object.
It would be helpful if Arnd gave this revision his blessing (Ack).
> [1]: https://lkml.org/lkml/2014/6/17/331
>
> drivers/mfd/syscon.c | 112
>
> include/linux/mfd/syscon.h | 14 ++
> 2 files changed, 86 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index ca15878..a91db30 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -14,6 +14,7 @@
[...]
> struct regmap *syscon_regmap_lookup_by_pdevname(const char *s)
> {
> - struct device *dev;
> - struct syscon *syscon;
> -
> - dev = driver_find_device(&syscon_driver.driver, NULL, (void *)s,
> - syscon_match_pdevname);
> - if (!dev)
> - return ERR_PTR(-EPROBE_DEFER);
> -
> - syscon = dev_get_drvdata(dev);
> + struct syscon *entry, *syscon = NULL;
> + struct platform_device *pdev = NULL;
> +
> + spin_lock(&syscon_list_slock);
> + list_for_each_entry(entry, &syscon_list, list) {
> + pdev = of_find_device_by_node(entry->np);
White space error.
Did you run this through checkpatch.pl?
> + if (pdev && !strcmp(dev_name(&pdev->dev), s)) {
> + syscon = entry;
> + break;
> + }
> + }
> + spin_unlock(&syscon_list_slock);
>
> - return syscon->regmap;
> + return syscon ? syscon->regmap : ERR_PTR(-EPROBE_DEFER);
> }
> EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_pdevname);
[...]
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/29] drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
> Hi Greg,
>
> On 2014-08-05 12:47, Marek Szyprowski wrote:
> > This patch adds a new flags for device drivers. This flag instructs
> > kernel that the device driver does it own management of IOMMU assisted
> > IO address space translations, so no default dma-mapping structures
> > should be initialized.
> >
> > Signed-off-by: Marek Szyprowski
> > ---
> > include/linux/device.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 5f4ff02..2e62371 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -253,6 +253,8 @@ struct device_driver {
> >
> > /* disables bind/unbind via sysfs */
> > #define DRIVER_SUPPRESS_BIND_ATTRS(1 << 0)
> > +/* driver uses own methods to manage IO address space */
> > +#define DRIVER_HAS_OWN_IOMMU_MANAGER (1 << 1)
> >
> > extern int __must_check driver_register(struct device_driver *drv);
> > extern void driver_unregister(struct device_driver *drv);
>
> Could you comment if the approach of using flags in the struct driver
> could be accepted? I've converted suppress_bind_attrs entry to flags to
> avoid extending the structure, please see patch "[PATCH 05/29] drivers:
> convert suppress_bind_attrs parameter into flags".
Is this really necessary? What I did as part of an RFC series for Tegra
IOMMU support is keep this knowledge within the IOMMU driver rather than
export it to the driver core.
The idea being that the IOMMU driver wouldn't create an ARM DMA/IOMMU
mapping by default but rather allow individual drivers to be marked as
"kernel-internal" and use the DMA/IOMMU glue in that case. Drivers such
as DRM would use the IOMMU API directly.
Thierry
pgp4tBk3cYzvn.pgp
Description: PGP signature
