* Removing PLAT_ORION dependency from ARCH_MVEBU (Was Re: [PATCH v2 14/15] watchdog: orion: Allow to build on any Orion platform)
From: Sebastian Hesselbarth @ 2014-01-21 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121110603.GB4356@localhost>
On 01/21/14 12:06, Ezequiel Garcia wrote:
> Sebastian,
>
> I'm picking on this discussion, with a new Subject.
>
> On Tue, Jan 21, 2014 at 10:41:17AM +0100, Sebastian Hesselbarth wrote:
>> On 01/21/14 10:12, Ezequiel Garcia wrote:
>>> After getting rid of all the mach-specific code, it's now possible
>>> to allow builds in any Orion platform.
>>>
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>>> ---
>>> drivers/watchdog/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>>> index 5be6e91..1689f72 100644
>>> --- a/drivers/watchdog/Kconfig
>>> +++ b/drivers/watchdog/Kconfig
>>> @@ -282,7 +282,7 @@ config DAVINCI_WATCHDOG
>>>
>>> config ORION_WATCHDOG
>>> tristate "Orion watchdog"
>>> - depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE
>>> + depends on PLAT_ORION
> [..]
>>
>> I haven't checked why ARCH_MVEBU at all added PLAT_ORION as dependency,
>> but IIRC it was just because of a missing mbus driver? If it is just
>> this, we should also remove PLAT_ORION from ARCH_MVEBU to have a clean
>> cut between new common arch and existing sub-archs.
>>
>
> Well, I'm not sure if I'm following you. Many drivers currently depend
> on PLAT_ORION, so if we remove PLAT_ORION from ARCH_MVEBU we would have
> to replace: s/PLAT_ORION/ARCH_{MVEBU, KIRKWOOD, DOVE, ...}.
>
> Is this the suggested roadmap or I've completely misunderstood it?
Actually, you are right, PLAT_ORION is dependency for a bunch of
drivers. But as PLAT_ORION - code-wise - almost only contains non-DT
stuff, I'd prefer to use ARCH_MVEBU for DT enabled Marvell SoCs where
possible.
So for the above, just add ARCH_MVEBU and remove ARCH_KIRKWOOD,
ARCH_DOVE later when we kill them, instead of hiding all behind
PLAT_ORION. Also remove the dependency of ARCH_MVEBU to PLAT_ORION
where possible or replace it with ARCH_MVEBU directly.
This way we would have a clean ARCH_MVEBU config for DT-enabled
SoCs and PLAT_ORION for non-DT ones. BTW, there is also
PLAT_ORION_LEGACY which is just selecting PLAT_ORION. IIRC, I added
that to distinguish non-DT and DT earlier, but ARCH_MVEBU selecting
PLAT_ORION made that redundant.
Sebastian
^ permalink raw reply
* [PATCH v2 5/7] clk: exynos: use cpu-clock provider type to represent arm clock
From: Lukasz Majewski @ 2014-01-21 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9agR182H1NPj8N6TmBhBvKEk=QvKqNa_7T95SA5GxqQXGg@mail.gmail.com>
Hi Thomas,
> Hi Lukasz,
>
> On Tue, Jan 21, 2014 at 4:08 PM, Lukasz Majewski
> <l.majewski@samsung.com> wrote:
> > Hi Thomas,
> >
> >> On Mon, Jan 20, 2014 at 1:17 PM, Lukasz Majewski
> >> <l.majewski@samsung.com> wrote:
> >> > Hi Thomas,
> >> >
> >> >> From: Thomas Abraham <thomas.ab@samsung.com>
> >> >>
> >> >> With the addition of the new Samsung specific cpu-clock type,
> >> >> the arm clock can be represented as a cpu-clock type and the
> >> >> independent clock blocks that made up the arm clock can be
> >> >> removed.
> >> >>
> >> >> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> >> >> ---
> >> >> .../devicetree/bindings/clock/exynos5250-clock.txt | 1 +
> >> >> drivers/clk/samsung/clk-exynos4.c | 11
> >> >> +++++------ drivers/clk/samsung/clk-exynos5250.c
> >> >> | 8 ++++---- include/dt-bindings/clock/exynos5250.h
> >> >> | 1 + 4 files changed, 11 insertions(+), 10 deletions(-)
> >> >>
> >> >> diff --git
> >> >> a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> >> >> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> >> >> index 99eae9c..acf867a 100644 ---
> >> >> a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> >> >> +++
> >> >> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> >> >> @@ -38,6 +38,7 @@ clock which they consume.
> >> >> ---------------------------- fin_pll 1
> >> >> + armclk 12
> >> >>
> >> >> [Clock Gate for Special Clocks]
> >> >>
> >> >> diff --git a/drivers/clk/samsung/clk-exynos4.c
> >> >> b/drivers/clk/samsung/clk-exynos4.c index 010f071..efcf4a3
> >> >> 100644 --- a/drivers/clk/samsung/clk-exynos4.c
> >> >> +++ b/drivers/clk/samsung/clk-exynos4.c
> >> >> @@ -437,8 +437,6 @@ static struct samsung_mux_clock
> >> >> exynos4x12_mux_clks[] __initdata = {
> >> >> /* list of divider clocks supported in all exynos4 soc's */
> >> >> static struct samsung_div_clock exynos4_div_clks[] __initdata
> >> >> = {
> >> >> - DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
> >> >> - DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
> >> >> DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
> >> >> DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
> >> >> DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
> >> >> @@ -484,8 +482,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_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
> >> >> - 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, 0),
> >> >> 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,
> >> >> @@ -870,7 +868,6 @@ static struct samsung_gate_clock
> >> >> exynos4x12_gate_clks[] __initdata = {
> >> >> static struct samsung_clock_alias exynos4_aliases[] __initdata
> >> >> = { ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
> >> >> - ALIAS(CLK_ARM_CLK, NULL, "armclk"),
> >> >> ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
> >> >> };
> >> >>
> >> >> @@ -1125,12 +1122,14 @@ static void __init
> >> >> exynos4_clk_init(struct device_node *np,
> >> >> samsung_clk_register_alias(exynos4_aliases,
> >> >> ARRAY_SIZE(exynos4_aliases));
> >> >>
> >> >> + samsung_register_arm_clock(np, CLK_ARM_CLK, "mout_apll",
> >> >> reg_base); +
> >> >
> >> > I've got some doubts about allowing only the "mout_apll" clock to
> >> > be the only parent for armclk Samsung clock.
> >> >
> >> > For the Exynos4412 it is also valid to have SCLK_MPLL_USER_C [*]
> >> > as a parent for this clock.
> >> >
> >> > The problem is that you are reparenting the armclk to [*] with
> >> > the register modification - no CCF involved.
> >>
> >> The MUX_CORE mux is part of the larger cpu clock type and not
> >> registered as a separate mux clock with CCF. So I would like to
> >> know if there are any potential issues you see if this mux clock is
> >> internally managed within the set_rate of the larger cpu clock
> >> type.
> >
> > So the large opaque clock (armclk) starts with inputs to MUX_CORE
> > (and embrace this MUX as well)?
>
> Yes, the MUX_CORE is now part of the large opaque clock and will only
> use mout_apll as the parent clock. The other parent will be used
> temporarily only when the frequency of the mout_apll (leading to APLL)
> has to be changed.
>
> >
> > If yes, then I don't mind if it is solely managed inside the armclk.
> >
> > This however allows the armclk to be fed from mout_apll[*] and
> > sclk_mpll__user_c[**]. And this would be nice if reflected in the
> > code.
>
> Okay.
>
> >
> >>
> >> >
> >> > I just would like to know if this is yours design decision or
> >> > something, that we have overlooked in the v1 of this patch
> >> > series.
> >>
> >> I did overlook this one. This will be fixed in the next version by
> >> ensuring that the dividers for SCLK_HPM clock will be updated only
> >> if mout_apll is the parent of the MUX_HPM clock mux.
> >
> > Shall not they be updated if whatever connected to the MUX_HPM
> > ([*] and [**]) changes?
>
> They will be updated if their parent is mout_apll. If their parent is
> a MPLL sourced clock, the divider will not be updated since the set
> rate on this opaque clock will not change the frequency of the MPLL
> sourced clock.
Ok, Thanks for clarification.
>
> Thanks,
> Thomas.
>
> >
> >>
> >> Thanks,
> >> Thomas.
> >>
> >> >
> >> >> pr_info("%s clocks: sclk_apll = %ld, sclk_mpll = %ld\n"
> >> >> "\tsclk_epll = %ld, sclk_vpll = %ld, arm_clk =
> >> >> %ld\n", exynos4_soc == EXYNOS4210 ? "Exynos4210" : "Exynos4x12",
> >> >> _get_rate("sclk_apll"),
> >> >> _get_rate("sclk_mpll"), _get_rate("sclk_epll"),
> >> >> _get_rate("sclk_vpll"),
> >> >> - _get_rate("arm_clk"));
> >> >> + _get_rate("armclk"));
> >> >> }
> >> >>
> >> >>
> >> >> diff --git a/drivers/clk/samsung/clk-exynos5250.c
> >> >> b/drivers/clk/samsung/clk-exynos5250.c index ff4beeb..487be36
> >> >> 100644 --- a/drivers/clk/samsung/clk-exynos5250.c
> >> >> +++ b/drivers/clk/samsung/clk-exynos5250.c
> >> >> @@ -298,9 +298,8 @@ static struct samsung_div_clock
> >> >> exynos5250_div_clks[] __initdata = { /*
> >> >> * CMU_CPU
> >> >> */
> >> >> - DIV(0, "div_arm", "mout_cpu", DIV_CPU0, 0, 3),
> >> >> - DIV(0, "div_apll", "mout_apll", DIV_CPU0, 24, 3),
> >> >> - DIV_A(0, "div_arm2", "div_arm", DIV_CPU0, 28, 3,
> >> >> "armclk"),
> >> >> + DIV_F(0, "div_apll", "mout_apll", DIV_CPU0, 24, 3,
> >> >> + CLK_GET_RATE_NOCACHE, 0),
> >> >>
> >> >> /*
> >> >> * CMU_TOP
> >> >> @@ -684,8 +683,9 @@ static void __init
> >> >> exynos5250_clk_init(struct device_node *np)
> >> >> ARRAY_SIZE(exynos5250_div_clks));
> >> >> samsung_clk_register_gate(exynos5250_gate_clks,
> >> >> ARRAY_SIZE(exynos5250_gate_clks));
> >> >> + samsung_register_arm_clock(np, CLK_ARM_CLK, "mout_apll",
> >> >> reg_base);
> >> >> pr_info("Exynos5250: clock setup completed, armclk=%ld\n",
> >> >> - _get_rate("div_arm2"));
> >> >> + _get_rate("armclk"));
> >> >> }
> >> >> CLK_OF_DECLARE(exynos5250_clk, "samsung,exynos5250-clock",
> >> >> exynos5250_clk_init); diff --git
> >> >> a/include/dt-bindings/clock/exynos5250.h
> >> >> b/include/dt-bindings/clock/exynos5250.h index 922f2dc..59a10fb
> >> >> 100644 --- a/include/dt-bindings/clock/exynos5250.h +++
> >> >> b/include/dt-bindings/clock/exynos5250.h @@ -21,6 +21,7 @@
> >> >> #define CLK_FOUT_CPLL 6
> >> >> #define CLK_FOUT_EPLL 7
> >> >> #define CLK_FOUT_VPLL 8
> >> >> +#define CLK_ARM_CLK 12
> >> >>
> >> >> /* gate for special clocks (sclk) */
> >> >> #define CLK_SCLK_CAM_BAYER 128
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> > Lukasz Majewski
> >> >
> >> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> >
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* [RESEND][RFC PATCH 0/2] Early patches to get rid of meminfo
From: Leif Lindholm @ 2014-01-21 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389813057-26572-1-git-send-email-lauraa@codeaurora.org>
On Wed, Jan 15, 2014 at 11:10:55AM -0800, Laura Abbott wrote:
> With the move away from bootmem and the convergence on memblock, it seems
> like meminfo should be deprecated as well to avoid duplication. This is
> a first pass attempt to just use memblock and not have meminfo integrated.
> There is still a major issue in terms of actually specifying mem at location
> on the command line but I wanted to send this out for some early feedback
> before putting any more effort into this. I've done basic boot testing on
> a simple DT target.
Well, this set makes takes away most of the complexity of using the
UEFI memory map instead of DT for populating memblock.
I'm all for it.
/
Leif
^ permalink raw reply
* [RFC PATCH 0/3] Add support for dwarf compat mode unwinding
From: Will Deacon @ 2014-01-21 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390252922-25889-1-git-send-email-jean.pihet@linaro.org>
On Mon, Jan 20, 2014 at 09:21:59PM +0000, Jean Pihet wrote:
> In the case of unwinding the debug info from a binary that has a different
> address size than the current native platform, it is needed to record
> it in the address space struct, in order to correctly parse the debug
> info later. This mode is known as compat mode.
Terminology issues here.... compat mode isn't really that well defined, but
typically involves a different kernel ABI. That doesn't necessarily affect
the address size.
> This is the case when e.g. profiling an ARMv7 binary that runs on an
> ARMv8 (aka AARCH64) platform.
ARMv8 != AArch64
Will
^ permalink raw reply
* [PATCH] ARM64: perf: support dwarf unwinding in compat mode
From: Will Deacon @ 2014-01-21 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFrcx1=53sUDjxa-DjuJUScxanhQJqAVA36RaYNo5-Dfegij7g@mail.gmail.com>
On Mon, Jan 20, 2014 at 05:05:14PM +0000, Jean Pihet wrote:
> Hi Will,
>
> Here is an updated version of the change, which uses compat_sp at only
> one place.
> The drawback is that compat_user_mode is checked when calling
> compat_user_stack_pointer, which seems unnecessary. Unfortunately the
> check is not optimized out by the complier as I could check with
> objdump -S.
>
> What do you think?
I think that's cleaner and really wouldn't worry about the couple of extra
instructions.
Cheers,
Will
> diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
> index fda2704..e71f81f 100644
> --- a/arch/arm64/include/asm/compat.h
> +++ b/arch/arm64/include/asm/compat.h
> @@ -228,7 +228,7 @@ static inline compat_uptr_t ptr_to_compat(void __user *uptr)
> return (u32)(unsigned long)uptr;
> }
>
> -#define compat_user_stack_pointer() (current_pt_regs()->compat_sp)
> +#define compat_user_stack_pointer() (user_stack_pointer(current_pt_regs()))
>
> static inline void __user *arch_compat_alloc_user_space(long len)
> {
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index fbb0020..86d5b54 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -133,7 +133,7 @@ struct pt_regs {
> (!((regs)->pstate & PSR_F_BIT))
>
> #define user_stack_pointer(regs) \
> - ((regs)->sp)
> + (!compat_user_mode(regs)) ? ((regs)->sp) : ((regs)->compat_sp)
>
> /*
> * Are the current registers suitable for user mode? (used to maintain
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Vincent Guittot @ 2014-01-21 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390240079-6495-3-git-send-email-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On 20 January 2014 18:47, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> ARM based platforms implement a variety of power management schemes that
> allow processors to enter at run-time low-power states, aka C-states
> in ACPI jargon. The parameters defining these C-states vary on a per-platform
> basis forcing the OS to hardcode the state parameters in platform
> specific static tables whose size grows as the number of platforms supported
> in the kernel increases and hampers device drivers standardization.
>
> Therefore, this patch aims at standardizing C-state device tree bindings for
> ARM platforms. Bindings define C-state parameters inclusive of entry methods
> and state latencies, to allow operating systems to retrieve the
> configuration entries from the device tree and initialize the related
> power management drivers, paving the way for common code in the kernel
> to deal with power states and removing the need for static data in current
> and previous kernel versions.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> Documentation/devicetree/bindings/arm/c-states.txt | 774 +++++++++++++++++++++
> Documentation/devicetree/bindings/arm/cpus.txt | 10 +
> 2 files changed, 784 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/c-states.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/c-states.txt b/Documentation/devicetree/bindings/arm/c-states.txt
> new file mode 100644
> index 0000000..0b5617b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/c-states.txt
> @@ -0,0 +1,774 @@
> +==========================================
> +ARM C-states binding description
> +==========================================
> +
> +==========================================
> +1 - Introduction
> +==========================================
> +
> +ARM systems contain HW capable of managing power consumption dynamically,
> +where cores can be put in different low-power states (ranging from simple
> +wfi to power gating) according to OSPM policies. Borrowing concepts
> +from the ACPI specification[1], the CPU states representing the range of
> +dynamic states that a processor can enter at run-time, aka C-state, can be
> +specified through device tree bindings representing the parameters required to
> +enter/exit specific C-states on a given processor.
> +
> +The state an ARM CPU can be put into is loosely identified by one of the
> +following operating modes:
> +
> +- Running:
> + # Processor core is executing instructions
> +
> +- Wait for Interrupt:
> + # An ARM processor enters wait for interrupt (WFI) low power
> + state by executing a wfi instruction. When a processor enters
> + wfi state it disables most of the clocks while keeping the processor
> + powered up. This state is standard on all ARM processors and it is
> + defined as C1 in the remainder of this document.
> +
> +- Dormant:
> + # Dormant mode is entered by executing wfi instructions and by sending
> + platform specific commands to the platform power controller (coupled
> + with processor specific SW/HW control sequences).
> + In dormant mode, most of the processor control and debug logic is
> + powered up but cache RAM can be put in retention state, providing
Base on your description, it's not clear for me what is on, what is
lost and what is power down ?
My understand of the dormant mode that you described above is : the
cache is preserved (and especially the cache RAM) but the processor
state is lost (registers ...). Do I understand correctly ?
What about retention mode where the contents of processor and cache
are preserved but the power consumption is reduced ? it can be seen as
a special wfi mode which need specific SW/HW control sequences but i'm
not sure to understand how to describe such state with your proposal.
> + additional power savings.
> +
> +- Sleep:
> + # Sleep mode is entered by executing the wfi instruction and by sending
> + platform specific commands to the platform power controller (coupled
> + with processor specific SW/HW control sequences). In sleep mode, a
> + processor and its caches are shutdown, the entire processor state is
> + lost.
> +
> +Building on top of the previous processor modes, ARM platforms implement power
> +management schemes that allow an OS PM implementation to put the processor in
> +different CPU states (C-states). C-states parameters (eg latency) are
> +platform specific and need to be characterized with bindings that provide the
> +required information to OSPM code so that it can build the required tables and
> +use them at runtime.
> +
> +The device tree binding definition for ARM C-states is the subject of this
> +document.
> +
[snip]
> +
> + - psci-power-state
> + Usage: Required if entry-method property value is set to
> + "psci".
> + Value type: <u32>
> + Definition: power_state parameter to pass to the PSCI
> + suspend call to enter the C-state.
Why psci has got a dedicated field and not vendor methods ? can't you
make that more generic ?
> +
> + - latency
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: List of u32 values representing worst case latency
> + in microseconds required to enter and exit the
> + C-state, one value per OPP [2]. The list should
> + be specified in the same order as the operating
> + points property list of the cpu this state is
> + valid on.
> + If no OPP bindings are present, the latency value
> + is associated with the current OPP of CPUs in the
> + system.
> +
[snip]
Thanks
Vincent
^ permalink raw reply
* [PATCH v2 5/7] clk: exynos: use cpu-clock provider type to represent arm clock
From: Thomas Abraham @ 2014-01-21 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121113855.3875555d@amdc2363>
Hi Lukasz,
On Tue, Jan 21, 2014 at 4:08 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Thomas,
>
>> On Mon, Jan 20, 2014 at 1:17 PM, Lukasz Majewski
>> <l.majewski@samsung.com> wrote:
>> > Hi Thomas,
>> >
>> >> From: Thomas Abraham <thomas.ab@samsung.com>
>> >>
>> >> With the addition of the new Samsung specific cpu-clock type, the
>> >> arm clock can be represented as a cpu-clock type and the
>> >> independent clock blocks that made up the arm clock can be removed.
>> >>
>> >> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> >> ---
>> >> .../devicetree/bindings/clock/exynos5250-clock.txt | 1 +
>> >> drivers/clk/samsung/clk-exynos4.c | 11
>> >> +++++------ drivers/clk/samsung/clk-exynos5250.c
>> >> | 8 ++++---- include/dt-bindings/clock/exynos5250.h
>> >> | 1 + 4 files changed, 11 insertions(+), 10 deletions(-)
>> >>
>> >> diff --git
>> >> a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> >> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
>> >> index 99eae9c..acf867a 100644 ---
>> >> a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++
>> >> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@
>> >> -38,6 +38,7 @@ clock which they consume.
>> >> ---------------------------- fin_pll 1
>> >> + armclk 12
>> >>
>> >> [Clock Gate for Special Clocks]
>> >>
>> >> diff --git a/drivers/clk/samsung/clk-exynos4.c
>> >> b/drivers/clk/samsung/clk-exynos4.c index 010f071..efcf4a3 100644
>> >> --- a/drivers/clk/samsung/clk-exynos4.c
>> >> +++ b/drivers/clk/samsung/clk-exynos4.c
>> >> @@ -437,8 +437,6 @@ static struct samsung_mux_clock
>> >> exynos4x12_mux_clks[] __initdata = {
>> >> /* list of divider clocks supported in all exynos4 soc's */
>> >> static struct samsung_div_clock exynos4_div_clks[] __initdata = {
>> >> - DIV(0, "div_core", "mout_core", DIV_CPU0, 0, 3),
>> >> - DIV(0, "div_core2", "div_core", DIV_CPU0, 28, 3),
>> >> DIV(0, "div_fimc0", "mout_fimc0", DIV_CAM, 0, 4),
>> >> DIV(0, "div_fimc1", "mout_fimc1", DIV_CAM, 4, 4),
>> >> DIV(0, "div_fimc2", "mout_fimc2", DIV_CAM, 8, 4),
>> >> @@ -484,8 +482,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_ARM_CLK, "arm_clk", "div_core2", DIV_CPU0, 28, 3),
>> >> - 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, 0),
>> >> 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,
>> >> @@ -870,7 +868,6 @@ static struct samsung_gate_clock
>> >> exynos4x12_gate_clks[] __initdata = {
>> >> static struct samsung_clock_alias exynos4_aliases[] __initdata = {
>> >> ALIAS(CLK_MOUT_CORE, NULL, "moutcore"),
>> >> - ALIAS(CLK_ARM_CLK, NULL, "armclk"),
>> >> ALIAS(CLK_SCLK_APLL, NULL, "mout_apll"),
>> >> };
>> >>
>> >> @@ -1125,12 +1122,14 @@ static void __init exynos4_clk_init(struct
>> >> device_node *np, samsung_clk_register_alias(exynos4_aliases,
>> >> ARRAY_SIZE(exynos4_aliases));
>> >>
>> >> + samsung_register_arm_clock(np, CLK_ARM_CLK, "mout_apll",
>> >> reg_base); +
>> >
>> > I've got some doubts about allowing only the "mout_apll" clock to
>> > be the only parent for armclk Samsung clock.
>> >
>> > For the Exynos4412 it is also valid to have SCLK_MPLL_USER_C [*] as
>> > a parent for this clock.
>> >
>> > The problem is that you are reparenting the armclk to [*] with the
>> > register modification - no CCF involved.
>>
>> The MUX_CORE mux is part of the larger cpu clock type and not
>> registered as a separate mux clock with CCF. So I would like to know
>> if there are any potential issues you see if this mux clock is
>> internally managed within the set_rate of the larger cpu clock type.
>
> So the large opaque clock (armclk) starts with inputs to MUX_CORE (and
> embrace this MUX as well)?
Yes, the MUX_CORE is now part of the large opaque clock and will only
use mout_apll as the parent clock. The other parent will be used
temporarily only when the frequency of the mout_apll (leading to APLL)
has to be changed.
>
> If yes, then I don't mind if it is solely managed inside the armclk.
>
> This however allows the armclk to be fed from mout_apll[*] and
> sclk_mpll__user_c[**]. And this would be nice if reflected in the code.
Okay.
>
>>
>> >
>> > I just would like to know if this is yours design decision or
>> > something, that we have overlooked in the v1 of this patch series.
>>
>> I did overlook this one. This will be fixed in the next version by
>> ensuring that the dividers for SCLK_HPM clock will be updated only if
>> mout_apll is the parent of the MUX_HPM clock mux.
>
> Shall not they be updated if whatever connected to the MUX_HPM
> ([*] and [**]) changes?
They will be updated if their parent is mout_apll. If their parent is
a MPLL sourced clock, the divider will not be updated since the set
rate on this opaque clock will not change the frequency of the MPLL
sourced clock.
Thanks,
Thomas.
>
>>
>> Thanks,
>> Thomas.
>>
>> >
>> >> pr_info("%s clocks: sclk_apll = %ld, sclk_mpll = %ld\n"
>> >> "\tsclk_epll = %ld, sclk_vpll = %ld, arm_clk =
>> >> %ld\n", exynos4_soc == EXYNOS4210 ? "Exynos4210" : "Exynos4x12",
>> >> _get_rate("sclk_apll"),
>> >> _get_rate("sclk_mpll"), _get_rate("sclk_epll"),
>> >> _get_rate("sclk_vpll"),
>> >> - _get_rate("arm_clk"));
>> >> + _get_rate("armclk"));
>> >> }
>> >>
>> >>
>> >> diff --git a/drivers/clk/samsung/clk-exynos5250.c
>> >> b/drivers/clk/samsung/clk-exynos5250.c index ff4beeb..487be36
>> >> 100644 --- a/drivers/clk/samsung/clk-exynos5250.c
>> >> +++ b/drivers/clk/samsung/clk-exynos5250.c
>> >> @@ -298,9 +298,8 @@ static struct samsung_div_clock
>> >> exynos5250_div_clks[] __initdata = { /*
>> >> * CMU_CPU
>> >> */
>> >> - DIV(0, "div_arm", "mout_cpu", DIV_CPU0, 0, 3),
>> >> - DIV(0, "div_apll", "mout_apll", DIV_CPU0, 24, 3),
>> >> - DIV_A(0, "div_arm2", "div_arm", DIV_CPU0, 28, 3, "armclk"),
>> >> + DIV_F(0, "div_apll", "mout_apll", DIV_CPU0, 24, 3,
>> >> + CLK_GET_RATE_NOCACHE, 0),
>> >>
>> >> /*
>> >> * CMU_TOP
>> >> @@ -684,8 +683,9 @@ static void __init exynos5250_clk_init(struct
>> >> device_node *np) ARRAY_SIZE(exynos5250_div_clks));
>> >> samsung_clk_register_gate(exynos5250_gate_clks,
>> >> ARRAY_SIZE(exynos5250_gate_clks));
>> >> + samsung_register_arm_clock(np, CLK_ARM_CLK, "mout_apll",
>> >> reg_base);
>> >> pr_info("Exynos5250: clock setup completed, armclk=%ld\n",
>> >> - _get_rate("div_arm2"));
>> >> + _get_rate("armclk"));
>> >> }
>> >> CLK_OF_DECLARE(exynos5250_clk, "samsung,exynos5250-clock",
>> >> exynos5250_clk_init); diff --git
>> >> a/include/dt-bindings/clock/exynos5250.h
>> >> b/include/dt-bindings/clock/exynos5250.h index 922f2dc..59a10fb
>> >> 100644 --- a/include/dt-bindings/clock/exynos5250.h +++
>> >> b/include/dt-bindings/clock/exynos5250.h @@ -21,6 +21,7 @@
>> >> #define CLK_FOUT_CPLL 6
>> >> #define CLK_FOUT_EPLL 7
>> >> #define CLK_FOUT_VPLL 8
>> >> +#define CLK_ARM_CLK 12
>> >>
>> >> /* gate for special clocks (sclk) */
>> >> #define CLK_SCLK_CAM_BAYER 128
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > Lukasz Majewski
>> >
>> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* [PATCH v3] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Will Deacon @ 2014-01-21 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1401201523240.21510@kaball.uk.xensource.com>
On Mon, Jan 20, 2014 at 03:32:48PM +0000, Stefano Stabellini wrote:
> On Thu, 16 Jan 2014, Will Deacon wrote:
> > For the xchg part, yes, that looks a lot better. I don't like the #undef
> > CONFIG_CPU_V6 though, can that be rewritten to use __LINUX_ARM_ARCH__?
>
> The problem is that the 1 and 2 byte parameter size cases in __cmpxchg
> are ifdef'ed CONFIG_CPU_V6 but drivers/xen/grant-table.c needs them.
>
> So we can either undef CONFIG_CPU_V6 in grant-table.c or call a
> different function.
>
> If I switch from ifdef CONFIG_CPU_V6 to if __LINUX_ARM_ARCH__ > 6 in
> __cmpxchg, we still have the problem that if __LINUX_ARM_ARCH__ == 6,
> grant-table.c doesn't compile.
>
> Maybe the approach taken by the other patch for cmpxchg is better, see
> below.
Yes, I prefer this approach. Minor comment below.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index c1f1a7e..ae54ae0 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1881,8 +1881,7 @@ config XEN_DOM0
> config XEN
> bool "Xen guest support on ARM (EXPERIMENTAL)"
> depends on ARM && AEABI && OF
> - depends on CPU_V7 && !CPU_V6
> - depends on !GENERIC_ATOMIC64
> + depends on CPU_V7
> select ARM_PSCI
> select SWIOTLB_XEN
> help
> diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
> index df2fbba..cc8a4a2 100644
> --- a/arch/arm/include/asm/cmpxchg.h
> +++ b/arch/arm/include/asm/cmpxchg.h
> @@ -133,6 +133,44 @@ extern void __bad_cmpxchg(volatile void *ptr, int size);
> * cmpxchg only support 32-bits operands on ARMv6.
> */
>
> +static inline unsigned long __cmpxchg8(volatile void *ptr, unsigned long old,
> + unsigned long new)
> +{
> + unsigned long oldval, res;
> +
> + do {
> + asm volatile("@ __cmpxchg1\n"
> + " ldrexb %1, [%2]\n"
> + " mov %0, #0\n"
> + " teq %1, %3\n"
> + " strexbeq %0, %4, [%2]\n"
> + : "=&r" (res), "=&r" (oldval)
> + : "r" (ptr), "Ir" (old), "r" (new)
> + : "memory", "cc");
> + } while (res);
> +
> + return oldval;
> +}
> +
> +static inline unsigned long __cmpxchg16(volatile void *ptr, unsigned long old,
> + unsigned long new)
> +{
> + unsigned long oldval, res;
> +
> + do {
> + asm volatile("@ __cmpxchg1\n"
Can you fix this comment while you're here please?
Will
^ permalink raw reply
* Removing PLAT_ORION dependency from ARCH_MVEBU (Was Re: [PATCH v2 14/15] watchdog: orion: Allow to build on any Orion platform)
From: Ezequiel Garcia @ 2014-01-21 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DE40BD.10700@gmail.com>
Sebastian,
I'm picking on this discussion, with a new Subject.
On Tue, Jan 21, 2014 at 10:41:17AM +0100, Sebastian Hesselbarth wrote:
> On 01/21/14 10:12, Ezequiel Garcia wrote:
> > After getting rid of all the mach-specific code, it's now possible
> > to allow builds in any Orion platform.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> > ---
> > drivers/watchdog/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index 5be6e91..1689f72 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -282,7 +282,7 @@ config DAVINCI_WATCHDOG
> >
> > config ORION_WATCHDOG
> > tristate "Orion watchdog"
> > - depends on ARCH_ORION5X || ARCH_KIRKWOOD || ARCH_DOVE
> > + depends on PLAT_ORION
[..]
>
> I haven't checked why ARCH_MVEBU at all added PLAT_ORION as dependency,
> but IIRC it was just because of a missing mbus driver? If it is just
> this, we should also remove PLAT_ORION from ARCH_MVEBU to have a clean
> cut between new common arch and existing sub-archs.
>
Well, I'm not sure if I'm following you. Many drivers currently depend
on PLAT_ORION, so if we remove PLAT_ORION from ARCH_MVEBU we would have
to replace: s/PLAT_ORION/ARCH_{MVEBU, KIRKWOOD, DOVE, ...}.
Is this the suggested roadmap or I've completely misunderstood it?
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] arm64: mm: use ubfm for dcache_line_size
From: Will Deacon @ 2014-01-21 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002501cf159c$85a358b0$90ea0a10$%han@samsung.com>
On Mon, Jan 20, 2014 at 05:00:21AM +0000, Jingoo Han wrote:
> Use 'ubfm' for the bitfield move instruction; thus, single
> instruction can be used instead of two instructions, when
> getting the minimum D-cache line size from CTR_EL0 register.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Thanks,
Will
> ---
> Change since v1
> - Remove unnecessary prefix '0x' from immediates, per Will Deacon
> - Add '#' to immediates for consistency, per Ard Biesheuvel
>
> arch/arm64/mm/proc-macros.S | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/proc-macros.S b/arch/arm64/mm/proc-macros.S
> index 8957b82..005d29e 100644
> --- a/arch/arm64/mm/proc-macros.S
> +++ b/arch/arm64/mm/proc-macros.S
> @@ -38,8 +38,7 @@
> */
> .macro dcache_line_size, reg, tmp
> mrs \tmp, ctr_el0 // read CTR
> - lsr \tmp, \tmp, #16
> - and \tmp, \tmp, #0xf // cache line size encoding
> + ubfm \tmp, \tmp, #16, #19 // cache line size encoding
> mov \reg, #4 // bytes per word
> lsl \reg, \reg, \tmp // actual cache line size
> .endm
> --
> 1.7.10.4
>
>
>
^ permalink raw reply
* [PATCH v2 02/15] clocksource: orion: Use atomic access for shared registers
From: Andrew Lunn @ 2014-01-21 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4103670.WQZpL6dQdj@wuerfel>
> > The real problem with this is that it resides in orion-time.c which
> > is fine for Orion SoCs. Armada 370/XP use a different timer and
> > therefore the _common_ watchdog driver cannot call this function.
>
> Right, I had missed this part.
>
> > Moreover, Dove (out of Orion) and Armada 370/XP will happily live in
> > one V7 kernel with both time-orion and time-armada-370-xp compiled in.
>
> It still wouldn't be too hard to do: both clock drivers could export
> functions with different identifiers, and the wdt driver can use
> conditional compilation (#ifdef or if(IS_ENABLED())) to only call
> those functions when the respective clocksource drivers are enabled.
Hi Arnd.
The plan is to make dove part of MULTI_V7. At that point, you have
both dove and armada-370-xp in the same kernel. Conditional
compilation does not work, the watchdog driver would need to know at
runtime which timer is in use, and call the right timer function.
I'm working on making DT Kirkwood part of MULTI_V5. The changes needed
are mostly trivial. I expect making Dove part of MULTI_V7 is also
trivial, so could happen during the next cycle. So this mix of Dove
and Armada 370 XP is not a theoretical problem, it is something which
needs to be solved ready for merging during the next window.
Andrew
^ permalink raw reply
* [PATCH v2] dma: imx-sdma: clarify firmare not found warning
From: Russell King - ARM Linux @ 2014-01-21 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121075922.2a83e076@ipc1.ka-ro>
On Tue, Jan 21, 2014 at 07:59:22AM +0100, Lothar Wa?mann wrote:
> The file is automatically removed after the timeout has expired (or
> the frimware has been loaded).
> Thus you must check for it within the timeout period during boot.
... which is impossible if imx-sdma is built into the kernel - it
expires while the initramfs has only just started running, giving a
very narrow window for userspace to load firmware.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v2 2/7] clk: samsung: add infrastructure to register cpu clocks
From: Lukasz Majewski @ 2014-01-21 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9aj07i31ntS2sJ9ESObQXEA4HVjtN2saHTqoWu6bO=w58Q@mail.gmail.com>
Hi Thomas,
> On Tue, Jan 21, 2014 at 3:55 PM, Lukasz Majewski
> <l.majewski@samsung.com> wrote:
> > Hi Thomas,
> >
> >> Hi Lukasz,
> >>
> >> On Mon, Jan 20, 2014 at 1:54 PM, Lukasz Majewski
> >> <l.majewski@samsung.com> wrote:
> >> > Hi Thomas,
> >> >
> >> >> From: Thomas Abraham <thomas.ab@samsung.com>
> >> >>
> >> >> 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.
> >> >>
> >> >> In addition to this, the arm cpu clock provider for Exynos4210
> >> >> and compatible SoCs is instantiated using the new cpu clock
> >> >> type. The clock frequency table and the clock configuration
> >> >> data for this clock is obtained from device tree. This
> >> >> implementation is reusable for Exynos4x12 and Exynos5250 SoCs
> >> >> as well.
> >> >>
> >> >> Cc: Tomasz Figa <t.figa@samsung.com>
> >> >> Cc: Lukasz Majewski <l.majewski@majess.pl>
> >> >> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> >> >> ---
> >> >> drivers/clk/samsung/Makefile | 2 +-
> >> >> drivers/clk/samsung/clk-cpu.c | 345
> >> >> +++++++++++++++++++++++++++++++++++++++++
> >> >> drivers/clk/samsung/clk.h | 3 + 3 files changed, 349
> >> >> insertions(+), 1 deletions(-) create mode 100644
> >> >> drivers/clk/samsung/clk-cpu.c
> >> >>
> >> >> diff --git a/drivers/clk/samsung/Makefile
> >> >> b/drivers/clk/samsung/Makefile index 8eb4799..e2b453f 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_ARCH_EXYNOS4) += clk-exynos4.o
> >> >> obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
> >> >> obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
> >> >> diff --git a/drivers/clk/samsung/clk-cpu.c
> >> >> b/drivers/clk/samsung/clk-cpu.c new file mode 100644
> >> >> index 0000000..92fba45
> >> >> --- /dev/null
> >> >> +++ b/drivers/clk/samsung/clk-cpu.c
> >> >> @@ -0,0 +1,345 @@
> >> >> +/*
> >> >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> >> >> + * Author: Thomas Abraham <thomas.ab@samsung.com>
> >> >> + *
> >> >> + * This program is free software; you can redistribute it
> >> >> and/or modify
> >> >> + * it under the terms of the GNU General Public License
> >> >> version 2 as
> >> >> + * published by the Free Software Foundation.
> >> >> + *
> >> >> + * This file contains the utility functions to register the cpu
> >> >> clocks
> >> >> + * for samsung platforms.
> >> >> +*/
> >> >> +
> >> >> +#include <linux/errno.h>
> >> >> +#include "clk.h"
> >> >> +
> >> >> +#define SRC_CPU 0x0
> >> >> +#define STAT_CPU 0x200
> >> >> +#define DIV_CPU0 0x300
> >> >> +#define DIV_CPU1 0x304
> >> >> +#define DIV_STAT_CPU0 0x400
> >> >> +#define DIV_STAT_CPU1 0x404
> >> >> +
> >> >> +/**
> >> >> + * struct samsung_cpuclk_freq_table: table of frequency
> >> >> supported by
> >> >> + * a cpu clock and associated data if any.
> >> >> + * @freq: points to a table of supported frequencies (in KHz)
> >> >> + * @freq_count: number of entries in the frequency table
> >> >> + * @data: cpu clock specific data, if any
> >> >> + *
> >> >> + * This structure holds the frequency options supported by the
> >> >> cpu clock in
> >> >> + * which this structure is contained. The data pointer is an
> >> >> optional data
> >> >> + * that can provide any additional configuration options for
> >> >> the supported
> >> >> + * frequencies. This structure is intended to be reusable for
> >> >> all cpu clocks
> >> >> + * in Samsung SoC based platforms
> >> >> + */
> >> >> +struct samsung_cpuclk_freq_table {
> >> >> + const unsigned long *freq; /* in KHz */
> >> >> + unsigned long freq_count;
> >> >> + const void *data;
> >> >> +};
> >> >> +
> >> >> +/**
> >> >> + * struct exynos4210_freq_data: format of auxillary data
> >> >> associated with
> >> >> + * each frequency supported by the cpu clock for exynos4210.
> >> >> + * @parent_freq: The frequency of the parent clock required to
> >> >> generate the
> >> >> + * supported cpu clock speed.
> >> >> + * @div0: value to be programmed in the div_cpu0 register.
> >> >> + * @div1: value to be programmed in the div_cpu1 register.
> >> >> + *
> >> >> + * This structure holds the auxillary configuration data for
> >> >> each supported
> >> >> + * cpu clock frequency on Exynos4210 and compatible SoCs.
> >> >> + */
> >> >> +struct exynos4210_freq_data {
> >> >> + unsigned long parent_freq;
> >> >> + unsigned int div0;
> >> >> + unsigned int div1;
> >> >> +};
> >> >> +
> >> >> +/**
> >> >> + * struct samsung_cpuclk: information about clock supplied to a
> >> >> CPU core.
> >> >> + * @hw: handle between ccf and cpu clock.
> >> >> + * @ctrl_base: base address of the clock controller.
> >> >> + * @offset: offset from the ctrl_base address where the cpu
> >> >> clock div/mux
> >> >> + * registers can be accessed.
> >> >> + * @parent: clock handle representing the clock output of the
> >> >> parent clock.
> >> >> + * @freq_table: the frequency table supported by this cpu
> >> >> clock.
> >> >> + */
> >> >> +struct samsung_cpuclk {
> >> >> + struct clk_hw hw;
> >> >> + void __iomem *ctrl_base;
> >> >> + unsigned long offset;
> >> >> + struct clk *parent;
> >> >> + const struct samsung_cpuclk_freq_table *freq_table;
> >> >> +};
> >> >> +
> >> >> +#define to_samsung_cpuclk(hw) container_of(hw, struct
> >> >> samsung_cpuclk, hw) +
> >> >> +/**
> >> >> + * struct samsung_cpuclk_match_data: soc specific data for cpu
> >> >> clocks.
> >> >> + * @parser: pointer to a function that can parse SoC specific
> >> >> cpu clock
> >> >> + * frequency and associated configuration data.
> >> >> + * @offset: optional offset from base of clock controller
> >> >> register base,
> >> >> + * to be used when accessing clock controller registers
> >> >> related to the
> >> >> + * cpu clock.
> >> >> + * @offset: offset from the ctrl_base address where the cpu
> >> >> clock div/mux
> >> >> + * registers can be accessed.
> >> >> + */
> >> >> +struct samsung_cpuclk_match_data {
> >> >> + int (*parser)(struct device_node *,
> >> >> + struct samsung_cpuclk_freq_table **);
> >> >> + unsigned int offset;
> >> >> +};
> >> >> +
> >> >> +/* This is a helper function to perform clock rounding for cpu
> >> >> clocks. */ +static long samsung_cpuclk_round_rate(struct clk_hw
> >> >> *hw,
> >> >> + unsigned long drate, unsigned long *prate)
> >> >> +{
> >> >> + struct samsung_cpuclk *cpuclk = to_samsung_cpuclk(hw);
> >> >> + const struct samsung_cpuclk_freq_table *freq_tbl;
> >> >> + int i;
> >> >> +
> >> >> + freq_tbl = cpuclk->freq_table;
> >> >> + drate /= 1000;
> >> >> +
> >> >> + for (i = 0; i < freq_tbl->freq_count; i++) {
> >> >> + if (drate >= freq_tbl->freq[i])
> >> >> + return freq_tbl->freq[i] * 1000;
> >> >> + }
> >> >> + return freq_tbl->freq[i - 1] * 1000;
> >> >> +}
> >> >> +
> >> >> +#define EXYNOS4210_ARM_DIV1(base) ((readl(base + DIV_CPU0) &
> >> >> 0xf)
> >> >> + 1) +#define EXYNOS4210_ARM_DIV2(base) (((readl(base +
> >> >> DIV_CPU0)
> >> >> >> 28) & 0xf) + 1) +
> >> >> +/*
> >> >> + * CPU clock speed for Exynos4210 and compatible SoCs is
> >> >> + * parent clock speed / core1_ratio / core2_ratio
> >> >> + */
> >> >> +static unsigned long exynos4210_armclk_recalc_rate(struct
> >> >> clk_hw *hw,
> >> >> + unsigned long parent_rate)
> >> >> +{
> >> >> + struct samsung_cpuclk *armclk = to_samsung_cpuclk(hw);
> >> >> + void __iomem *base = armclk->ctrl_base + armclk->offset;
> >> >> +
> >> >> + return parent_rate / EXYNOS4210_ARM_DIV1(base) /
> >> >> + EXYNOS4210_ARM_DIV2(base);
> >> >> +}
> >> >> +
> >> >> +/* set rate callback for cpuclk type on Exynos4210 and similar
> >> >> SoCs */ +static int exynos4210_armclk_set_rate(struct clk_hw
> >> >> *hw, unsigned long drate,
> >> >> + unsigned long prate)
> >> >> +{
> >> >> + struct samsung_cpuclk *armclk = to_samsung_cpuclk(hw);
> >> >> + const struct samsung_cpuclk_freq_table *freq_tbl;
> >> >> + const struct exynos4210_freq_data *freq_data;
> >> >> + unsigned long mux_reg, idx;
> >> >> + void __iomem *base;
> >> >> +
> >> >> + if (drate == prate)
> >> >> + return 0;
> >> >> +
> >> >> + freq_tbl = armclk->freq_table;
> >> >> + freq_data = freq_tbl->data;
> >> >> + base = armclk->ctrl_base + armclk->offset;
> >> >> +
> >> >> + for (idx = 0; idx < freq_tbl->freq_count; idx++,
> >> >> freq_data++)
> >> >> + if ((freq_tbl->freq[idx] * 1000) == drate)
> >> >> + break;
> >> >> +
> >> >> + if (drate < prate) {
> >> >> + mux_reg = readl(base + SRC_CPU);
> >> >> + writel(mux_reg | (1 << 16), base + SRC_CPU);
> >> >> + while (((readl(base + STAT_CPU) >> 16) & 0x7) !=
> >> >> 2)
> >> >> + ;
> >> >> +
> >> >> + clk_set_rate(armclk->parent, drate);
> >> >> + }
> >> >> +
> >> >> + writel(freq_data->div0, base + DIV_CPU0);
> >> >> + while (readl(base + DIV_STAT_CPU0) != 0)
> >> >> + ;
> >> >> + writel(freq_data->div1, base + DIV_CPU1);
> >> >> + while (readl(base + DIV_STAT_CPU1) != 0)
> >> >> + ;
> >> >> +
> >> >> + if (drate > prate) {
> >> >> + mux_reg = readl(base + SRC_CPU);
> >> >> + writel(mux_reg | (1 << 16), base + SRC_CPU);
> >> >> + while (((readl(base + STAT_CPU) >> 16) & 0x7) !=
> >> >> 2)
> >> >> + ;
> >> >> +
> >> >> + clk_set_rate(armclk->parent,
> >> >> freq_data->parent_freq
> >> >> * 1000);
> >> >> + }
> >> >> +
> >> >> + mux_reg = readl(base + SRC_CPU);
> >> >> + writel(mux_reg & ~(1 << 16), base + SRC_CPU);
> >> >> + while (((readl(base + STAT_CPU) >> 16) & 0x7) != 1)
> >> >> + ;
> >> >> + return 0;
> >> >> +}
> >> >> +
> >> >> +/* clock ops for armclk on Exynos4210 and compatible
> >> >> platforms. */ +static const struct clk_ops
> >> >> exynos4210_armclk_clk_ops = {
> >> >> + .recalc_rate = exynos4210_armclk_recalc_rate,
> >> >> + .round_rate = samsung_cpuclk_round_rate,
> >> >> + .set_rate = exynos4210_armclk_set_rate,
> >> >> +};
> >> >> +
> >> >> +/* helper function to register a cpu clock */
> >> >> +static void __init samsung_cpuclk_register(unsigned int
> >> >> lookup_id,
> >> >> + const char *name, const char *parent, const struct
> >> >> clk_ops *ops,
> >> >> + const struct samsung_cpuclk_freq_table *freq_tbl,
> >> >> + void __iomem *reg_base,
> >> >> + const struct samsung_cpuclk_match_data *data)
> >> >> +{
> >> >> + struct samsung_cpuclk *cpuclk;
> >> >> + struct clk_init_data init;
> >> >> + struct clk *clk;
> >> >> +
> >> >> + cpuclk = kzalloc(sizeof(*cpuclk), GFP_KERNEL);
> >> >> + if (!cpuclk) {
> >> >> + pr_err("%s: could not allocate memory for cpuclk
> >> >> %s\n",
> >> >> + __func__, name);
> >> >> + return;
> >> >> + }
> >> >> +
> >> >> + init.name = name;
> >> >> + init.flags = CLK_GET_RATE_NOCACHE;
> >> >> + init.parent_names = &parent;
> >> >> + init.num_parents = 1;
> >> >> + init.ops = ops;
> >> >> +
> >> >> + cpuclk->hw.init = &init;
> >> >> + cpuclk->ctrl_base = reg_base;
> >> >> + cpuclk->offset = data->offset;
> >> >> + cpuclk->freq_table = freq_tbl;
> >> >> + cpuclk->parent = __clk_lookup(parent);
> >> >> +
> >> >> + clk = clk_register(NULL, &cpuclk->hw);
> >> >> + if (IS_ERR(clk)) {
> >> >> + pr_err("%s: could not register cpuclk %s\n",
> >> >> __func__, name);
> >> >> + kfree(cpuclk);
> >> >> + return;
> >> >> + }
> >> >> + samsung_clk_add_lookup(clk, lookup_id);
> >> >> +}
> >> >> +
> >> >> +#define EXYNOS4210_DIV_CPU01(d0, d1, d2, d3, d4, d5, d6,
> >> >> d7) \
> >> >> + ((d0 << 28) | (d1 << 24) | (d2 << 20) | (d3
> >> >> << 16) | \
> >> >> + (d4 << 12) | (d5 << 8) | (d6 << 4) | (d7 << 0))
> >> >> +#define EXYNOS4210_DIV_CPU11(d0, d1,
> >> >> d2) \
> >> >> + ((d0 << 8) | (d1 << 4) | (d2 << 0))
> >> >> +#define EXYNOS4210_CFG_LEN 13
> >> >> +
> >> >> +/*
> >> >> + * parse cpu clock frequency table and auxillary configuration
> >> >> data from dt
> >> >> + * for exynos4210 and compatible SoC's.
> >> >> + */
> >> >> +static int exynos4210_armclk_cfg_parser(struct device_node *np,
> >> >> + struct samsung_cpuclk_freq_table **tbl)
> >> >> +{
> >> >> + struct samsung_cpuclk_freq_table *freq_tbl;
> >> >> + struct exynos4210_freq_data *fdata, *t_fdata;
> >> >> + unsigned long *freqs, cfg[EXYNOS4210_CFG_LEN];
> >> >> + const struct property *prop;
> >> >> + unsigned int tbl_sz, i, j;
> >> >> + const __be32 *val;
> >> >> + int ret;
> >> >> +
> >> >> + prop = of_find_property(np, "arm-frequency-table", NULL);
> >> >> + if (!prop)
> >> >> + return -EINVAL;
> >> >> + if (!prop->value)
> >> >> + return -EINVAL;
> >> >> + if ((prop->length / sizeof(u32)) % EXYNOS4210_CFG_LEN)
> >> >
> >> > Cannot we have the EXYNOS4210_CFG_LEN parsed from DT as well?
> >>
> >> As per Rob's suggestion, the clock divider ration table will be
> >> removed. So this portion of the code will be reworked.
> >
> > Ok. Thanks.
> >
> >>
> >> >
> >> >> + return -EINVAL;
> >> >> + tbl_sz = (prop->length / sizeof(u32)) /
> >> >> EXYNOS4210_CFG_LEN; +
> >> >> + freq_tbl = kzalloc(sizeof(*freq_tbl), GFP_KERNEL);
> >> >> + if (!freq_tbl)
> >> >> + return -ENOMEM;
> >> >> +
> >> >> + freqs = kzalloc(sizeof(u32) * tbl_sz, GFP_KERNEL);
> >> >> + if (!freqs) {
> >> >> + ret = -ENOMEM;
> >> >> + goto free_freq_tbl;
> >> >> + }
> >> >> +
> >> >> + fdata = kzalloc(sizeof(*fdata) * tbl_sz, GFP_KERNEL);
> >> >> + if (!fdata) {
> >> >> + ret = -ENOMEM;
> >> >> + goto free_freqs;
> >> >> + }
> >> >> + t_fdata = fdata;
> >> >> +
> >> >> + val = prop->value;
> >> >> + for (i = 0; i < tbl_sz; i++, fdata++) {
> >> >> + for (j = 0; j < EXYNOS4210_CFG_LEN; j++)
> >> >> + cfg[j] = be32_to_cpup(val++);
> >> >> + freqs[i] = cfg[0];
> >> >> + fdata->parent_freq = cfg[1];
> >> >
> >> > Why do we need the separate parent_freq entry here?
> >> >
> >> > In the patch 4/7 the freqs (cfg[0]) and parent_freq (cfg[1])
> >> > values are the same for all supported devices (at
> >> > "arm-frequency-table").
> >> >
> >> > What is the rationale for having those values duplicated in the
> >> > DT?
> >>
> >> The intention was to support frequencies which may not be direct
> >> output of the parent PLL clock. For instance, if the PLL supports
> >> 200MHz, 400MHz and 600MHz and the CPU clock needs to be set to
> >> 300MHz, then 600MHz / 2 is a valid clock output for the cpu clock.
^^^^^^^^^^^^^^^^^^^^ [1]
> >> So this is an example where the cpu clock speed is different from
> >> its parent clock speed.
> >
> > But shall not this case been handled by CCF internally?
>
> The divider which actually can divide the PLL clock output is now part
> of the larger cpu clock type. So it is the implementation of the
> set_rate function of the cpu clock that has to handle this division.
> So there is no core CCF support to handle this.
I rather thought about the situation you brought up [1].
I agree with the above statement, that it shall be divided internally
(with use of DIV_CORE and DIV_CORE2).
>
> >
> > Is there any Samsung PLL clock, which has such property?
>
> Yes, this functionality is available on all Exynos SoCs but it is not
> a Samsung PLL clock property.
So the example [1] cannot be applied to PLLs to Samsung SOCs?
> The PLL clock output can optionally be
> divided and then used as arm clock output.
It will be divided by DIV_CORE and DIV_CORE2, which will be done
internally (at .set_rate) at "armclk".
>
> >
> >> If possible, I will try and remove the need for this table in the
> >> next version.
> >
> > Ok.
>
> On second thoughts, it looks possible to get rid of this table and I
> am testing with this approach now.
Ok, thanks.
>
> >
> >>
> >> Thanks,
> >> Thomas.
> >>
> >> >
> >> >
> >> >> + fdata->div0 = EXYNOS4210_DIV_CPU01(cfg[9], cfg[8],
> >> >> cfg[7],
> >> >> + cfg[6], cfg[5], cfg[4], cfg[3],
> >> >> cfg[2]);
> >> >> + fdata->div1 = EXYNOS4210_DIV_CPU11(cfg[12],
> >> >> cfg[11], cfg[10]);
> >> >> + }
> >> >> +
> >> >> + freq_tbl->freq = freqs;
> >> >> + freq_tbl->freq_count = tbl_sz;
> >> >> + freq_tbl->data = t_fdata;
> >> >> + *tbl = freq_tbl;
> >> >> + return 0;
> >> >> +
> >> >> +free_freqs:
> >> >> + kfree(freqs);
> >> >> +free_freq_tbl:
> >> >> + kfree(freq_tbl);
> >> >> + return ret;
> >> >> +}
> >> >> +
> >> >> +static struct samsung_cpuclk_match_data
> >> >> exynos4210_cpuclk_match_data = {
> >> >> + .parser = exynos4210_armclk_cfg_parser,
> >> >> + .offset = 0x14200,
> >> >> +};
> >> >> +
> >> >> +static struct samsung_cpuclk_match_data
> >> >> exynos5250_cpuclk_match_data = {
> >> >> + .parser = exynos4210_armclk_cfg_parser,
> >> >> + .offset = 0x200,
> >> >> +};
> >> >> +
> >> >> +static const struct of_device_id samsung_clock_ids[] = {
> >> >> + { .compatible = "samsung,exynos4210-clock",
> >> >> + .data = &exynos4210_cpuclk_match_data, },
> >> >> + { .compatible = "samsung,exynos4412-clock",
> >> >> + .data = &exynos4210_cpuclk_match_data, },
> >> >> + { .compatible = "samsung,exynos5250-clock",
> >> >> + .data = &exynos5250_cpuclk_match_data, },
> >> >> +};
> >> >> +
> >> >> +int __init samsung_register_arm_clock(struct device_node *np,
> >> >> + unsigned int lookup_id, const char *parent,
> >> >> void __iomem *base) +{
> >> >> + const struct of_device_id *match;
> >> >> + struct samsung_cpuclk_freq_table *freq_table;
> >> >> + const struct samsung_cpuclk_match_data *data;
> >> >> + int ret;
> >> >> +
> >> >> + match = of_match_node(samsung_clock_ids, np);
> >> >> + if (!match) {
> >> >> + pr_err("%s: could not determine soc type\n",
> >> >> __func__);
> >> >> + return -EINVAL;
> >> >> + }
> >> >> +
> >> >> + data = match->data;
> >> >> + ret = data->parser(np, &freq_table);
> >> >> + if (ret) {
> >> >> + pr_err("%s: error %d in parsing arm clock freq
> >> >> table",
> >> >> + __func__, ret);
> >> >> + return -EINVAL;
> >> >> + }
> >> >> +
> >> >> + samsung_cpuclk_register(lookup_id, "armclk", parent,
> >> >> + &exynos4210_armclk_clk_ops, freq_table, base,
> >> >> data); +
> >> >> + return 0;
> >> >> +}
> >> >> diff --git a/drivers/clk/samsung/clk.h
> >> >> b/drivers/clk/samsung/clk.h index 31b4174..a759330 100644
> >> >> --- a/drivers/clk/samsung/clk.h
> >> >> +++ b/drivers/clk/samsung/clk.h
> >> >> @@ -340,4 +340,7 @@ extern void __init
> >> >> samsung_clk_register_pll(struct samsung_pll_clock *pll_list,
> >> >> extern unsigned long _get_rate(const char *clk_name);
> >> >>
> >> >> +extern int __init samsung_register_arm_clock(struct device_node
> >> >> *np,
> >> >> + unsigned int lookup_id, const char *parent, void
> >> >> __iomem *base); +
> >> >> #endif /* __SAMSUNG_CLK_H */
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> >
> >> > Lukasz Majewski
> >> >
> >> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
> >
> > --
> > Best regards,
> >
> > Lukasz Majewski
> >
> > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
^ permalink raw reply
* [PATCHv3 41/41] Doc/DT: Add DT binding documentation for tpd12s015 encoder
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for tpd12s015 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
new file mode 100644
index 000000000000..26e6d32e3f20
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
@@ -0,0 +1,44 @@
+TPD12S015 HDMI level shifter and ESD protection chip
+====================================================
+
+Required properties:
+- compatible: "ti,tpd12s015"
+
+Optional properties:
+- gpios: CT CP HPD, LS OE and HPD gpios
+
+Required nodes:
+- Video port 0 for HDMI input
+- Video port 1 for HDMI output
+
+Example
+-------
+
+tpd12s015: encoder at 1 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint at 0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint at 0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 40/41] Doc/DT: Add DT binding documentation for TFP410 encoder
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for TFP410 encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/ti,tfp410.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt
new file mode 100644
index 000000000000..6a5a04627584
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt
@@ -0,0 +1,41 @@
+TFP410 DPI to DVI encoder
+=========================
+
+Required properties:
+- compatible: "ti,tfp410"
+
+Optional properties:
+- gpios: power-down gpio
+
+Required nodes:
+- Video port 0 for DPI input
+- Video port 1 for DVI output
+
+Example
+-------
+
+tfp410: encoder at 0 {
+ compatible = "ti,tfp410";
+ gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ tfp410_in: endpoint at 0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tfp410_out: endpoint at 0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 39/41] Doc/DT: Add DT binding documentation for Sony acx565akm panel
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for Sony acx565akm panel
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/sony,acx565akm.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
new file mode 100644
index 000000000000..cd9cfdf7e3fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
@@ -0,0 +1,28 @@
+Sony ACX565AKM SDI Panel
+========================
+
+Required properties:
+- compatible: "sony,acx565akm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio
+
+Required nodes:
+- Video port for SDI input
+
+Example
+-------
+
+acx565akm at 2 {
+ compatible = "sony,acx565akm";
+ spi-max-frequency = <6000000>;
+ reg = <2>;
+
+ label = "lcd";
+ gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
+
+ lcd_in: endpoint {
+ remote-endpoint = <&sdi_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 38/41] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for MIPI DSI Command Mode Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
new file mode 100644
index 000000000000..73f422556d4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
@@ -0,0 +1,26 @@
+Generic MIPI DSI Command Mode Panel
+===================================
+
+Required properties:
+- compatible: "panel-dsi-cm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel reset gpio and TE gpio
+
+Required nodes:
+- Video port for DSI input
+
+Example
+-------
+
+lcd0: display {
+ compatible = "tpo,taal", "panel-dsi-cm";
+ label = "lcd0";
+
+ gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = <&dsi1_out_ep>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 37/41] Doc/DT: Add DT binding documentation for MIPI DPI Panel
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for MIPI DPI Panel.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/panel-dpi.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
new file mode 100644
index 000000000000..72636c6f1c67
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
@@ -0,0 +1,43 @@
+Generic MIPI DPI Panel
+======================
+
+Required properties:
+- compatible: "panel-dpi"
+
+Optional properties:
+- label: a symbolic name for the panel
+- gpios: panel enable gpio and backlight enable gpio
+
+Required nodes:
+- "panel-timing" containing video timings
+ (Documentation/devicetree/bindings/video/display-timing.txt)
+- Video port for DPI input
+
+Example
+-------
+
+lcd0: display at 0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+ label = "lcd";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+
+ panel-timing {
+ clock-frequency = <9200000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <8>;
+ hback-porch = <4>;
+ hsync-len = <41>;
+ vback-porch = <2>;
+ vfront-porch = <4>;
+ vsync-len = <10>;
+
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 36/41] Doc/DT: Add DT binding documentation for HDMI Connector
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for HDMI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/hdmi-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
new file mode 100644
index 000000000000..5d25f6a432bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -0,0 +1,23 @@
+HDMI Connector
+==============
+
+Required properties:
+- compatible: "hdmi-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for HDMI input
+
+Example
+-------
+
+hdmi0: connector at 1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 35/41] Doc/DT: Add DT binding documentation for DVI Connector
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for DVI Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/dvi-connector.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
new file mode 100644
index 000000000000..6a0aff866c78
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
@@ -0,0 +1,26 @@
+DVI Connector
+==============
+
+Required properties:
+- compatible: "dvi-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+
+Required nodes:
+- Video port for DVI input
+
+Example
+-------
+
+dvi0: connector at 0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 34/41] Doc/DT: Add DT binding documentation for Analog TV Connector
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for Analog TV Connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../bindings/video/analog-tv-connector.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
new file mode 100644
index 000000000000..d6be373d8705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -0,0 +1,23 @@
+Analog TV Connector
+===================
+
+Required properties:
+- compatible: "composite-connector" or "svideo-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for TV input
+
+Example
+-------
+
+tv: connector {
+ compatible = "composite-connector";
+ label = "tv";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 33/41] Doc/DT: Add OMAP DSS DT Bindings
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add device tree bindings for OMAP Display Subsystem for the following
SoCs: OMAP2, OMAP3, OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../devicetree/bindings/video/ti,omap-dss.txt | 197 +++++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 ++++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 73 ++++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 99 +++++++++++
.../devicetree/bindings/video/video-ports.txt | 22 +++
5 files changed, 445 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
new file mode 100644
index 000000000000..3b3a7c09106c
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
@@ -0,0 +1,197 @@
+Texas Instruments OMAP Display Subsystem
+========================================
+
+Generic Description
+-------------------
+
+This document is a generic description of the OMAP Display Subsystem bindings.
+Binding details for each OMAP SoC version are described in respective binding
+documentation.
+
+The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
+the encoder modules vary.
+
+The DSS Core is the parent of the other DSS modules, and manages clock routing,
+integration to the SoC, etc.
+
+DISPC is the display controller, which reads pixels from the memory and outputs
+a RGB pixel stream to encoders.
+
+The encoder modules encode the received RGB pixel stream to a video output like
+HDMI, MIPI DPI, etc.
+
+Video Ports
+-----------
+
+The DSS Core and the encoders have video port outputs. The structure of the
+video ports is described in Documentation/devicetree/bindings/video/video-
+ports.txt, and the properties for the ports and endpoints for each encoder are
+described in the SoC's DSS binding documentation.
+
+The video ports are used to describe the connections to external hardware, like
+panels or external encoders.
+
+Aliases
+-------
+
+The board dts file may define aliases for displays to assign "displayX" style
+name for each display. If no aliases are defined, a semi-random number is used
+for the display.
+
+Example
+-------
+
+A shortened example of the DSS description for OMAP4, with non-relevant parts
+removed, defined in omap4.dtsi:
+
+dss: dss at 58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ status = "disabled";
+ ti,hwmods = "dss_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc at 58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ ti,hwmods = "dss_dispc";
+ };
+
+ hdmi: encoder at 58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x200>,
+ <0x58006200 0x100>,
+ <0x58006300 0x100>,
+ <0x58006400 0x1000>;
+ reg-names = "wp", "pll", "phy", "core";
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ ti,hwmods = "dss_hdmi";
+ };
+};
+
+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI COnnector
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder at 0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tfp410_pins>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ tfp410_in: endpoint at 0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tfp410_out: endpoint at 0 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector at 0 {
+ compatible = "dvi-connector";
+ label = "dvi";
+
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tpd12s015: encoder at 1 {
+ compatible = "ti,tpd12s015";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&tpd12s015_pins>;
+
+ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint at 0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint at 0 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector at 1 {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_dpi_pins>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&hdmi {
+ status = "ok";
+ vdda-supply = <&vdac>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_hdmi_pins>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
new file mode 100644
index 000000000000..fa8bb2ed1170
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
@@ -0,0 +1,54 @@
+Texas Instruments OMAP2 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap2-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap2-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap2-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap2-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+
+Required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
new file mode 100644
index 000000000000..2b62c78c9596
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
@@ -0,0 +1,73 @@
+Texas Instruments OMAP3 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap3-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video ports:
+ - Port 0: DPI output
+ - Port 1: SDI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+SDI Endpoint required properties:
+- datapairs: number of datapairs used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap3-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap3-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap3-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap3-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1"
+- vdd-supply: power supply for DSI
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
new file mode 100644
index 000000000000..37aa9e6a173e
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -0,0 +1,99 @@
+Texas Instruments OMAP4 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap4-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, VENC, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap4-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap4-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap4-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+Optional nodes:
+- Video port for VENC output
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap4-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+ DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap4-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+ 'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+
+Optional nodes:
+- Video port for HDMI output
diff --git a/Documentation/devicetree/bindings/video/video-ports.txt b/Documentation/devicetree/bindings/video/video-ports.txt
new file mode 100644
index 000000000000..dad4c436caae
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/video-ports.txt
@@ -0,0 +1,22 @@
+Video Ports
+===========
+
+The video port bindings used for display devices is a superset of the v4l2 video
+ports described here:
+
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+The only difference is a more compact way to describe devices with only one
+endpoint. In cases like that, the 'ports' and 'port' nodes are not needed. For
+example, a DPI panel with a single input endpoint:
+
+lcd0: display at 0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+};
+
+The rest of the bindings are the same as in v4l2 video port bindings and not
+described here.
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 32/41] ARM: OMAP2+: remove pdata quirks for displays
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Remove pdata quirks for the displays on boards that are now supported
properly with DT.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/dss-common.c | 224 -------------------------------------
arch/arm/mach-omap2/pdata-quirks.c | 3 -
2 files changed, 227 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index dadccc91488c..010bb72d2b75 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -33,227 +33,3 @@
#include "soc.h"
#include "dss-common.h"
#include "mux.h"
-
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
-
-#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap4_panda_dvi_connector_pdata = {
- .name = "dvi",
- .source = "tfp410.0",
- .i2c_bus_num = 2,
-};
-
-static struct platform_device omap4_panda_dvi_connector_device = {
- .name = "connector-dvi",
- .id = 0,
- .dev.platform_data = &omap4_panda_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap4_panda_tfp410_pdata = {
- .name = "tfp410.0",
- .source = "dpi.0",
- .data_lines = 24,
- .power_down_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap4_panda_tfp410_device = {
- .name = "tfp410",
- .id = 0,
- .dev.platform_data = &omap4_panda_tfp410_pdata,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data omap4_panda_hdmi_connector_pdata = {
- .name = "hdmi",
- .source = "tpd12s015.0",
-};
-
-static struct platform_device omap4_panda_hdmi_connector_device = {
- .name = "connector-hdmi",
- .id = 0,
- .dev.platform_data = &omap4_panda_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection & level shifter chip */
-static struct encoder_tpd12s015_platform_data omap4_panda_tpd_pdata = {
- .name = "tpd12s015.0",
- .source = "hdmi.0",
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device omap4_panda_tpd_device = {
- .name = "tpd12s015",
- .id = 0,
- .dev.platform_data = &omap4_panda_tpd_pdata,
-};
-
-static struct omap_dss_board_info omap4_panda_dss_data = {
- .default_display_name = "dvi",
-};
-
-void __init omap4_panda_display_init_of(void)
-{
- omap_display_init(&omap4_panda_dss_data);
-
- platform_device_register(&omap4_panda_tfp410_device);
- platform_device_register(&omap4_panda_dvi_connector_device);
-
- platform_device_register(&omap4_panda_tpd_device);
- platform_device_register(&omap4_panda_hdmi_connector_device);
-}
-
-
-/* OMAP4 Blaze display data */
-
-#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO 40
-
-static struct panel_dsicm_platform_data dsi1_panel = {
- .name = "lcd",
- .source = "dsi.0",
- .reset_gpio = 102,
- .use_ext_te = false,
- .ext_te_gpio = 101,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct platform_device sdp4430_lcd_device = {
- .name = "panel-dsi-cm",
- .id = 0,
- .dev.platform_data = &dsi1_panel,
-};
-
-static struct panel_dsicm_platform_data dsi2_panel = {
- .name = "lcd2",
- .source = "dsi.1",
- .reset_gpio = 104,
- .use_ext_te = false,
- .ext_te_gpio = 103,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct platform_device sdp4430_lcd2_device = {
- .name = "panel-dsi-cm",
- .id = 1,
- .dev.platform_data = &dsi2_panel,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data sdp4430_hdmi_connector_pdata = {
- .name = "hdmi",
- .source = "tpd12s015.0",
-};
-
-static struct platform_device sdp4430_hdmi_connector_device = {
- .name = "connector-hdmi",
- .id = 0,
- .dev.platform_data = &sdp4430_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection & level shifter chip */
-static struct encoder_tpd12s015_platform_data sdp4430_tpd_pdata = {
- .name = "tpd12s015.0",
- .source = "hdmi.0",
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device sdp4430_tpd_device = {
- .name = "tpd12s015",
- .id = 0,
- .dev.platform_data = &sdp4430_tpd_pdata,
-};
-
-
-static struct omap_dss_board_info sdp4430_dss_data = {
- .default_display_name = "lcd",
-};
-
-/*
- * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
- * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
- * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
- * selected by default
- */
-void __init omap_4430sdp_display_init_of(void)
-{
- int r;
-
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- "display_sel");
- if (r)
- pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
- r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- "DLP POWER ON");
- if (r)
- pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
- omap_display_init(&sdp4430_dss_data);
-
- platform_device_register(&sdp4430_lcd_device);
- platform_device_register(&sdp4430_lcd2_device);
-
- platform_device_register(&sdp4430_tpd_device);
- platform_device_register(&sdp4430_hdmi_connector_device);
-}
-
-
-/* OMAP3 IGEPv2 data */
-
-#define IGEP2_DVI_TFP410_POWER_DOWN_GPIO 170
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap3_igep2_dvi_connector_pdata = {
- .name = "dvi",
- .source = "tfp410.0",
- .i2c_bus_num = 2,
-};
-
-static struct platform_device omap3_igep2_dvi_connector_device = {
- .name = "connector-dvi",
- .id = 0,
- .dev.platform_data = &omap3_igep2_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap3_igep2_tfp410_pdata = {
- .name = "tfp410.0",
- .source = "dpi.0",
- .data_lines = 24,
- .power_down_gpio = IGEP2_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap3_igep2_tfp410_device = {
- .name = "tfp410",
- .id = 0,
- .dev.platform_data = &omap3_igep2_tfp410_pdata,
-};
-
-static struct omap_dss_board_info igep2_dss_data = {
- .default_display_name = "dvi",
-};
-
-void __init omap3_igep2_display_init_of(void)
-{
- omap_display_init(&igep2_dss_data);
-
- platform_device_register(&omap3_igep2_tfp410_device);
- platform_device_register(&omap3_igep2_dvi_connector_device);
-}
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 39f020c982e8..68e3bca42e60 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -80,7 +80,6 @@ static void __init hsmmc2_internal_input_clk(void)
static void __init omap3_igep0020_legacy_init(void)
{
- omap3_igep2_display_init_of();
}
static void __init omap3_evm_legacy_init(void)
@@ -97,14 +96,12 @@ static void __init omap3_zoom_legacy_init(void)
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
- omap_4430sdp_display_init_of();
legacy_init_wl12xx(WL12XX_REFCLOCK_26,
WL12XX_TCXOCLOCK_26, 53);
}
static void __init omap4_panda_legacy_init(void)
{
- omap4_panda_display_init_of();
legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 31/41] OMAPDSS: remove DT hacks for regulators
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
For booting Panda and 4430SDP with DT, while DSS did not support DT, we
had to had small hacks in the omapdss driver to get the regulators. With
DT now supported in DSS, we can remove those hacks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 9 +--------
drivers/video/omap2/dss/hdmi4.c | 9 +--------
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 98bb2d68a462..f461fe015554 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1162,16 +1162,9 @@ static int dsi_regulator_init(struct platform_device *dsidev)
vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "vdd");
- if (IS_ERR(vdds_dsi))
- vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "vdds_dsi");
-
- /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
- if (IS_ERR(vdds_dsi))
- vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "VCXIO");
-
if (IS_ERR(vdds_dsi)) {
if (PTR_ERR(vdds_dsi) != -EPROBE_DEFER)
- DSSERR("can't get VDDS_DSI regulator\n");
+ DSSERR("can't get DSI VDD regulator\n");
return PTR_ERR(vdds_dsi);
}
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index 064bec4e08d4..17b24b26f6cd 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -90,16 +90,9 @@ static int hdmi_init_regulator(void)
reg = devm_regulator_get(&hdmi.pdev->dev, "vdda");
- if (IS_ERR(reg)
- reg = devm_regulator_get(&hdmi.pdev->dev, "vdda_hdmi_dac");
-
- /* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
- if (IS_ERR(reg))
- reg = devm_regulator_get(&hdmi.pdev->dev, "VDAC");
-
if (IS_ERR(reg)) {
if (PTR_ERR(reg) != -EPROBE_DEFER)
- DSSERR("can't get VDDA_HDMI_DAC regulator\n");
+ DSSERR("can't get VDDA regulator\n");
return PTR_ERR(reg);
}
--
1.8.3.2
^ permalink raw reply related
* [PATCHv3 30/41] ARM: omap3-n900.dts: add display information
From: Tomi Valkeinen @ 2014-01-21 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Add DT data for OMAP3 N900 board. The board has the following displays:
lcd: LCD panel connected to OMAP's SDI output
tv: analog svideo
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3-n900.dts | 70 +++++++++++++++++++++++++++++++++++++---
1 file changed, 66 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 6fc85f963530..c1bb04d55d4b 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -74,6 +74,14 @@
};
};
+ tv: connector {
+ compatible = "composite-connector";
+ label = "tv";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+ };
};
&omap3_pmx_core {
@@ -140,11 +148,23 @@
>;
};
- display_pins: pinmux_display_pins {
+ acx565akm_pins: pinmux_acx565akm_pins {
pinctrl-single,pins = <
0x0d4 (PIN_OUTPUT | MUX_MODE4) /* RX51_LCD_RESET_GPIO */
>;
};
+
+ dss_sdi_pins: pinmux_dss_sdi_pins {
+ pinctrl-single,pins = <
+ 0x0c0 (PIN_OUTPUT | MUX_MODE1) /* dss_data10.sdi_dat1n */
+ 0x0c2 (PIN_OUTPUT | MUX_MODE1) /* dss_data11.sdi_dat1p */
+ 0x0c4 (PIN_OUTPUT | MUX_MODE1) /* dss_data12.sdi_dat2n */
+ 0x0c6 (PIN_OUTPUT | MUX_MODE1) /* dss_data13.sdi_dat2p */
+
+ 0x0d8 (PIN_OUTPUT | MUX_MODE1) /* dss_data22.sdi_clkp */
+ 0x0da (PIN_OUTPUT | MUX_MODE1) /* dss_data23.sdi_clkn */
+ >;
+ };
};
&i2c1 {
@@ -471,13 +491,21 @@
spi-max-frequency = <6000000>;
reg = <0>;
};
- mipid at 2 {
- compatible = "acx565akm";
+
+ acx565akm at 2 {
+ compatible = "sony,acx565akm";
spi-max-frequency = <6000000>;
reg = <2>;
pinctrl-names = "default";
- pinctrl-0 = <&display_pins>;
+ pinctrl-0 = <&acx565akm_pins>;
+
+ label = "lcd";
+ gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
+
+ lcd_in: endpoint {
+ remote-endpoint = <&sdi_out>;
+ };
};
};
@@ -503,3 +531,37 @@
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
};
+
+&dss {
+ status = "ok";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_sdi_pins>;
+
+ vdds_sdi-supply = <&vaux1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 1 {
+ reg = <1>;
+
+ sdi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ datapairs = <2>;
+ };
+ };
+ };
+};
+
+&venc {
+ status = "ok";
+
+ vdda-supply = <&vdac>;
+
+ venc_out: endpoint {
+ remote-endpoint = <&tv_connector_in>;
+ ti,channels = <1>;
+ };
+};
--
1.8.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox