Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting
On Fri, Mar 08, 2013 at 08:37:00PM +0530, Mugunthan V N wrote: > > As Peter Korsgaard mentioned we need to have infrastructure to handle CPSW > kind of hardware. This will be a big job, I think, but I agree that it is worth doing. I can think of one other switch-with-host-port device. Maybe we should start off by making a list of actual products and their capabilities, in order to get an overall idea of what we would need to develop. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 11/17] ARM: OMAP2+: Add device-tree support for NOR flash
On Fri, Mar 8, 2013 at 5:58 PM, Jon Hunter wrote:
> NOR flash is not currently supported when booting with device-tree
> on OMAP2+ devices. Add support to detect and configure NOR devices
> when booting with device-tree.
>
> Add documentation for the TI GPMC NOR binding.
>
> Signed-off-by: Jon Hunter
> ---
> Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 +
> arch/arm/mach-omap2/gpmc.c | 113
>
> 2 files changed, 211 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
> b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
> new file mode 100644
> index 000..8c638fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
> @@ -0,0 +1,98 @@
> +Device tree bindings for NOR flash connect to TI GPMC
> +
> +NOR flash connected to the TI GPMC (found on OMAP boards) are represented as
> +child nodes of the GPMC controller with a name of "nor".
> +
> +All timing relevant properties as well as generic GPMC child properties are
> +explained in a separate documents. Please refer to
> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
> +
> +Required properties:
> +- bank-width: Width of NOR flash in bytes. GPMC supports 8-bit and
> + 16-bit devices and so must be either 1 or 2 bytes.
> +- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> +- gpmc,cs-on: Chip-select assertion time
> +- gpmc,cs-rd-off: Chip-select de-assertion time for reads
> +- gpmc,cs-wr-off: Chip-select de-assertion time for writes
> +- gpmc,oe-on: Output-enable assertion time
> +- gpmc,oe-off Output-enable de-assertion time
> +- gpmc,we-on: Write-enable assertion time
> +- gpmc,we-off: Write-enable de-assertion time
> +- gpmc,access: Start cycle to first data capture (read access)
> +- gpmc,rd-cycle: Total read cycle time
> +- gpmc,wr-cycle: Total write cycle time
> +- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> +- reg: Chip-select, base address (relative to chip-select)
> + and size of NOR flash. Note that base address will be
> + typically 0 as this is the start of the chip-select.
> +
> +Optional properties:
> +- gpmc,XXX Additional GPMC timings and settings parameters. See
> + Documentation/devicetree/bindings/bus/ti-gpmc.txt
> +
> +Optional properties for partiton table parsing:
> +- #address-cells: should be set to 1
> +- #size-cells: should be set to 1
> +
> +Example:
> +
> +gpmc: gpmc@6e00 {
> + compatible = "ti,omap3430-gpmc", "simple-bus";
> + ti,hwmods = "gpmc";
> + reg = <0x6e00 0x1000>;
> + interrupts = <20>;
> + gpmc,num-cs = <8>;
> + gpmc,num-waitpins = <4>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + ranges = <0 0 0x1000 0x0800>;
> +
> + nor@0,0 {
> + compatible = "cfi-flash";
> + linux,mtd-name= "intel,pf48f6000m0y1be";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0 0 0x0800>;
> + bank-width = <2>;
> +
> + gpmc,mux-add-data;
> + gpmc,cs-on = <0>;
> + gpmc,cs-rd-off = <186>;
> + gpmc,cs-wr-off = <186>;
> + gpmc,adv-on = <12>;
> + gpmc,adv-rd-off = <48>;
> + gpmc,adv-wr-off = <48>;
> + gpmc,oe-on = <54>;
> + gpmc,oe-off = <168>;
> + gpmc,we-on = <54>;
> + gpmc,we-off = <168>;
> + gpmc,rd-cycle = <186>;
> + gpmc,wr-cycle = <186>;
> + gpmc,access = <114>;
> + gpmc,page-burst-access = <6>;
> + gpmc,bus-turnaround = <12>;
> + gpmc,cycle2cycle-delay = <18>;
> + gpmc,wr-data-mux-bus = <90>;
> + gpmc,wr-access = <186>;
> + gpmc,cycle2cycle-samecsen;
> + gpmc,cycle2cycle-diffcsen;
> +
> + partition@0 {
> + label = "bootloader-nor";
> + reg = <0 0x4>;
> + };
> + partition@0x4 {
> + label = "params-nor";
> + reg = <0x4 0x4>;
> + };
> + partition@0x8 {
> + label = "kernel-nor";
> + reg = <0x8 0x20>;
> + };
> + partition@0x28 {
> + label = "filesystem-nor";
> + reg = <0x24 0x7d8>;
> + };
> + };
> +};
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 80808ad..0
Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
Hi Jon,
On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter wrote:
> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
> of RAM and uses the TWL4030 power management IC.
I think this board support should be in separate patch series with
related patches.
>
> Signed-off-by: Jon Hunter
> ---
> arch/arm/boot/dts/Makefile |1 +
> arch/arm/boot/dts/omap3430-sdp.dts | 46
>
> 2 files changed, 47 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9c62558..89013ed 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> omap3-beagle-xm.dtb \
> omap3-evm.dtb \
> omap3-tobi.dtb \
> + omap3430-sdp.dtb \
> omap4-panda.dtb \
> omap4-panda-a4.dtb \
> omap4-panda-es.dtb \
> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
> b/arch/arm/boot/dts/omap3430-sdp.dts
> new file mode 100644
> index 000..be0650d
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
> @@ -0,0 +1,46 @@
> +/*
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.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.
> + */
> +/dts-v1/;
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + model = "TI OMAP3430 SDP";
> + compatible = "ti,omap3430-sdp", "ti,omap3";
I have not seen any related changes in "board-generic.c" for your board.
So just wanted know, how this board is booting ?
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <260>;
> +
> + twl: twl@48 {
> + reg = <0x48>;
> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> + interrupt-parent = <&intc>;
> + };
> +};
> +
> +/include/ "twl4030.dtsi"
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc1>;
> + vmmc_aux-supply = <&vsim>;
> + bus-width = <8>;
> +};
> +
> +&mmc2 {
> + status = "disabled";
> +};
> +
> +&mmc3 {
> + status = "disabled";
> +};
I think you should disable modules those are not currently used
as they are enabled by default in omap3.dtsi.
exp:-
&mcbsp2 {
status = "disabled";
};
> --
> 1.7.10.4
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter wrote:
>
> On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
>> On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter wrote:
>>> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
>>>
>>> Signed-off-by: Jon Hunter
>>> ---
>>> arch/arm/boot/dts/omap2420.dtsi | 11 +++
>>> arch/arm/boot/dts/omap2430.dtsi | 11 +++
>>> arch/arm/boot/dts/omap4.dtsi| 11 +++
>>> arch/arm/boot/dts/omap5.dtsi| 11 +++
>>> 4 files changed, 44 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap2420.dtsi
>>> b/arch/arm/boot/dts/omap2420.dtsi
>>> index af65609..d4ce6c2 100644
>>> --- a/arch/arm/boot/dts/omap2420.dtsi
>>> +++ b/arch/arm/boot/dts/omap2420.dtsi
>>> @@ -29,6 +29,17 @@
>>> pinctrl-single,function-mask = <0x3f>;
>>> };
>>>
>>> + gpmc: gpmc@6800a000 {
>>> + compatible = "ti,omap2420-gpmc";
>>> + reg = <0x6800a000 0x1000>;
>>> + #address-cells = <2>;
>>> + #size-cells = <1>;
>>> + interrupts = <20>;
>>> + gpmc,num-cs = <8>;
>>> + gpmc,num-waitpins = <4>;
>>> + ti,hwmods = "gpmc";
>>> + };
>>> +
>>> mcbsp1: mcbsp@48074000 {
>>> compatible = "ti,omap2420-mcbsp";
>>> reg = <0x48074000 0xff>;
>>> diff --git a/arch/arm/boot/dts/omap2430.dtsi
>>> b/arch/arm/boot/dts/omap2430.dtsi
>>> index c392445..832f184 100644
>>> --- a/arch/arm/boot/dts/omap2430.dtsi
>>> +++ b/arch/arm/boot/dts/omap2430.dtsi
>>> @@ -29,6 +29,17 @@
>>> pinctrl-single,function-mask = <0x3f>;
>>> };
>>>
>>> + gpmc: gpmc@6e00 {
>>> + compatible = "ti,omap2430-gpmc";
>>> + reg = <0x6e00 0x1000>;
>>> + #address-cells = <2>;
>>> + #size-cells = <1>;
>>> + interrupts = <20>;
>>> + gpmc,num-cs = <8>;
>>> + gpmc,num-waitpins = <4>;
>>> + ti,hwmods = "gpmc";
>>> + };
>>> +
>>> mcbsp1: mcbsp@48074000 {
>>> compatible = "ti,omap2430-mcbsp";
>>> reg = <0x48074000 0xff>;
>>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>>> index 827f6f3..726ef11 100644
>>> --- a/arch/arm/boot/dts/omap4.dtsi
>>> +++ b/arch/arm/boot/dts/omap4.dtsi
>>> @@ -196,6 +196,17 @@
>>> #interrupt-cells = <1>;
>>> };
>>>
>>> + gpmc: gpmc@5000 {
>>> + compatible = "ti,omap4430-gpmc";
>>> + reg = <0x5000 0x1000>;
>>
>> Hi Jon,
>>
>> By looking at the GPMC Register Summary from both the OMAP4460 and OMAP
>> OMAP35x
>> Technical Reference Manuals I see that the GPMC register address space
>> is only 720 bytes length. From base address + 0x0 to base address +
>> 0x02d0.
>>
>> So shouldn't the regs property be <0x5000 0x2d0> instead?
>>
>> Of course are only a few kilobytes but still I wonder if it makes
>> sense to map them when they are not going to be used.
>
> Yes you are correct. In general, I have been trying to stay some-what
> consistent with what hwmod was doing as this was being auto-generated by
> some hardware design specs and I believe they wanted to eventually get
> to the point where DT files would be auto-generated too for OMAP.
> Furthermore my understanding is that the smallest page that can be
> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
> 0x1000 it will map a 4kB page (I could be wrong here).
>
> I don't have any strong feelings here but will do what the consensus
> prefers.
>
Yes, you are right here.
I forget that ioremap() does a page-aligned mapping and since the
minimum page size for ARM is 4KB as you said, there is no difference
between using 0x2d0 and 0x1000. Sorry for the noise.
Reviewed-by: Javier Martinez Canillas
> Cheers
> Jon
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On 03/08/2013 04:56 PM, Arnd Bergmann wrote: > On Friday 08 March 2013, Stephen Warren wrote: >>> config USB_ULPI_VIEWPORT >>> def_bool y >>> depends on USB_EHCI_TEGRA >>> >>> If USB_ULPI_VIEWPORT has any other dependencies, the best solution >>> in the above scenario is to make USB_EHCI_TEGRA depend on those. >> >> USB_ULPI_VIEWPORT is, AFAIK, a generic piece of infra-structure that >> USB_EHCI_TEGRA depends upon. > > Sorry, I was probably confusing the symbol names. I meant whatever > you were going to "select" from USB_EHCI_TEGRA. Ah OK, that'd be the Tegra PHY driver. Except now that I look, it doesn't actually have its own Kconfig symbol (the Makefile builds it if the Tegra EHCI driver is enabled). Perhaps it should? Otherwise, I guess the Tegra EHCI driver Kconfig symbol would just have to depend on everything that it and the PHY driver depend on. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
On Fri, Mar 08, 2013 at 07:02:44PM +0100, Paul Bolle wrote:
> On Fri, 2013-03-08 at 09:55 -0800, Tony Lindgren wrote:
> > * Paul Bolle [130308 09:24]:
> > > Should I draft a patch?
> >
> > Sure that would be nice.
>
> One thing I couldn't determine is how the generated mach-types.h header
> handles multiple CONFIG_MACH_* macros.
>
> If both CONFIG_MACH_FOO and CONFIG_MACH_BAR are defined, and these both
> have a line in */mach-types, will the machine_is_foo() and
> machine_is_bar() macros both behave as one would expect?
It's actually quite clever. There's two levels to it.
The first is that CONFIG_MACH_xxx result in their machine_is_xxx() macros
being defined to constant zero if the CONFIG option is not enabled. That
allows the compiler to throw away code for disabled platforms because
the expression is always false.
Otherwise, they end up as (machine_arch_type == MACH_TYPE_xxx).
The second is the magic which happens when two CONFIG_MACH_xxx are
selected. If only one is selected, then machine_arch_type is defined
to the appropriate MACH_TYPE_xxx. This means that the above expression
becomes constant-true, and the conditional is eliminated.
If more than one is selected, then machine_arch_type is defined to a
variable which is appropriately set to one of the MACH_TYPE_xxx values.
So, the result is that:
- de-selected platforms have their if (machine_is_xxx()) { } optimised
out of the kernel.
- for a kernel built targetting one platform, all the
if (machine_is_xxx()) tests are optimised away, leaving only the
relevant code behind.
- otherwise, we get the _appropriate_ conditional code for the
configuration generated.
However, going back to that MACH_NOKIA_RM696. If there exists only a
select of this symbol and no "config MACH_NOKIA_RM696" entry, then the
symbol will never be generated in the output .config file.
I too can find no trace of any use of machine_is_nokia_rm696 in the
mainline kernel. So, if there's nothing using the machine_is_()
symbol, and nothing using the CONFIG_MACH_NOKIA_RM696 symbol, then
any select of that is entirely superfluous.
Well, I did this:
$ git grep -i nokia_rm696
arch/arm/mach-omap2/Kconfig:select MACH_NOKIA_RM696
arch/arm/mach-omap2/board-rm680.c:MACHINE_START(NOKIA_RM696, "Nokia RM-696
board")
arch/arm/tools/mach-types:nokia_rm696 MACH_NOKIA_RM696
NOKIA_RM696 3522
So, there exists platform support for this device, provided by the RM680
support, but there's no use of the machine_is_xxx() symbol - and if there
was, it would always be false.
My conclusion is... it's a mess.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On Friday 08 March 2013, Stephen Warren wrote: > > config USB_ULPI_VIEWPORT > > def_bool y > > depends on USB_EHCI_TEGRA > > > > If USB_ULPI_VIEWPORT has any other dependencies, the best solution > > in the above scenario is to make USB_EHCI_TEGRA depend on those. > > USB_ULPI_VIEWPORT is, AFAIK, a generic piece of infra-structure that > USB_EHCI_TEGRA depends upon. Sorry, I was probably confusing the symbol names. I meant whatever you were going to "select" from USB_EHCI_TEGRA. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On 03/08/2013 04:08 PM, Arnd Bergmann wrote: > On Friday 08 March 2013, Stephen Warren wrote: >> Yes, I think it should instead work like: >> >> ARCH_TEGRA* selects nothing in particular related to USB. >> >> The Tegra EHCI controller Kconfig depends on ARCH_TEGRA so it doesn't >> show up for other builds. > > Yes, that's fine. > >> I hope it's OK for the EHCI controller to select USB_ARCH_HAS_EHCI? > > I think that would create a circular dependency, which Kconfig will > refuse. We talked about the USB_ARCH_HAS_* Kconfig symbols recently > and Alan Stern agreed to my suggestion of removing all of them, > reworking the logic so we can always enable USB and EHCI but even > when there is no bus glue enabled. > > I'll have to do a proper patch one of these days, or find someone in > my team to do it right for all the corner cases. > >> The Tegra PHY Kconfig probably shouldn't be user-visible (relying on >> being selected by the Tegra EHCI controller) and itself selects >> anything it relies on. >> >> Does that sound reasonable? > > It is often safer to express the logic using "depends on" than using > "select", e.g. doing > > config USB_EHCI_TEGRA > bool "EHCI support for NVIDIA Tegra" > depends on USB_EHCI_HCD > depends on ARCH_TEGRA > > config USB_ULPI_VIEWPORT > def_bool y > depends on USB_EHCI_TEGRA > > If USB_ULPI_VIEWPORT has any other dependencies, the best solution > in the above scenario is to make USB_EHCI_TEGRA depend on those. USB_ULPI_VIEWPORT is, AFAIK, a generic piece of infra-structure that USB_EHCI_TEGRA depends upon. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On Friday 08 March 2013, Stephen Warren wrote: > Yes, I think it should instead work like: > > ARCH_TEGRA* selects nothing in particular related to USB. > > The Tegra EHCI controller Kconfig depends on ARCH_TEGRA so it doesn't > show up for other builds. Yes, that's fine. > I hope it's OK for the EHCI controller to select USB_ARCH_HAS_EHCI? I think that would create a circular dependency, which Kconfig will refuse. We talked about the USB_ARCH_HAS_* Kconfig symbols recently and Alan Stern agreed to my suggestion of removing all of them, reworking the logic so we can always enable USB and EHCI but even when there is no bus glue enabled. I'll have to do a proper patch one of these days, or find someone in my team to do it right for all the corner cases. > The Tegra PHY Kconfig probably shouldn't be user-visible (relying on > being selected by the Tegra EHCI controller) and itself selects > anything it relies on. > > Does that sound reasonable? It is often safer to express the logic using "depends on" than using "select", e.g. doing config USB_EHCI_TEGRA bool "EHCI support for NVIDIA Tegra" depends on USB_EHCI_HCD depends on ARCH_TEGRA config USB_ULPI_VIEWPORT def_bool y depends on USB_EHCI_TEGRA If USB_ULPI_VIEWPORT has any other dependencies, the best solution in the above scenario is to make USB_EHCI_TEGRA depend on those. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/08/2013 02:25 PM, Javier Martinez Canillas wrote:
> On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter wrote:
>> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> arch/arm/boot/dts/omap2420.dtsi | 11 +++
>> arch/arm/boot/dts/omap2430.dtsi | 11 +++
>> arch/arm/boot/dts/omap4.dtsi| 11 +++
>> arch/arm/boot/dts/omap5.dtsi| 11 +++
>> 4 files changed, 44 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap2420.dtsi
>> b/arch/arm/boot/dts/omap2420.dtsi
>> index af65609..d4ce6c2 100644
>> --- a/arch/arm/boot/dts/omap2420.dtsi
>> +++ b/arch/arm/boot/dts/omap2420.dtsi
>> @@ -29,6 +29,17 @@
>> pinctrl-single,function-mask = <0x3f>;
>> };
>>
>> + gpmc: gpmc@6800a000 {
>> + compatible = "ti,omap2420-gpmc";
>> + reg = <0x6800a000 0x1000>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + interrupts = <20>;
>> + gpmc,num-cs = <8>;
>> + gpmc,num-waitpins = <4>;
>> + ti,hwmods = "gpmc";
>> + };
>> +
>> mcbsp1: mcbsp@48074000 {
>> compatible = "ti,omap2420-mcbsp";
>> reg = <0x48074000 0xff>;
>> diff --git a/arch/arm/boot/dts/omap2430.dtsi
>> b/arch/arm/boot/dts/omap2430.dtsi
>> index c392445..832f184 100644
>> --- a/arch/arm/boot/dts/omap2430.dtsi
>> +++ b/arch/arm/boot/dts/omap2430.dtsi
>> @@ -29,6 +29,17 @@
>> pinctrl-single,function-mask = <0x3f>;
>> };
>>
>> + gpmc: gpmc@6e00 {
>> + compatible = "ti,omap2430-gpmc";
>> + reg = <0x6e00 0x1000>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + interrupts = <20>;
>> + gpmc,num-cs = <8>;
>> + gpmc,num-waitpins = <4>;
>> + ti,hwmods = "gpmc";
>> + };
>> +
>> mcbsp1: mcbsp@48074000 {
>> compatible = "ti,omap2430-mcbsp";
>> reg = <0x48074000 0xff>;
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 827f6f3..726ef11 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -196,6 +196,17 @@
>> #interrupt-cells = <1>;
>> };
>>
>> + gpmc: gpmc@5000 {
>> + compatible = "ti,omap4430-gpmc";
>> + reg = <0x5000 0x1000>;
>
> Hi Jon,
>
> By looking at the GPMC Register Summary from both the OMAP4460 and OMAP
> OMAP35x
> Technical Reference Manuals I see that the GPMC register address space
> is only 720 bytes length. From base address + 0x0 to base address +
> 0x02d0.
>
> So shouldn't the regs property be <0x5000 0x2d0> instead?
>
> Of course are only a few kilobytes but still I wonder if it makes
> sense to map them when they are not going to be used.
Yes you are correct. In general, I have been trying to stay some-what
consistent with what hwmod was doing as this was being auto-generated by
some hardware design specs and I believe they wanted to eventually get
to the point where DT files would be auto-generated too for OMAP.
Furthermore my understanding is that the smallest page that can be
mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or
0x1000 it will map a 4kB page (I could be wrong here).
I don't have any strong feelings here but will do what the consensus
prefers.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Fri, Mar 8, 2013 at 6:27 PM, Jon Hunter wrote:
> Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
>
> Signed-off-by: Jon Hunter
> ---
> arch/arm/boot/dts/omap2420.dtsi | 11 +++
> arch/arm/boot/dts/omap2430.dtsi | 11 +++
> arch/arm/boot/dts/omap4.dtsi| 11 +++
> arch/arm/boot/dts/omap5.dtsi| 11 +++
> 4 files changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
> index af65609..d4ce6c2 100644
> --- a/arch/arm/boot/dts/omap2420.dtsi
> +++ b/arch/arm/boot/dts/omap2420.dtsi
> @@ -29,6 +29,17 @@
> pinctrl-single,function-mask = <0x3f>;
> };
>
> + gpmc: gpmc@6800a000 {
> + compatible = "ti,omap2420-gpmc";
> + reg = <0x6800a000 0x1000>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + interrupts = <20>;
> + gpmc,num-cs = <8>;
> + gpmc,num-waitpins = <4>;
> + ti,hwmods = "gpmc";
> + };
> +
> mcbsp1: mcbsp@48074000 {
> compatible = "ti,omap2420-mcbsp";
> reg = <0x48074000 0xff>;
> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
> index c392445..832f184 100644
> --- a/arch/arm/boot/dts/omap2430.dtsi
> +++ b/arch/arm/boot/dts/omap2430.dtsi
> @@ -29,6 +29,17 @@
> pinctrl-single,function-mask = <0x3f>;
> };
>
> + gpmc: gpmc@6e00 {
> + compatible = "ti,omap2430-gpmc";
> + reg = <0x6e00 0x1000>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + interrupts = <20>;
> + gpmc,num-cs = <8>;
> + gpmc,num-waitpins = <4>;
> + ti,hwmods = "gpmc";
> + };
> +
> mcbsp1: mcbsp@48074000 {
> compatible = "ti,omap2430-mcbsp";
> reg = <0x48074000 0xff>;
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 827f6f3..726ef11 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -196,6 +196,17 @@
> #interrupt-cells = <1>;
> };
>
> + gpmc: gpmc@5000 {
> + compatible = "ti,omap4430-gpmc";
> + reg = <0x5000 0x1000>;
Hi Jon,
By looking at the GPMC Register Summary from both the OMAP4460 and OMAP OMAP35x
Technical Reference Manuals I see that the GPMC register address space
is only 720 bytes length. From base address + 0x0 to base address +
0x02d0.
So shouldn't the regs property be <0x5000 0x2d0> instead?
Of course are only a few kilobytes but still I wonder if it makes
sense to map them when they are not going to be used.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2: twl-common: Add default power configuration
Hello Tony and Peter,
2013/2/19 Peter Ujfalusi :
> Hi Matthias,
>
> On 02/15/2013 04:59 PM, Matthias Brugger wrote:
>> 2013/2/1 Tony Lindgren :
>>> Hi,
>>>
>>> * Robert Nelson [130124 07:58]:
On Wed, Jan 23, 2013 at 12:50 PM, Matthias Brugger
wrote:
> This patch adds a generic power script configuration.
> When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
> With the generic power script, TWL4030 will be reset
> when a warm reset occures. This way the OMAP3530 does not
> hang on reboot.
>>>
>>> Both look OK to me. I've added Peter to cc, it's best that he queues
>>> all the twl changes.
>>>
>>
>> Peter any comments on this patch?
>
> The patch looks good to me as well.
It looks like the patch wasn't added to the 3.9 series. Is there any
reason for that, or was it just a misunderstanding between you two,
about who will push it to Linus?
Cheers,
Matthias
>
>> Are you maintaining the whole twl4030 support or just the codec driver?
>
> Right now I'm maintaining the audio support (audio MFD, vibra, ASoC) in twl*
> While I have done some cleanup in the twl-core and related drivers recently
> and I'm reviewing patches sent for any *twl* driver (if I'm in the CC) I have
> not declared myself as Maintainer of the twl stack.
> The problem with the twl stack is that the drivers are spread around in
> different subsystem so if one takes maintainer responsibility for the stack,
> he/she need to have several entries in MAINTAINERS file to cover twl. I still
> don't think it is a good idea to 'bloat' the MAINTAINERS file for this.
> I'm happy to review patches. About a year ago we had internal discussion
> regarding to twl in upstream and Tero Kristo 'volunteered' to review patches
> as well.
>
> I still think that the twl patches should be queued via the corresponding
> subsystem (OMAP, MFD, Input, GPIO, PWM, etc).
>
> --
> Péter
>
>>
>> Best regards,
>> Matthias
>>
>>
>>> Regards,
>>>
>>> Tony
>>>
> Signed-off-by: Matthias Brugger
> ---
> arch/arm/mach-omap2/twl-common.c | 38
> ++
> arch/arm/mach-omap2/twl-common.h | 1 +
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/twl-common.c
> b/arch/arm/mach-omap2/twl-common.c
> index e49b40b..f096beb 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -120,6 +120,41 @@ static struct twl4030_audio_data omap3_audio_pdata =
> {
> .codec = &omap3_codec,
> };
>
> +static struct twl4030_ins wrst_seq[] __initdata = {
> + {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
> + {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
> + {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
> + {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
> + {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
> + {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
> +};
> +
> +static struct twl4030_script wrst_script __initdata = {
> + .script = wrst_seq,
> + .size = ARRAY_SIZE(wrst_seq),
> + .flags = TWL4030_WRST_SCRIPT,
> +};
> +
> +static struct twl4030_script *omap3_power_scripts[] __initdata = {
> + &wrst_script,
> +};
> +
> +static struct twl4030_resconfig omap3_rconfig[] = {
> + { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
> + .type2 = -1 },
> + { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
> + .type2 = -1 },
> + { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
> + .type2 = -1 },
> + { 0, 0},
> +};
> +
> +static struct twl4030_power_data omap3_power_pdata = {
> + .scripts= omap3_power_scripts,
> + .num= ARRAY_SIZE(omap3_power_scripts),
> + .resource_config = omap3_rconfig,
> +};
> +
> static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
> REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
> };
> @@ -224,6 +259,9 @@ void __init omap3_pmic_get_config(struct
> twl4030_platform_data *pmic_data,
> if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
> pmic_data->audio = &omap3_audio_pdata;
>
> + if (pdata_flags & TWL_COMMON_PDATA_POWER && !pmic_data->power)
> + pmic_data->power = &omap3_power_pdata;
> +
> /* Common regulator configurations */
> if (regulators_flags & TWL_COMMON_REGULATOR_VDAC &&
> !pmic_data->vdac)
> pmic_data->vdac = &omap3_vdac_idata;
> diff --git a/arch/arm/mach-omap2/twl-common.h
> b/arch/arm/mach-omap2/twl-common.h
> index dcfbad5..dbeb905 100644
> --- a/arch/arm/mach-omap2/twl-common.h
> +++ b/arch/arm/ma
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On 03/08/2013 11:26 AM, Felipe Balbi wrote: > On Fri, Mar 08, 2013 at 10:14:11AM -0700, Stephen Warren wrote: >> On 03/08/2013 12:14 AM, Felipe Balbi wrote: >>> Hi, >>> >>> On Thu, Mar 07, 2013 at 02:20:36PM -0700, Stephen Warren >>> wrote: On 03/07/2013 02:35 AM, Felipe Balbi wrote: > Hi folks, > > inspired by Paul's DWC2 patchset which added > usb_otg_state_string() (a copy of otg_state_string()) I > have now renamed otg_state_string() to > usb_otg_state_string(), moved it to usb-common, then moved > all phy drivers to drivers/usb/phy/ and completely deleted > the otg directory. > > We're also removing CONFIG_USB_OTG_UTILS since that has > lots its meaning long ago. > > I have compiled all patches with allyes, allno and allmod > configs, but please make sure to test on your platforms to > make sure we're not leaking any more problems to mainline. What branch do the patches apply to? They didn't "git am" for me on either next-20130305, nor git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next. >>> >>> they're on top of my testing branch. >> >> Ah, thanks. I took that whole branch, built ARM's >> tegra_defconfig, and see: >> >>> warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects >>> USB_ULPI which has unmet direct dependencies (USB_SUPPORT && >>> USB_PHY && ARM) warning: (ARCH_TEGRA_2x_SOC && >>> ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT which has unmet >>> direct dependencies (USB_SUPPORT && USB_PHY && USB_ULPI) >>> warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects >>> USB_ULPI which has unmet direct dependencies (USB_SUPPORT && >>> USB_PHY && ARM) warning: (ARCH_TEGRA_2x_SOC && >>> ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT which has unmet >>> direct dependencies (USB_SUPPORT && USB_PHY && USB_ULPI) >> >> Manually enabling USB_PHY fixes this. However, this highlights >> an issue with your removal of all selects (as mentioned in your >> other email) - it will break perhaps any defconfig that has USB >> enabled. >> >> After enabling USB_PHY, the code builds and runs without issue. > > fair enough, but then I'm just exposing the trouble. ARCH > shouldn't select USB_ULTI or any of the phy drivers, for that > matter. Yes, I think it should instead work like: ARCH_TEGRA* selects nothing in particular related to USB. The Tegra EHCI controller Kconfig depends on ARCH_TEGRA so it doesn't show up for other builds. I hope it's OK for the EHCI controller to select USB_ARCH_HAS_EHCI? The Tegra EHCI controller Kconfig selects everything needed for it to be useful, i.e. PHY support and the Tegra PHY, and I guess the ULPI viewport options. The Tegra PHY Kconfig probably shouldn't be user-visible (relying on being selected by the Tegra EHCI controller) and itself selects anything it relies on. Does that sound reasonable? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On Fri, Mar 08, 2013 at 10:14:11AM -0700, Stephen Warren wrote: > On 03/08/2013 12:14 AM, Felipe Balbi wrote: > > Hi, > > > > On Thu, Mar 07, 2013 at 02:20:36PM -0700, Stephen Warren wrote: > >> On 03/07/2013 02:35 AM, Felipe Balbi wrote: > >>> Hi folks, > >>> > >>> inspired by Paul's DWC2 patchset which added > >>> usb_otg_state_string() (a copy of otg_state_string()) I have > >>> now renamed otg_state_string() to usb_otg_state_string(), moved > >>> it to usb-common, then moved all phy drivers to > >>> drivers/usb/phy/ and completely deleted the otg directory. > >>> > >>> We're also removing CONFIG_USB_OTG_UTILS since that has lots > >>> its meaning long ago. > >>> > >>> I have compiled all patches with allyes, allno and allmod > >>> configs, but please make sure to test on your platforms to make > >>> sure we're not leaking any more problems to mainline. > >> > >> What branch do the patches apply to? They didn't "git am" for me > >> on either next-20130305, nor > >> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > >> next. > > > > they're on top of my testing branch. > > Ah, thanks. I took that whole branch, built ARM's tegra_defconfig, and > see: > > > warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI > > which has unmet direct dependencies (USB_SUPPORT && USB_PHY && > > ARM) warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects > > USB_ULPI_VIEWPORT which has unmet direct dependencies (USB_SUPPORT > > && USB_PHY && USB_ULPI) warning: (ARCH_TEGRA_2x_SOC && > > ARCH_TEGRA_3x_SOC) selects USB_ULPI which has unmet direct > > dependencies (USB_SUPPORT && USB_PHY && ARM) warning: > > (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT > > which has unmet direct dependencies (USB_SUPPORT && USB_PHY && > > USB_ULPI) > > Manually enabling USB_PHY fixes this. However, this highlights an > issue with your removal of all selects (as mentioned in your other > email) - it will break perhaps any defconfig that has USB enabled. > > After enabling USB_PHY, the code builds and runs without issue. fair enough, but then I'm just exposing the trouble. ARCH shouldn't select USB_ULTI or any of the phy drivers, for that matter. -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
* Paul Bolle [130308 10:06]: > On Fri, 2013-03-08 at 09:55 -0800, Tony Lindgren wrote: > > * Paul Bolle [130308 09:24]: > > > Should I draft a patch? > > > > Sure that would be nice. > > One thing I couldn't determine is how the generated mach-types.h header > handles multiple CONFIG_MACH_* macros. > > If both CONFIG_MACH_FOO and CONFIG_MACH_BAR are defined, and these both > have a line in */mach-types, will the machine_is_foo() and > machine_is_bar() macros both behave as one would expect? Yes they do, for the selected ones the macro becomes machine_arch_type == MACH_TYPE_XYZ instead of 0. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
On Fri, 2013-03-08 at 09:55 -0800, Tony Lindgren wrote: > * Paul Bolle [130308 09:24]: > > Should I draft a patch? > > Sure that would be nice. One thing I couldn't determine is how the generated mach-types.h header handles multiple CONFIG_MACH_* macros. If both CONFIG_MACH_FOO and CONFIG_MACH_BAR are defined, and these both have a line in */mach-types, will the machine_is_foo() and machine_is_bar() macros both behave as one would expect? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
* Paul Bolle [130308 09:24]: > On Fri, 2013-03-08 at 08:35 -0800, Tony Lindgren wrote: > > I think the righ fix is to just add > > > > config MACH_NOKIA_RM680 > > bool > > I guess you meant MACH_NOKIA_RM696. Ooops yes. > > to the mach-omap2/Kconfig like we have for n8x0 also. > > Should I draft a patch? Sure that would be nice. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] ARM: dts: OMAP3+: Correct gpio #interrupts-cells property
The OMAP gpio binding documention [1] states that the #interrupts-cells
property for gpio controllers should be 2. Currently, for OMAP3+ devices
the #interrupt-cells is set to 1. By setting this property to 2, it
allows clients to pass a 2nd parameter indicating the sensitivity (level
or edge) and polarity (high or low) of the interrupt. The OMAP gpio
controllers support these options and so update the #interrupt-cells
property for OMAP3+ devices to 2.
[1] Documentation/devicetree/bindings/gpio/gpio-omap.txt
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap3.dtsi | 12 ++--
arch/arm/boot/dts/omap4.dtsi | 12 ++--
arch/arm/boot/dts/omap5.dtsi | 16
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 5b36de5..c9bedf7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -117,7 +117,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio2: gpio@4905 {
@@ -126,7 +126,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio3: gpio@49052000 {
@@ -135,7 +135,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio4: gpio@49054000 {
@@ -144,7 +144,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio5: gpio@49056000 {
@@ -153,7 +153,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio6: gpio@49058000 {
@@ -162,7 +162,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
uart1: serial@4806a000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 726ef11..544be06 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -138,7 +138,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio2: gpio@48055000 {
@@ -149,7 +149,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio3: gpio@48057000 {
@@ -160,7 +160,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio4: gpio@48059000 {
@@ -171,7 +171,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio5: gpio@4805b000 {
@@ -182,7 +182,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpio6: gpio@4805d000 {
@@ -193,7 +193,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
- #interrupt-cells = <1>;
+ #interrupt-cells = <2>;
};
gpmc: gpmc@5000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 34f41ad..93feb50 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -128,7 +128,7 @@
gpio-cont
[PATCH 9/9] ARM: dts: OMAP3: Add reg and interrupt properties for gpio
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap3.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index c9bedf7..f4651af 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,6 +113,8 @@
gpio1: gpio@4831 {
compatible = "ti,omap3-gpio";
+ reg = <0x4831 0x200>;
+ interrupts = <29>;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -122,6 +124,8 @@
gpio2: gpio@4905 {
compatible = "ti,omap3-gpio";
+ reg = <0x4905 0x200>;
+ interrupts = <30>;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -131,6 +135,8 @@
gpio3: gpio@49052000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49052000 0x200>;
+ interrupts = <31>;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -140,6 +146,8 @@
gpio4: gpio@49054000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49054000 0x200>;
+ interrupts = <32>;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -149,6 +157,8 @@
gpio5: gpio@49056000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49056000 0x200>;
+ interrupts = <33>;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -158,6 +168,8 @@
gpio6: gpio@49058000 {
compatible = "ti,omap3-gpio";
+ reg = <0x49058000 0x200>;
+ interrupts = <34>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter
Reviewed-by: Felipe Balbi
Acked-by: Santosh Shilimkar
Tested-by: Santosh Shilimkar
---
.../devicetree/bindings/dma/omap-sdma.txt | 51
arch/arm/boot/dts/omap2.dtsi | 12 +
arch/arm/boot/dts/omap3.dtsi | 40 +++
arch/arm/boot/dts/omap4.dtsi | 41
arch/arm/boot/dts/omap5.dtsi | 41
5 files changed, 185 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt
b/Documentation/devicetree/bindings/dma/omap-sdma.txt
new file mode 100644
index 000..22aab28
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
@@ -0,0 +1,51 @@
+* TI OMAP SDMA controller
+
+Required properties:
+- compatible: Should be set to one of the following:
+
+ ti,omap2420-sdma (omap2420)
+ ti,omap2430-sdma (omap2430)
+ ti,omap3430-sdma (omap3430)
+ ti,omap3630-sdma (omap3630)
+ ti,omap4430-sdma (omap4430 & omap4460 & omap543x)
+
+- reg: Contains DMA registers location and length.
+- interrupts: Contains DMA interrupt information.
+- #dma-cells: Must be 1.
+- #dma-channels: Contains total number of programmable DMA channels.
+- #dma-requests: Contains total number of DMA requests.
+
+Example:
+
+ sdma: dma-controller@4A056000 {
+ compatible = "ti,omap-sdma";
+ reg = <0x4A056000 0x1000>;
+ interrupts = <0 12 0x4>,
+<0 13 0x4>,
+<0 14 0x4>,
+<0 15 0x4>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <127>;
+ };
+
+
+* TI OMAP SDMA clients
+
+Required properties:
+- dmas:List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - The DMA request number associated with client device
+- dma-names: Contains one identifier string for each dma specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
+
+Example:
+
+ mmc1: mmc@4809c000 {
+ ...
+ dmas = <&sdma 61>, /* TX channel */
+ <&sdma 62>; /* RX channel */
+ dma-names = "tx", "rx";
+ ...
+ };
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 27f5ea1..84183f0 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -54,6 +54,18 @@
reg = <0x480FE000 0x1000>;
};
+ sdma: dma-controller@48056000 {
+ compatible = "ti,omap2430-sdma", "ti,omap2420-sdma";
+ reg = <0x48056000 0x1000>;
+ interrupts = <12>,
+<13>,
+<14>,
+<15>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <64>;
+ };
+
uart1: serial@4806a000 {
compatible = "ti,omap2-uart";
ti,hwmods = "uart1";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 2ddae38..5b36de5 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -81,6 +81,18 @@
reg = <0x4820 0x1000>;
};
+ sdma: dma-controller@48056000 {
+ compatible = "ti,omap3630-sdma", "ti,omap3430-sdma";
+ reg = <0x48056000 0x1000>;
+ interrupts = <12>,
+<13>,
+<14>,
+<15>;
+ #dma-cells = <1>;
+ #dma-channels = <32>;
+ #dma-requests = <96>;
+ };
+
omap3_pmx_core: pinmux@48002030 {
compatible = "ti,omap3-padconf", "pinctrl-single";
reg = <0x48002030 0x05cc>;
@@ -198,6 +210,16 @@
#size-cells = <0>;
ti,hwmods = "mcspi1";
[PATCH 7/9] ARM: dts: Add OMAP2 gpio bindings
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2420.dtsi | 44 +++
arch/arm/boot/dts/omap2430.dtsi | 55 +++
2 files changed, 99 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index d4ce6c2..eee902f 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,50 @@
pinctrl-single,function-mask = <0x3f>;
};
+ gpio1: gpio@48018000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x48018000 0x200>;
+ interrupts = <29>;
+ ti,hwmods = "gpio1";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio2: gpio@4801a000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4801a000 0x200>;
+ interrupts = <30>;
+ ti,hwmods = "gpio2";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio3: gpio@4801c000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4801c000 0x200>;
+ interrupts = <31>;
+ ti,hwmods = "gpio3";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio4: gpio@4801e000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4801e000 0x200>;
+ interrupts = <32>;
+ ti,hwmods = "gpio4";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
gpmc: gpmc@6800a000 {
compatible = "ti,omap2420-gpmc";
reg = <0x6800a000 0x1000>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 832f184..fb74382 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,61 @@
pinctrl-single,function-mask = <0x3f>;
};
+ gpio1: gpio@4900c000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4900c000 0x200>;
+ interrupts = <29>;
+ ti,hwmods = "gpio1";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio2: gpio@4900e000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4900e000 0x200>;
+ interrupts = <30>;
+ ti,hwmods = "gpio2";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio3: gpio@4901 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x4901 0x200>;
+ interrupts = <31>;
+ ti,hwmods = "gpio3";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio4: gpio@49012000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x49012000 0x200>;
+ interrupts = <32>;
+ ti,hwmods = "gpio4";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
+ gpio5: gpio@480b6000 {
+ compatible = "ti,omap2-gpio";
+ reg = <0x480b6000 0x200>;
+ interrupts = <33>;
+ ti,hwmods = "gpio5";
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
+
gpmc: gpmc@6e00 {
compatible = "ti,omap2430-gpmc";
reg = <0x6e000
[PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings
Add the device-tree nodes for the 128MB ONENAND flash and 256MB NAND
flash memories found on the OMAP3430 SDP board.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap3430-sdp.dts | 95
1 file changed, 95 insertions(+)
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index be0650d..c313762 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -44,3 +44,98 @@
&mmc3 {
status = "disabled";
};
+
+&gpmc {
+ ranges = <1 0 0x2800 0x0800>,
+<2 0 0x2000 0x1000>;
+
+ nand@1,0 {
+ linux,mtd-name= "micron,mt29f1g08abb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <1 0 0x0800>;
+ nand-bus-width = <8>;
+
+ gpmc,device_nand;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <36>;
+ gpmc,cs-wr-off = <36>;
+ gpmc,adv-on = <6>;
+ gpmc,adv-rd-off = <24>;
+ gpmc,adv-wr-off = <36>;
+ gpmc,oe-on = <6>;
+ gpmc,oe-off = <48>;
+ gpmc,we-on = <6>;
+ gpmc,we-off = <30>;
+ gpmc,rd-cycle = <72>;
+ gpmc,wr-cycle = <72>;
+ gpmc,access = <54>;
+ gpmc,wr-access = <30>;
+
+ partition@0 {
+ label = "xloader-nand";
+ reg = <0 0x8>;
+ };
+ partition@0x8 {
+ label = "bootloader-nand";
+ reg = <0x8 0x14>;
+ };
+ partition@0x1c {
+ label = "params-nand";
+ reg = <0x1c 0xc>;
+ };
+ partition@0x28 {
+ label = "kernel-nand";
+ reg = <0x28 0x50>;
+ };
+ partition@0x78 {
+ label = "filesystem-nand";
+ reg = <0x78 0x788>;
+ };
+ };
+
+ onenand@2,0 {
+ linux,mtd-name= "samsung,kfm2g16q2m-deb8";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <2 0 0x1000>;
+
+ gpmc,device-width = <2>;
+ gpmc,mux-add-data = <2>;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <84>;
+ gpmc,cs-wr-off = <72>;
+ gpmc,adv-on = <0>;
+ gpmc,adv-rd-off = <18>;
+ gpmc,adv-wr-off = <18>;
+ gpmc,oe-on = <30>;
+ gpmc,oe-off = <84>;
+ gpmc,we-on = <0>;
+ gpmc,we-off = <42>;
+ gpmc,rd-cycle = <108>;
+ gpmc,wr-cycle = <96>;
+ gpmc,access = <78>;
+ gpmc,wr-data-mux-bus = <30>;
+
+ partition@0 {
+ label = "xloader-onenand";
+ reg = <0 0x8>;
+ };
+ partition@0x8 {
+ label = "bootloader-onenand";
+ reg = <0x8 0x4>;
+ };
+ partition@0xc {
+ label = "params-onenand";
+ reg = <0xc 0x2>;
+ };
+ partition@0xe {
+ label = "kernel-onenand";
+ reg = <0xe 0x20>;
+ };
+ partition@0x2e {
+ label = "filesystem-onenand";
+ reg = <0x2e 0xfd2>;
+ };
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] ARM: dts: OMAP2+: Add PMU nodes
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
4 files changed, 31 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4460.dtsi
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..27f5ea1 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -26,6 +26,11 @@
};
};
+ pmu {
+ compatible = "arm,arm1136-pmu";
+ interrupts = <3>;
+ };
+
soc {
compatible = "ti,omap-infra";
mpu {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 9f36531..2ddae38 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -26,6 +26,12 @@
};
};
+ pmu {
+ compatible = "arm,cortex-a8-pmu";
+ interrupts = <3>;
+ ti,hwmods = "debugss";
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 73bc1a6..2a6e344 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -5,7 +5,9 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+
/include/ "omap4-panda.dts"
+/include/ "omap4460.dtsi"
/* Audio routing is differnet between PandaBoard4430 and PandaBoardES */
&sound {
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
new file mode 100644
index 000..0a1d38b
--- /dev/null
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -0,0 +1,18 @@
+/*
+ * Device Tree Source for OMAP4460 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/ {
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts = <0 54 0x4>,
+<0 55 0x4>;
+ ti,hwmods = "debugss";
+ };
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
arch/arm/boot/dts/omap4.dtsi| 11 +++
arch/arm/boot/dts/omap5.dtsi| 11 +++
4 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index af65609..d4ce6c2 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = <0x3f>;
};
+ gpmc: gpmc@6800a000 {
+ compatible = "ti,omap2420-gpmc";
+ reg = <0x6800a000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ ti,hwmods = "gpmc";
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = "ti,omap2420-mcbsp";
reg = <0x48074000 0xff>;
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c392445..832f184 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,17 @@
pinctrl-single,function-mask = <0x3f>;
};
+ gpmc: gpmc@6e00 {
+ compatible = "ti,omap2430-gpmc";
+ reg = <0x6e00 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ ti,hwmods = "gpmc";
+ };
+
mcbsp1: mcbsp@48074000 {
compatible = "ti,omap2430-mcbsp";
reg = <0x48074000 0xff>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 827f6f3..726ef11 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,17 @@
#interrupt-cells = <1>;
};
+ gpmc: gpmc@5000 {
+ compatible = "ti,omap4430-gpmc";
+ reg = <0x5000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <0 20 0x4>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ ti,hwmods = "gpmc";
+ };
+
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 06d21d6..34f41ad 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -208,6 +208,17 @@
#interrupt-cells = <1>;
};
+ gpmc: gpmc@5000 {
+ compatible = "ti,omap4430-gpmc";
+ reg = <0x5000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ interrupts = <0 20 0x4>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ ti,hwmods = "gpmc";
+ };
+
i2c1: i2c@4807 {
compatible = "ti,omap4-i2c";
reg = <0x4807 0x100>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM and uses the TWL4030 power management IC.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 46
2 files changed, 47 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..89013ed 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3430-sdp.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
new file mode 100644
index 000..be0650d
--- /dev/null
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.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.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+ model = "TI OMAP3430 SDP";
+ compatible = "ti,omap3430-sdp", "ti,omap3";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+};
+
+&i2c1 {
+ clock-frequency = <260>;
+
+ twl: twl@48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ };
+};
+
+/include/ "twl4030.dtsi"
+
+&mmc1 {
+ vmmc-supply = <&vmmc1>;
+ vmmc_aux-supply = <&vsim>;
+ bus-width = <8>;
+};
+
+&mmc2 {
+ status = "disabled";
+};
+
+&mmc3 {
+ status = "disabled";
+};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] ARM: OMAP2+: Prepare for device-tree PMU support
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/pmu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 9debf82..9ace8ea 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,6 +11,8 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
+#include
+
#include
#include "soc.h"
@@ -63,6 +65,15 @@ static int __init omap_init_pmu(void)
unsigned oh_num;
char **oh_names;
+ /* XXX Remove this check when the CTI driver is available */
+ if (cpu_is_omap443x()) {
+ pr_info("ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n");
+ return 0;
+ }
+
+ if (of_have_populated_dt())
+ return 0;
+
/*
* To create an ARM-PMU device the following HWMODs
* are required for the various OMAP2+ devices.
@@ -75,9 +86,6 @@ static int __init omap_init_pmu(void)
if (cpu_is_omap443x()) {
oh_num = ARRAY_SIZE(omap4430_pmu_oh_names);
oh_names = omap4430_pmu_oh_names;
- /* XXX Remove the next two lines when CTI driver available */
- pr_info("ARM PMU: not yet supported on OMAP4430 due to missing
CTI driver\n");
- return 0;
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] ARM: dts: Various OMAP2+ device-tree updates
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards. The DMA, PMU and OMAP3430 SDP board changes have been sent before individually but re-sending here as a complete series for v3.10. This is based upon v3.9-rc1 and the OMAP3 GPMC binding from Florian Vaussard [1] and OMAP5 DT SPI patch from Felipe Balbi [2]. [1] https://patchwork.kernel.org/patch/2057111/ [2] https://patchwork.kernel.org/patch/2134711/ Jon Hunter (9): ARM: OMAP2+: Prepare for device-tree PMU support ARM: dts: OMAP2+: Add PMU nodes ARM: dts: OMAP2+: Add SDMA controller bindings and nodes ARM: dts: OMAP3: Add support for OMAP3430 SDP board ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5 ARM: dts: Add OMAP3430 SDP flash memory bindings ARM: dts: Add OMAP2 gpio bindings ARM: dts: OMAP3+: Correct gpio #interrupts-cells property ARM: dts: OMAP3: Add reg and interrupt properties for gpio .../devicetree/bindings/dma/omap-sdma.txt | 51 +++ arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/omap2.dtsi | 17 +++ arch/arm/boot/dts/omap2420.dtsi| 55 arch/arm/boot/dts/omap2430.dtsi| 66 + arch/arm/boot/dts/omap3.dtsi | 70 +- arch/arm/boot/dts/omap3430-sdp.dts | 141 arch/arm/boot/dts/omap4-panda-es.dts |2 + arch/arm/boot/dts/omap4.dtsi | 64 - arch/arm/boot/dts/omap4460.dtsi| 18 +++ arch/arm/boot/dts/omap5.dtsi | 68 -- arch/arm/mach-omap2/pmu.c | 14 +- 12 files changed, 544 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts create mode 100644 arch/arm/boot/dts/omap4460.dtsi -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ASoC: OMAP2+: Update Audio IP with sDMA binding for DT boot
On Fri, Mar 08, 2013 at 10:23:41AM +0100, Peter Ujfalusi wrote: > If we have them as separate we will have runtime regression between the > patches. It is better to have them squashed together. Other than the issues mentioned this looks OK to me. signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
On Fri, 2013-03-08 at 08:35 -0800, Tony Lindgren wrote: > I think the righ fix is to just add > > config MACH_NOKIA_RM680 > bool I guess you meant MACH_NOKIA_RM696. > to the mach-omap2/Kconfig like we have for n8x0 also. Should I draft a patch? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
On Fri, 2013-03-08 at 18:11 +0200, Aaro Koskinen wrote:
> On Fri, Mar 08, 2013 at 11:29:56AM +0100, Paul Bolle wrote:
> > When support was added for Nokia N9 (RM-696), with commit
> > 63fc5f3bb3d0ca9ab4767a801b518aa6335f87ad ("ARM: OMAP: add minimal
> > support for Nokia RM-696"), a select statement for MACH_NOKIA_RM696 was
> > added to the tree. But there's no Kconfig symbol with that name. That
> > symbol would be superfluous, since support for that machine piggybacks
> > on MACH_NOKIA_RM680. So drop that select.
>
> This is needed because of arch/arm/tools/mach-types. See
> include/generated/mach-types.h.
How does that file actually need this select statement?
> If you have just CONFIG_MACH_NOKIA_RM680 and run the kernel on RM-696,
> then machine_is_nokia_rm696() will return false. If I rememeber correctly,
> this broke at least early printk / uncompressor output at the time.
>
> I guess people may still want to use machine_is_... macros e.g. for
> debugging.
What in the current mainline kernel cares about a
machine_is_nokia_rm696() macro?
$ git grep -n machine_is_nokia v3.9-rc1
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:349: if (machine_is_nokia_n800()
|| slot == 0)
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:395: if
(machine_is_nokia_n800()) {
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:428: if (machine_is_nokia_n800())
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:451: if
(machine_is_nokia_n800()) {
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:478: if (machine_is_nokia_n800())
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:493: if
(machine_is_nokia_n810()) {
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:544: if
(machine_is_nokia_n810()) {
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:562: if
(machine_is_nokia_n810()) {
v3.9-rc1:arch/arm/mach-omap2/board-n8x0.c:714: if (machine_is_nokia_n810())
v3.9-rc1:arch/arm/mach-omap2/board-rx51-video.c:71: if
(!machine_is_nokia_rx51())
v3.9-rc1:drivers/usb/host/ohci-omap.c:267: } else if
(machine_is_nokia770()) {
v3.9-rc1:sound/soc/omap/n810.c:309: if (!(machine_is_nokia_n810() ||
machine_is_nokia_n810_wimax()))
v3.9-rc1:sound/soc/omap/rx51.c:400: if (!machine_is_nokia_rx51())
$ git grep -n rm696 v3.9-rc1
v3.9-rc1:arch/arm/tools/mach-types:589:nokia_rm696
MACH_NOKIA_RM696NOKIA_RM696 3522
I don't find any actual usage of that macro. Are its uses also
generated?
> > 0) Tested with "git grep".
>
> git grep won't search generated source files.
Of course. That's one of the reasons why I explicitly state that I only
tested it that way.
> > 1) Some searching on the web didn't return a "config MACH_NOKIA_RM696".
> > So apparently there's not even a development tree that uses this symbol.
>
> You can see machine_is_nokia_rm696() used in the public kernel source
> for Nokia N9 product. :-)
Where would that be? And does that tree actually have a Kconfig entry
MACH_NOKIA_RM696?
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories
On 03/08/2013 12:14 AM, Felipe Balbi wrote: > Hi, > > On Thu, Mar 07, 2013 at 02:20:36PM -0700, Stephen Warren wrote: >> On 03/07/2013 02:35 AM, Felipe Balbi wrote: >>> Hi folks, >>> >>> inspired by Paul's DWC2 patchset which added >>> usb_otg_state_string() (a copy of otg_state_string()) I have >>> now renamed otg_state_string() to usb_otg_state_string(), moved >>> it to usb-common, then moved all phy drivers to >>> drivers/usb/phy/ and completely deleted the otg directory. >>> >>> We're also removing CONFIG_USB_OTG_UTILS since that has lots >>> its meaning long ago. >>> >>> I have compiled all patches with allyes, allno and allmod >>> configs, but please make sure to test on your platforms to make >>> sure we're not leaking any more problems to mainline. >> >> What branch do the patches apply to? They didn't "git am" for me >> on either next-20130305, nor >> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git >> next. > > they're on top of my testing branch. Ah, thanks. I took that whole branch, built ARM's tegra_defconfig, and see: > warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI > which has unmet direct dependencies (USB_SUPPORT && USB_PHY && > ARM) warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects > USB_ULPI_VIEWPORT which has unmet direct dependencies (USB_SUPPORT > && USB_PHY && USB_ULPI) warning: (ARCH_TEGRA_2x_SOC && > ARCH_TEGRA_3x_SOC) selects USB_ULPI which has unmet direct > dependencies (USB_SUPPORT && USB_PHY && ARM) warning: > (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT > which has unmet direct dependencies (USB_SUPPORT && USB_PHY && > USB_ULPI) Manually enabling USB_PHY fixes this. However, this highlights an issue with your removal of all selects (as mentioned in your other email) - it will break perhaps any defconfig that has USB enabled. After enabling USB_PHY, the code builds and runs without issue. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 16/17] ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable
With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the
variable "boot_rom_space" is now not needed and the code surrounding
this variable can be cleaned up and simplified. Remove unnecessary
definitions and clean-up the comment as well.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4d662ce..c79f80e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -92,9 +92,7 @@
#define GPMC_CS_SIZE 0x30
#defineGPMC_BCH_SIZE 0x10
-#define GPMC_MEM_START 0x
#define GPMC_MEM_END 0x3FFF
-#define BOOT_ROM_SPACE 0x10/* 1MB */
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
#define GPMC_SECTION_SHIFT 28 /* 128 MB */
@@ -790,13 +788,13 @@ static void gpmc_mem_exit(void)
static int gpmc_mem_init(void)
{
int cs, rc;
- unsigned long boot_rom_space = 0;
- /* never allocate the first page, to facilitate bug detection;
-* even if we didn't boot from ROM.
+ /*
+* The first 1MB of GPMC address space is typically mapped to
+* the internal ROM. Never allocate the first page, to
+* facilitate bug detection; even if we didn't boot from ROM.
*/
- boot_rom_space = BOOT_ROM_SPACE;
- gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
+ gpmc_mem_root.start = SZ_1M;
gpmc_mem_root.end = GPMC_MEM_END;
/* Reserve all regions that has been set up by bootloader */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 12/17] ARM: OMAP2+: Add additional GPMC timing parameters
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them.
The existing code in gpmc_read_timings_dt() is checking the value of
of_property_read_u32() and only is successful storing the value read
in the gpmc_timings structure. Checking the return value in this case
is not necessary and we can simply read the value, if present, and
store directly in the gpmc_timings structure. Therefore, simplify the
code by removing these checks.
The comment in the gpmc_read_timings_dt() function, "only for OMAP3430"
is also incorrect as it is applicable to all OMAP3+ devices. So correct
this too.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 25 +-
arch/arm/mach-omap2/gpmc.c| 93 ++---
2 files changed, 66 insertions(+), 52 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 6fde1cf..a63bd93 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -56,10 +56,27 @@ Timing properties for child nodes. All are optional and
default to 0.
- gpmc,oe-off:Deassertion time
Access time and cycle time timings corresponding to GPMC_CONFIG5:
- - gpmc,page-burst-access: Multiple access word delay
- - gpmc,access:Start-cycle to first data valid delay
- - gpmc,rd-cycle: Total read cycle time
- - gpmc,wr-cycle: Total write cycle time
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access:Start-cycle to first data valid delay
+ - gpmc,rd-cycle: Total read cycle time
+ - gpmc,wr-cycle: Total write cycle time
+ - gpmc,bus-turnaround:Turn-around time between successive
accesses
+ - gpmc,cycle2cycle-delay: Delay between chip-select pulses
+ - gpmc,clk-activation:GPMC clock activation time
+ - gpmc,wait-monitoring: Start of wait monitoring with regard to valid
+ data
+
+Boolean timing parameters. If property is present parameter enabled and
+disabled if omitted:
+ - gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock
+ - gpmc,cs-extra-delay:CS signal is delayed by half GPMC clock
+ - gpmc,cycle2cycle-diffcsen: Add "cycle2cycle-delay" between successive
+ accesses to a different CS
+ - gpmc,cycle2cycle-samecsen: Add "cycle2cycle-delay" between successive
+ accesses to the same CS
+ - gpmc,oe-extra-delay:OE signal is delayed by half GPMC clock
+ - gpmc,we-extra-delay:WE signal is delayed by half GPMC clock
+ - gpmc,time-para-granularity: Multiply all access times by 2
The following are only applicable to OMAP3+ and AM335x:
- gpmc,wr-access
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 05ca0af..6dd110e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1274,67 +1274,64 @@ void gpmc_read_settings_dt(struct device_node *np,
struct gpmc_settings *p)
static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
struct gpmc_timings *gpmc_t)
{
- u32 val;
-
memset(gpmc_t, 0, sizeof(*gpmc_t));
/* minimum clock period for syncronous mode */
- if (!of_property_read_u32(np, "gpmc,sync-clk", &val))
- gpmc_t->sync_clk = val;
+ of_property_read_u32(np, "gpmc,sync-clk", &gpmc_t->sync_clk);
/* chip select timtings */
- if (!of_property_read_u32(np, "gpmc,cs-on", &val))
- gpmc_t->cs_on = val;
-
- if (!of_property_read_u32(np, "gpmc,cs-rd-off", &val))
- gpmc_t->cs_rd_off = val;
-
- if (!of_property_read_u32(np, "gpmc,cs-wr-off", &val))
- gpmc_t->cs_wr_off = val;
+ of_property_read_u32(np, "gpmc,cs-on", &gpmc_t->cs_on);
+ of_property_read_u32(np, "gpmc,cs-rd-off", &gpmc_t->cs_rd_off);
+ of_property_read_u32(np, "gpmc,cs-wr-off", &gpmc_t->cs_wr_off);
/* ADV signal timings */
- if (!of_property_read_u32(np, "gpmc,adv-on", &val))
- gpmc_t->adv_on = val;
-
- if (!of_property_read_u32(np, "gpmc,adv-rd-off", &val))
- gpmc_t->adv_rd_off = val;
-
- if (!of_property_read_u32(np, "gpmc,adv-wr-off", &val))
- gpmc_t->adv_wr_off = val;
+ of_property_read_u32(np, "gpmc,adv-on", &gpmc_t->adv_on);
+ of_property_read_u32(np, "gpmc,adv-rd-off", &gpmc_t->adv_rd_off);
+ of_property_read_u32(np, "gpmc,adv-wr-off", &gpmc_t->adv_wr_off);
/* WE signal timings */
- if (!of_property_read_u32(np, "gpmc,we-on", &val))
- gpmc_t->we_on = val;
-
- if (!of_property_read_u3
[PATCH V2 17/17] ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails
When the GPMC driver is probed, we call gpmc_mem_init() to see which
chip-selects have already been configured and enabled by the boot-loader
and allocate space for them. If we fail to allocate space for one
chip-select, then we return failure from the probe and the GPMC driver
will not be available.
Rather than render the GPMC useless for all GPMC devices, if we fail to
allocate space for one chip-select print a warning and disable the
chip-select. This way other GPMC clients can still be used.
There is no downside to this approach, because all GPMC clients need to
request a chip-select before they can use the GPMC and on requesting a
chip-select, if memory has not already been reserved for the chip-select
then it will be.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c79f80e..70b5489 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -785,9 +785,9 @@ static void gpmc_mem_exit(void)
}
-static int gpmc_mem_init(void)
+static void gpmc_mem_init(void)
{
- int cs, rc;
+ int cs;
/*
* The first 1MB of GPMC address space is typically mapped to
@@ -804,16 +804,12 @@ static int gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, &base, &size);
- rc = gpmc_cs_insert_mem(cs, base, size);
- if (IS_ERR_VALUE(rc)) {
- while (--cs >= 0)
- if (gpmc_cs_mem_enabled(cs))
- gpmc_cs_delete_mem(cs);
- return rc;
+ if (gpmc_cs_insert_mem(cs, base, size)) {
+ pr_warn("%s: disabling cs %d mapped at 0x%x-0x%x\n",
+ __func__, cs, base, base + size);
+ gpmc_cs_disable_mem(cs);
}
}
-
- return 0;
}
static u32 gpmc_round_ps_to_sync_clk(u32 time_ps, u32 sync_clk)
@@ -1618,13 +1614,7 @@ static int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- rc = gpmc_mem_init();
- if (IS_ERR_VALUE(rc)) {
- clk_disable_unprepare(gpmc_l3_clk);
- clk_put(gpmc_l3_clk);
- dev_err(gpmc_dev, "failed to reserve memory\n");
- return rc;
- }
+ gpmc_mem_init();
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 14/17] ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT
When booting with device-tree, retrieve GPMC settings for ONENAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
The user must now specify the ONENAND device width in the device-tree
binding so that the GPMC can be programmed correctly. Therefore, update
the device-tree binding documentation for ONENAND devices connected to
the GPMC to reflect this.
Please note that this does not include GPMC timings for ONENAND. The
timings are being calculated at runtime.
There is some legacy code that only enables read wait monitoring for
non-OMAP3 devices. There are no known OMAP3 device issues that prevent
this feature being enabled and so when booting with device-tree use the
wait-monitoring settings described in the device-tree blob.
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/mtd/gpmc-onenand.txt |3 +++
arch/arm/mach-omap2/gpmc-onenand.c | 21 ++--
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
index deec9da..b752942 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -10,6 +10,8 @@ Documentation/devicetree/bindings/bus/ti-gpmc.txt
Required properties:
- reg:The CS line the peripheral is connected to
+ - gpmc,device-width Width of the ONENAND device connected to the GPMC
+ in bytes. Must be 1 or 2.
Optional properties:
@@ -34,6 +36,7 @@ Example for an OMAP3430 board:
onenand@0 {
reg = <0 0 0>; /* CS0, offset 0 */
+ gpmc,device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index aa3f53e..454371b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -272,6 +272,10 @@ static int omap2_onenand_setup_async(void __iomem
*onenand_base)
struct gpmc_timings t;
int ret;
+ if (gpmc_onenand_data->of_node)
+ gpmc_read_settings_dt(gpmc_onenand_data->of_node,
+ &onenand_async);
+
omap2_onenand_set_async_mode(onenand_base);
omap2_onenand_calc_async_timings(&t);
@@ -300,12 +304,17 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
set_onenand_cfg(onenand_base);
}
- /*
-* FIXME: Appears to be legacy code from initial ONENAND commit.
-* Unclear what boards this is for and if this can be removed.
-*/
- if (!cpu_is_omap34xx())
- onenand_sync.wait_on_read = true;
+ if (gpmc_onenand_data->of_node) {
+ gpmc_read_settings_dt(gpmc_onenand_data->of_node,
+ &onenand_sync);
+ } else {
+ /*
+* FIXME: Appears to be legacy code from initial ONENAND commit.
+* Unclear what boards this is for and if this can be removed.
+*/
+ if (!cpu_is_omap34xx())
+ onenand_sync.wait_on_read = true;
+ }
omap2_onenand_calc_sync_timings(&t, gpmc_onenand_data->flags, freq);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 09/17] ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure()
With the addition of the gpmc_cs_program_settings(), we no longer need
or use gpmc_cs_configure() to configure some of the GPMC chip-select
options. So rename the function to gpmc_configure() and remove code that
modifies options in the CONFIG1 register.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-nand.c |2 +-
arch/arm/mach-omap2/gpmc.c | 49 ++-
arch/arm/mach-omap2/gpmc.h |5 +---
3 files changed, 9 insertions(+), 47 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 1c57755..d673155 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -152,7 +152,7 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
if (IS_ERR_VALUE(err))
goto out_free_cs;
- err = gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_WP, 0);
+ err = gpmc_configure(GPMC_CONFIG_WP, 0);
if (IS_ERR_VALUE(err))
goto out_free_cs;
}
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1b81ca1..e4323ca 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -550,16 +550,14 @@ void gpmc_cs_free(int cs)
EXPORT_SYMBOL(gpmc_cs_free);
/**
- * gpmc_cs_configure - write request to configure gpmc
- * @cs: chip select number
+ * gpmc_configure - write request to configure gpmc
* @cmd: command type
* @wval: value to write
* @return status of the operation
*/
-int gpmc_cs_configure(int cs, int cmd, int wval)
+int gpmc_configure(int cmd, int wval)
{
- int err = 0;
- u32 regval = 0;
+ u32 regval;
switch (cmd) {
case GPMC_ENABLE_IRQ:
@@ -579,47 +577,14 @@ int gpmc_cs_configure(int cs, int cmd, int wval)
gpmc_write_reg(GPMC_CONFIG, regval);
break;
- case GPMC_CONFIG_RDY_BSY:
- regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
- if (wval)
- regval |= WR_RD_PIN_MONITORING;
- else
- regval &= ~WR_RD_PIN_MONITORING;
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
- break;
-
- case GPMC_CONFIG_DEV_SIZE:
- regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
-
- /* clear 2 target bits */
- regval &= ~GPMC_CONFIG1_DEVICESIZE(3);
-
- /* set the proper value */
- regval |= GPMC_CONFIG1_DEVICESIZE(wval);
-
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
- break;
-
- case GPMC_CONFIG_DEV_TYPE:
- regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
- /* clear 4 target bits */
- regval &= ~(GPMC_CONFIG1_DEVICETYPE(3) |
- GPMC_CONFIG1_MUXTYPE(3));
- /* set the proper value */
- regval |= GPMC_CONFIG1_DEVICETYPE(wval);
- if (wval == GPMC_DEVICETYPE_NOR)
- regval |= GPMC_CONFIG1_MUXADDDATA;
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
- break;
-
default:
- printk(KERN_ERR "gpmc_configure_cs: Not supported\n");
- err = -EINVAL;
+ pr_err("%s: command not supported\n", __func__);
+ return -EINVAL;
}
- return err;
+ return 0;
}
-EXPORT_SYMBOL(gpmc_cs_configure);
+EXPORT_SYMBOL(gpmc_configure);
void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
{
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index ce6ae21..87d2a22 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -59,9 +59,6 @@
#define GPMC_CONFIG1_DEVICETYPE(val)((val & 3) << 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
#define GPMC_CONFIG1_MUXTYPE(val) ((val & 3) << 8)
-#define GPMC_CONFIG1_MUXNONMUX GPMC_CONFIG1_MUXTYPE(0)
-#define GPMC_CONFIG1_MUXAAD GPMC_CONFIG1_MUXTYPE(GPMC_MUX_AAD)
-#define GPMC_CONFIG1_MUXADDDATA GPMC_CONFIG1_MUXTYPE(GPMC_MUX_AD)
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 << 4)
#define GPMC_CONFIG1_FCLK_DIV(val) (val & 3)
#define GPMC_CONFIG1_FCLK_DIV2 (GPMC_CONFIG1_FCLK_DIV(1))
@@ -227,6 +224,6 @@ extern int gpmc_cs_request(int cs, unsigned long size,
unsigned long *base);
extern void gpmc_cs_free(int cs);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
-extern int gpmc_cs_configure(int cs, int cmd, int wval);
+extern int gpmc_configure(int cmd, int wval);
#endif
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 15/17] ARM: OMAP2+: Detect incorrectly aligned GPMC base address
Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB
of address space. The physical base address where a chip-select starts
is also configurable and must be aligned on a boundary that is equal to
or greater than the size of the address space mapped bt the chip-select.
When enabling a GPMC chip-select, ensure that the base address is aligned
to the appropriate boundary.
Reported-by: Mark Jackson
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 6dd110e..4d662ce 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -403,11 +403,18 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
return 0;
}
-static void gpmc_cs_enable_mem(int cs, u32 base, u32 size)
+static int gpmc_cs_enable_mem(int cs, u32 base, u32 size)
{
u32 l;
u32 mask;
+ /*
+* Ensure that base address is aligned on a
+* boundary equal to or greater than size.
+*/
+ if (base & (size - 1))
+ return -EINVAL;
+
mask = (1 << GPMC_SECTION_SHIFT) - size;
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
l &= ~0x3f;
@@ -416,6 +423,8 @@ static void gpmc_cs_enable_mem(int cs, u32 base, u32 size)
l |= ((mask >> GPMC_CHUNK_SHIFT) & 0x0f) << 8;
l |= GPMC_CONFIG7_CSVALID;
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG7, l);
+
+ return 0;
}
static void gpmc_cs_disable_mem(int cs)
@@ -526,7 +535,9 @@ static int gpmc_cs_remap(int cs, u32 base)
ret = gpmc_cs_insert_mem(cs, base, size);
if (IS_ERR_VALUE(ret))
return ret;
- gpmc_cs_enable_mem(cs, base, size);
+ ret = gpmc_cs_enable_mem(cs, base, size);
+ if (IS_ERR_VALUE(ret))
+ return ret;
return 0;
}
@@ -556,7 +567,12 @@ int gpmc_cs_request(int cs, unsigned long size, unsigned
long *base)
if (r < 0)
goto out;
- gpmc_cs_enable_mem(cs, res->start, resource_size(res));
+ r = gpmc_cs_enable_mem(cs, res->start, resource_size(res));
+ if (IS_ERR_VALUE(r)) {
+ release_resource(res);
+ goto out;
+ }
+
*base = res->start;
gpmc_cs_set_reserved(cs, 1);
out:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 11/17] ARM: OMAP2+: Add device-tree support for NOR flash
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 +
arch/arm/mach-omap2/gpmc.c | 113
2 files changed, 211 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
new file mode 100644
index 000..8c638fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
@@ -0,0 +1,98 @@
+Device tree bindings for NOR flash connect to TI GPMC
+
+NOR flash connected to the TI GPMC (found on OMAP boards) are represented as
+child nodes of the GPMC controller with a name of "nor".
+
+All timing relevant properties as well as generic GPMC child properties are
+explained in a separate documents. Please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Required properties:
+- bank-width: Width of NOR flash in bytes. GPMC supports 8-bit and
+ 16-bit devices and so must be either 1 or 2 bytes.
+- compatible: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- gpmc,cs-on: Chip-select assertion time
+- gpmc,cs-rd-off: Chip-select de-assertion time for reads
+- gpmc,cs-wr-off: Chip-select de-assertion time for writes
+- gpmc,oe-on: Output-enable assertion time
+- gpmc,oe-off Output-enable de-assertion time
+- gpmc,we-on: Write-enable assertion time
+- gpmc,we-off: Write-enable de-assertion time
+- gpmc,access: Start cycle to first data capture (read access)
+- gpmc,rd-cycle: Total read cycle time
+- gpmc,wr-cycle: Total write cycle time
+- linux,mtd-name: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+- reg: Chip-select, base address (relative to chip-select)
+ and size of NOR flash. Note that base address will be
+ typically 0 as this is the start of the chip-select.
+
+Optional properties:
+- gpmc,XXX Additional GPMC timings and settings parameters. See
+ Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+Optional properties for partiton table parsing:
+- #address-cells: should be set to 1
+- #size-cells: should be set to 1
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = "ti,omap3430-gpmc", "simple-bus";
+ ti,hwmods = "gpmc";
+ reg = <0x6e00 0x1000>;
+ interrupts = <20>;
+ gpmc,num-cs = <8>;
+ gpmc,num-waitpins = <4>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <0 0 0x1000 0x0800>;
+
+ nor@0,0 {
+ compatible = "cfi-flash";
+ linux,mtd-name= "intel,pf48f6000m0y1be";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0 0x0800>;
+ bank-width = <2>;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <186>;
+ gpmc,cs-wr-off = <186>;
+ gpmc,adv-on = <12>;
+ gpmc,adv-rd-off = <48>;
+ gpmc,adv-wr-off = <48>;
+ gpmc,oe-on = <54>;
+ gpmc,oe-off = <168>;
+ gpmc,we-on = <54>;
+ gpmc,we-off = <168>;
+ gpmc,rd-cycle = <186>;
+ gpmc,wr-cycle = <186>;
+ gpmc,access = <114>;
+ gpmc,page-burst-access = <6>;
+ gpmc,bus-turnaround = <12>;
+ gpmc,cycle2cycle-delay = <18>;
+ gpmc,wr-data-mux-bus = <90>;
+ gpmc,wr-access = <186>;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ partition@0 {
+ label = "bootloader-nor";
+ reg = <0 0x4>;
+ };
+ partition@0x4 {
+ label = "params-nor";
+ reg = <0x4 0x4>;
+ };
+ partition@0x8 {
+ label = "kernel-nor";
+ reg = <0x8 0x20>;
+ };
+ partition@0x28 {
+ label = "filesystem-nor";
+ reg = <0x24 0x7d8>;
+ };
+ };
+};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 80808ad..05ca0af 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -499,6 +500,37 @@ static int gpmc_cs_delete_mem(int cs)
return r;
}
+/**
+ * gpmc_cs_remap - remaps a
[PATCH V2 13/17] ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT
When booting with device-tree, retrieve GPMC settings for NAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-nand.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index d673155..260915a 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -135,12 +135,16 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
return err;
}
- s.device_nand = true;
-
- /* Enable RD PIN Monitoring Reg */
- if (gpmc_nand_data->dev_ready) {
- s.wait_on_read = true;
- s.wait_on_write = true;
+ if (gpmc_nand_data->of_node) {
+ gpmc_read_settings_dt(gpmc_nand_data->of_node, &s);
+ } else {
+ s.device_nand = true;
+
+ /* Enable RD PIN Monitoring Reg */
+ if (gpmc_nand_data->dev_ready) {
+ s.wait_on_read = true;
+ s.wait_on_write = true;
+ }
}
if (gpmc_nand_data->devsize == NAND_BUSWIDTH_16)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 10/17] ARM: OMAP2+: Add function to read GPMC settings from device-tree
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation to describe these
options.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 23 ++
arch/arm/mach-omap2/gpmc.c| 49 +
arch/arm/mach-omap2/gpmc.h|2 +
3 files changed, 74 insertions(+)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 5ddb2e9..6fde1cf 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x:
- gpmc,wr-access
- gpmc,wr-data-mux-bus
+GPMC chip-select settings properties for child nodes. All are optional.
+
+- gpmc,burst-lengthPage/burst length. Must be 4, 8 or 16.
+- gpmc,burst-wrap Enables wrap bursting
+- gpmc,burst-read Enables read page/burst mode
+- gpmc,burst-write Enables write page/burst mode
+- gpmc,device-nand Device is NAND
+- gpmc,device-widthTotal width of device(s) connected to a GPMC
+ chip-select in bytes. The GPMC supports 8-bit
+ and 16-bit devices and so this property must be
+ 1 or 2.
+- gpmc,mux-add-dataAddress and data multiplexing configuration.
+ Valid values are 1 for address-address-data
+ multiplexing mode and 2 for address-data
+ multiplexing mode.
+- gpmc,sync-read Enables synchronous read. Defaults to asynchronous
+ is this is not set.
+- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous
+ is this is not set.
+- gpmc,wait-pinWait-pin used by client. Must be less than
+ "gpmc,num-waitpins".
+- gpmc,wait-on-readEnables wait monitoring on reads.
+- gpmc,wait-on-write Enables wait monitoring on writes.
Example for an AM33xx board:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index e4323ca..80808ad 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1190,6 +1190,55 @@ static struct of_device_id gpmc_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
+/**
+ * gpmc_read_settings_dt - read gpmc settings from device-tree
+ * @np:pointer to device-tree node for a gpmc child device
+ * @p: pointer to gpmc settings structure
+ *
+ * Reads the GPMC settings for a GPMC child device from device-tree and
+ * stores them in the GPMC settings structure passed. The GPMC settings
+ * structure is initialise to zero by this function and so any previously
+ * stored settings will be clearer.
+ */
+void gpmc_read_settings_dt(struct device_node *np, struct gpmc_settings *p)
+{
+ memset(p, 0, sizeof(struct gpmc_settings));
+
+ if (of_find_property(np, "gpmc,sync-read", NULL))
+ p->sync_read = true;
+ if (of_find_property(np, "gpmc,sync-write", NULL))
+ p->sync_write = true;
+
+ if (!of_property_read_u32(np, "gpmc,burst-length", &p->burst_len)) {
+ if (of_find_property(np, "gpmc,burst-wrap", NULL))
+ p->burst_wrap = true;
+ if (of_find_property(np, "gpmc,burst-read", NULL))
+ p->burst_read = true;
+ if (of_find_property(np, "gpmc,burst-write", NULL))
+ p->burst_write = true;
+ if (!p->burst_read && !p->burst_write)
+ pr_warn("%s: page/burst-length set but not used!\n",
+ __func__);
+ }
+
+ if (!of_property_read_u32(np, "gpmc,wait-pin", &p->wait_pin)) {
+ if (of_find_property(np, "gpmc,wait-on-read", NULL))
+ p->wait_on_read = true;
+ if (of_find_property(np, "gpmc,wait-on-write", NULL))
+ p->wait_on_write = true;
+ if (!p->wait_on_read && !p->wait_on_write)
+ pr_warn("%s: read/write wait monitoring not enabled!\n",
+ __func__);
+ }
+
+ of_property_read_u32(np, "gpmc,device-width", &p->device_width);
+
+ if (of_find_property(np, "gpmc,device-nand", NULL))
+ p->device_nand = true;
+
+ of_property_read_u32(np, "gpmc,mux-add-data", &p->mux_add_data);
+}
+
static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
struct gpmc_timings *gpmc_t)
{
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index 87d2a22..707f6d5 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -225,5 +225,7 @@ extern void gpmc_cs_free(int cs);
extern
[PATCH V2 04/17] ARM: OMAP2+: Add function for configuring GPMC settings
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no common function for configuring these options and
various devices set these options by either programming the GPMC CONFIG1
register directly or by calling gpmc_cs_configure() to set some of the
options.
Add a new function for configuring all of the GPMC options. Having a common
function for configuring this options will simplify code and ease the
migration to device-tree.
Also add a new capability flag to detect devices that support the
address-address-data multiplexing mode.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 100
arch/arm/mach-omap2/gpmc.h |6 +++
2 files changed, 106 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 38c7f50..1b81ca1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -107,6 +107,7 @@
#defineGPMC_HAS_WR_ACCESS 0x1
#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+#defineGPMC_HAS_MUX_AAD0x4
#define GPMC_NR_WAITPINS 4
@@ -1129,6 +1130,90 @@ int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
return 0;
}
+/**
+ * gpmc_cs_program_settings - programs non-timing related settings
+ * @cs:GPMC chip-select to program
+ * @p: pointer to GPMC settings structure
+ *
+ * Programs non-timing related settings for a GPMC chip-select, such as
+ * bus-width, burst configuration, etc. Function should be called once
+ * for each chip-select that is being used and must be called before
+ * calling gpmc_cs_set_timings() as timing parameters in the CONFIG1
+ * register will be initialised to zero by this function. Returns 0 on
+ * success and appropriate negative error code on failure.
+ */
+int gpmc_cs_program_settings(int cs, struct gpmc_settings *p)
+{
+ u32 config1;
+
+ if ((!p->device_width) || (p->device_width > GPMC_DEVWIDTH_16BIT)) {
+ pr_err("%s: invalid width %d!", __func__, p->device_width);
+ return -EINVAL;
+ }
+
+ /* Address-data multiplexing not supported for NAND devices */
+ if (p->device_nand && p->mux_add_data) {
+ pr_err("%s: invalid configuration!\n", __func__);
+ return -EINVAL;
+ }
+
+ if ((p->mux_add_data > GPMC_MUX_AD) ||
+ ((p->mux_add_data == GPMC_MUX_AAD) &&
+!(gpmc_capability & GPMC_HAS_MUX_AAD))) {
+ pr_err("%s: invalid multiplex configuration!\n", __func__);
+ return -EINVAL;
+ }
+
+ /* Page/burst mode supports lengths of 4, 8 and 16 bytes */
+ if (p->burst_read || p->burst_write) {
+ switch (p->burst_len) {
+ case GPMC_BURST_4:
+ case GPMC_BURST_8:
+ case GPMC_BURST_16:
+ break;
+ default:
+ pr_err("%s: invalid page/burst-length (%d)\n",
+ __func__, p->burst_len);
+ return -EINVAL;
+ }
+ }
+
+ if ((p->wait_on_read || p->wait_on_write) &&
+ (p->wait_pin > gpmc_nr_waitpins)) {
+ pr_err("%s: invalid wait-pin (%d)\n", __func__, p->wait_pin);
+ return -EINVAL;
+ }
+
+ config1 = GPMC_CONFIG1_DEVICESIZE((p->device_width - 1));
+
+ if (p->sync_read)
+ config1 |= GPMC_CONFIG1_READTYPE_SYNC;
+ if (p->sync_write)
+ config1 |= GPMC_CONFIG1_WRITETYPE_SYNC;
+ if (p->wait_on_read)
+ config1 |= GPMC_CONFIG1_WAIT_READ_MON;
+ if (p->wait_on_write)
+ config1 |= GPMC_CONFIG1_WAIT_WRITE_MON;
+ if (p->wait_on_read || p->wait_on_write)
+ config1 |= GPMC_CONFIG1_WAIT_PIN_SEL(p->wait_pin);
+ if (p->device_nand)
+ config1 |= GPMC_CONFIG1_DEVICETYPE(GPMC_DEVICETYPE_NAND);
+ if (p->mux_add_data)
+ config1 |= GPMC_CONFIG1_MUXTYPE(p->mux_add_data);
+ if (p->burst_read)
+ config1 |= GPMC_CONFIG1_READMULTIPLE_SUPP;
+ if (p->burst_write)
+ config1 |= GPMC_CONFIG1_WRITEMULTIPLE_SUPP;
+ if (p->burst_read || p->burst_write) {
+ config1 |= GPMC_CONFIG1_PAGE_LEN(p->burst_len >> 3);
+ config1 |= p->burst_wrap ? GPMC_CONFIG1_WRAPBURST_SUPP : 0;
+ }
+
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, config1);
+
+ return 0;
+}
+
#ifdef CONFIG_OF
static struct of_device_id gpmc_dt_ids[] = {
{ .compatible = "ti,omap2420-gpmc" },
@@ -1375,8 +1460,23 @@ static int gpmc_probe(struct platform_device *pdev)
gpmc_dev = &pdev->dev;
l = gpmc_read_reg(GPMC_REVISION);
+
+ /*
+* FIXME: Once device-tree migration is complete the below flags
+* should be populated b
[PATCH V2 06/17] ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()
Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
This moves the configuration of some GPMC options outside the
nand_gpmc_retime() because these options should only need to be set once
regardless of whether the gpmc timing is changing dynamically at runtime.
The programming of where the wait-pin is also moved slightly, but this
will not have any impact to existing devices as no boards are currently
setting the dev_ready variable.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-nand.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e50e438..1c57755 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -74,14 +74,6 @@ static int omap2_nand_gpmc_retime(
t.cs_wr_off = gpmc_t->cs_wr_off;
t.wr_cycle = gpmc_t->wr_cycle;
- /* Configure GPMC */
- if (gpmc_nand_data->devsize == NAND_BUSWIDTH_16)
- gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_DEV_SIZE, 1);
- else
- gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_DEV_SIZE, 0);
- gpmc_cs_configure(gpmc_nand_data->cs,
- GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND);
- gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_WP, 0);
err = gpmc_cs_set_timings(gpmc_nand_data->cs, &t);
if (err)
return err;
@@ -115,6 +107,7 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
struct gpmc_timings *gpmc_t)
{
int err = 0;
+ struct gpmc_settings s;
struct device *dev = &gpmc_nand_device.dev;
gpmc_nand_device.dev.platform_data = gpmc_nand_data;
@@ -141,11 +134,27 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
dev_err(dev, "Unable to set gpmc timings: %d\n", err);
return err;
}
- }
- /* Enable RD PIN Monitoring Reg */
- if (gpmc_nand_data->dev_ready) {
- gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_RDY_BSY, 1);
+ s.device_nand = true;
+
+ /* Enable RD PIN Monitoring Reg */
+ if (gpmc_nand_data->dev_ready) {
+ s.wait_on_read = true;
+ s.wait_on_write = true;
+ }
+
+ if (gpmc_nand_data->devsize == NAND_BUSWIDTH_16)
+ s.device_width = GPMC_DEVWIDTH_16BIT;
+ else
+ s.device_width = GPMC_DEVWIDTH_8BIT;
+
+ err = gpmc_cs_program_settings(gpmc_nand_data->cs, &s);
+ if (IS_ERR_VALUE(err))
+ goto out_free_cs;
+
+ err = gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_WP, 0);
+ if (IS_ERR_VALUE(err))
+ goto out_free_cs;
}
gpmc_update_nand_reg(&gpmc_nand_data->reg, gpmc_nand_data->cs);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 07/17] ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings()
Convert the OMAP2+ SMC91x code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Move configuration of the GPMC settings outside retime function and
this does not need to be done if the timings are changed dynamically
at runtime.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-smc91x.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index 4b78338..b9bd7cb 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -49,6 +49,10 @@ static struct platform_device gpmc_smc91x_device = {
.resource = gpmc_smc91x_resources,
};
+static struct gpmc_settings smc91x_settings = {
+ .device_width = GPMC_DEVWIDTH_16BIT,
+};
+
/*
* Set the gpmc timings for smc91c96. The timings are taken
* from the data sheet available at:
@@ -67,18 +71,6 @@ static int smc91c96_gpmc_retime(void)
const int t7 = 5; /* Figure 12.4 write */
const int t8 = 5; /* Figure 12.4 write */
const int t20 = 185;/* Figure 12.2 read and 12.4 write */
- u32 l;
-
- l = GPMC_CONFIG1_DEVICESIZE_16;
- if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
- l |= GPMC_CONFIG1_MUXADDDATA;
- if (gpmc_cfg->flags & GPMC_READ_MON)
- l |= GPMC_CONFIG1_WAIT_READ_MON;
- if (gpmc_cfg->flags & GPMC_WRITE_MON)
- l |= GPMC_CONFIG1_WAIT_WRITE_MON;
- if (gpmc_cfg->wait_pin)
- l |= GPMC_CONFIG1_WAIT_PIN_SEL(gpmc_cfg->wait_pin);
- gpmc_cs_write_reg(gpmc_cfg->cs, GPMC_CS_CONFIG1, l);
/*
* FIXME: Calculate the address and data bus muxed timings.
@@ -104,7 +96,7 @@ static int smc91c96_gpmc_retime(void)
dev_t.t_cez_w = t4_w * 1000;
dev_t.t_wr_cycle = (t20 - t3) * 1000;
- gpmc_calc_timings(&t, NULL, &dev_t);
+ gpmc_calc_timings(&t, &smc91x_settings, &dev_t);
return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
}
@@ -133,6 +125,18 @@ void __init gpmc_smc91x_init(struct
omap_smc91x_platform_data *board_data)
gpmc_smc91x_resources[0].end = cs_mem_base + 0x30f;
gpmc_smc91x_resources[1].flags |= (gpmc_cfg->flags & IRQF_TRIGGER_MASK);
+ if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
+ smc91x_settings.mux_add_data = GPMC_MUX_AD;
+ if (gpmc_cfg->flags & GPMC_READ_MON)
+ smc91x_settings.wait_on_read = true;
+ if (gpmc_cfg->flags & GPMC_WRITE_MON)
+ smc91x_settings.wait_on_write = true;
+ if (gpmc_cfg->wait_pin)
+ smc91x_settings.wait_pin = gpmc_cfg->wait_pin;
+ ret = gpmc_cs_program_settings(gpmc_cfg->cs, &smc91x_settings);
+ if (IS_ERR_VALUE(ret))
+ goto free1;
+
if (gpmc_cfg->retime) {
ret = gpmc_cfg->retime();
if (ret != 0)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 08/17] ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings()
Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/usb-tusb6010.c | 43
1 file changed, 19 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index faaf96d..1902b0b 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -27,12 +28,21 @@ static u8 async_cs, sync_cs;
static unsignedrefclk_psec;
static struct gpmc_settings tusb_async = {
+ .wait_on_read = true,
+ .wait_on_write = true,
+ .device_width = GPMC_DEVWIDTH_16BIT,
.mux_add_data = GPMC_MUX_AD,
};
static struct gpmc_settings tusb_sync = {
+ .burst_read = true,
+ .burst_write= true,
.sync_read = true,
.sync_write = true,
+ .wait_on_read = true,
+ .wait_on_write = true,
+ .burst_len = GPMC_BURST_16,
+ .device_width = GPMC_DEVWIDTH_16BIT,
.mux_add_data = GPMC_MUX_AD,
};
@@ -168,18 +178,12 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data
*data,
return status;
}
tusb_resources[0].end = tusb_resources[0].start + 0x9ff;
+ tusb_async.wait_pin = waitpin;
async_cs = async;
- gpmc_cs_write_reg(async, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_PAGE_LEN(2)
- | GPMC_CONFIG1_WAIT_READ_MON
- | GPMC_CONFIG1_WAIT_WRITE_MON
- | GPMC_CONFIG1_WAIT_PIN_SEL(waitpin)
- | GPMC_CONFIG1_READTYPE_ASYNC
- | GPMC_CONFIG1_WRITETYPE_ASYNC
- | GPMC_CONFIG1_DEVICESIZE_16
- | GPMC_CONFIG1_DEVICETYPE_NOR
- | GPMC_CONFIG1_MUXADDDATA);
+ status = gpmc_cs_program_settings(async_cs, &tusb_async);
+ if (IS_ERR_VALUE(status))
+ return status;
/* SYNC region, primarily for DMA */
status = gpmc_cs_request(sync, SZ_16M, (unsigned long *)
@@ -189,21 +193,12 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data
*data,
return status;
}
tusb_resources[1].end = tusb_resources[1].start + 0x9ff;
+ tusb_sync.wait_pin = waitpin;
sync_cs = sync;
- gpmc_cs_write_reg(sync, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_READMULTIPLE_SUPP
- | GPMC_CONFIG1_READTYPE_SYNC
- | GPMC_CONFIG1_WRITEMULTIPLE_SUPP
- | GPMC_CONFIG1_WRITETYPE_SYNC
- | GPMC_CONFIG1_PAGE_LEN(2)
- | GPMC_CONFIG1_WAIT_READ_MON
- | GPMC_CONFIG1_WAIT_WRITE_MON
- | GPMC_CONFIG1_WAIT_PIN_SEL(waitpin)
- | GPMC_CONFIG1_DEVICESIZE_16
- | GPMC_CONFIG1_DEVICETYPE_NOR
- | GPMC_CONFIG1_MUXADDDATA
- /* fclk divider gets set later */
- );
+
+ status = gpmc_cs_program_settings(sync_cs, &tusb_sync);
+ if (IS_ERR_VALUE(status))
+ return status;
/* IRQ */
status = gpio_request_one(irq, GPIOF_IN, "TUSB6010 irq");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 05/17] ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings()
Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-onenand.c | 61 +++-
1 file changed, 25 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 261eed1..aa3f53e 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -48,18 +48,22 @@ static struct platform_device gpmc_onenand_device = {
};
static struct gpmc_settings onenand_async = {
+ .device_width = GPMC_DEVWIDTH_16BIT,
.mux_add_data = GPMC_MUX_AD,
};
static struct gpmc_settings onenand_sync = {
.burst_read = true,
+ .burst_wrap = true,
+ .burst_len = GPMC_BURST_16,
+ .device_width = GPMC_DEVWIDTH_16BIT,
.mux_add_data = GPMC_MUX_AD,
+ .wait_pin = 0,
};
static void omap2_onenand_calc_async_timings(struct gpmc_timings *t)
{
struct gpmc_device_timings dev_t;
-
const int t_cer = 15;
const int t_avdp = 12;
const int t_aavdh = 7;
@@ -86,16 +90,6 @@ static void omap2_onenand_calc_async_timings(struct
gpmc_timings *t)
gpmc_calc_timings(t, &onenand_async, &dev_t);
}
-static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
-{
- /* Configure GPMC for asynchronous read */
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_DEVICESIZE_16 |
- GPMC_CONFIG1_MUXADDDATA);
-
- return gpmc_cs_set_timings(cs, t);
-}
-
static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
{
u32 reg;
@@ -243,8 +237,11 @@ static void omap2_onenand_calc_sync_timings(struct
gpmc_timings *t,
/* Set synchronous read timings */
memset(&dev_t, 0, sizeof(dev_t));
+ if (onenand_flags & ONENAND_FLAG_SYNCREAD)
+ onenand_sync.sync_read = true;
if (onenand_flags & ONENAND_FLAG_SYNCWRITE) {
onenand_sync.sync_write = true;
+ onenand_sync.burst_write = true;
} else {
dev_t.t_avdp_w = max(t_avdp, t_cer) * 1000;
dev_t.t_wpl = t_wpl * 1000;
@@ -270,29 +267,6 @@ static void omap2_onenand_calc_sync_timings(struct
gpmc_timings *t,
gpmc_calc_timings(t, &onenand_sync, &dev_t);
}
-static int gpmc_set_sync_mode(int cs, struct gpmc_timings *t)
-{
- unsigned sync_read = onenand_flags & ONENAND_FLAG_SYNCREAD;
- unsigned sync_write = onenand_flags & ONENAND_FLAG_SYNCWRITE;
-
- /* Configure GPMC for synchronous read */
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_WRAPBURST_SUPP |
- GPMC_CONFIG1_READMULTIPLE_SUPP |
- (sync_read ? GPMC_CONFIG1_READTYPE_SYNC : 0) |
- (sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
- (sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
- GPMC_CONFIG1_PAGE_LEN(2) |
- (cpu_is_omap34xx() ? 0 :
- (GPMC_CONFIG1_WAIT_READ_MON |
-GPMC_CONFIG1_WAIT_PIN_SEL(0))) |
- GPMC_CONFIG1_DEVICESIZE_16 |
- GPMC_CONFIG1_DEVICETYPE_NOR |
- GPMC_CONFIG1_MUXADDDATA);
-
- return gpmc_cs_set_timings(cs, t);
-}
-
static int omap2_onenand_setup_async(void __iomem *onenand_base)
{
struct gpmc_timings t;
@@ -302,7 +276,11 @@ static int omap2_onenand_setup_async(void __iomem
*onenand_base)
omap2_onenand_calc_async_timings(&t);
- ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
+ ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_async);
+ if (IS_ERR_VALUE(ret))
+ return ret;
+
+ ret = gpmc_cs_set_timings(gpmc_onenand_data->cs, &t);
if (IS_ERR_VALUE(ret))
return ret;
@@ -322,9 +300,20 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
set_onenand_cfg(onenand_base);
}
+ /*
+* FIXME: Appears to be legacy code from initial ONENAND commit.
+* Unclear what boards this is for and if this can be removed.
+*/
+ if (!cpu_is_omap34xx())
+ onenand_sync.wait_on_read = true;
+
omap2_onenand_calc_sync_timings(&t, gpmc_onenand_data->flags, freq);
- ret = gpmc_set_sync_mode(gpmc_onenand_data->cs, &t);
+ ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_sync);
+ if (IS_ERR_VALUE(ret))
+ return ret;
+
+ ret = gpmc_cs_set_timings(gpmc_onenand_data->cs, &t);
if (IS_ERR_VALUE(ret))
return ret;
--
1.7.10.4
--
To unsubscribe from this l
[PATCH V2 03/17] ARM: OMAP2+: Add structure for storing GPMC settings
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no central structure for storing all these options
when configuring the GPMC for a given device. Some of the options are
stored in the GPMC timing structure and some are directly programmed
into the GPMC configuration register. Add a new structure to store
these options and convert code to use this structure. Adding this
structure will allow us to create a common function for configuring
these options.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-onenand.c | 18 ++-
arch/arm/mach-omap2/gpmc-smc91x.c |2 +-
arch/arm/mach-omap2/gpmc.c | 45 +---
arch/arm/mach-omap2/gpmc.h | 28 --
arch/arm/mach-omap2/usb-tusb6010.c | 19 ---
5 files changed, 72 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 9f4c937..261eed1 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -47,6 +47,15 @@ static struct platform_device gpmc_onenand_device = {
.resource = &gpmc_onenand_resource,
};
+static struct gpmc_settings onenand_async = {
+ .mux_add_data = GPMC_MUX_AD,
+};
+
+static struct gpmc_settings onenand_sync = {
+ .burst_read = true,
+ .mux_add_data = GPMC_MUX_AD,
+};
+
static void omap2_onenand_calc_async_timings(struct gpmc_timings *t)
{
struct gpmc_device_timings dev_t;
@@ -63,7 +72,6 @@ static void omap2_onenand_calc_async_timings(struct
gpmc_timings *t)
memset(&dev_t, 0, sizeof(dev_t));
- dev_t.mux = true;
dev_t.t_avdp_r = max_t(int, t_avdp, t_cer) * 1000;
dev_t.t_avdp_w = dev_t.t_avdp_r;
dev_t.t_aavdh = t_aavdh * 1000;
@@ -75,7 +83,7 @@ static void omap2_onenand_calc_async_timings(struct
gpmc_timings *t)
dev_t.t_wpl = t_wpl * 1000;
dev_t.t_wph = t_wph * 1000;
- gpmc_calc_timings(t, &dev_t);
+ gpmc_calc_timings(t, &onenand_async, &dev_t);
}
static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
@@ -235,10 +243,8 @@ static void omap2_onenand_calc_sync_timings(struct
gpmc_timings *t,
/* Set synchronous read timings */
memset(&dev_t, 0, sizeof(dev_t));
- dev_t.mux = true;
- dev_t.sync_read = true;
if (onenand_flags & ONENAND_FLAG_SYNCWRITE) {
- dev_t.sync_write = true;
+ onenand_sync.sync_write = true;
} else {
dev_t.t_avdp_w = max(t_avdp, t_cer) * 1000;
dev_t.t_wpl = t_wpl * 1000;
@@ -261,7 +267,7 @@ static void omap2_onenand_calc_sync_timings(struct
gpmc_timings *t,
dev_t.cyc_aavdh_oe = 1;
dev_t.t_rdyo = t_rdyo * 1000 + min_gpmc_clk_period;
- gpmc_calc_timings(t, &dev_t);
+ gpmc_calc_timings(t, &onenand_sync, &dev_t);
}
static int gpmc_set_sync_mode(int cs, struct gpmc_timings *t)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index 11d0b75..4b78338 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -104,7 +104,7 @@ static int smc91c96_gpmc_retime(void)
dev_t.t_cez_w = t4_w * 1000;
dev_t.t_wr_cycle = (t20 - t3) * 1000;
- gpmc_calc_timings(&t, &dev_t);
+ gpmc_calc_timings(&t, NULL, &dev_t);
return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
}
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 452617b..38c7f50 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -817,9 +817,9 @@ static u32 gpmc_round_ps_to_sync_clk(u32 time_ps, u32
sync_clk)
/* XXX: can the cycles be avoided ? */
static int gpmc_calc_sync_read_timings(struct gpmc_timings *gpmc_t,
- struct gpmc_device_timings *dev_t)
+ struct gpmc_device_timings *dev_t,
+ bool mux)
{
- bool mux = dev_t->mux;
u32 temp;
/* adv_rd_off */
@@ -872,9 +872,9 @@ static int gpmc_calc_sync_read_timings(struct gpmc_timings
*gpmc_t,
}
static int gpmc_calc_sync_write_timings(struct gpmc_timings *gpmc_t,
- struct gpmc_device_timings *dev_t)
+ struct gpmc_device_timings *dev_t,
+ bool mux)
{
- bool mux = dev_t->mux;
u32 temp;
/* adv_wr_off */
@@ -934,9 +934,9 @@ static int gpmc_calc_sync_write_timings(struct gpmc_timings
*gpmc_t,
}
static int gpmc_calc_async_read_timings(struct gpmc_timings *gpmc_t,
- struct gpmc_device_timings *dev_t)
+ struct gpmc_device_timings *dev_t,
+ bool mux)
{
- bool
[PATCH V2 00/17] ARM: OMAP2+: GPMC clean-up and DT update
While adding device-tree support for NOR memories, it became apparent that there is no common way for configuring various GPMC settings for devices that interface to the GPMC. These settings include bus-width, synchronous/asynchronous mode, burst settings, wait monitoring etc. Therefore, to simplify the GPMC code and add device-tree support for NOR, it was first necessary to consolidate how these settings are programmed. Series based upon Mark Jackson's patch [1] and Ezequiel Garcia GPMC clean-up series [2]. Entire series available here [3]. V2 changes: - Made gpmc_settings structure local in gpmc_nand_init(). - Use resource_size() API in probe_nor(). - Add kernel-doc for gpmc_cs_program_settings() function. - Use of_platform_device_create() to register NOR devices in probe_nor(). - Add support for GPMC address-address-data multiplexing which required changing GPMC DT property "gpmc,mux-add-data" to store a 32-bit value and changing mux_add_data member of gpmc_settings to be a 32-bit type instead of bool. - Add detection for incorrect GPMC chip-select base addresses. - Cleaned-up code in gpmc_mem_init() and changed gpmc_mem_init() so that it would not return an error when the GPMC driver is being probed. V1 changes: - Clean-up/simplification of ONENAND initialisation code. - Add a new GPMC structure to unify storage of various GPMC settings (that are non-timing related) for client devices and add a new function to program these settings in a common way. - Migrate initialisation code for existing flash, usb and networking devices to use the new structure and function for GPMC settings. - Add device-tree support for NOR flash memories. - Add additional GPMC timing parameters to GPMC device-tree binding. - Update GPMC NAND and ONENAND device-tree support to retrieve GPMC settings from device-tree. Testing includes: - Boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 SDP with and without device-tree present. - OMAP2420 H4 board has NOR flash and OMAP3430 SDP has NOR, NAND and ONENAND flash. So verified that flash is detected on boot as expected. Note additional patches [4] are required for OMAP2420 H4 and OMAP3430 SDP dts files in order to enable flash memory support. - All of the above boards use GPMC for interfacing to a networking chip and so verified that networking is working wit this series. However, please note that networking is not currently supported on these boards when booting with DT and so networking is only tested without DT. [1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/94765 [2] http://comments.gmane.org/gmane.linux.ports.arm.omap/93784 [3] https://github.com/jonhunter/linux/tree/omap-gpmc-for-v3.10 [4] https://github.com/jonhunter/linux/tree/omap-dt-for-v3.10 Jon Hunter (17): ARM: OMAP2+: Simplify code configuring ONENAND devices ARM: OMAP2+: Add variable to store number of GPMC waitpins ARM: OMAP2+: Add structure for storing GPMC settings ARM: OMAP2+: Add function for configuring GPMC settings ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings() ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings() ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure() ARM: OMAP2+: Add function to read GPMC settings from device-tree ARM: OMAP2+: Add device-tree support for NOR flash ARM: OMAP2+: Add additional GPMC timing parameters ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT ARM: OMAP2+: Detect incorrectly aligned GPMC base address ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails Documentation/devicetree/bindings/bus/ti-gpmc.txt | 48 +- Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 .../devicetree/bindings/mtd/gpmc-onenand.txt |3 + arch/arm/mach-omap2/gpmc-nand.c| 37 +- arch/arm/mach-omap2/gpmc-onenand.c | 110 ++--- arch/arm/mach-omap2/gpmc-smc91x.c | 30 +- arch/arm/mach-omap2/gpmc.c | 521 +++- arch/arm/mach-omap2/gpmc.h | 37 +- arch/arm/mach-omap2/usb-tusb6010.c | 62 ++- 9 files changed, 686 insertions(+), 260 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nor.txt -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 01/17] ARM: OMAP2+: Simplify code configuring ONENAND devices
The OMAP2+ code that configures the GPMC for ONENAND devices is copying
structures between functions unnecessarily. Avoid this by passing
pointers instead and simplify the code.
A pointer to structure "omap_onenand_platform_data" is passed to the
function omap2_onenand_calc_sync_timings(), but only the flags member
of the structure is used. Simplify the code by only passing the flags
member and not the entire structure.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-onenand.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index fd6e35b..9f4c937 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -47,10 +47,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = &gpmc_onenand_resource,
};
-static struct gpmc_timings omap2_onenand_calc_async_timings(void)
+static void omap2_onenand_calc_async_timings(struct gpmc_timings *t)
{
struct gpmc_device_timings dev_t;
- struct gpmc_timings t;
const int t_cer = 15;
const int t_avdp = 12;
@@ -76,9 +75,7 @@ static struct gpmc_timings
omap2_onenand_calc_async_timings(void)
dev_t.t_wpl = t_wpl * 1000;
dev_t.t_wph = t_wph * 1000;
- gpmc_calc_timings(&t, &dev_t);
-
- return t;
+ gpmc_calc_timings(t, &dev_t);
}
static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
@@ -158,12 +155,11 @@ static int omap2_onenand_get_freq(struct
omap_onenand_platform_data *cfg,
return freq;
}
-static struct gpmc_timings
-omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
- int freq)
+static void omap2_onenand_calc_sync_timings(struct gpmc_timings *t,
+ unsigned int flags,
+ int freq)
{
struct gpmc_device_timings dev_t;
- struct gpmc_timings t;
const int t_cer = 15;
const int t_avdp = 12;
const int t_cez = 20; /* max of t_cez, t_oez */
@@ -172,9 +168,9 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
int div, gpmc_clk_ns;
- if (cfg->flags & ONENAND_SYNC_READ)
+ if (flags & ONENAND_SYNC_READ)
onenand_flags = ONENAND_FLAG_SYNCREAD;
- else if (cfg->flags & ONENAND_SYNC_READWRITE)
+ else if (flags & ONENAND_SYNC_READWRITE)
onenand_flags = ONENAND_FLAG_SYNCREAD | ONENAND_FLAG_SYNCWRITE;
switch (freq) {
@@ -265,9 +261,7 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
dev_t.cyc_aavdh_oe = 1;
dev_t.t_rdyo = t_rdyo * 1000 + min_gpmc_clk_period;
- gpmc_calc_timings(&t, &dev_t);
-
- return t;
+ gpmc_calc_timings(t, &dev_t);
}
static int gpmc_set_sync_mode(int cs, struct gpmc_timings *t)
@@ -300,7 +294,7 @@ static int omap2_onenand_setup_async(void __iomem
*onenand_base)
omap2_onenand_set_async_mode(onenand_base);
- t = omap2_onenand_calc_async_timings();
+ omap2_onenand_calc_async_timings(&t);
ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
if (IS_ERR_VALUE(ret))
@@ -322,7 +316,7 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
set_onenand_cfg(onenand_base);
}
- t = omap2_onenand_calc_sync_timings(gpmc_onenand_data, freq);
+ omap2_onenand_calc_sync_timings(&t, gpmc_onenand_data->flags, freq);
ret = gpmc_set_sync_mode(gpmc_onenand_data->cs, &t);
if (IS_ERR_VALUE(ret))
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 02/17] ARM: OMAP2+: Add variable to store number of GPMC waitpins
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect if the wait-pin being selected is valid or not.
When booting with device-tree read the number of wait-pins from the
device-tree blob. When device-tree is not used set the number of
wait-pins to 4 which is valid for OMAP2-5 devices. Newer devices
that have less wait-pins (such as AM335x) only support booting with
device-tree and so hard-coding the wait-pin number when not using
device-tree is fine.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 6ddecc8..452617b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -108,6 +108,8 @@
#defineGPMC_HAS_WR_ACCESS 0x1
#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+#define GPMC_NR_WAITPINS 4
+
/* XXX: Only NAND irq has been considered,currently these are the only ones
used
*/
#defineGPMC_NR_IRQ 2
@@ -153,6 +155,7 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
/* Define chip-selects as reserved by default until probe completes */
static unsigned int gpmc_cs_map = ((1 << GPMC_CS_NUM) - 1);
+static unsigned int gpmc_nr_waitpins;
static struct device *gpmc_dev;
static int gpmc_irq;
static resource_size_t phys_base, mem_size;
@@ -1297,6 +1300,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
if (!of_id)
return 0;
+ ret = of_property_read_u32(pdev->dev.of_node, "gpmc,num-waitpins",
+ &gpmc_nr_waitpins);
+ if (ret) {
+ pr_err("%s: number of wait pins not found!\n", __func__);
+ return ret;
+ }
+
for_each_node_by_name(child, "nand") {
ret = gpmc_probe_nand_child(pdev, child);
if (ret < 0) {
@@ -1372,6 +1382,12 @@ static int gpmc_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
+ /* Now the GPMC is initialised, unreserve the chip-selects */
+ gpmc_cs_map = 0;
+
+ if (!pdev->dev.of_node)
+ gpmc_nr_waitpins = GPMC_NR_WAITPINS;
+
rc = gpmc_probe_dt(pdev);
if (rc < 0) {
clk_disable_unprepare(gpmc_l3_clk);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] usb: musb: am335x support
On 07.03.2013 13:51, Daniel Mack wrote:
> On 04.03.2013 00:53, Daniel Mack wrote:
>> Hi Peter,
>>
>> On 03.03.2013 23:24, Peter Korsgaard wrote:
"Daniel" == Daniel Mack writes:
>>>
>>> Hi,
>>>
>>> Daniel> On my board, the USB is purely used as host interface, with a
>>> Daniel> type B plug soldered. In the DT, I'm using the following
>>> Daniel> sniplet in accordance to the documentation of the bindings:
>>>
>>> Daniel>usb_otg_hs: usb@4740 {
>>> Daniel>compatible = "ti,musb-am33xx";
>>> Daniel>reg = <0x4740 0x1000/* usbss */
>>> Daniel> 0x47401000 0x800 /* musb instance 0 */
>>> Daniel> 0x47401800 0x800>; /* musb instance 1 */
>>> Daniel>interrupt-parent = <&intc>;
>>> Daniel>interrupts = <17/* usbss */
>>> Daniel> 18/* musb instance 0 */
>>> 19> ; /* musb instance 1 */
>>> Daniel>multipoint = <1>;
>>> Daniel>num-eps = <16>;
>>> Daniel>ram-bits = <12>;
>>> Daniel>port0-mode = <3>;
>>> Daniel>port1-mode = <3>;
>>> Daniel>power = <250>;
>>> Daniel>ti,hwmods = "usb_otg_hs";
>>> Daniel>};
>>>
>>> Daniel> The relevant config options are
>>>
>>> Daniel> CONFIG_USB_MUSB_HDRC=y
>>> Daniel> # CONFIG_USB_MUSB_TUSB6010 is not set
>>> Daniel> # CONFIG_USB_MUSB_OMAP2PLUS is not set
>>> Daniel> # CONFIG_USB_MUSB_AM35X is not set
>>> Daniel> CONFIG_USB_MUSB_DSPS=y
>>> Daniel> CONFIG_MUSB_PIO_ONLY=y
>>> Daniel> CONFIG_USB_GADGET=y
>>> Daniel> CONFIG_USB_GADGET_DEBUG=y
>>> Daniel> CONFIG_USB_GADGET_DEBUG_FILES=y
>>> Daniel> CONFIG_USB_GADGET_DEBUG_FS=y
>>> Daniel> CONFIG_USB_GADGET_VBUS_DRAW=2
>>> Daniel> CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
>>> Daniel> CONFIG_USB_GADGET_MUSB_HDRC=y
>>>
>>> Ehh, I'm confused here. You talk about host mode, a single 'B' (gadget)
>>> connector
>>
>> I'm sorry for the confusion caused. This is a stupid mistake - I'm in
>> fact talking about an 'A' type plug of course (host mode).
>>
>>> and your device tree mentions 2 OTG ports.
>>
>> That's what I said in a follow up - the same happens for mode '1'.
>>
>>> What is the configuration exactly?
>>
>> Again to summarize: host-only mode, type 'A' plug.
>>
>> The gadget driver is is enabled in the config because the only
>> occurrence of usb_add_hcd() in the musb driver is in the gagdget part,
>> so supposedly, there has to be a gadget driver loaded in order to make
>> the host interface going.
>
> Just be clear: I'd happily help and dig for the reason of this, I'd just
> need to know how things are _supposed_ to work ...
So I dug a little on this topic, and restored the behaviour I need with
the attached patch.
The funny part is that the value set in the port0-mode/port1-mode DT
properties are not even looked at by the code.
I know this patch reintroduces bits that have been intentionally removed
before, in particular by 032ec49f53 ("usb: musb: drop useless board_mode
usage"), but I don't know how this usb driver is supposed to work in
host mode without taking the configured port mode into account. If
anyone can explain to me which information I'm missing here, I can
happily test a patch. For now, this works for me.
Thanks,
Daniel
>From a98a5d15332dc261bb3f366ccc2ef6e2cb924730 Mon Sep 17 00:00:00 2001
From: Daniel Mack
Date: Fri, 8 Mar 2013 17:31:10 +0100
Subject: [PATCH] drivers: usb: musb: re-enable host-only mode
Currently, the port%d-mode properties in DT are completely unused, and
support code for enabling host-only mode configurations is missing,
partly due to the recent rework in the musb core driver.
Fix this with the following changes:
- store the port mode information in struct musb
- in case of host-only mode setups, add the HCD directly from
musb_init_controller()
- refuse to start a gadget on a host-only configured port
Store the port mode in struct musb and handle
Signed-off-by: Daniel Mack
---
drivers/usb/musb/musb_core.c | 47 ++
drivers/usb/musb/musb_core.h | 5 +
drivers/usb/musb/musb_gadget.c | 5 +
3 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 60b41cc..726c4ec 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -937,15 +937,19 @@ void musb_start(struct musb *musb)
devctl = musb_readb(regs, MUSB_DEVCTL);
devctl &= ~MUSB_DEVCTL_SESSION;
- /* session started after:
- * (a) ID-grounded irq, host mode;
- * (b) vbus present/connect IRQ, peripheral mode;
- * (c) peripheral initiates, using SRP
- */
- if ((devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS)
- musb->is_active = 1;
- else
+ if (musb->port_mode == MUSB_PORT_MODE_HOST) {
devctl |= MUSB_DEVCTL_SESSION;
+ } else {
+ /* session started after:
+ * (a) ID-grounded
Re: [PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
* Aaro Koskinen [130308 08:16]:
> On Fri, Mar 08, 2013 at 11:29:56AM +0100, Paul Bolle wrote:
> > When support was added for Nokia N9 (RM-696), with commit
> > 63fc5f3bb3d0ca9ab4767a801b518aa6335f87ad ("ARM: OMAP: add minimal
> > support for Nokia RM-696"), a select statement for MACH_NOKIA_RM696 was
> > added to the tree. But there's no Kconfig symbol with that name. That
> > symbol would be superfluous, since support for that machine piggybacks
> > on MACH_NOKIA_RM680. So drop that select.
>
> This is needed because of arch/arm/tools/mach-types. See
> include/generated/mach-types.h.
>
> If you have just CONFIG_MACH_NOKIA_RM680 and run the kernel on RM-696,
> then machine_is_nokia_rm696() will return false. If I rememeber correctly,
> this broke at least early printk / uncompressor output at the time.
>
> I guess people may still want to use machine_is_... macros e.g. for
> debugging.
I think the righ fix is to just add
config MACH_NOKIA_RM680
bool
to the mach-omap2/Kconfig like we have for n8x0 also.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
On Fri, Mar 08, 2013 at 11:29:56AM +0100, Paul Bolle wrote:
> When support was added for Nokia N9 (RM-696), with commit
> 63fc5f3bb3d0ca9ab4767a801b518aa6335f87ad ("ARM: OMAP: add minimal
> support for Nokia RM-696"), a select statement for MACH_NOKIA_RM696 was
> added to the tree. But there's no Kconfig symbol with that name. That
> symbol would be superfluous, since support for that machine piggybacks
> on MACH_NOKIA_RM680. So drop that select.
This is needed because of arch/arm/tools/mach-types. See
include/generated/mach-types.h.
If you have just CONFIG_MACH_NOKIA_RM680 and run the kernel on RM-696,
then machine_is_nokia_rm696() will return false. If I rememeber correctly,
this broke at least early printk / uncompressor output at the time.
I guess people may still want to use machine_is_... macros e.g. for
debugging.
> Signed-off-by: Paul Bolle
> ---
> 0) Tested with "git grep".
git grep won't search generated source files.
> 1) Some searching on the web didn't return a "config MACH_NOKIA_RM696".
> So apparently there's not even a development tree that uses this symbol.
You can see machine_is_nokia_rm696() used in the public kernel source
for Nokia N9 product. :-)
A.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: phy: nop: Add device tree support and binding information
On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
> On 02/04/2013 04:58 PM, Roger Quadros wrote:
>> The PHY clock, clock rate, VCC regulator and RESET regulator
>> can now be provided via device tree.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
>>
>> drivers/usb/otg/nop-usb-xceiv.c| 31 ++
>> 2 files changed, 65 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> new file mode 100644
>> index 000..d7e2726
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -0,0 +1,34 @@
>> +USB NOP PHY
>> +
>> +Required properties:
>> +- compatible: should be usb-nop-xceiv
>> +
>> +Optional properties:
>> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
>> + /bindings/clock/clock-bindings.txt
>> + This property is required if clock-frequency is specified.
>> +
>> +- clock-names: Should be "main_clk"
>> +
>> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
>> + be configured to.
>> +
>> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
>> +
>> +- reset-supply: phandle to the regulator that provides power to the PHY.
>> +
>> +Example:
>> +
>> +hsusb1_phy {
>> +compatible = "usb-nop-xceiv";
>> +clock-frequency = <1920>;
>
> Why do you hardcode the clock frequency here? You should use
> clk_get_rate() to get the frequency from the clock tree.
What about declaring a "fixed-clock" node in the device tree? Then it
should be possible to keep the driver free of any omap specific code.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting
On 3/8/2013 8:34 PM, Peter Korsgaard wrote: "Ben" == Ben Hutchings writes: Hi, Ben> The 'active slave' property would also be needed for the SIOCGMIIPHY Ben> ioctl and not just ethtool. But it's really quite arbitrary. Perhaps Ben> each of them should have their own net device (as with DSA). Indeed, I think that would simplify all of this quite a bit. I will update this in the next patch series Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting
On 3/8/2013 8:23 PM, Ben Hutchings wrote: On Fri, 2013-03-08 at 12:53 +0530, Mugunthan V N wrote: On 3/8/2013 1:29 AM, Ben Hutchings wrote: On Thu, 2013-03-07 at 14:24 +0100, Peter Korsgaard wrote: "M" == Mugunthan V N writes: M> This patch implements get/set of the phy settings via ethtool apis M> Signed-off-by: Mugunthan V N M> --- M> Documentation/devicetree/bindings/net/cpsw.txt |3 +++ M> drivers/net/ethernet/ti/cpsw.c | 32 M> include/linux/platform_data/cpsw.h |1 + M> 3 files changed, 36 insertions(+) M> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt M> index ecfdf75..8d61300 100644 M> --- a/Documentation/devicetree/bindings/net/cpsw.txt M> +++ b/Documentation/devicetree/bindings/net/cpsw.txt M> @@ -20,6 +20,7 @@ Required properties: M> - cpts_clock_shift: Denominator to convert input clock ticks into nanoseconds M> - phy_id : Specifies slave phy id M> - mac-address : Specifies slave MAC address M> +- ethtool-active-slave: Specifies the slave to use for ethtool command That again sounds like something Linux specific rather than a hardware property. Yes, indeed. Isn't it redundant with the phy_id? Ben. phy_id is part of slave data and will be present for both the slaves. so phy_id cannot be used for get/set phy setting until phy framework allows to change settings without going through eth interface. Now I've looked at the examples in this file, I think I see what you're getting at. What confused me is that you're adding to a single list of properties without a proper distinction of which devices they are applied to. It really ought to be properly divided between switch and 'slave' properties. Will fix this in next patch series. The 'active slave' property would also be needed for the SIOCGMIIPHY ioctl and not just ethtool. But it's really quite arbitrary. Perhaps each of them should have their own net device (as with DSA). But if we have net device for each of the slaves then it is dual EMAC which will kill hardware switching functionality. To achieve switching bridge has to be done and there will be a performance drop as well. As Peter Korsgaard mentioned we need to have infrastructure to handle CPSW kind of hardware. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: phy: nop: Add device tree support and binding information
On 03/08/2013 12:46 PM, Marc Kleine-Budde wrote:
> On 02/04/2013 04:58 PM, Roger Quadros wrote:
>> The PHY clock, clock rate, VCC regulator and RESET regulator
>> can now be provided via device tree.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
>>
>> drivers/usb/otg/nop-usb-xceiv.c| 31 ++
>> 2 files changed, 65 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> new file mode 100644
>> index 000..d7e2726
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -0,0 +1,34 @@
>> +USB NOP PHY
>> +
>> +Required properties:
>> +- compatible: should be usb-nop-xceiv
>> +
>> +Optional properties:
>> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
>> + /bindings/clock/clock-bindings.txt
>> + This property is required if clock-frequency is specified.
>> +
>> +- clock-names: Should be "main_clk"
>> +
>> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
>> + be configured to.
>> +
>> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
>> +
>> +- reset-supply: phandle to the regulator that provides power to the PHY.
>> +
>> +Example:
>> +
>> +hsusb1_phy {
>> +compatible = "usb-nop-xceiv";
>> +clock-frequency = <1920>;
>
> Why do you hardcode the clock frequency here? You should use
> clk_get_rate() to get the frequency from the clock tree.
That would work only if the clock was programmed to the correct frequency
by someone.
e.g. In the OMAP case nobody programs the auxiliary clock on Panda which clocks
the USB PHY.
The usb-nop-xceiv device driver must program the clock rate using
clk_set_rate(),
but it needs to know what frequency it must program it to. Different boards/PHYs
might use a different clock frequency. The 'clock-frequency' property
is used to pass on this information to the driver.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting
> "Ben" == Ben Hutchings writes: Hi, Ben> The 'active slave' property would also be needed for the SIOCGMIIPHY Ben> ioctl and not just ethtool. But it's really quite arbitrary. Perhaps Ben> each of them should have their own net device (as with DSA). Indeed, I think that would simplify all of this quite a bit. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] driver: net: ethernet: cpsw: implement ethtool get/set phy setting
On Fri, 2013-03-08 at 12:53 +0530, Mugunthan V N wrote: > On 3/8/2013 1:29 AM, Ben Hutchings wrote: > > On Thu, 2013-03-07 at 14:24 +0100, Peter Korsgaard wrote: > >>> "M" == Mugunthan V N writes: > >> M> This patch implements get/set of the phy settings via ethtool apis > >> M> Signed-off-by: Mugunthan V N > >> M> --- > >> M> Documentation/devicetree/bindings/net/cpsw.txt |3 +++ > >> M> drivers/net/ethernet/ti/cpsw.c | 32 > >> > >> M> include/linux/platform_data/cpsw.h |1 + > >> M> 3 files changed, 36 insertions(+) > >> > >> M> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt > >> b/Documentation/devicetree/bindings/net/cpsw.txt > >> M> index ecfdf75..8d61300 100644 > >> M> --- a/Documentation/devicetree/bindings/net/cpsw.txt > >> M> +++ b/Documentation/devicetree/bindings/net/cpsw.txt > >> M> @@ -20,6 +20,7 @@ Required properties: > >> M> - cpts_clock_shift : Denominator to convert input clock ticks into > >> nanoseconds > >> M> - phy_id : Specifies slave phy id > >> M> - mac-address: Specifies slave MAC address > >> M> +- ethtool-active-slave : Specifies the slave to use for > >> ethtool command > >> > >> That again sounds like something Linux specific rather than a hardware > >> property. > > Yes, indeed. Isn't it redundant with the phy_id? > > > > Ben. > phy_id is part of slave data and will be present for both the slaves. > so phy_id cannot be used for get/set phy setting until phy framework > allows to change settings without going through eth interface. Now I've looked at the examples in this file, I think I see what you're getting at. What confused me is that you're adding to a single list of properties without a proper distinction of which devices they are applied to. It really ought to be properly divided between switch and 'slave' properties. The 'active slave' property would also be needed for the SIOCGMIIPHY ioctl and not just ethtool. But it's really quite arbitrary. Perhaps each of them should have their own net device (as with DSA). Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support
> -Original Message- > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, Matt > Sent: Thursday, March 07, 2013 9:33 PM > To: Hiremath, Vaibhav > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; Devicetree > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; Linux > ARM Kernel List > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > On Thu, Mar 07, 2013 at 03:50:01PM +, Vaibhav Hiremath wrote: > > > > > -Original Message- > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of Porter, > Matt > > > Sent: Thursday, March 07, 2013 8:34 PM > > > To: Hiremath, Vaibhav > > > Cc: Chris Ball; Russell King; Krishnamoorthy, Balaji T; Devicetree > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Linux OMAP > List; > > > Linux ARM Kernel List > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > On Thu, Mar 07, 2013 at 02:59:42PM +, Vaibhav Hiremath wrote: > > > > > > > > > -Original Message- > > > > > From: Hiremath, Vaibhav > > > > > Sent: Thursday, March 07, 2013 8:24 PM > > > > > To: Porter, Matt > > > > > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; > > > Devicetree > > > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris Ball; > > > Linux > > > > > ARM Kernel List > > > > > Subject: RE: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > -Original Message- > > > > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of > Porter, > > > > > Matt > > > > > > Sent: Thursday, March 07, 2013 8:17 PM > > > > > > To: Hiremath, Vaibhav > > > > > > Cc: Linux OMAP List; Russell King; Krishnamoorthy, Balaji T; > > > > > Devicetree > > > > > > Discuss; Linux MMC List; Linux Kernel Mailing List; Chris > Ball; > > > Linux > > > > > > ARM Kernel List > > > > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > On Thu, Mar 07, 2013 at 02:39:55PM +, Vaibhav Hiremath > wrote: > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Matt Porter [mailto:ohio...@gmail.com] On Behalf Of > > > Porter, > > > > > > Matt > > > > > > > > Sent: Thursday, March 07, 2013 7:43 PM > > > > > > > > To: Hiremath, Vaibhav > > > > > > > > Cc: Krishnamoorthy, Balaji T; Chris Ball; Cousson, > Benoit; > > > Tony > > > > > > > > Lindgren; Russell King; Devicetree Discuss; Linux ARM > Kernel > > > > > List; > > > > > > > > Linux OMAP List; Linux Kernel Mailing List; Linux MMC > List > > > > > > > > Subject: Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > > > > > On Thu, Mar 07, 2013 at 05:29:24AM +, Vaibhav > Hiremath > > > wrote: > > > > > > > > > > -Original Message- > > > > > > > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux- > > > omap- > > > > > > > > > > ow...@vger.kernel.org] On Behalf Of Porter, Matt > > > > > > > > > > Sent: Thursday, March 07, 2013 9:47 AM > > > > > > > > > > To: Krishnamoorthy, Balaji T; Chris Ball; Cousson, > > > Benoit; > > > > > Tony > > > > > > > > > > Lindgren; Russell King > > > > > > > > > > Cc: Devicetree Discuss; Linux ARM Kernel List; Linux > OMAP > > > > > List; > > > > > > > > Linux > > > > > > > > > > Kernel Mailing List; Linux MMC List > > > > > > > > > > Subject: [PATCH 2/2] ARM: dts: add AM33XX MMC support > > > > > > > > > > > > > > > > > > > > > > > > I believe you meant "CONFIG_TI_EDMA" right? > > > > > > > > > > Yes, I just enabled it and the result is still same. > > > > > > > > > > > > > > > > > > > > [root@arago /]# dmesg | grep -ir mmc > > > > > [0.506844] vmmc: 1800 <--> 3300 mV at 3300 mV > > > > > [0.506970] vmmc: supplied by vbat > > > > > [root@arago /]# > > > > > [root@arago /]# > > > > > [root@arago /]# dmesg | grep -ir dma > > > > > [0.217063] DMA: preallocated 256 KiB pool for atomic > coherent > > > > > allocations > > > > > [0.236321] platform 4900.edma: alias fck already exists > > > > > [0.236360] platform 4900.edma: alias fck already exists > > > > > [0.236381] platform 4900.edma: alias fck already exists > > > > > [0.370705] edma-dma-engine edma-dma-engine.0: TI EDMA DMA > > > engine > > > > > driver > > > > > [0.445156] omap-dma-engine omap-dma-engine: OMAP DMA engine > > > driver > > > > > [root@arago /]# > > > > > [root@arago /]# > > > > > > > > > > > > > > I have applied below patches from your recent post > > > > > > > > > > > > [2/2] ARM: dts: add AM33XX MMC support > > > > [1/2] mmc: omap_hsmmc: set max_segs based on dma engine limits > > > > [v4,3/3] mmc: davinci: get SG segment limits with > > > dma_get_slave_sg_limits() > > > > [v4,2/3] dma: edma: add device_slave_sg_limits() support > > > > [v4,1/3] dmaengine: add dma_get_slave_sg_limits() > > > > [v9,9/9] ARM: dts: add AM33XX SPI DMA support > > > > [v9,8/9] spi: omap2-mcspi: add generic DMA request support to the > DT > > > binding > > > > [v9,7/9] spi: omap2-mcspi: convert to > > > dma_request_slave
[PATCH] ARM: OMAP: fix typo "CONFIG_SMC91x_MODULE"
There's a (rather subtle) typo in "CONFIG_SMC91x_MODULE". Fix it once
and for all by using IS_ENABLED(), which is designed to avoid issues
like this.
Signed-off-by: Paul Bolle
---
Untested! And this needs build- and runtime testing, especially for the
MODULE case!
arch/arm/mach-omap2/board-2430sdp.c | 2 +-
arch/arm/mach-omap2/board-h4.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index a3e0aaa..cb0596b 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -166,7 +166,7 @@ static void __init sdp2430_display_init(void)
omap_display_init(&sdp2430_dss_data);
}
-#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
+#if IS_ENABLED(CONFIG_SMC91X)
static struct omap_smc91x_platform_data board_smc91x_data = {
.cs = 5,
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 812c829..5b4ec51 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -246,7 +246,7 @@ static u32 is_gpmc_muxed(void)
return 0;
}
-#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91x_MODULE)
+#if IS_ENABLED(CONFIG_SMC91X)
static struct omap_smc91x_platform_data board_smc91x_data = {
.cs = 1,
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/14] OMAPDSS: DSI: simplify dsi configuration
We have a bunch of dsi functions that are used to do the basic
configuration for DSI. To simplify things, and to make sure we have all
the necessary information, create a single dsi config function, which
does the basic configuration.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/panel-taal.c | 16 ---
drivers/video/omap2/dss/dsi.c | 74 -
include/video/omapdss.h | 23 -
3 files changed, 31 insertions(+), 82 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index bc4c95e..eb86cba 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -919,6 +919,13 @@ static int taal_power_on(struct omap_dss_device *dssdev)
struct taal_data *td = dev_get_drvdata(&dssdev->dev);
u8 id1, id2, id3;
int r;
+ struct omap_dss_dsi_config dsi_config = {
+ .mode = OMAP_DSS_DSI_CMD_MODE,
+ .pixel_format = OMAP_DSS_DSI_FMT_RGB888,
+ .timings = &dssdev->panel.timings,
+ .hs_clk = 21600,
+ .lp_clk = 1000,
+ };
r = omapdss_dsi_configure_pins(dssdev, &td->pin_config);
if (r) {
@@ -926,14 +933,9 @@ static int taal_power_on(struct omap_dss_device *dssdev)
goto err0;
};
- omapdss_dsi_set_size(dssdev, dssdev->panel.timings.x_res,
- dssdev->panel.timings.y_res);
- omapdss_dsi_set_pixel_format(dssdev, OMAP_DSS_DSI_FMT_RGB888);
- omapdss_dsi_set_operation_mode(dssdev, OMAP_DSS_DSI_CMD_MODE);
-
- r = omapdss_dsi_set_clocks(dssdev, 21600, 1000);
+ r = omapdss_dsi_set_config(dssdev, &dsi_config);
if (r) {
- dev_err(&dssdev->dev, "failed to set HS and LP clocks\n");
+ dev_err(&dssdev->dev, "failed to configure DSI\n");
goto err0;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 5f5b475..901b721 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4278,7 +4278,7 @@ int omapdss_dsi_configure_pins(struct omap_dss_device
*dssdev,
}
EXPORT_SYMBOL(omapdss_dsi_configure_pins);
-int omapdss_dsi_set_clocks(struct omap_dss_device *dssdev,
+static int dsi_set_clocks(struct omap_dss_device *dssdev,
unsigned long ddr_clk, unsigned long lp_clk)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
@@ -4293,8 +4293,6 @@ int omapdss_dsi_set_clocks(struct omap_dss_device *dssdev,
DSSDBG("Setting DSI clocks: ddr_clk %lu, lp_clk %lu", ddr_clk, lp_clk);
- mutex_lock(&dsi->lock);
-
/* Calculate PLL output clock */
r = dsi_pll_calc_ddrfreq(dsidev, ddr_clk * 4, &cinfo);
if (r)
@@ -4336,13 +4334,10 @@ int omapdss_dsi_set_clocks(struct omap_dss_device
*dssdev,
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI :
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI;
- mutex_unlock(&dsi->lock);
return 0;
err:
- mutex_unlock(&dsi->lock);
return r;
}
-EXPORT_SYMBOL(omapdss_dsi_set_clocks);
int dsi_enable_video_output(struct omap_dss_device *dssdev, int channel)
{
@@ -4884,75 +4879,26 @@ int omapdss_dsi_enable_te(struct omap_dss_device
*dssdev, bool enable)
}
EXPORT_SYMBOL(omapdss_dsi_enable_te);
-void omapdss_dsi_set_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
+int omapdss_dsi_set_config(struct omap_dss_device *dssdev,
+ const struct omap_dss_dsi_config *config)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
mutex_lock(&dsi->lock);
- dsi->timings = *timings;
-
- mutex_unlock(&dsi->lock);
-}
-EXPORT_SYMBOL(omapdss_dsi_set_timings);
-
-void omapdss_dsi_set_size(struct omap_dss_device *dssdev, u16 w, u16 h)
-{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
- struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
-
- mutex_lock(&dsi->lock);
+ dsi->timings = *config->timings;
+ dsi->vm_timings = *config->vm_timings;
+ dsi->pix_fmt = config->pixel_format;
+ dsi->mode = config->mode;
- dsi->timings.x_res = w;
- dsi->timings.y_res = h;
+ dsi_set_clocks(dssdev, config->hs_clk, config->lp_clk);
mutex_unlock(&dsi->lock);
-}
-EXPORT_SYMBOL(omapdss_dsi_set_size);
-void omapdss_dsi_set_pixel_format(struct omap_dss_device *dssdev,
- enum omap_dss_dsi_pixel_format fmt)
-{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
- struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
-
- mutex_lock(&dsi->lock);
-
- dsi->pix_fmt = fmt;
-
- mutex_unlock(&dsi->lock);
-}
-EXPORT_SYMBOL(omapdss_dsi_set_pixel_for
[PATCH 07/14] OMAPDSS: DISPC: add new clock calculation code
Add new way to iterate over DISPC clock divisors. dispc_div_calc()
provides a generic way to go over all the divisors, within given pixel
clock range. dispc_div_calc() will call a callback function for each
divider set, making the function reusable for all use cases.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 60 +++
drivers/video/omap2/dss/dss.h |6
2 files changed, 66 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index f564955..cd54e8f 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3374,6 +3374,66 @@ int dispc_calc_clock_rates(unsigned long dispc_fclk_rate,
return 0;
}
+bool dispc_div_calc(unsigned long dispc,
+ unsigned long pck_min, unsigned long pck_max,
+ dispc_div_calc_func func, void *data)
+{
+ int lckd, lckd_start, lckd_stop;
+ int pckd, pckd_start, pckd_stop;
+ unsigned long pck, lck;
+ unsigned long lck_max;
+ unsigned long pckd_hw_min, pckd_hw_max;
+ unsigned min_fck_per_pck;
+ unsigned long fck;
+
+#ifdef CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK
+ min_fck_per_pck = CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK;
+#else
+ min_fck_per_pck = 0;
+#endif
+
+ pckd_hw_min = dss_feat_get_param_min(FEAT_PARAM_DSS_PCD);
+ pckd_hw_max = dss_feat_get_param_max(FEAT_PARAM_DSS_PCD);
+
+ lck_max = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+
+ pck_min = pck_min ? pck_min : 1;
+ pck_max = pck_max ? pck_max : ULONG_MAX;
+
+ lckd_start = max(DIV_ROUND_UP(dispc, lck_max), 1ul);
+ lckd_stop = min(dispc / pck_min, 255ul);
+
+ for (lckd = lckd_start; lckd <= lckd_stop; ++lckd) {
+ lck = dispc / lckd;
+
+ pckd_start = max(DIV_ROUND_UP(lck, pck_max), pckd_hw_min);
+ pckd_stop = min(lck / pck_min, pckd_hw_max);
+
+ for (pckd = pckd_start; pckd <= pckd_stop; ++pckd) {
+ pck = lck / pckd;
+
+ /*
+* For OMAP2/3 the DISPC fclk is the same as LCD's logic
+* clock, which means we're configuring DISPC fclk here
+* also. Thus we need to use the calculated lck. For
+* OMAP4+ the DISPC fclk is a separate clock.
+*/
+ if (dss_has_feature(FEAT_CORE_CLK_DIV))
+ fck = dispc_core_clk_rate();
+ else
+ fck = lck;
+
+ if (fck < pck * min_fck_per_pck)
+ continue;
+
+ if (func(lckd, pckd, lck, pck, data))
+ return true;
+ }
+ }
+
+ return false;
+}
+
void dispc_mgr_set_clock_div(enum omap_channel channel,
const struct dispc_clock_info *cinfo)
{
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 610c8e5..0ff41dd 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -376,6 +376,12 @@ void dispc_enable_fifomerge(bool enable);
void dispc_enable_gamma_table(bool enable);
void dispc_set_loadmode(enum omap_dss_load_mode mode);
+typedef bool (*dispc_div_calc_func)(int lckd, int pckd, unsigned long lck,
+ unsigned long pck, void *data);
+bool dispc_div_calc(unsigned long dispc,
+ unsigned long pck_min, unsigned long pck_max,
+ dispc_div_calc_func func, void *data);
+
bool dispc_mgr_timings_ok(enum omap_channel channel,
const struct omap_video_timings *timings);
unsigned long dispc_fclk_rate(void);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/14] OMAPDSS: remove unused old clock calculation code
Now that the old clock calculation code is no longer used, we can remove
it from the driver.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 48 --
drivers/video/omap2/dss/dsi.c | 317 ---
drivers/video/omap2/dss/dss.c | 115 --
drivers/video/omap2/dss/dss.h | 15 --
4 files changed, 495 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index cd54e8f..8cfa27b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3311,54 +3311,6 @@ static void dispc_dump_regs(struct seq_file *s)
#undef DUMPREG
}
-/* with fck as input clock rate, find dispc dividers that produce req_pck */
-void dispc_find_clk_divs(unsigned long req_pck, unsigned long fck,
- struct dispc_clock_info *cinfo)
-{
- u16 pcd_min, pcd_max;
- unsigned long best_pck;
- u16 best_ld, cur_ld;
- u16 best_pd, cur_pd;
-
- pcd_min = dss_feat_get_param_min(FEAT_PARAM_DSS_PCD);
- pcd_max = dss_feat_get_param_max(FEAT_PARAM_DSS_PCD);
-
- best_pck = 0;
- best_ld = 0;
- best_pd = 0;
-
- for (cur_ld = 1; cur_ld <= 255; ++cur_ld) {
- unsigned long lck = fck / cur_ld;
-
- for (cur_pd = pcd_min; cur_pd <= pcd_max; ++cur_pd) {
- unsigned long pck = lck / cur_pd;
- long old_delta = abs(best_pck - req_pck);
- long new_delta = abs(pck - req_pck);
-
- if (best_pck == 0 || new_delta < old_delta) {
- best_pck = pck;
- best_ld = cur_ld;
- best_pd = cur_pd;
-
- if (pck == req_pck)
- goto found;
- }
-
- if (pck < req_pck)
- break;
- }
-
- if (lck / pcd_min < req_pck)
- break;
- }
-
-found:
- cinfo->lck_div = best_ld;
- cinfo->pck_div = best_pd;
- cinfo->lck = fck / cinfo->lck_div;
- cinfo->pck = cinfo->lck / cinfo->pck_div;
-}
-
/* calculate clock rates using dividers in cinfo */
int dispc_calc_clock_rates(unsigned long dispc_fclk_rate,
struct dispc_clock_info *cinfo)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 593022b..46e3d47 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1430,190 +1430,6 @@ static int dsi_calc_clock_rates(struct platform_device
*dsidev,
return 0;
}
-int dsi_pll_calc_clock_div_pck(struct platform_device *dsidev,
- unsigned long req_pck, struct dsi_clock_info *dsi_cinfo,
- struct dispc_clock_info *dispc_cinfo)
-{
- struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- struct dsi_clock_info cur, best;
- struct dispc_clock_info best_dispc;
- int min_fck_per_pck;
- int match = 0;
- unsigned long dss_sys_clk, max_dss_fck;
-
- dss_sys_clk = clk_get_rate(dsi->sys_clk);
-
- max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
-
- if (req_pck == dsi->cache_req_pck &&
- dsi->cache_cinfo.clkin == dss_sys_clk) {
- DSSDBG("DSI clock info found from cache\n");
- *dsi_cinfo = dsi->cache_cinfo;
- dispc_find_clk_divs(req_pck, dsi_cinfo->dsi_pll_hsdiv_dispc_clk,
- dispc_cinfo);
- return 0;
- }
-
- min_fck_per_pck = CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK;
-
- if (min_fck_per_pck &&
- req_pck * min_fck_per_pck > max_dss_fck) {
- DSSERR("Requested pixel clock not possible with the current "
- "OMAP2_DSS_MIN_FCK_PER_PCK setting. Turning "
- "the constraint off.\n");
- min_fck_per_pck = 0;
- }
-
- DSSDBG("dsi_pll_calc\n");
-
-retry:
- memset(&best, 0, sizeof(best));
- memset(&best_dispc, 0, sizeof(best_dispc));
-
- memset(&cur, 0, sizeof(cur));
- cur.clkin = dss_sys_clk;
-
- /* 0.75MHz < Fint = clkin / regn < 2.1MHz */
- /* To reduce PLL lock time, keep Fint high (around 2 MHz) */
- for (cur.regn = 1; cur.regn < dsi->regn_max; ++cur.regn) {
- cur.fint = cur.clkin / cur.regn;
-
- if (cur.fint > dsi->fint_max || cur.fint < dsi->fint_min)
- continue;
-
- /* DSIPHY(MHz) = (2 * regm / regn) * clkin */
- for (cur.regm = 1; cur.regm < dsi->regm_max; ++cur.regm) {
- unsigned long a, b;
-
- a = 2 * cur.regm * (cur.clkin/1000);
- b = cur.regn;
- cur.clkin4ddr = a / b * 1000;
-
- if (cur.clkin4ddr > 1
[PATCH 12/14] OMAPDSS: DSI: use new clock calculation code
Use the new clock calculation code in the DSI driver.
The new code does not need DSI video mode parameters from the panel
driver, like the old code does. Instead the new code is given the normal
video timings, and a few DSI parameters, which are used to create DSI
video timings.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/panel-taal.c |7 +-
drivers/video/omap2/dss/dsi.c | 504 -
include/video/omapdss.h | 20 +-
3 files changed, 513 insertions(+), 18 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index eb86cba..2fc923d 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -787,6 +787,7 @@ static int taal_probe(struct omap_dss_device *dssdev)
dssdev->panel.timings.x_res = 864;
dssdev->panel.timings.y_res = 480;
+ dssdev->panel.timings.pixel_clock = DIV_ROUND_UP(864 * 480 * 60, 1000);
dssdev->panel.dsi_pix_fmt = OMAP_DSS_DSI_FMT_RGB888;
dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE |
OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
@@ -923,8 +924,10 @@ static int taal_power_on(struct omap_dss_device *dssdev)
.mode = OMAP_DSS_DSI_CMD_MODE,
.pixel_format = OMAP_DSS_DSI_FMT_RGB888,
.timings = &dssdev->panel.timings,
- .hs_clk = 21600,
- .lp_clk = 1000,
+ .hs_clk_min = 15000,
+ .hs_clk_max = 3,
+ .lp_clk_min = 700,
+ .lp_clk_max = 1000,
};
r = omapdss_dsi_configure_pins(dssdev, &td->pin_config);
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c8d5574..593022b 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -255,6 +255,24 @@ struct dsi_isr_tables {
struct dsi_isr_data isr_table_cio[DSI_MAX_NR_ISRS];
};
+struct dsi_clk_calc_ctx {
+ struct platform_device *dsidev;
+
+ /* inputs */
+
+ const struct omap_dss_dsi_config *config;
+
+ unsigned long req_pck_min, req_pck_nom, req_pck_max;
+
+ /* outputs */
+
+ struct dsi_clock_info dsi_cinfo;
+ struct dispc_clock_info dispc_cinfo;
+
+ struct omap_video_timings dispc_vm;
+ struct omap_dss_dsi_videomode_timings dsi_vm;
+};
+
struct dsi_data {
struct platform_device *pdev;
void __iomem*base;
@@ -1201,6 +1219,25 @@ static unsigned long dsi_fclk_rate(struct
platform_device *dsidev)
return r;
}
+static int dsi_lp_clock_calc(struct dsi_clock_info *cinfo,
+ unsigned long lp_clk_min, unsigned long lp_clk_max)
+{
+ unsigned long dsi_fclk = cinfo->dsi_pll_hsdiv_dsi_clk;
+ unsigned lp_clk_div;
+ unsigned long lp_clk;
+
+ lp_clk_div = DIV_ROUND_UP(dsi_fclk, lp_clk_max * 2);
+ lp_clk = dsi_fclk / 2 / lp_clk_div;
+
+ if (lp_clk < lp_clk_min || lp_clk > lp_clk_max)
+ return -EINVAL;
+
+ cinfo->lp_clk_div = lp_clk_div;
+ cinfo->lp_clk = lp_clk;
+
+ return 0;
+}
+
static int dsi_set_lp_clk_divisor(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
@@ -1577,8 +1614,7 @@ found:
return 0;
}
-static void dsi_pll_calc_dsi_fck(struct platform_device *dsidev,
- struct dsi_clock_info *cinfo)
+static void dsi_pll_calc_dsi_fck(struct dsi_clock_info *cinfo)
{
unsigned long max_dsi_fck;
@@ -4369,7 +4405,7 @@ static int dsi_set_clocks(struct omap_dss_device *dssdev,
goto err;
/* Calculate PLL's DSI clock */
- dsi_pll_calc_dsi_fck(dsidev, &cinfo);
+ dsi_pll_calc_dsi_fck(&cinfo);
/* Calculate PLL's DISPC clock and pck & lck divs */
pck = cinfo.clkin4ddr / 16 * (dsi->num_lanes_used - 1) * 8 / bpp;
@@ -4693,13 +4729,6 @@ static int dsi_display_init_dispc(struct platform_device
*dsidev,
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC);
if (dsi->mode == OMAP_DSS_DSI_CMD_MODE) {
- dsi->timings.hsw = 1;
- dsi->timings.hfp = 1;
- dsi->timings.hbp = 1;
- dsi->timings.vsw = 1;
- dsi->timings.vfp = 0;
- dsi->timings.vbp = 0;
-
r = dss_mgr_register_framedone_handler(mgr,
dsi_framedone_irq_callback, dsidev);
if (r) {
@@ -4941,24 +4970,473 @@ int omapdss_dsi_enable_te(struct omap_dss_device
*dssdev, bool enable)
}
EXPORT_SYMBOL(omapdss_dsi_enable_te);
+#ifdef PRINT_VERBOSE_VM_TIMINGS
+static void print_dsi_vm(const char *str,
+ const struct omap_dss_dsi_videomode_timings *t)
+{
+ unsigned long byteclk = t->hsclk / 4;
+ int bl, wc, pps, tot;
+
+ wc = DIV_ROUND_UP(t->hact * t->bitspp, 8);
+ pps = DIV_ROUND_UP(w
[PATCH 14/14] OMAPDSS: remove dsi videomode from dssdev
DSI videomode is no longer needed in the omap_dss_device, so remove it.
Signed-off-by: Tomi Valkeinen
---
include/video/omapdss.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index cbaf60f..8979086 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -631,7 +631,6 @@ struct omap_dss_device {
enum omap_dss_dsi_pixel_format dsi_pix_fmt;
enum omap_dss_dsi_mode dsi_mode;
- struct omap_dss_dsi_videomode_timings dsi_vm_timings;
} panel;
struct {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/14] OMAPDSS: DPI: use new clock calculation code
Use the new clock calculation code in the DPI driver.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 212 +
1 file changed, 172 insertions(+), 40 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 775214c..c7363b1 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -91,31 +91,170 @@ static enum omap_dss_clk_source dpi_get_alt_clk_src(enum
omap_channel channel)
}
}
+struct dpi_clk_calc_ctx {
+ struct platform_device *dsidev;
+
+ /* inputs */
+
+ unsigned long pck_min, pck_max;
+
+ /* outputs */
+
+ struct dsi_clock_info dsi_cinfo;
+ struct dss_clock_info dss_cinfo;
+ struct dispc_clock_info dispc_cinfo;
+};
+
+static bool dpi_calc_dispc_cb(int lckd, int pckd, unsigned long lck,
+ unsigned long pck, void *data)
+{
+ struct dpi_clk_calc_ctx *ctx = data;
+
+ /*
+* Odd dividers give us uneven duty cycle, causing problem when level
+* shifted. So skip all odd dividers when the pixel clock is on the
+* higher side.
+*/
+ if (ctx->pck_min >= 100) {
+ if (lckd > 1 && lckd % 2 != 0)
+ return false;
+
+ if (pckd > 1 && pckd % 2 != 0)
+ return false;
+ }
+
+ ctx->dispc_cinfo.lck_div = lckd;
+ ctx->dispc_cinfo.pck_div = pckd;
+ ctx->dispc_cinfo.lck = lck;
+ ctx->dispc_cinfo.pck = pck;
+
+ return true;
+}
+
+
+static bool dpi_calc_hsdiv_cb(int regm_dispc, unsigned long dispc,
+ void *data)
+{
+ struct dpi_clk_calc_ctx *ctx = data;
+
+ /*
+* Odd dividers give us uneven duty cycle, causing problem when level
+* shifted. So skip all odd dividers when the pixel clock is on the
+* higher side.
+*/
+ if (regm_dispc > 1 && regm_dispc % 2 != 0 && ctx->pck_min >= 100)
+ return false;
+
+ ctx->dsi_cinfo.regm_dispc = regm_dispc;
+ ctx->dsi_cinfo.dsi_pll_hsdiv_dispc_clk = dispc;
+
+ return dispc_div_calc(dispc, ctx->pck_min, ctx->pck_max,
+ dpi_calc_dispc_cb, ctx);
+}
+
+
+static bool dpi_calc_pll_cb(int regn, int regm, unsigned long fint,
+ unsigned long pll,
+ void *data)
+{
+ struct dpi_clk_calc_ctx *ctx = data;
+
+ ctx->dsi_cinfo.regn = regn;
+ ctx->dsi_cinfo.regm = regm;
+ ctx->dsi_cinfo.fint = fint;
+ ctx->dsi_cinfo.clkin4ddr = pll;
+
+ return dsi_hsdiv_calc(ctx->dsidev, pll, ctx->pck_min,
+ dpi_calc_hsdiv_cb, ctx);
+}
+
+static bool dpi_calc_dss_cb(int fckd, unsigned long fck, void *data)
+{
+ struct dpi_clk_calc_ctx *ctx = data;
+
+ ctx->dss_cinfo.fck = fck;
+ ctx->dss_cinfo.fck_div = fckd;
+
+ return dispc_div_calc(fck, ctx->pck_min, ctx->pck_max,
+ dpi_calc_dispc_cb, ctx);
+}
+
+static bool dpi_dsi_clk_calc(unsigned long pck, struct dpi_clk_calc_ctx *ctx)
+{
+ unsigned long clkin;
+ unsigned long pll_min, pll_max;
+
+ clkin = dsi_get_pll_clkin(dpi.dsidev);
+
+ memset(ctx, 0, sizeof(*ctx));
+ ctx->dsidev = dpi.dsidev;
+ ctx->pck_min = pck - 1000;
+ ctx->pck_max = pck + 1000;
+ ctx->dsi_cinfo.clkin = clkin;
+
+ pll_min = 0;
+ pll_max = 0;
+
+ return dsi_pll_calc(dpi.dsidev, clkin,
+ pll_min, pll_max,
+ dpi_calc_pll_cb, ctx);
+}
+
+static bool dpi_dss_clk_calc(unsigned long pck, struct dpi_clk_calc_ctx *ctx)
+{
+ int i;
+
+ /*
+* DSS fck gives us very few possibilities, so finding a good pixel
+* clock may not be possible. We try multiple times to find the clock,
+* each time widening the pixel clock range we look for, up to
+* +/- 1MHz.
+*/
+
+ for (i = 0; i < 10; ++i) {
+ bool ok;
+
+ memset(ctx, 0, sizeof(*ctx));
+ if (pck > 1000 * i * i * i)
+ ctx->pck_min = max(pck - 1000 * i * i * i, 0lu);
+ else
+ ctx->pck_min = 0;
+ ctx->pck_max = pck + 1000 * i * i * i;
+
+ ok = dss_div_calc(ctx->pck_min, dpi_calc_dss_cb, ctx);
+ if (ok)
+ return ok;
+ }
+
+ return false;
+}
+
+
+
static int dpi_set_dsi_clk(enum omap_channel channel,
unsigned long pck_req, unsigned long *fck, int *lck_div,
int *pck_div)
{
- struct dsi_clock_info dsi_cinfo;
- struct dispc_clock_info dispc_cinfo;
+ struct dpi_clk_calc_ctx ctx;
int r;
+ bool ok;
- r = dsi_pll_calc_clock_div_pck(dpi.dsidev, pck_req, &dsi_cinfo,
- &dispc_cinfo);
- if (r)
- return r;
+ ok = dpi_dsi_clk_calc(pck_req, &ctx);
[PATCH 10/14] OMAPDSS: SDI: use new clock calculation code
Use the new clock calculation code in the SDI driver.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/sdi.c | 68 -
1 file changed, 67 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index eb4ee17..5754245 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -41,6 +41,72 @@ static struct {
struct omap_dss_output output;
} sdi;
+struct sdi_clk_calc_ctx {
+ unsigned long pck_min, pck_max;
+
+ struct dss_clock_info dss_cinfo;
+ struct dispc_clock_info dispc_cinfo;
+};
+
+static bool dpi_calc_dispc_cb(int lckd, int pckd, unsigned long lck,
+ unsigned long pck, void *data)
+{
+ struct sdi_clk_calc_ctx *ctx = data;
+
+ ctx->dispc_cinfo.lck_div = lckd;
+ ctx->dispc_cinfo.pck_div = pckd;
+ ctx->dispc_cinfo.lck = lck;
+ ctx->dispc_cinfo.pck = pck;
+
+ return true;
+}
+
+static bool dpi_calc_dss_cb(int fckd, unsigned long fck, void *data)
+{
+ struct sdi_clk_calc_ctx *ctx = data;
+
+ ctx->dss_cinfo.fck = fck;
+ ctx->dss_cinfo.fck_div = fckd;
+
+ return dispc_div_calc(fck, ctx->pck_min, ctx->pck_max,
+ dpi_calc_dispc_cb, ctx);
+}
+
+static int sdi_calc_clock_div(unsigned long pclk,
+ struct dss_clock_info *dss_cinfo,
+ struct dispc_clock_info *dispc_cinfo)
+{
+ int i;
+ struct sdi_clk_calc_ctx ctx;
+
+ /*
+* DSS fclk gives us very few possibilities, so finding a good pixel
+* clock may not be possible. We try multiple times to find the clock,
+* each time widening the pixel clock range we look for, up to
+* +/- 1MHz.
+*/
+
+ for (i = 0; i < 10; ++i) {
+ bool ok;
+
+ memset(&ctx, 0, sizeof(ctx));
+ if (pclk > 1000 * i * i * i)
+ ctx.pck_min = max(pclk - 1000 * i * i * i, 0lu);
+ else
+ ctx.pck_min = 0;
+ ctx.pck_max = pclk + 1000 * i * i * i;
+
+ ok = dss_div_calc(ctx.pck_min, dpi_calc_dss_cb, &ctx);
+ if (ok) {
+ *dss_cinfo = ctx.dss_cinfo;
+ *dispc_cinfo = ctx.dispc_cinfo;
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
{
struct omap_overlay_manager *mgr = dssdev->output->manager;
@@ -88,7 +154,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
t->data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
t->sync_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
- r = dss_calc_clock_div(t->pixel_clock * 1000, &dss_cinfo, &dispc_cinfo);
+ r = sdi_calc_clock_div(t->pixel_clock * 1000, &dss_cinfo, &dispc_cinfo);
if (r)
goto err_calc_clock_div;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/14] OMAPDSS: DSS: add new clock calculation code
Add new way to iterate over DSS clock divisors. dss_div_calc() provides
a generic way to go over all the divisors, within given clock range.
dss_div_calc() will call a callback function for each divider set,
making the function reusable for all use cases.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss.c | 36
drivers/video/omap2/dss/dss.h |3 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 054c2a2..21a3dc8 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -473,6 +473,42 @@ int dss_calc_clock_rates(struct dss_clock_info *cinfo)
return 0;
}
+bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void *data)
+{
+ int fckd, fckd_start, fckd_stop;
+ unsigned long fck;
+ unsigned long fck_hw_max;
+ unsigned long fckd_hw_max;
+ unsigned long prate;
+
+ if (dss.dpll4_m4_ck == NULL) {
+ /* XXX can we change the clock on omap2? */
+ fck = clk_get_rate(dss.dss_clk);
+ fckd = 1;
+
+ return func(fckd, fck, data);
+ }
+
+ fck_hw_max = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+ fckd_hw_max = dss.feat->fck_div_max;
+
+ prate = dss_get_dpll4_rate() * dss.feat->dss_fck_multiplier;
+
+ fck_min = fck_min ? fck_min : 1;
+
+ fckd_start = min(prate / fck_min, fckd_hw_max);
+ fckd_stop = max(DIV_ROUND_UP(prate, fck_hw_max), 1ul);
+
+ for (fckd = fckd_start; fckd >= fckd_stop; --fckd) {
+ fck = prate / fckd;
+
+ if (func(fckd, fck, data))
+ return true;
+ }
+
+ return false;
+}
+
int dss_set_clock_div(struct dss_clock_info *cinfo)
{
if (dss.dpll4_m4_ck) {
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 0ff41dd..4180302 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -271,6 +271,9 @@ int dss_set_clock_div(struct dss_clock_info *cinfo);
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
struct dispc_clock_info *dispc_cinfo);
+typedef bool (*dss_div_calc_func)(int fckd, unsigned long fck, void *data);
+bool dss_div_calc(unsigned long fck_min, dss_div_calc_func func, void *data);
+
/* SDI */
int sdi_init_platform_driver(void) __init;
void sdi_uninit_platform_driver(void) __exit;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/14] OMAPDSS: DSI: add new clock calculation code
Add new way to iterate over DSI PLL and HSDIV clock divisors.
dsi_pll_calc() and dss_hsdiv_calc() provide a generic way to go over
all the divisors, within given clock range. The functions will call a
callback function for each divider set, making the function reusable for
all use cases.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c | 69 +
drivers/video/omap2/dss/dss.h | 12 +++
2 files changed, 81 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index aabe472..c8d5574 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1280,6 +1280,75 @@ static int dsi_pll_power(struct platform_device *dsidev,
return 0;
}
+unsigned long dsi_get_pll_clkin(struct platform_device *dsidev)
+{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ return clk_get_rate(dsi->sys_clk);
+}
+
+bool dsi_hsdiv_calc(struct platform_device *dsidev, unsigned long pll,
+ unsigned long out_min, dsi_hsdiv_calc_func func, void *data)
+{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ int regm, regm_start, regm_stop;
+ unsigned long out_max;
+ unsigned long out;
+
+ out_min = out_min ? out_min : 1;
+ out_max = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+
+ regm_start = max(DIV_ROUND_UP(pll, out_max), 1ul);
+ regm_stop = min(pll / out_min, dsi->regm_dispc_max);
+
+ for (regm = regm_start; regm <= regm_stop; ++regm) {
+ out = pll / regm;
+
+ if (func(regm, out, data))
+ return true;
+ }
+
+ return false;
+}
+
+bool dsi_pll_calc(struct platform_device *dsidev, unsigned long clkin,
+ unsigned long pll_min, unsigned long pll_max,
+ dsi_pll_calc_func func, void *data)
+{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ int regn, regn_start, regn_stop;
+ int regm, regm_start, regm_stop;
+ unsigned long fint, pll;
+ const unsigned long pll_hw_max = 18;
+ unsigned long fint_hw_min, fint_hw_max;
+
+ fint_hw_min = dsi->fint_min;
+ fint_hw_max = dsi->fint_max;
+
+ regn_start = max(DIV_ROUND_UP(clkin, fint_hw_max), 1ul);
+ regn_stop = min(clkin / fint_hw_min, dsi->regn_max);
+
+ pll_max = pll_max ? pll_max : ULONG_MAX;
+
+ for (regn = regn_start; regn <= regn_stop; ++regn) {
+ fint = clkin / regn;
+
+ regm_start = max(DIV_ROUND_UP(DIV_ROUND_UP(pll_min, fint), 2),
+ 1ul);
+ regm_stop = min3(pll_max / fint / 2,
+ pll_hw_max / fint / 2,
+ dsi->regm_max);
+
+ for (regm = regm_start; regm <= regm_stop; ++regm) {
+ pll = 2 * regm * fint;
+
+ if (func(regn, regm, fint, pll, data))
+ return true;
+ }
+ }
+
+ return false;
+}
+
/* calculate clock rates using dividers in cinfo */
static int dsi_calc_clock_rates(struct platform_device *dsidev,
struct dsi_clock_info *cinfo)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 4180302..dde6cc1 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -295,6 +295,18 @@ void dsi_dump_clocks(struct seq_file *s);
void dsi_irq_handler(void);
u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);
+unsigned long dsi_get_pll_clkin(struct platform_device *dsidev);
+
+typedef bool (*dsi_pll_calc_func)(int regn, int regm, unsigned long fint,
+ unsigned long pll, void *data);
+typedef bool (*dsi_hsdiv_calc_func)(int regm_dispc, unsigned long dispc,
+ void *data);
+bool dsi_hsdiv_calc(struct platform_device *dsidev, unsigned long pll,
+ unsigned long out_min, dsi_hsdiv_calc_func func, void *data);
+bool dsi_pll_calc(struct platform_device *dsidev, unsigned long clkin,
+ unsigned long pll_min, unsigned long pll_max,
+ dsi_pll_calc_func func, void *data);
+
unsigned long dsi_get_pll_hsdiv_dispc_rate(struct platform_device *dsidev);
int dsi_pll_set_clock_div(struct platform_device *dsidev,
struct dsi_clock_info *cinfo);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/14] OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode
Instead of managing DSI sync ends with booleans, add an enum for the DSI
transfer mode. This is much cleaner way to handle the DSI syncs.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c | 15 ++-
include/video/omapdss.h | 13 ++---
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 374fd8f..7faad58 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3813,18 +3813,22 @@ static void dsi_config_vp_num_line_buffers(struct
platform_device *dsidev)
static void dsi_config_vp_sync_events(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- bool vsync_end = dsi->vm_timings.vp_vsync_end;
- bool hsync_end = dsi->vm_timings.vp_hsync_end;
+ bool sync_end;
u32 r;
+ if (dsi->vm_timings.trans_mode == OMAP_DSS_DSI_PULSE_MODE)
+ sync_end = true;
+ else
+ sync_end = false;
+
r = dsi_read_reg(dsidev, DSI_CTRL);
r = FLD_MOD(r, 1, 9, 9);/* VP_DE_POL */
r = FLD_MOD(r, 1, 10, 10); /* VP_HSYNC_POL */
r = FLD_MOD(r, 1, 11, 11); /* VP_VSYNC_POL */
r = FLD_MOD(r, 1, 15, 15); /* VP_VSYNC_START */
- r = FLD_MOD(r, vsync_end, 16, 16); /* VP_VSYNC_END */
+ r = FLD_MOD(r, sync_end, 16, 16); /* VP_VSYNC_END */
r = FLD_MOD(r, 1, 17, 17); /* VP_HSYNC_START */
- r = FLD_MOD(r, hsync_end, 18, 18); /* VP_HSYNC_END */
+ r = FLD_MOD(r, sync_end, 18, 18); /* VP_HSYNC_END */
dsi_write_reg(dsidev, DSI_CTRL, r);
}
@@ -4171,11 +4175,12 @@ static void dsi_proto_timings(struct platform_device
*dsidev)
int vfp = dsi->vm_timings.vfp;
int vbp = dsi->vm_timings.vbp;
int window_sync = dsi->vm_timings.window_sync;
- bool hsync_end = dsi->vm_timings.vp_hsync_end;
+ bool hsync_end;
struct omap_video_timings *timings = &dsi->timings;
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
int tl, t_he, width_bytes;
+ hsync_end = dsi->vm_timings.trans_mode ==
OMAP_DSS_DSI_PULSE_MODE;
t_he = hsync_end ?
((hsa == 0 && ndl == 3) ? 1 : DIV_ROUND_UP(4, ndl)) : 0;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 4a52197..161011e 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -257,6 +257,15 @@ void rfbi_bus_unlock(void);
/* DSI */
+enum omap_dss_dsi_trans_mode {
+ /* Sync Pulses: both sync start and end packets sent */
+ OMAP_DSS_DSI_PULSE_MODE,
+ /* Sync Events: only sync start packets sent */
+ OMAP_DSS_DSI_EVENT_MODE,
+ /* Burst: only sync start packets sent, pixels are time compressed */
+ OMAP_DSS_DSI_BURST_MODE,
+};
+
struct omap_dss_dsi_videomode_timings {
/* DSI video mode blanking data */
/* Unit: byte clock cycles */
@@ -274,9 +283,7 @@ struct omap_dss_dsi_videomode_timings {
int hbp_blanking_mode;
int hfp_blanking_mode;
- /* Video port sync events */
- bool vp_vsync_end;
- bool vp_hsync_end;
+ enum omap_dss_dsi_trans_mode trans_mode;
bool ddr_clk_always_on;
int window_sync;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/14] OMAPDSS: DSI remove unneeded clk source setup code
We always use the same clock sources for DSI, so let's remove the
unnecessary clock source fields from dsi_data.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 7faad58..aabe472 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -269,10 +269,6 @@ struct dsi_data {
struct dispc_clock_info user_dispc_cinfo;
struct dsi_clock_info user_dsi_cinfo;
- enum omap_dss_clk_source user_dispc_fclk_src;
- enum omap_dss_clk_source user_lcd_clk_src;
- enum omap_dss_clk_source user_dsi_fclk_src;
-
struct dsi_clock_info current_cinfo;
bool vdds_dsi_enabled;
@@ -4327,18 +4323,6 @@ static int dsi_set_clocks(struct omap_dss_device *dssdev,
dsi->user_dispc_cinfo.lck_div = dispc_cinfo.lck_div;
dsi->user_dispc_cinfo.pck_div = dispc_cinfo.pck_div;
- dsi->user_dispc_fclk_src = OMAP_DSS_CLK_SRC_FCK;
-
- dsi->user_lcd_clk_src =
- dsi->module_id == 0 ?
- OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC :
- OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC;
-
- dsi->user_dsi_fclk_src =
- dsi->module_id == 0 ?
- OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI :
- OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI;
-
return 0;
err:
return r;
@@ -4635,7 +4619,9 @@ static int dsi_display_init_dispc(struct platform_device
*dsidev,
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
int r;
- dss_select_lcd_clk_source(mgr->id, dsi->user_lcd_clk_src);
+ dss_select_lcd_clk_source(mgr->id, dsi->module_id == 0 ?
+ OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC :
+ OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC);
if (dsi->mode == OMAP_DSS_DSI_CMD_MODE) {
dsi->timings.hsw = 1;
@@ -4741,7 +4727,9 @@ static int dsi_display_init_dsi(struct platform_device
*dsidev)
if (r)
goto err1;
- dss_select_dsi_clk_source(dsi->module_id, dsi->user_dsi_fclk_src);
+ dss_select_dsi_clk_source(dsi->module_id, dsi->module_id == 0 ?
+ OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI :
+ OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI);
DSSDBG("PLL OK\n");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/14] OMAPDSS: DSI: get line buffer size at probe
To find out the DSI line buffer size we need to read HW registers. To
make it possible to do DSI configuration calculations without HW powered
up, store the line buffer size at DSI driver's probe.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 901b721..374fd8f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -336,6 +336,7 @@ struct dsi_data {
unsigned long lpdiv_max;
unsigned num_lanes_supported;
+ unsigned line_buffer_size;
struct dsi_lane_config lanes[DSI_MAX_NR_LANES];
unsigned num_lanes_used;
@@ -3791,13 +3792,12 @@ static void dsi_config_vp_num_line_buffers(struct
platform_device *dsidev)
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
- unsigned line_buf_size = dsi_get_line_buf_size(dsidev);
struct omap_video_timings *timings = &dsi->timings;
/*
* Don't use line buffers if width is greater than the video
* port's line buffer size
*/
- if (line_buf_size <= timings->x_res * bpp / 8)
+ if (dsi->line_buffer_size <= timings->x_res * bpp / 8)
num_line_buffers = 0;
else
num_line_buffers = 2;
@@ -4447,7 +4447,7 @@ static void dsi_update_screen_dispc(struct
platform_device *dsidev)
u32 l;
int r;
const unsigned channel = dsi->update_channel;
- const unsigned line_buf_size = dsi_get_line_buf_size(dsidev);
+ const unsigned line_buf_size = dsi->line_buffer_size;
u16 w = dsi->timings.x_res;
u16 h = dsi->timings.y_res;
@@ -5290,6 +5290,8 @@ static int __init omap_dsihw_probe(struct platform_device
*dsidev)
else
dsi->num_lanes_supported = 3;
+ dsi->line_buffer_size = dsi_get_line_buf_size(dsidev);
+
dsi_init_output(dsidev);
dsi_probe_pdata(dsidev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/14] OMAPDSS: DSI: fix wrong unsigned long long use
dsi_configure_dispc_clocks() stores dsi func clock into unsigned long long, but it should really be just unsigned long. Fix this. Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/dss/dsi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index 2d95ed9..5f5b475 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -4611,7 +4611,7 @@ static int dsi_configure_dispc_clocks(struct platform_device *dsidev) struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev); struct dispc_clock_info dispc_cinfo; int r; - unsigned long long fck; + unsigned long fck; fck = dsi_get_pll_hsdiv_dispc_rate(dsidev); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/14] OMAPDSS: new clock calculation + DSI VM
Hi, Here's a series for improving omapdss clock calculation, and also automatically calculating DSI videomode parameters, instead of requiring them to be precalculated and passed to omapdss. These are based on the previous misc patches series. Tomi Tomi Valkeinen (14): OMAPDSS: DISPC: store core clk rate OMAPDSS: DSI: fix wrong unsigned long long use OMAPDSS: DSI: simplify dsi configuration OMAPDSS: DSI: get line buffer size at probe OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode OMAPDSS: DSI remove unneeded clk source setup code OMAPDSS: DISPC: add new clock calculation code OMAPDSS: DSS: add new clock calculation code OMAPDSS: DSI: add new clock calculation code OMAPDSS: SDI: use new clock calculation code OMAPDSS: DPI: use new clock calculation code OMAPDSS: DSI: use new clock calculation code OMAPDSS: remove unused old clock calculation code OMAPDSS: remove dsi videomode from dssdev drivers/video/omap2/displays/panel-taal.c | 19 +- drivers/video/omap2/dss/dispc.c | 124 ++-- drivers/video/omap2/dss/dpi.c | 212 +-- drivers/video/omap2/dss/dsi.c | 959 + drivers/video/omap2/dss/dss.c | 151 ++--- drivers/video/omap2/dss/dss.h | 36 +- drivers/video/omap2/dss/sdi.c | 68 +- include/video/omapdss.h | 51 +- 8 files changed, 977 insertions(+), 643 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] OMAPDSS: DISPC: store core clk rate
Store dispc core clock rate so that it's available for calculations even
if the HW is disabled.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 05ff2b9..f564955 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -97,6 +97,8 @@ static struct {
int irq;
+ unsigned long core_clk_rate;
+
u32 fifo_size[DISPC_MAX_NR_FIFOS];
/* maps which plane is using a fifo. fifo-id -> plane-id */
int fifo_assignment[DISPC_MAX_NR_FIFOS];
@@ -2951,6 +2953,10 @@ static void dispc_mgr_set_lcd_divisor(enum omap_channel
channel, u16 lck_div,
dispc_write_reg(DISPC_DIVISORo(channel),
FLD_VAL(lck_div, 23, 16) | FLD_VAL(pck_div, 7, 0));
+
+ if (dss_has_feature(FEAT_CORE_CLK_DIV) == false &&
+ channel == OMAP_DSS_CHANNEL_LCD)
+ dispc.core_clk_rate = dispc_fclk_rate() / lck_div;
}
static void dispc_mgr_get_lcd_divisor(enum omap_channel channel, int *lck_div,
@@ -3056,15 +3062,7 @@ unsigned long dispc_mgr_pclk_rate(enum omap_channel
channel)
unsigned long dispc_core_clk_rate(void)
{
- int lcd;
- unsigned long fclk = dispc_fclk_rate();
-
- if (dss_has_feature(FEAT_CORE_CLK_DIV))
- lcd = REG_GET(DISPC_DIVISOR, 23, 16);
- else
- lcd = REG_GET(DISPC_DIVISORo(OMAP_DSS_CHANNEL_LCD), 23, 16);
-
- return fclk / lcd;
+ return dispc.core_clk_rate;
}
static unsigned long dispc_plane_pclk_rate(enum omap_plane plane)
@@ -3451,6 +3449,8 @@ static void _omap_dispc_initial_config(void)
l = FLD_MOD(l, 1, 0, 0);
l = FLD_MOD(l, 1, 23, 16);
dispc_write_reg(DISPC_DIVISOR, l);
+
+ dispc.core_clk_rate = dispc_fclk_rate();
}
/* FUNCGATED */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/20] OMAPDSS: DSI: remove omap_dss_device uses
The role of struct omap_dss_device will change in the future. The exact
details of that are still a bit unclear. However, the less uses of
omap_dss_device we have, the easier the change is in the future.
This patch removes uses of omap_dss_device from dsi.c, where it can be
done easily. Mostly this means passing dsi platform device to functions,
instead of the omap_dss_device.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c | 68 ++---
1 file changed, 29 insertions(+), 39 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 9eb7845..815c930 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1199,9 +1199,8 @@ static unsigned long dsi_fclk_rate(struct platform_device
*dsidev)
return r;
}
-static int dsi_set_lp_clk_divisor(struct omap_dss_device *dssdev)
+static int dsi_set_lp_clk_divisor(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
unsigned long dsi_fclk;
unsigned lp_clk_div;
@@ -3904,9 +3903,8 @@ static int dsi_compute_interleave_lp(int blank, int
enter_hs, int exit_hs,
return max(lp_inter, 0);
}
-static void dsi_config_cmd_mode_interleaving(struct omap_dss_device *dssdev)
+static void dsi_config_cmd_mode_interleaving(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
int blanking_mode;
int hfp_blanking_mode, hbp_blanking_mode, hsa_blanking_mode;
@@ -4022,9 +4020,8 @@ static void dsi_config_cmd_mode_interleaving(struct
omap_dss_device *dssdev)
dsi_write_reg(dsidev, DSI_VM_TIMING6, r);
}
-static int dsi_proto_config(struct omap_dss_device *dssdev)
+static int dsi_proto_config(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
u32 r;
int buswidth = 0;
@@ -4082,7 +4079,7 @@ static int dsi_proto_config(struct omap_dss_device
*dssdev)
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
dsi_config_vp_sync_events(dsidev);
dsi_config_blanking_modes(dsidev);
- dsi_config_cmd_mode_interleaving(dssdev);
+ dsi_config_cmd_mode_interleaving(dsidev);
}
dsi_vc_initial_config(dsidev, 0);
@@ -4343,7 +4340,7 @@ int dsi_enable_video_output(struct omap_dss_device
*dssdev, int channel)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- struct omap_overlay_manager *mgr = dssdev->output->manager;
+ struct omap_overlay_manager *mgr = dsi->output.manager;
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
u8 data_type;
u16 word_count;
@@ -4401,7 +4398,7 @@ void dsi_disable_video_output(struct omap_dss_device
*dssdev, int channel)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- struct omap_overlay_manager *mgr = dssdev->output->manager;
+ struct omap_overlay_manager *mgr = dsi->output.manager;
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
dsi_if_enable(dsidev, false);
@@ -4418,11 +4415,10 @@ void dsi_disable_video_output(struct omap_dss_device
*dssdev, int channel)
}
EXPORT_SYMBOL(dsi_disable_video_output);
-static void dsi_update_screen_dispc(struct omap_dss_device *dssdev)
+static void dsi_update_screen_dispc(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- struct omap_overlay_manager *mgr = dssdev->output->manager;
+ struct omap_overlay_manager *mgr = dsi->output.manager;
unsigned bytespp;
unsigned bytespl;
unsigned bytespf;
@@ -4578,7 +4574,7 @@ int omap_dsi_update(struct omap_dss_device *dssdev, int
channel,
dsi->update_bytes = dw * dh *
dsi_get_pixel_size(dsi->pix_fmt) / 8;
#endif
- dsi_update_screen_dispc(dssdev);
+ dsi_update_screen_dispc(dsidev);
return 0;
}
@@ -4586,9 +4582,8 @@ EXPORT_SYMBOL(omap_dsi_update);
/* Display funcs */
-static int dsi_configure_dispc_clocks(struct omap_dss_device *dssdev)
+static int dsi_configure_dispc_clocks(struct platform_device *dsidev)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct dispc_clock_info dispc_cinfo;
int r;
@@ -4610,11 +4605,10 @@ static int dsi_configure_dispc_clocks(struct
omap_dss_device *dssdev)
return 0;
}
-static int dsi_display_init_
[PATCH 18/20] OMAPDSS: DSI: delay dispc initialization
We currently setup both DSI and DISPC related things when the DSI bus is
enabled. There's no need for DISPC related thing at that point, though,
but only later when the video output is enabled.
To make it possible to use the DSI bus before DISPC overlay manager is
selected, this patch moves DSI's DISPC initialization to
dsi_enable_video_output(), from omapdss_dsi_display_enable(). We also
move the selection of DISPC's LCD clock to dsi_enable_video_output.
This way there are no DISPC dependencies until the video output is
enabled.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c | 75 ++---
1 file changed, 40 insertions(+), 35 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index f44316a..da8a678 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -200,6 +200,11 @@ struct dsi_reg { u16 idx; };
typedef void (*omap_dsi_isr_t) (void *arg, u32 mask);
+static int dsi_display_init_dispc(struct platform_device *dsidev,
+ struct omap_overlay_manager *mgr);
+static void dsi_display_uninit_dispc(struct platform_device *dsidev,
+ struct omap_overlay_manager *mgr);
+
#define DSI_MAX_NR_ISRS2
#define DSI_MAX_NR_LANES 5
@@ -4342,10 +4347,20 @@ int dsi_enable_video_output(struct omap_dss_device
*dssdev, int channel)
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct omap_overlay_manager *mgr = dsi->output.manager;
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
+ struct omap_dss_output *out = &dsi->output;
u8 data_type;
u16 word_count;
int r;
+ if (out == NULL || out->manager == NULL) {
+ DSSERR("failed to enable display: no output/manager\n");
+ return -ENODEV;
+ }
+
+ r = dsi_display_init_dispc(dsidev, mgr);
+ if (r)
+ goto err_init_dispc;
+
if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
switch (dsi->pix_fmt) {
case OMAP_DSS_DSI_FMT_RGB888:
@@ -4361,8 +4376,8 @@ int dsi_enable_video_output(struct omap_dss_device
*dssdev, int channel)
data_type = MIPI_DSI_PACKED_PIXEL_STREAM_16;
break;
default:
- BUG();
- return -EINVAL;
+ r = -EINVAL;
+ goto err_pix_fmt;
};
dsi_if_enable(dsidev, false);
@@ -4381,16 +4396,20 @@ int dsi_enable_video_output(struct omap_dss_device
*dssdev, int channel)
}
r = dss_mgr_enable(mgr);
- if (r) {
- if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
- dsi_if_enable(dsidev, false);
- dsi_vc_enable(dsidev, channel, false);
- }
-
- return r;
- }
+ if (r)
+ goto err_mgr_enable;
return 0;
+
+err_mgr_enable:
+ if (dsi->mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ dsi_if_enable(dsidev, false);
+ dsi_vc_enable(dsidev, channel, false);
+ }
+err_pix_fmt:
+ dsi_display_uninit_dispc(dsidev, mgr);
+err_init_dispc:
+ return r;
}
EXPORT_SYMBOL(dsi_enable_video_output);
@@ -4412,6 +4431,8 @@ void dsi_disable_video_output(struct omap_dss_device
*dssdev, int channel)
}
dss_mgr_disable(mgr);
+
+ dsi_display_uninit_dispc(dsidev, mgr);
}
EXPORT_SYMBOL(dsi_disable_video_output);
@@ -4605,12 +4626,14 @@ static int dsi_configure_dispc_clocks(struct
platform_device *dsidev)
return 0;
}
-static int dsi_display_init_dispc(struct platform_device *dsidev)
+static int dsi_display_init_dispc(struct platform_device *dsidev,
+ struct omap_overlay_manager *mgr)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- struct omap_overlay_manager *mgr = dsi->output.manager;
int r;
+ dss_select_lcd_clk_source(mgr->id, dsi->user_lcd_clk_src);
+
if (dsi->mode == OMAP_DSS_DSI_CMD_MODE) {
dsi->timings.hsw = 1;
dsi->timings.hfp = 1;
@@ -4663,17 +4686,20 @@ err1:
dss_mgr_unregister_framedone_handler(mgr,
dsi_framedone_irq_callback, dsidev);
err:
+ dss_select_lcd_clk_source(mgr->id, OMAP_DSS_CLK_SRC_FCK);
return r;
}
-static void dsi_display_uninit_dispc(struct platform_device *dsidev)
+static void dsi_display_uninit_dispc(struct platform_device *dsidev,
+ struct omap_overlay_manager *mgr)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- struct omap_overlay_manager *mgr = dsi->output.manager;
if (dsi->mode == OMAP_DSS_DSI_CMD_MODE)
dss_mgr_unregister_framedone_handler(mgr,
dsi_framedone_irq_callback, dsidev);
+
+ dss_select_lcd_clk_source(mgr->id, OMAP_DSS_CL
[PATCH 11/20] OMAPDSS: add output->recommended_channel
Add recommended_channel for omapdss's outputs. The field tells which
DISPC channel should be used for that output.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c |1 +
drivers/video/omap2/dss/dsi.c |1 +
drivers/video/omap2/dss/hdmi.c |1 +
drivers/video/omap2/dss/rfbi.c |1 +
drivers/video/omap2/dss/sdi.c |1 +
drivers/video/omap2/dss/venc.c |1 +
include/video/omapdss.h|3 +++
7 files changed, 9 insertions(+)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 3261644..fb38019 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -540,6 +540,7 @@ static void __init dpi_init_output(struct platform_device
*pdev)
out->id = OMAP_DSS_OUTPUT_DPI;
out->type = OMAP_DISPLAY_TYPE_DPI;
out->name = "dpi";
+ out->recommended_channel = dpi_get_channel();
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c39ca86..e0c9e31 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5232,6 +5232,7 @@ static void __init dsi_init_output(struct platform_device
*dsidev)
out->type = OMAP_DISPLAY_TYPE_DSI;
out->name = dsi->module_id == 0 ? "dsi0" : "dsi1";
+ out->recommended_channel = dsi_get_channel(dsi->module_id);
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 888cfe3..e4c3be4 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1047,6 +1047,7 @@ static void __init hdmi_init_output(struct
platform_device *pdev)
out->id = OMAP_DSS_OUTPUT_HDMI;
out->type = OMAP_DISPLAY_TYPE_HDMI;
out->name = "hdmi";
+ out->recommended_channel = OMAP_DSS_CHANNEL_DIGIT;
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 04c4ab6..991ec93 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1028,6 +1028,7 @@ static void __init rfbi_init_output(struct
platform_device *pdev)
out->id = OMAP_DSS_OUTPUT_DBI;
out->type = OMAP_DISPLAY_TYPE_DBI;
out->name = "rfbi";
+ out->recommended_channel = OMAP_DSS_CHANNEL_LCD;
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index d24e971..c797b33 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -281,6 +281,7 @@ static void __init sdi_init_output(struct platform_device
*pdev)
out->id = OMAP_DSS_OUTPUT_SDI;
out->type = OMAP_DISPLAY_TYPE_SDI;
out->name = "sdi";
+ out->recommended_channel = OMAP_DSS_CHANNEL_LCD;
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index c8130f8..b85fd3d 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -820,6 +820,7 @@ static void __init venc_init_output(struct platform_device
*pdev)
out->id = OMAP_DSS_OUTPUT_VENC;
out->type = OMAP_DISPLAY_TYPE_VENC;
out->name = "venc";
+ out->recommended_channel = OMAP_DSS_CHANNEL_DIGIT;
dss_register_output(out);
}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ba9cea7..8647646 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -547,6 +547,9 @@ struct omap_dss_output {
/* display type supported by the output */
enum omap_display_type type;
+ /* recommended DISPC channel for this output */
+ enum omap_channel recommended_channel;
+
/* output instance */
enum omap_dss_output_id id;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/20] OMAPDSS: DSI: fix DSI channel source initialization
During the initialization of the DSI protocol registers, we always set
the sources of all DSI channels to L4. However, we don't update the
value in the dsi_data, so we may end up with a different value in the
register and in the dsi_data, leading to DSI problems.
This patch fixes the issue by initializing also the channel source in
the dsi_data.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index da8a678..2d95ed9 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -2794,6 +2794,7 @@ static int dsi_vc_enable(struct platform_device *dsidev,
int channel,
static void dsi_vc_initial_config(struct platform_device *dsidev, int channel)
{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
u32 r;
DSSDBG("Initial config of virtual channel %d", channel);
@@ -2818,6 +2819,8 @@ static void dsi_vc_initial_config(struct platform_device
*dsidev, int channel)
r = FLD_MOD(r, 4, 23, 21); /* DMA_TX_REQ_NB = no dma */
dsi_write_reg(dsidev, DSI_VC_CTRL(channel), r);
+
+ dsi->vc[channel].source = DSI_VC_SOURCE_L4;
}
static int dsi_vc_config_source(struct platform_device *dsidev, int channel,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/20] OMAPDSS: Taal: remove rotate & mirror support
Taal panel driver has support to set rotation and mirroring. However,
these features cannot be used without causing tearing, and are never
used. The code is just extra bloat, so let's remove it.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/panel-taal.c | 170 +
1 file changed, 2 insertions(+), 168 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 038a815..bc4c95e 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -76,8 +76,6 @@ struct taal_data {
/* runtime variables */
bool enabled;
- u8 rotate;
- bool mirror;
bool te_enabled;
@@ -202,49 +200,6 @@ static int taal_get_id(struct taal_data *td, u8 *id1, u8
*id2, u8 *id3)
return 0;
}
-static int taal_set_addr_mode(struct taal_data *td, u8 rotate, bool mirror)
-{
- int r;
- u8 mode;
- int b5, b6, b7;
-
- r = taal_dcs_read_1(td, MIPI_DCS_GET_ADDRESS_MODE, &mode);
- if (r)
- return r;
-
- switch (rotate) {
- default:
- case 0:
- b7 = 0;
- b6 = 0;
- b5 = 0;
- break;
- case 1:
- b7 = 0;
- b6 = 1;
- b5 = 1;
- break;
- case 2:
- b7 = 1;
- b6 = 1;
- b5 = 0;
- break;
- case 3:
- b7 = 1;
- b6 = 0;
- b5 = 1;
- break;
- }
-
- if (mirror)
- b6 = !b6;
-
- mode &= ~((1<<7) | (1<<6) | (1<<5));
- mode |= (b7 << 7) | (b6 << 6) | (b5 << 5);
-
- return taal_dcs_write_1(td, MIPI_DCS_SET_ADDRESS_MODE, mode);
-}
-
static int taal_set_update_window(struct taal_data *td,
u16 x, u16 y, u16 w, u16 h)
{
@@ -455,15 +410,8 @@ static const struct backlight_ops taal_bl_ops = {
static void taal_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
{
- struct taal_data *td = dev_get_drvdata(&dssdev->dev);
-
- if (td->rotate == 0 || td->rotate == 2) {
- *xres = dssdev->panel.timings.x_res;
- *yres = dssdev->panel.timings.y_res;
- } else {
- *yres = dssdev->panel.timings.x_res;
- *xres = dssdev->panel.timings.y_res;
- }
+ *xres = dssdev->panel.timings.x_res;
+ *yres = dssdev->panel.timings.y_res;
}
static ssize_t taal_num_errors_show(struct device *dev,
@@ -1025,10 +973,6 @@ static int taal_power_on(struct omap_dss_device *dssdev)
if (r)
goto err;
- r = taal_set_addr_mode(td, td->rotate, td->mirror);
- if (r)
- goto err;
-
if (!td->cabc_broken) {
r = taal_dcs_write_1(td, DCS_WRITE_CABC, td->cabc_mode);
if (r)
@@ -1340,112 +1284,6 @@ static int taal_get_te(struct omap_dss_device *dssdev)
return r;
}
-static int taal_rotate(struct omap_dss_device *dssdev, u8 rotate)
-{
- struct taal_data *td = dev_get_drvdata(&dssdev->dev);
- u16 dw, dh;
- int r;
-
- dev_dbg(&dssdev->dev, "rotate %d\n", rotate);
-
- mutex_lock(&td->lock);
-
- if (td->rotate == rotate)
- goto end;
-
- dsi_bus_lock(dssdev);
-
- if (td->enabled) {
- r = taal_wake_up(dssdev);
- if (r)
- goto err;
-
- r = taal_set_addr_mode(td, rotate, td->mirror);
- if (r)
- goto err;
- }
-
- if (rotate == 0 || rotate == 2) {
- dw = dssdev->panel.timings.x_res;
- dh = dssdev->panel.timings.y_res;
- } else {
- dw = dssdev->panel.timings.y_res;
- dh = dssdev->panel.timings.x_res;
- }
-
- omapdss_dsi_set_size(dssdev, dw, dh);
-
- td->rotate = rotate;
-
- dsi_bus_unlock(dssdev);
-end:
- mutex_unlock(&td->lock);
- return 0;
-err:
- dsi_bus_unlock(dssdev);
- mutex_unlock(&td->lock);
- return r;
-}
-
-static u8 taal_get_rotate(struct omap_dss_device *dssdev)
-{
- struct taal_data *td = dev_get_drvdata(&dssdev->dev);
- int r;
-
- mutex_lock(&td->lock);
- r = td->rotate;
- mutex_unlock(&td->lock);
-
- return r;
-}
-
-static int taal_mirror(struct omap_dss_device *dssdev, bool enable)
-{
- struct taal_data *td = dev_get_drvdata(&dssdev->dev);
- int r;
-
- dev_dbg(&dssdev->dev, "mirror %d\n", enable);
-
- mutex_lock(&td->lock);
-
- if (td->mirror == enable)
- goto end;
-
- dsi_bus_lock(dssdev);
- if (td->enabled) {
- r = taal_wake_up(dssdev);
- if (r)
- goto err;
-
- r = taal_set_addr_mode(td, td->rotate, enable)
[PATCH 15/20] OMAP: dss-common.c: remove uses of dss channel (LATER)
Now that omap_dss_device's channel is resolved automatically, we can
remove its uses from the board files.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/dss-common.c |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 4be5cfc..125c4eb 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -55,7 +55,6 @@ static struct omap_dss_device omap4_panda_dvi_device = {
.data = &omap4_dvi_panel,
.phy.dpi.data_lines = 24,
.reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
- .channel= OMAP_DSS_CHANNEL_LCD2,
};
static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
@@ -68,7 +67,6 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
.name = "hdmi",
.driver_name = "hdmi_panel",
.type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
.data = &omap4_panda_hdmi_data,
};
@@ -132,7 +130,6 @@ static struct omap_dss_device sdp4430_lcd_device = {
.phy.dsi= {
.module = 0,
},
- .channel= OMAP_DSS_CHANNEL_LCD,
};
static struct nokia_dsi_panel_data dsi2_panel = {
@@ -156,7 +153,6 @@ static struct omap_dss_device sdp4430_lcd2_device = {
.module = 1,
},
- .channel= OMAP_DSS_CHANNEL_LCD2,
};
static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
@@ -169,7 +165,6 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.name = "hdmi",
.driver_name = "hdmi_panel",
.type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
.data = &sdp4430_hdmi_data,
};
@@ -215,7 +210,6 @@ static struct omap_dss_device sdp4430_picodlp_device = {
.driver_name= "picodlp_panel",
.type = OMAP_DISPLAY_TYPE_DPI,
.phy.dpi.data_lines = 24,
- .channel= OMAP_DSS_CHANNEL_LCD2,
.platform_enable= sdp4430_panel_enable_picodlp,
.platform_disable = sdp4430_panel_disable_picodlp,
.data = &sdp4430_picodlp_pdata,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/20] OMAPDSS: add pdata->default_display_name
We can currently set the default display (i.e. the initial display) in
the omapdss platform data by using a pointer to the default
omap_dss_device. Internally omapdss uses the device's name to resolve
the default display.
As it's difficult to get the omap_dss_device pointer in the future,
after we've changed the omapdss device model, this patch adds a new way
to define the default display, by using the name of the display.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/core.c |2 ++
include/video/omapdss.h|1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index f8779d4..a9bab9f 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -238,6 +238,8 @@ static int __init omap_dss_probe(struct platform_device
*pdev)
if (def_disp_name)
core.default_display_name = def_disp_name;
+ else if (pdata->default_display_name)
+ core.default_display_name = pdata->default_display_name;
else if (pdata->default_device)
core.default_display_name = pdata->default_device->name;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index cd028c8..9057e21 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -334,6 +334,7 @@ struct omap_dss_board_info {
int num_devices;
struct omap_dss_device **devices;
struct omap_dss_device *default_device;
+ const char *default_display_name;
int (*dsi_enable_pads)(int dsi_id, unsigned lane_mask);
void (*dsi_disable_pads)(int dsi_id, unsigned lane_mask);
int (*set_min_bus_tput)(struct device *dev, unsigned long r);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/20] OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync
dss_mgr_wait_for_vsync() uses dssdev->type to find out if the output is
going to VENC, HDMI, or something else. This creates a dependency on
dssdev, which we want to remove. The task is more logically done by
looking at the output to which the overlay manager in question is
connected to.
This patch changes the code to use output->id to find out which kind of
output we use.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/apply.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index d446bdf..a4b356a 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -435,20 +435,27 @@ static inline struct omap_dss_device
*dss_mgr_get_device(struct omap_overlay_man
static int dss_mgr_wait_for_vsync(struct omap_overlay_manager *mgr)
{
unsigned long timeout = msecs_to_jiffies(500);
- struct omap_dss_device *dssdev = mgr->get_device(mgr);
u32 irq;
int r;
+ if (mgr->output == NULL)
+ return -ENODEV;
+
r = dispc_runtime_get();
if (r)
return r;
- if (dssdev->type == OMAP_DISPLAY_TYPE_VENC)
+ switch (mgr->output->id) {
+ case OMAP_DSS_OUTPUT_VENC:
irq = DISPC_IRQ_EVSYNC_ODD;
- else if (dssdev->type == OMAP_DISPLAY_TYPE_HDMI)
+ break;
+ case OMAP_DSS_OUTPUT_HDMI:
irq = DISPC_IRQ_EVSYNC_EVEN;
- else
+ break;
+ default:
irq = dispc_mgr_get_vsync_irq(mgr->id);
+ break;
+ }
r = omap_dispc_wait_for_irq_interruptible_timeout(irq, timeout);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/20] OMAPDSS: add output->name
Add name field to omapdss's outputs to help debugging.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c |1 +
drivers/video/omap2/dss/dsi.c |1 +
drivers/video/omap2/dss/hdmi.c |1 +
drivers/video/omap2/dss/rfbi.c |1 +
drivers/video/omap2/dss/sdi.c |1 +
drivers/video/omap2/dss/venc.c |1 +
include/video/omapdss.h|3 +++
7 files changed, 9 insertions(+)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index cb6b280..e282456 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -512,6 +512,7 @@ static void __init dpi_init_output(struct platform_device
*pdev)
out->pdev = pdev;
out->id = OMAP_DSS_OUTPUT_DPI;
out->type = OMAP_DISPLAY_TYPE_DPI;
+ out->name = "dpi";
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 815c930..1a6ad6f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5183,6 +5183,7 @@ static void __init dsi_init_output(struct platform_device
*dsidev)
OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2;
out->type = OMAP_DISPLAY_TYPE_DSI;
+ out->name = dsi->module_id == 0 ? "dsi0" : "dsi1";
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f3768d0..888cfe3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1046,6 +1046,7 @@ static void __init hdmi_init_output(struct
platform_device *pdev)
out->pdev = pdev;
out->id = OMAP_DSS_OUTPUT_HDMI;
out->type = OMAP_DISPLAY_TYPE_HDMI;
+ out->name = "hdmi";
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index e903dd3..a47a9e5 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1025,6 +1025,7 @@ static void __init rfbi_init_output(struct
platform_device *pdev)
out->pdev = pdev;
out->id = OMAP_DSS_OUTPUT_DBI;
out->type = OMAP_DISPLAY_TYPE_DBI;
+ out->name = "rfbi";
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 62b5374..0802927 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -278,6 +278,7 @@ static void __init sdi_init_output(struct platform_device
*pdev)
out->pdev = pdev;
out->id = OMAP_DSS_OUTPUT_SDI;
out->type = OMAP_DISPLAY_TYPE_SDI;
+ out->name = "sdi";
dss_register_output(out);
}
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 006caf3..c8130f8 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -819,6 +819,7 @@ static void __init venc_init_output(struct platform_device
*pdev)
out->pdev = pdev;
out->id = OMAP_DSS_OUTPUT_VENC;
out->type = OMAP_DISPLAY_TYPE_VENC;
+ out->name = "venc";
dss_register_output(out);
}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 2cb2b0e..ba9cea7 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -541,6 +541,9 @@ struct omap_dss_writeback_info {
struct omap_dss_output {
struct list_head list;
+ /* name of the output for debug */
+ const char *name;
+
/* display type supported by the output */
enum omap_display_type type;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/20] OMAPDSS: remove dssdev->channel assignments
Now that the driver uses ooutput->recommended_channel, we can remove the
uses of the hacky dssdev->channel field.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c |2 --
drivers/video/omap2/dss/dsi.c |2 --
drivers/video/omap2/dss/hdmi.c |2 --
drivers/video/omap2/dss/rfbi.c |2 --
drivers/video/omap2/dss/sdi.c |2 --
drivers/video/omap2/dss/venc.c |2 --
6 files changed, 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index eba6b87..775214c 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -432,8 +432,6 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
DSSDBG("init_display\n");
- dssdev->channel = dpi_get_channel();
-
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
dpi.vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index e0c9e31..f44316a 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5000,8 +5000,6 @@ static int __init dsi_init_display(struct omap_dss_device
*dssdev)
DSSDBG("DSI init\n");
- dssdev->channel = dsi_get_channel(dsi->module_id);
-
if (dsi->vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index e4c3be4..a49e73f 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1012,8 +1012,6 @@ static void __init hdmi_probe_pdata(struct
platform_device *pdev)
hdmi.ls_oe_gpio = priv->ls_oe_gpio;
hdmi.hpd_gpio = priv->hpd_gpio;
- dssdev->channel = OMAP_DSS_CHANNEL_DIGIT;
-
r = hdmi_init_display(dssdev);
if (r) {
DSSERR("device %s init failed: %d\n", dssdev->name, r);
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 991ec93..48d51ca 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -945,8 +945,6 @@ EXPORT_SYMBOL(omapdss_rfbi_display_disable);
static int __init rfbi_init_display(struct omap_dss_device *dssdev)
{
- dssdev->channel = OMAP_DSS_CHANNEL_LCD;
-
rfbi.dssdev[dssdev->phy.rfbi.channel] = dssdev;
return 0;
}
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index c797b33..eb4ee17 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -186,8 +186,6 @@ static int __init sdi_init_display(struct omap_dss_device
*dssdev)
{
DSSDBG("SDI init\n");
- dssdev->channel = OMAP_DSS_CHANNEL_LCD;
-
if (sdi.vdds_sdi_reg == NULL) {
struct regulator *vdds_sdi;
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index b85fd3d..6d25a12 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -786,8 +786,6 @@ static void __init venc_probe_pdata(struct platform_device
*vencdev)
dss_copy_device_pdata(dssdev, plat_dssdev);
- dssdev->channel = OMAP_DSS_CHANNEL_DIGIT;
-
r = venc_init_display(dssdev);
if (r) {
DSSERR("device %s init failed: %d\n", dssdev->name, r);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/20] OMAPDSS: omapdss.h: remove channel field from omap_dss_device (LATER)
Signed-off-by: Tomi Valkeinen
---
include/video/omapdss.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 8647646..cd028c8 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -567,8 +567,6 @@ struct omap_dss_device {
enum omap_display_type type;
- enum omap_channel channel;
-
union {
struct {
u8 data_lines;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/20] OMAPDSS: DPI: use output->recommended_channel
Use output's recommended_channel instead of dssdev->channel in DPI
driver.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index fb38019..eba6b87 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -448,7 +448,7 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
dpi.vdds_dsi_reg = vdds_dsi;
}
- dsidev = dpi_get_dsidev(dssdev->channel);
+ dsidev = dpi_get_dsidev(dpi.output.recommended_channel);
if (dsidev && dpi_verify_dsi_pll(dsidev)) {
dsidev = NULL;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/20] OMAPFB: use output->recommended_channel
Use output's recommended_channel instead of dssdev->channel in OMAPFB driver. Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/omapfb/omapfb-main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index ca585ef..24f159e 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -2388,7 +2388,7 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev, struct omap_dss_device *dssdev = fbdev->displays[i].dssdev; struct omap_dss_output *out = dssdev->output; - mgr = omap_dss_get_overlay_manager(dssdev->channel); + mgr = omap_dss_get_overlay_manager(out->recommended_channel); if (!mgr || !out) continue; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/20] OMAPDSS: Resolve channels for outputs
The DISPC channel used for each output is currently passed in panel
platform data from the board files.
To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 37 ++-
drivers/video/omap2/dss/dsi.c | 48
drivers/video/omap2/dss/rfbi.c |2 ++
drivers/video/omap2/dss/sdi.c |2 ++
4 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e282456..3261644 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
platform_device *dsidev)
return 0;
}
+/*
+ * Return a hardcoded channel for the DPI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dpi_get_channel(void)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ case OMAPDSS_VER_OMAP5:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ default:
+ DSSWARN("unsupported DSS version\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+}
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev;
DSSDBG("init_display\n");
+ dssdev->channel = dpi_get_channel();
+
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
dpi.vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
@@ -416,11 +448,6 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
dpi.vdds_dsi_reg = vdds_dsi;
}
- /*
-* XXX We shouldn't need dssdev->channel for this. The dsi pll clock
-* source for DPI is SoC integration detail, not something that should
-* be configured in the dssdev
-*/
dsidev = dpi_get_dsidev(dssdev->channel);
if (dsidev && dpi_verify_dsi_pll(dsidev)) {
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1a6ad6f..c39ca86 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct
omap_dss_device *dssdev,
}
EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
+/*
+ * Return a hardcoded channel for the DSI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dsi_get_channel(int module_id)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ switch (module_id) {
+ case 0:
+ return OMAP_DSS_CHANNEL_LCD;
+ case 1:
+ return OMAP_DSS_CHANNEL_LCD2;
+ default:
+ DSSWARN("unsupported module id\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+
+ case OMAPDSS_VER_OMAP5:
+ switch (module_id) {
+ case 0:
+ return OMAP_DSS_CHANNEL_LCD;
+ case 1:
+ return OMAP_DSS_CHANNEL_LCD3;
+ default:
+ DSSWARN("unsupported module id\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+
+ default:
+ DSSWARN("unsupported DSS version\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+}
+
static int __init dsi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev =
@@ -4954,6 +5000,8 @@ static int __init dsi_init_display(struct omap_dss_device
*dssdev)
DSSDBG("DSI init\n");
+ dssdev->channel = dsi_get_channel(dsi->module_id);
+
if (dsi->vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
diff --git a/drivers/video/omap2/d
[PATCH 08/20] OMAPDSS: HDMI: init output earlier
Move hdmi driver's output initialization a bit earlier, so that it
happens before hdmi panel init. In the future the hdmi panel will depend
on the output being ready.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/hdmi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index e5682ae..f3768d0 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1094,6 +1094,8 @@ static int __init omapdss_hdmihw_probe(struct
platform_device *pdev)
hdmi.ip_data.pll_offset = HDMI_PLLCTRL;
hdmi.ip_data.phy_offset = HDMI_PHY;
+ hdmi_init_output(pdev);
+
r = hdmi_panel_init();
if (r) {
DSSERR("can't init panel\n");
@@ -1102,8 +1104,6 @@ static int __init omapdss_hdmihw_probe(struct
platform_device *pdev)
dss_debugfs_create_file("hdmi", hdmi_dump_regs);
- hdmi_init_output(pdev);
-
hdmi_probe_pdata(pdev);
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/20] OMAPDSS: Taal: remove multi-panel support
Taal panel driver was originally meant to support multiple different DSI
command mode panel models. This never realized, and the multi-panel
support code is lying there unused, making the driver more difficult to
maintain.
This patch removes the multi-panel support from Taal driver.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/panel-taal.c | 109 -
1 file changed, 15 insertions(+), 94 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index a32407a..038a815 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -54,61 +54,6 @@ static int _taal_enable_te(struct omap_dss_device *dssdev,
bool enable);
static int taal_panel_reset(struct omap_dss_device *dssdev);
-/**
- * struct panel_config - panel configuration
- * @name: panel name
- * @type: panel type
- * @timings: panel resolution
- * @sleep: various panel specific delays, passed to msleep() if non-zero
- * @reset_sequence: reset sequence timings, passed to udelay() if non-zero
- * @regulators: array of panel regulators
- * @num_regulators: number of regulators in the array
- */
-struct panel_config {
- const char *name;
- int type;
-
- struct omap_video_timings timings;
-
- struct {
- unsigned int sleep_in;
- unsigned int sleep_out;
- unsigned int hw_reset;
- unsigned int enable_te;
- } sleep;
-
- struct {
- unsigned int high;
- unsigned int low;
- } reset_sequence;
-
-};
-
-enum {
- PANEL_TAAL,
-};
-
-static struct panel_config panel_configs[] = {
- {
- .name = "taal",
- .type = PANEL_TAAL,
- .timings= {
- .x_res = 864,
- .y_res = 480,
- },
- .sleep = {
- .sleep_in = 5,
- .sleep_out = 5,
- .hw_reset = 5,
- .enable_te = 100, /* possible panel bug */
- },
- .reset_sequence = {
- .high = 10,
- .low= 10,
- },
- },
-};
-
struct taal_data {
struct mutex lock;
@@ -121,9 +66,6 @@ struct taal_data {
struct omap_dss_device *dssdev;
- /* panel specific HW info */
- struct panel_config *panel_config;
-
/* panel HW configuration from DT or platform data */
int reset_gpio;
int ext_te_gpio;
@@ -221,8 +163,7 @@ static int taal_sleep_in(struct taal_data *td)
hw_guard_start(td, 120);
- if (td->panel_config->sleep.sleep_in)
- msleep(td->panel_config->sleep.sleep_in);
+ msleep(5);
return 0;
}
@@ -239,8 +180,7 @@ static int taal_sleep_out(struct taal_data *td)
hw_guard_start(td, 120);
- if (td->panel_config->sleep.sleep_out)
- msleep(td->panel_config->sleep.sleep_out);
+ msleep(5);
return 0;
}
@@ -845,17 +785,14 @@ static void taal_hw_reset(struct omap_dss_device *dssdev)
return;
gpio_set_value(td->reset_gpio, 1);
- if (td->panel_config->reset_sequence.high)
- udelay(td->panel_config->reset_sequence.high);
+ udelay(10);
/* reset the panel */
gpio_set_value(td->reset_gpio, 0);
/* assert reset */
- if (td->panel_config->reset_sequence.low)
- udelay(td->panel_config->reset_sequence.low);
+ udelay(10);
gpio_set_value(td->reset_gpio, 1);
/* wait after releasing reset */
- if (td->panel_config->sleep.hw_reset)
- msleep(td->panel_config->sleep.hw_reset);
+ msleep(5);
}
static void taal_probe_pdata(struct taal_data *td,
@@ -881,8 +818,7 @@ static int taal_probe(struct omap_dss_device *dssdev)
struct backlight_properties props;
struct taal_data *td;
struct backlight_device *bldev = NULL;
- int r, i;
- const char *panel_name;
+ int r;
dev_dbg(&dssdev->dev, "probe\n");
@@ -897,26 +833,12 @@ static int taal_probe(struct omap_dss_device *dssdev)
const struct nokia_dsi_panel_data *pdata = dssdev->data;
taal_probe_pdata(td, pdata);
-
- panel_name = pdata->name;
} else {
return -ENODEV;
}
- if (panel_name == NULL)
- return -EINVAL;
-
- for (i = 0; i < ARRAY_SIZE(panel_configs); i++) {
- if (strcmp(panel_name, panel_configs[i].name) == 0) {
- td->panel_config = &panel_configs[i];
- break;
- }
- }
-
- if (!td->panel_config)
- return -EINVAL;
-
-
[PATCH 07/20] OMAPDSS: add missing export for omap_dss_get_output()
omap_dss_get_output() is a public function, but was missing EXPORT_SYMBOL(). Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/dss/output.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/omap2/dss/output.c b/drivers/video/omap2/dss/output.c index 79dea1a..5214df6 100644 --- a/drivers/video/omap2/dss/output.c +++ b/drivers/video/omap2/dss/output.c @@ -113,6 +113,7 @@ struct omap_dss_output *omap_dss_get_output(enum omap_dss_output_id id) return NULL; } +EXPORT_SYMBOL(omap_dss_get_output); static const struct dss_mgr_ops *dss_mgr_ops; -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/20] OMAPDSS: HDMI: remove HDMI clk divisors from dssdev
struct omap_dss_device contains HDMI clock divisors. The idea is that the
board file can pass precalculated divisors to the display driver.
However, these divsors are no longer needed, as the omapdss driver can
calculate the divisors during runtime.
This patch removes the divisors from omap_dss_device, and their uses
from the hdmi driver.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/hdmi.c | 11 +++
include/video/omapdss.h|8
2 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 769d082..e5682ae 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -472,17 +472,12 @@ static void hdmi_compute_pll(struct omap_dss_device
*dssdev, int phy,
* Input clock is predivided by N + 1
* out put of which is reference clk
*/
- if (dssdev->clocks.hdmi.regn == 0)
- pi->regn = HDMI_DEFAULT_REGN;
- else
- pi->regn = dssdev->clocks.hdmi.regn;
+
+ pi->regn = HDMI_DEFAULT_REGN;
refclk = clkin / pi->regn;
- if (dssdev->clocks.hdmi.regm2 == 0)
- pi->regm2 = HDMI_DEFAULT_REGM2;
- else
- pi->regm2 = dssdev->clocks.hdmi.regm2;
+ pi->regm2 = HDMI_DEFAULT_REGM2;
/*
* multiplier is pixel_clk/ref_clk
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 255bcf5..2cb2b0e 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -591,14 +591,6 @@ struct omap_dss_device {
} phy;
struct {
- struct {
- /* regn is one greater than TRM's REGN value */
- u16 regn;
- u16 regm2;
- } hdmi;
- } clocks;
-
- struct {
struct omap_video_timings timings;
enum omap_dss_dsi_pixel_format dsi_pix_fmt;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/20] OMAPDSS: DSI: remove DSI & DISPC clk divisors from dssdev
struct omap_dss_device contains DSS clock divisors. The idea is that the
board file can pass precalculated divisors to the display driver.
However, these divsors are no longer needed, as the omapdss driver can
calculate the divisors during runtime.
This patch removes the divisors from omap_dss_device, and their uses
from the dsi driver.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c | 47 +++--
include/video/omapdss.h | 21 --
2 files changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 28d41d1..9eb7845 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -261,6 +261,13 @@ struct dsi_data {
struct clk *dss_clk;
struct clk *sys_clk;
+ struct dispc_clock_info user_dispc_cinfo;
+ struct dsi_clock_info user_dsi_cinfo;
+
+ enum omap_dss_clk_source user_dispc_fclk_src;
+ enum omap_dss_clk_source user_lcd_clk_src;
+ enum omap_dss_clk_source user_dsi_fclk_src;
+
struct dsi_clock_info current_cinfo;
bool vdds_dsi_enabled;
@@ -1200,7 +1207,7 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device
*dssdev)
unsigned lp_clk_div;
unsigned long lp_clk;
- lp_clk_div = dssdev->clocks.dsi.lp_clk_div;
+ lp_clk_div = dsi->user_dsi_cinfo.lp_clk_div;
if (lp_clk_div == 0 || lp_clk_div > dsi->lpdiv_max)
return -EINVAL;
@@ -3910,7 +3917,7 @@ static void dsi_config_cmd_mode_interleaving(struct
omap_dss_device *dssdev)
struct omap_video_timings *timings = &dsi->timings;
int bpp = dsi_get_pixel_size(dsi->pix_fmt);
int ndl = dsi->num_lanes_used - 1;
- int dsi_fclk_hsdiv = dssdev->clocks.dsi.regm_dsi + 1;
+ int dsi_fclk_hsdiv = dsi->user_dsi_cinfo.regm_dsi + 1;
int hsa_interleave_hs = 0, hsa_interleave_lp = 0;
int hfp_interleave_hs = 0, hfp_interleave_lp = 0;
int hbp_interleave_hs = 0, hbp_interleave_lp = 0;
@@ -4302,24 +4309,24 @@ int omapdss_dsi_set_clocks(struct omap_dss_device
*dssdev,
dsi_fclk = cinfo.dsi_pll_hsdiv_dsi_clk;
lp_clk_div = DIV_ROUND_UP(dsi_fclk, lp_clk * 2);
- dssdev->clocks.dsi.regn = cinfo.regn;
- dssdev->clocks.dsi.regm = cinfo.regm;
- dssdev->clocks.dsi.regm_dispc = cinfo.regm_dispc;
- dssdev->clocks.dsi.regm_dsi = cinfo.regm_dsi;
+ dsi->user_dsi_cinfo.regn = cinfo.regn;
+ dsi->user_dsi_cinfo.regm = cinfo.regm;
+ dsi->user_dsi_cinfo.regm_dispc = cinfo.regm_dispc;
+ dsi->user_dsi_cinfo.regm_dsi = cinfo.regm_dsi;
- dssdev->clocks.dsi.lp_clk_div = lp_clk_div;
+ dsi->user_dsi_cinfo.lp_clk_div = lp_clk_div;
- dssdev->clocks.dispc.channel.lck_div = dispc_cinfo.lck_div;
- dssdev->clocks.dispc.channel.pck_div = dispc_cinfo.pck_div;
+ dsi->user_dispc_cinfo.lck_div = dispc_cinfo.lck_div;
+ dsi->user_dispc_cinfo.pck_div = dispc_cinfo.pck_div;
- dssdev->clocks.dispc.dispc_fclk_src = OMAP_DSS_CLK_SRC_FCK;
+ dsi->user_dispc_fclk_src = OMAP_DSS_CLK_SRC_FCK;
- dssdev->clocks.dispc.channel.lcd_clk_src =
+ dsi->user_lcd_clk_src =
dsi->module_id == 0 ?
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC :
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC;
- dssdev->clocks.dsi.dsi_fclk_src =
+ dsi->user_dsi_fclk_src =
dsi->module_id == 0 ?
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI :
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI;
@@ -4589,8 +4596,8 @@ static int dsi_configure_dispc_clocks(struct
omap_dss_device *dssdev)
fck = dsi_get_pll_hsdiv_dispc_rate(dsidev);
- dispc_cinfo.lck_div = dssdev->clocks.dispc.channel.lck_div;
- dispc_cinfo.pck_div = dssdev->clocks.dispc.channel.pck_div;
+ dispc_cinfo.lck_div = dsi->user_dispc_cinfo.lck_div;
+ dispc_cinfo.pck_div = dsi->user_dispc_cinfo.pck_div;
r = dispc_calc_clock_rates(fck, &dispc_cinfo);
if (r) {
@@ -4679,13 +4686,12 @@ static void dsi_display_uninit_dispc(struct
omap_dss_device *dssdev)
static int dsi_configure_dsi_clocks(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct dsi_clock_info cinfo;
int r;
- cinfo.regn = dssdev->clocks.dsi.regn;
- cinfo.regm = dssdev->clocks.dsi.regm;
- cinfo.regm_dispc = dssdev->clocks.dsi.regm_dispc;
- cinfo.regm_dsi = dssdev->clocks.dsi.regm_dsi;
+ cinfo = dsi->user_dsi_cinfo;
+
r = dsi_calc_clock_rates(dsidev, &cinfo);
if (r) {
DSSERR("Failed to calc dsi clocks\n");
@@ -4716,9 +4722,8 @@ static int dsi_display_init_dsi(struct omap_dss_device
*dssdev)
if (r)
goto err1;
- dss_select_dsi_clk_sourc
[PATCH 03/20] OMAPDSS: DPI: remove omap_dss_device uses
The role of struct omap_dss_device will change in the future. The exact
details of that are still a bit unclear. However, the less uses of
omap_dss_device we have, the easier the change is in the future.
This patch removes uses of omap_dss_device from dpi.c, where it can be
done neatly, by, for example, passing some lower level parameter in
function parameters.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 35 +++
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 4af136a..cb6b280 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -91,11 +91,10 @@ static enum omap_dss_clk_source dpi_get_alt_clk_src(enum
omap_channel channel)
}
}
-static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
+static int dpi_set_dsi_clk(enum omap_channel channel,
unsigned long pck_req, unsigned long *fck, int *lck_div,
int *pck_div)
{
- struct omap_overlay_manager *mgr = dssdev->output->manager;
struct dsi_clock_info dsi_cinfo;
struct dispc_clock_info dispc_cinfo;
int r;
@@ -109,8 +108,8 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
if (r)
return r;
- dss_select_lcd_clk_source(mgr->id,
- dpi_get_alt_clk_src(mgr->id));
+ dss_select_lcd_clk_source(channel,
+ dpi_get_alt_clk_src(channel));
dpi.mgr_config.clock_info = dispc_cinfo;
@@ -121,9 +120,8 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
return 0;
}
-static int dpi_set_dispc_clk(struct omap_dss_device *dssdev,
- unsigned long pck_req, unsigned long *fck, int *lck_div,
- int *pck_div)
+static int dpi_set_dispc_clk(unsigned long pck_req, unsigned long *fck,
+ int *lck_div, int *pck_div)
{
struct dss_clock_info dss_cinfo;
struct dispc_clock_info dispc_cinfo;
@@ -146,20 +144,19 @@ static int dpi_set_dispc_clk(struct omap_dss_device
*dssdev,
return 0;
}
-static int dpi_set_mode(struct omap_dss_device *dssdev)
+static int dpi_set_mode(struct omap_overlay_manager *mgr)
{
struct omap_video_timings *t = &dpi.timings;
- struct omap_overlay_manager *mgr = dssdev->output->manager;
int lck_div = 0, pck_div = 0;
unsigned long fck = 0;
unsigned long pck;
int r = 0;
if (dpi.dsidev)
- r = dpi_set_dsi_clk(dssdev, t->pixel_clock * 1000, &fck,
+ r = dpi_set_dsi_clk(mgr->id, t->pixel_clock * 1000, &fck,
&lck_div, &pck_div);
else
- r = dpi_set_dispc_clk(dssdev, t->pixel_clock * 1000, &fck,
+ r = dpi_set_dispc_clk(t->pixel_clock * 1000, &fck,
&lck_div, &pck_div);
if (r)
return r;
@@ -179,10 +176,8 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
return 0;
}
-static void dpi_config_lcd_manager(struct omap_dss_device *dssdev)
+static void dpi_config_lcd_manager(struct omap_overlay_manager *mgr)
{
- struct omap_overlay_manager *mgr = dssdev->output->manager;
-
dpi.mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
dpi.mgr_config.stallmode = false;
@@ -197,7 +192,7 @@ static void dpi_config_lcd_manager(struct omap_dss_device
*dssdev)
int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
{
- struct omap_dss_output *out = dssdev->output;
+ struct omap_dss_output *out = &dpi.output;
int r;
mutex_lock(&dpi.lock);
@@ -230,7 +225,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_get_dispc;
- r = dss_dpi_select_source(dssdev->channel);
+ r = dss_dpi_select_source(out->manager->id);
if (r)
goto err_src_sel;
@@ -244,11 +239,11 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
goto err_dsi_pll_init;
}
- r = dpi_set_mode(dssdev);
+ r = dpi_set_mode(out->manager);
if (r)
goto err_set_mode;
- dpi_config_lcd_manager(dssdev);
+ dpi_config_lcd_manager(out->manager);
mdelay(2);
@@ -285,7 +280,7 @@ EXPORT_SYMBOL(omapdss_dpi_display_enable);
void omapdss_dpi_display_disable(struct omap_dss_device *dssdev)
{
- struct omap_overlay_manager *mgr = dssdev->output->manager;
+ struct omap_overlay_manager *mgr = dpi.output.manager;
mutex_lock(&dpi.lock);
@@ -325,7 +320,7 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
int r;
- struct omap_overlay_manager *mgr = dssdev->output->manager;
+ struct omap_overlay_manager *mgr = dpi.output.manager;
int lck_div, pck_di
[PATCH 00/20] OMAPDSS: misc improvements
Hi, Here are a bunch of misc patches, created when working on improving DSS device model. Most notable is the recommended_channel stuff, which removes the need to pass LCD channel from the board file, which has been rather problematic. Two of the patches are marked LATER, as they affect the board files. They're pure cleanups, and can be sent after the rest are merged. Tomi Tomi Valkeinen (20): OMAPDSS: DSI: remove DSI & DISPC clk divisors from dssdev OMAPDSS: HDMI: remove HDMI clk divisors from dssdev OMAPDSS: DPI: remove omap_dss_device uses OMAPDSS: DSI: remove omap_dss_device uses OMAPDSS: Taal: remove multi-panel support OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync OMAPDSS: add missing export for omap_dss_get_output() OMAPDSS: HDMI: init output earlier OMAPDSS: add output->name OMAPDSS: Resolve channels for outputs OMAPDSS: add output->recommended_channel OMAPDSS: DPI: use output->recommended_channel OMAPFB: use output->recommended_channel OMAPDSS: remove dssdev->channel assignments OMAP: dss-common.c: remove uses of dss channel (LATER) OMAPDSS: omapdss.h: remove channel field from omap_dss_device (LATER) OMAPDSS: add pdata->default_display_name OMAPDSS: DSI: delay dispc initialization OMAPDSS: DSI: fix DSI channel source initialization OMAPDSS: Taal: remove rotate & mirror support arch/arm/mach-omap2/dss-common.c |6 - drivers/video/omap2/displays/panel-taal.c | 279 ++--- drivers/video/omap2/dss/apply.c | 15 +- drivers/video/omap2/dss/core.c|2 + drivers/video/omap2/dss/dpi.c | 74 +--- drivers/video/omap2/dss/dsi.c | 219 +- drivers/video/omap2/dss/hdmi.c| 19 +- drivers/video/omap2/dss/output.c |1 + drivers/video/omap2/dss/rfbi.c|2 + drivers/video/omap2/dss/sdi.c |2 + drivers/video/omap2/dss/venc.c|4 +- drivers/video/omap2/omapfb/omapfb-main.c |2 +- include/video/omapdss.h | 38 +--- 13 files changed, 235 insertions(+), 428 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] usb: phy: nop: Add device tree support and binding information
On 02/04/2013 04:58 PM, Roger Quadros wrote:
> The PHY clock, clock rate, VCC regulator and RESET regulator
> can now be provided via device tree.
>
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
>
> drivers/usb/otg/nop-usb-xceiv.c| 31 ++
> 2 files changed, 65 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> new file mode 100644
> index 000..d7e2726
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> @@ -0,0 +1,34 @@
> +USB NOP PHY
> +
> +Required properties:
> +- compatible: should be usb-nop-xceiv
> +
> +Optional properties:
> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
> + /bindings/clock/clock-bindings.txt
> + This property is required if clock-frequency is specified.
> +
> +- clock-names: Should be "main_clk"
> +
> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
> + be configured to.
> +
> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
> +
> +- reset-supply: phandle to the regulator that provides power to the PHY.
> +
> +Example:
> +
> + hsusb1_phy {
> + compatible = "usb-nop-xceiv";
> + clock-frequency = <1920>;
Why do you hardcode the clock frequency here? You should use
clk_get_rate() to get the frequency from the clock tree.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
[PATCH] ARM: OMAP: drop "select MACH_NOKIA_RM696"
When support was added for Nokia N9 (RM-696), with commit
63fc5f3bb3d0ca9ab4767a801b518aa6335f87ad ("ARM: OMAP: add minimal
support for Nokia RM-696"), a select statement for MACH_NOKIA_RM696 was
added to the tree. But there's no Kconfig symbol with that name. That
symbol would be superfluous, since support for that machine piggybacks
on MACH_NOKIA_RM680. So drop that select.
Signed-off-by: Paul Bolle
---
0) Tested with "git grep".
1) Some searching on the web didn't return a "config MACH_NOKIA_RM696".
So apparently there's not even a development tree that uses this symbol.
arch/arm/mach-omap2/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 49ac3df..5cafa77 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -296,7 +296,6 @@ config MACH_NOKIA_RM680
bool "Nokia N950 (RM-680) / N9 (RM-696) phones"
depends on ARCH_OMAP3
default y
- select MACH_NOKIA_RM696
select OMAP_PACKAGE_CBB
config MACH_NOKIA_RX51
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ASoC: OMAP2+: Update Audio IP with sDMA binding for DT boot
On 03/08/2013 08:25 AM, Jarkko Nikula wrote: >> The content of the patches looks about right for me, however I would >> squash together the IP and platform driver patches so we avoid breakage >> within the series. Also I would put the patch for the .dtsi files as >> first one. >> > Looks ok to me too at quick look. Would it be possible to avoid possible > breakage if first patch is divided to omap-pcm.h change which come before > audio link driver changes and do omap-pcm.c change last? If we have them as separate we will have runtime regression between the patches. It is better to have them squashed together. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
