* [PATCH] ARM-i.MX6Q-dts : Added USB_OTG Support
From: Ashutosh singh @ 2014-01-24 9:28 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for USB_OTG on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 22 ++++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 7d37ec6..39e69bd 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -32,3 +32,7 @@
&usdhc3 {
status = "okay";
};
+
+&usbotg {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index 1a3b50d..dcb1d59 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -18,6 +18,19 @@
memory {
reg = <0x10000000 0x80000000>;
};
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_usb_otg_vbus: usb_otg_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 15 0>;
+ enable-active-low;
+ };
+ };
};
&ecspi3 {
@@ -134,6 +147,7 @@
MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x80000000
MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000 /* SPI NOR chipselect */
MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x80000000 /* PMIC interrupt */
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x80000000 /* USB_OTG_PWR_EN */
>;
};
};
@@ -178,3 +192,11 @@
wp-gpios = <&gpio1 29 0>;
status = "disabled";
};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg_1>;
+ disable-over-current;
+ status = "disabled";
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Hanjun Guo @ 2014-01-24 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3140612.0s75qS6VKb@wuerfel>
On 2014?01?22? 22:56, Arnd Bergmann wrote:
> On Wednesday 22 January 2014 11:46:16 Mark Rutland wrote:
>> On Mon, Jan 20, 2014 at 09:08:32AM +0000, Hanjun Guo wrote:
>>> On 2014-1-17 22:21, Arnd Bergmann wrote:
>>>> On Friday 17 January 2014, Hanjun Guo wrote:
>>>>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>>>>
>>>>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
>>>>> name from the ACPI timer table is matched with all the registered
>>>>> timer controllers and matching initialisation routine is invoked.
>>>> I wouldn't anticipate this infrastructure to be required. Shouldn't all
>>>> ARMv8 machines have an architected timer?
>>> I not sure of this, could anyone can give some guidance? if only arch
>>> timer is available for ARM64, this will make thing very simple.
>> All ARMv8 systems should have an architected timer.
>>
>> However, they may also have other timers (e.g. global timers for use
>> when CPUs are in low power states and their local architected timers
>> aren't active).
> But all other timers could be regular platform drivers I suppose. No
> need for special infrastructure for those.
One more information, acpi_early_init() is run before timekeeping_init()
now, and that patch was merged into 3.14-rc1. So we can initialize
timers for scanning the DSDT table, and it also means that timer defined
in DSDT can be initialized early enough.
Thanks
Hanjun
^ permalink raw reply
* [Linaro-acpi] [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file
From: Hanjun Guo @ 2014-01-24 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E13BBC.5020005@linaro.org>
On 2014?01?23? 23:56, Tomasz Nowicki wrote:
> Hi Lorenzo,
>
> W dniu 22.01.2014 12:54, Lorenzo Pieralisi pisze:
>> On Fri, Jan 17, 2014 at 12:24:58PM +0000, Hanjun Guo wrote:
>>
>> [...]
>>
>>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>>> index bd9bbd0..2210353 100644
>>> --- a/arch/arm64/kernel/setup.c
>>> +++ b/arch/arm64/kernel/setup.c
>>> @@ -41,6 +41,7 @@
>>> #include <linux/memblock.h>
>>> #include <linux/of_fdt.h>
>>> #include <linux/of_platform.h>
>>> +#include <linux/acpi.h>
>>>
>>> #include <asm/cputype.h>
>>> #include <asm/elf.h>
>>> @@ -225,6 +226,11 @@ void __init setup_arch(char **cmdline_p)
>>>
>>> arm64_memblock_init();
>>>
>>> + /* Parse the ACPI tables for possible boot-time configuration */
>>> + acpi_boot_table_init();
>>> + early_acpi_boot_init();
>>> + acpi_boot_init();
>>> +
>>> paging_init();
>>
>> Can I ask you please why we need to parse ACPI tables before
>> paging_init() ?
> This is for future usage and because of couple of reasons. Mainly SRAT
> table parsing should be done (before paging_init()) for proper NUMA
> initialization and then paging_init().
Yes, I agree, thanks for Tomasz's clarification.
>>
>> [...]
>>
>>> +/*
>>> + * __acpi_map_table() will be called before page_init(), so
>>> early_ioremap()
>>> + * or early_memremap() should be called here.
>>
>> Again, why is this needed ? What's needed before paging_init() from
>> ACPI ?
>>
>> [...]
>>
>>> +/*
>>> + * acpi_boot_table_init() and acpi_boot_init()
>>> + * called from setup_arch(), always.
>>> + * 1. checksums all tables
>>> + * 2. enumerates lapics
>>> + * 3. enumerates io-apics
>>> + *
>>> + * acpi_table_init() is separated to allow reading SRAT without
>>> + * other side effects.
>>> + */
>>> +void __init acpi_boot_table_init(void)
>>> +{
>>> + /*
>>> + * If acpi_disabled, bail out
>>> + */
>>> + if (acpi_disabled)
>>> + return;
>>> +
>>> + /*
>>> + * Initialize the ACPI boot-time table parser.
>>> + */
>>> + if (acpi_table_init()) {
>>> + disable_acpi();
>>> + return;
>>> + }
>>> +}
>>> +
>>> +int __init early_acpi_boot_init(void)
>>> +{
>>> + /*
>>> + * If acpi_disabled, bail out
>>> + */
>>> + if (acpi_disabled)
>>> + return -ENODEV;
>>> +
>>> + /*
>>> + * Process the Multiple APIC Description Table (MADT), if present
>>> + */
>>> + early_acpi_process_madt();
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +int __init acpi_boot_init(void)
>>> +{
>>> + /*
>>> + * If acpi_disabled, bail out
>>> + */
>>> + if (acpi_disabled)
>>> + return -ENODEV;
>>> +
>>> + acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
>>> +
>>> + /*
>>> + * Process the Multiple APIC Description Table (MADT), if present
>>> + */
>>> + acpi_process_madt();
>>> +
>>> + return 0;
>>> +}
>>
>> Well, apart from having three init calls, one returning void and two
>> returning proper values, do not understand why, and do not understand
>> why we need three calls in the first place...why should we process MADT
>> twice in two separate calls ? What is supposed to change in between that
>> prevents you from merging the two together ?
Thanks for pointing this out. I can merge acpi_boot_table_init() and
early_acpi_boot_init() together, but can not merge early_acpi_boot_init()
and acpi_boot_init() together.
early_acpi_boot_init() and acpi_boot_init() was separated intentionally for
memory hotplug reasons. memory allocated in this stage can not be migrated
and cause memory hot-remove failed, in order to keep memory allocated
at base node (general NUMA node 0 in the system) at boot stage, we should
parse SRAT first before CPU is enumerated, does this make sense to you?
Thanks
Hanjun
^ permalink raw reply
* [PATCH 2/2] clk: exynos4: Fix spacing related checkpatch errors
From: Sachin Kamat @ 2014-01-24 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD1182.80200@samsung.com>
Hi Tomasz,
On 20 January 2014 17:37, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Sachin,
>
>
> On 15.01.2014 11:01, Sachin Kamat wrote:
>>
>> Silences the following type of checkpatch errors:
>> ERROR: space prohibited after that open parenthesis '('
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> ---
>> drivers/clk/samsung/clk-exynos4.c | 50
>> ++++++++++++++++++-------------------
>> 1 file changed, 25 insertions(+), 25 deletions(-)
>
>
> I believe this is a false warning. In this special case the spaces greatly
> improve readability of static data in the driver, which I believe is
> preferred over the strict rules of checkpatch.
I agree that the existing pattern looks good to eyes :)
But then you will keep getting many such fix patches. The intention was to
bring this to your notice.
What say about the other patch in this series?
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Hiremath, Vaibhav @ 2014-01-24 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0333F.4000400@gmail.com>
> -----Original Message-----
> From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov.75 at gmail.com]
> Sent: Thursday, January 23, 2014 2:38 AM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> fbdev at vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
>
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
>
Link seems to be coming blank to me :)
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Vincent Guittot @ 2014-01-24 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122192041.GA3709@e102568-lin.cambridge.arm.com>
On 22 January 2014 20:20, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> Hi Vincent,
>
> On Tue, Jan 21, 2014 at 11:16:46AM +0000, Vincent Guittot wrote:
>> Hi Lorenzo,
>>
>> On 20 January 2014 18:47, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> > ARM based platforms implement a variety of power management schemes that
>> > allow processors to enter at run-time low-power states, aka C-states
>> > in ACPI jargon. The parameters defining these C-states vary on a per-platform
>> > basis forcing the OS to hardcode the state parameters in platform
>> > specific static tables whose size grows as the number of platforms supported
>> > in the kernel increases and hampers device drivers standardization.
>> >
>> > Therefore, this patch aims at standardizing C-state device tree bindings for
>> > ARM platforms. Bindings define C-state parameters inclusive of entry methods
>> > and state latencies, to allow operating systems to retrieve the
>> > configuration entries from the device tree and initialize the related
>> > power management drivers, paving the way for common code in the kernel
>> > to deal with power states and removing the need for static data in current
>> > and previous kernel versions.
>> >
>> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> > ---
>> > Documentation/devicetree/bindings/arm/c-states.txt | 774 +++++++++++++++++++++
>> > Documentation/devicetree/bindings/arm/cpus.txt | 10 +
>> > 2 files changed, 784 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/arm/c-states.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/arm/c-states.txt b/Documentation/devicetree/bindings/arm/c-states.txt
>> > new file mode 100644
>> > index 0000000..0b5617b
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/arm/c-states.txt
>> > @@ -0,0 +1,774 @@
>> > +==========================================
>> > +ARM C-states binding description
>> > +==========================================
>> > +
>> > +==========================================
>> > +1 - Introduction
>> > +==========================================
>> > +
>> > +ARM systems contain HW capable of managing power consumption dynamically,
>> > +where cores can be put in different low-power states (ranging from simple
>> > +wfi to power gating) according to OSPM policies. Borrowing concepts
>> > +from the ACPI specification[1], the CPU states representing the range of
>> > +dynamic states that a processor can enter at run-time, aka C-state, can be
>> > +specified through device tree bindings representing the parameters required to
>> > +enter/exit specific C-states on a given processor.
>> > +
>> > +The state an ARM CPU can be put into is loosely identified by one of the
>> > +following operating modes:
>> > +
>> > +- Running:
>> > + # Processor core is executing instructions
>> > +
>> > +- Wait for Interrupt:
>> > + # An ARM processor enters wait for interrupt (WFI) low power
>> > + state by executing a wfi instruction. When a processor enters
>> > + wfi state it disables most of the clocks while keeping the processor
>> > + powered up. This state is standard on all ARM processors and it is
>> > + defined as C1 in the remainder of this document.
>> > +
>>
>> > +- Dormant:
>> > + # Dormant mode is entered by executing wfi instructions and by sending
>> > + platform specific commands to the platform power controller (coupled
>> > + with processor specific SW/HW control sequences).
>> > + In dormant mode, most of the processor control and debug logic is
>> > + powered up but cache RAM can be put in retention state, providing
>>
>> Base on your description, it's not clear for me what is on, what is
>> lost and what is power down ?
>> My understand of the dormant mode that you described above is : the
>> cache is preserved (and especially the cache RAM) but the processor
>> state is lost (registers ...). Do I understand correctly ?
>>
>> What about retention mode where the contents of processor and cache
>> are preserved but the power consumption is reduced ? it can be seen as
>> a special wfi mode which need specific SW/HW control sequences but i'm
>> not sure to understand how to describe such state with your proposal.
>
Hi Lorenzo,
Sorry for the late reply,
> I had an idea. To simplify things, I think that one possibility is to
> add a parameter to the power domain specifier (platform specific, see
> Tomasz bindings):
We can't use a simple boolean state (on/off) for defining the
powerdomain state associated to a c-state so your proposal of being
able to add a parameter that will define the power domain state is
interesting.
>
> Documentation/devicetree/bindings/power/power_domain.txt
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/224928.html
>
> to represent, when that state is entered the behavior of the power
> controller (ie cache RAM retention or cache shutdown or in general any
> substate within a power domain). Since it is platform specific, and since
> we are able to link caches to the power domain, the power controller will
> actually define what happens to the cache when that state is entered
> (basically we use the power domain specifier additional parameter to define
> a "substate" in that power domain e.g.:
>
> Example:
>
> foo_power_controller {
> [...]
> /*
> * first cell is register index, second one is the state index
> * that in turn implies the state behavior - eg cache lost or
> * retained
> */
> #power-domain-cells = <2>;
> };
>
> l1-cache {
> [...]
> /*
> * syntax: power-domains = list of power domain specifiers
> <[&power_domain_phandle register-index state],[&power_domain_phandle register-index state]>;
> The syntax is defined by the power controller du jour
> as described by Tomasz bindings
> */
> power-domains =<&foo_power_controller 0 0 &foo_power_controller 0 1>;
Normally, power-domains describes a list of power domain specifiers
that are necessary for the l1-cache to at least retain its state so
i'm not sure understand your example above
If we take the example of system that support running, retention and
powerdown state described as state 0, 1 and 2 for the power domain, i
would have set the l1-cache like:
power-domains =<&foo_power_controller 0 1>;
for saying that the state is retained up to state 1
Please look below, i have modified the rest of your example accordingly
>
> }:
>
> and then
>
> state0 {
> index = <2>;
> compatible = "arm,cpu-power-state";
> latency = <...>;
> /*
> * This means that when the state is entered, the power
> * controller should use register index 0 and state 0,
> * whose meaning is power controller specific. Since we
> * know all components affected (for every component
> * we declare its power domain(s) and states so we
> * know what components are affected by the state entry.
> * Given the cache node above and this phandle, the state
> * implies that the cache is retained, register index == 0 state == 0
> /*
> power-domain =<&foo_power_controller 0 0>;
for retention state we need to set the power domain in state 1
power-domain =<&foo_power_controller 0 1>;
> };
>
> state1 {
> index = <3>;
> compatible = "arm,cpu-power-state";
> latency = <...>;
> /*
> * This means that when the state is entered, the power
> * controller should use register index 0 and state 1,
> * whose meaning is power controller specific. Since we
> * know all components affected (for every component
> * we declare its power domain(s) and states so we
> * know what components are affected by the state entry.
> * Given the cache node above and this phandle, the state
> * implies that the cache is lost, register index == 0 state == 1
> /*
> power-domain =<&foo_power_controller 0 1>;
for power down mode, we need to set thge power domain in state 2
power-domain =<&foo_power_controller 0 2>;
Vincent
> };
>
> It is complex but it is probably the cleanest way. And it leaves complexity
> to power controller implementations (if managed in the kernel....), which
> actually makes sense because it is up to power controller to define the
> behavior of certain states.
>
> All in all it is just an idea, feel free to scotch it, it is complex but
> we have to sort it out, one way or another.
>
> Vincent, Tomasz, anyone, thoughts ?
> Lorenzo
>
^ permalink raw reply
* [PATCH v2 2/4] pinctrl: st: Add software edge trigger interrupt support.
From: Lee Jones @ 2014-01-24 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaBAnpfHBqkgU2emZrYwHGh9KvDvqfnCvaWdU5jYgxStA@mail.gmail.com>
> > +/*
> > + * As edge triggers are not supported at hardware level, it is supported by
> > + * software by exploiting the level trigger support in hardware.
>
> (...)
>
> All this is quite hard to understand. Maybe it's just because
> it's hard overall. Edge triggers are not supported by hardware
> so we use the hardware edge trigger support?
>
> That is a bit oxymoronic...
That's not what is says. Read it again. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] arm64: fix build error if DMA_CMA is enabled
From: Pankaj Dubey @ 2014-01-24 8:23 UTC (permalink / raw)
To: linux-arm-kernel
arm64/include/asm/dma-contiguous.h is trying to include
<asm-genric/dma-contiguous.h> which does not exist, and thus failing
build for arm64 if we enable CONFIG_DMA_CMA. This patch fixes build
error by removing unwanted header inclusion from arm64's dma-contiguous.h.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Somraj Mani <somraj.mani@samsung.com>
---
arch/arm64/include/asm/dma-contiguous.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/include/asm/dma-contiguous.h b/arch/arm64/include/asm/dma-contiguous.h
index d6aacb6..14c4c0c 100644
--- a/arch/arm64/include/asm/dma-contiguous.h
+++ b/arch/arm64/include/asm/dma-contiguous.h
@@ -18,7 +18,6 @@
#ifdef CONFIG_DMA_CMA
#include <linux/types.h>
-#include <asm-generic/dma-contiguous.h>
static inline void
dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) { }
--
1.7.10.4
^ permalink raw reply related
* [PATCH 9/9] ARM: DTS: am335x-evmsk: Correct audio clock frequency
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
The clock for audio is sourced from virt_24000000_ck, so the correct
frequency is 24000000.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: <stable@vger.kernel.org> # 3.13.x
---
arch/arm/boot/dts/am335x-evmsk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
index 4718ec4a4dbf..50abe53f6887 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -121,7 +121,7 @@
ti,model = "AM335x-EVMSK";
ti,audio-codec = <&tlv320aic3106>;
ti,mcasp-controller = <&mcasp1>;
- ti,codec-clock-rate = <24576000>;
+ ti,codec-clock-rate = <24000000>;
ti,audio-routing =
"Headphone Jack", "HPLOUT",
"Headphone Jack", "HPROUT";
--
1.8.5.3
^ permalink raw reply related
* [PATCH 8/9] ARM: DTS: omap2: Set disabled status for McBSP instances as default state
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
In omap2420.dtsi and omap2430.dtsi disable all mcbsp nodes and board dts
files can explicitly enable the mcbsp they are using.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap2420.dtsi | 2 ++
arch/arm/boot/dts/omap2430.dtsi | 5 +++++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 60c605de22dd..85b1fb014c43 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -99,6 +99,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 48076000 {
@@ -112,6 +113,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
msdi1: mmc at 4809c000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index d624345666f5..9d2f028fd687 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -113,6 +113,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 48076000 {
@@ -128,6 +129,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 4808c000 {
@@ -143,6 +145,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp4: mcbsp at 4808e000 {
@@ -158,6 +161,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp5: mcbsp at 48096000 {
@@ -173,6 +177,7 @@
dmas = <&sdma 21>,
<&sdma 22>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mmc1: mmc at 4809c000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 7/9] ARM: DTS: omap3: Set disabled status for McBSP instances as default state
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
In omap3.dtsi disable all mcbsp nodes and board dts files can explicitly
enable the mcbsp they are using.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 4 ++++
arch/arm/boot/dts/omap3-beagle.dts | 4 ++++
arch/arm/boot/dts/omap3-devkit8000.dts | 16 ++--------------
arch/arm/boot/dts/omap3-igep.dtsi | 1 +
arch/arm/boot/dts/omap3-overo.dtsi | 4 ++++
arch/arm/boot/dts/omap3.dtsi | 5 +++++
6 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index df33a50bc070..d9ae3f4d0aa4 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -222,3 +222,7 @@
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
+
+&mcbsp2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 3ba4a625ea5b..c13449773def 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -199,3 +199,7 @@
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
+
+&mcbsp2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts
index 4665421bb7bc..bf5a515a3247 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -101,20 +101,8 @@
status = "disabled";
};
-&mcbsp1 {
- status = "disabled";
-};
-
-&mcbsp3 {
- status = "disabled";
-};
-
-&mcbsp4 {
- status = "disabled";
-};
-
-&mcbsp5 {
- status = "disabled";
+&mcbsp2 {
+ status = "okay";
};
&gpmc {
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
index 165aaf7591ba..ced7aa0e503c 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -172,6 +172,7 @@
&mcbsp2 {
pinctrl-names = "default";
pinctrl-0 = <&mcbsp2_pins>;
+ status = "okay";
};
&mmc1 {
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
index a461d2fd1fb0..b08142f755fd 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -95,3 +95,7 @@
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
};
+
+&mcbsp2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99d402a..50767f339e2d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,6 +397,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 49022000 {
@@ -414,6 +415,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 49024000 {
@@ -431,6 +433,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp4: mcbsp at 49026000 {
@@ -446,6 +449,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp5: mcbsp at 48096000 {
@@ -461,6 +465,7 @@
dmas = <&sdma 21>,
<&sdma 22>;
dma-names = "tx", "rx";
+ status = "disabled";
};
sham: sham at 480c3000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 6/9] ARM: DTS: omap5: Set all audio related IP's status to disabled as default
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Board dts files will need to enable the IP nodes which they are using and
does not have to care about the not used ones (to disable them).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index fc3fad563861..84cee44f1fad 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -467,6 +467,7 @@
dmas = <&sdma 65>,
<&sdma 66>;
dma-names = "up_link", "dn_link";
+ status = "disabled";
};
dmic: dmic at 4012e000 {
@@ -478,6 +479,7 @@
ti,hwmods = "dmic";
dmas = <&sdma 67>;
dma-names = "up_link";
+ status = "disabled";
};
mcbsp1: mcbsp at 40122000 {
@@ -492,6 +494,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 40124000 {
@@ -506,6 +509,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 40126000 {
@@ -520,6 +524,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
timer1: timer at 4ae18000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 5/9] ARM: DTS: omap4-sdp: No need to disable mcbsp3 node
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
All audio nodes has been set to disabled state in omap4.dtsi file.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 513b01774966..9bbbbec1d63d 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -548,10 +548,6 @@
status = "okay";
};
-&mcbsp3 {
- status = "disabled";
-};
-
&dmic {
pinctrl-names = "default";
pinctrl-0 = <&dmic_pins>;
--
1.8.5.3
^ permalink raw reply related
* [PATCH 4/9] ARM: DTS: omap4-panda-common: No need to disable the unused audio nodes
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
All audio nodes has been set to disabled state in omap4.dtsi file.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 9067d4c0148d..f83dd4c365c7 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -387,18 +387,6 @@
status = "okay";
};
-&mcbsp2 {
- status = "disabled";
-};
-
-&mcbsp3 {
- status = "disabled";
-};
-
-&dmic {
- status = "disabled";
-};
-
&mcpdm {
pinctrl-names = "default";
pinctrl-0 = <&mcpdm_pins>;
--
1.8.5.3
^ permalink raw reply related
* [PATCH 3/9] ARM: DTS: omap4: Set all audio related IP's status to disabled as default
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Board dts files will need to enable the IP nodes which they are using and
does not have to care about the not used ones (to disable them).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e05853afcd..78c19e30eca0 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -426,6 +426,7 @@
dmas = <&sdma 65>,
<&sdma 66>;
dma-names = "up_link", "dn_link";
+ status = "disabled";
};
dmic: dmic at 4012e000 {
@@ -437,6 +438,7 @@
ti,hwmods = "dmic";
dmas = <&sdma 67>;
dma-names = "up_link";
+ status = "disabled";
};
mcbsp1: mcbsp at 40122000 {
@@ -451,6 +453,7 @@
dmas = <&sdma 33>,
<&sdma 34>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp2: mcbsp at 40124000 {
@@ -465,6 +468,7 @@
dmas = <&sdma 17>,
<&sdma 18>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp3: mcbsp at 40126000 {
@@ -479,6 +483,7 @@
dmas = <&sdma 19>,
<&sdma 20>;
dma-names = "tx", "rx";
+ status = "disabled";
};
mcbsp4: mcbsp at 48096000 {
@@ -492,6 +497,7 @@
dmas = <&sdma 31>,
<&sdma 32>;
dma-names = "tx", "rx";
+ status = "disabled";
};
keypad: keypad at 4a31c000 {
--
1.8.5.3
^ permalink raw reply related
* [PATCH 2/9] ARM: DTS: omap4-sdp: Move audio related pinmux to respective nodes
From: Peter Ujfalusi @ 2014-01-24 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Attach the pinctrl nodes to their respective device node:
mcbsp1, mcbsp2, dmic, mcpdm and twl6040.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 33 ++++++++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index dbc81fb6ef03..513b01774966 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,11 +158,6 @@
&omap4_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <
- &twl6040_pins
- &mcpdm_pins
- &dmic_pins
- &mcbsp1_pins
- &mcbsp2_pins
&dss_hdmi_pins
&tpd12s015_pins
>;
@@ -326,6 +321,10 @@
twl6040: twl at 4b {
compatible = "ti,twl6040";
reg = <0x4b>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&twl6040_pins>;
+
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_2N cascaded to gic */
interrupt-parent = <&gic>;
@@ -537,10 +536,34 @@
pinctrl-0 = <&uart4_pins>;
};
+&mcbsp1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp1_pins>;
+ status = "okay";
+};
+
+&mcbsp2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp2_pins>;
+ status = "okay";
+};
+
&mcbsp3 {
status = "disabled";
};
+&dmic {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dmic_pins>;
+ status = "okay";
+};
+
+&mcpdm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcpdm_pins>;
+ status = "okay";
+};
+
&twl_usb_comparator {
usb-supply = <&vusb>;
};
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/9] ARM: DTS: omap4-panda-common: Move audio related pinmux to respective nodes
From: Peter Ujfalusi @ 2014-01-24 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390551547-12406-1-git-send-email-peter.ujfalusi@ti.com>
Attach the pinctrl nodes to their respective device node:
mcbsp1, mcpdm and twl6040.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05cab41..9067d4c0148d 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -109,9 +109,6 @@
&omap4_pmx_core {
pinctrl-names = "default";
pinctrl-0 = <
- &twl6040_pins
- &mcpdm_pins
- &mcbsp1_pins
&dss_dpi_pins
&tfp410_pins
&dss_hdmi_pins
@@ -300,6 +297,10 @@
twl6040: twl@4b {
compatible = "ti,twl6040";
reg = <0x4b>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&twl6040_pins>;
+
/* IRQ# = 119 */
interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_2N cascaded to gic */
interrupt-parent = <&gic>;
@@ -380,6 +381,12 @@
device-handle = <&elpida_ECB240ABACN>;
};
+&mcbsp1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp1_pins>;
+ status = "okay";
+};
+
&mcbsp2 {
status = "disabled";
};
@@ -392,6 +399,12 @@
status = "disabled";
};
+&mcpdm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcpdm_pins>;
+ status = "okay";
+};
+
&twl_usb_comparator {
usb-supply = <&vusb>;
};
--
1.8.5.3
^ permalink raw reply related
* [PATCH 0/9] ARM: DTS: OMAP: Audio related cleanups for dtsi and dts files
From: Peter Ujfalusi @ 2014-01-24 8:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi Benoit,
OMAP: Put the audio nodes to disabled styate by default and board dts files should
enable the nodes which is used on the board.
am335x: correct the audio mclk clock. This patch has been marked to go to 3.13
stable as well.
Regards,
Peter
---
Peter Ujfalusi (9):
ARM: DTS: omap4-panda-common: Move audio related pinmux to respective
nodes
ARM: DTS: omap4-sdp: Move audio related pinmux to respective nodes
ARM: DTS: omap4: Set all audio related IP's status to disabled as
default
ARM: DTS: omap4-panda-common: No need to disable the unused audio
nodes
ARM: DTS: omap4-sdp: No need to disable mcbsp3 node
ARM: DTS: omap5: Set all audio related IP's status to disabled as
default
ARM: DTS: omap3: Set disabled status for McBSP instances as default
state
ARM: DTS: omap2: Set disabled status for McBSP instances as default
state
ARM: DTS: am335x-evmsk: Correct audio clock frequency
arch/arm/boot/dts/am335x-evmsk.dts | 2 +-
arch/arm/boot/dts/omap2420.dtsi | 2 ++
arch/arm/boot/dts/omap2430.dtsi | 5 +++++
arch/arm/boot/dts/omap3-beagle-xm.dts | 4 ++++
arch/arm/boot/dts/omap3-beagle.dts | 4 ++++
arch/arm/boot/dts/omap3-devkit8000.dts | 16 ++-------------
arch/arm/boot/dts/omap3-igep.dtsi | 1 +
arch/arm/boot/dts/omap3-overo.dtsi | 4 ++++
arch/arm/boot/dts/omap3.dtsi | 5 +++++
arch/arm/boot/dts/omap4-panda-common.dtsi | 23 ++++++++++-----------
arch/arm/boot/dts/omap4-sdp.dts | 33 ++++++++++++++++++++++++-------
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
arch/arm/boot/dts/omap5.dtsi | 5 +++++
13 files changed, 77 insertions(+), 33 deletions(-)
--
1.8.5.3
^ permalink raw reply
* [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
From: Heiko Stübner @ 2014-01-24 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E19931.80803@gmail.com>
On Thursday 23 January 2014 23:35:29 Tomasz Figa wrote:
> On 23.01.2014 20:02, Heiko St?bner wrote:
> > Am Donnerstag, 23. Januar 2014, 19:51:34 schrieb Tomasz Figa:
> >> On 23.01.2014 19:36, Heiko St?bner wrote:
> > In general, I want to try establishing some sort of general restart way,
> > as in the future one dt-board should hopefully be enough to cover all
> > s3c24xx soc variants.
>
> If you make SAMSUNG_WDT_RESET always selected on S3C24XX then I guess
> it's fine.
>
> >> Note that you can make the restart field NULL in mach_desc in board
> >> files.
> >
> > As I said above, this is mainly meant for the dt-case. The legacy-board
> > files are more or less only secondary, and the affected boards can of
> > course then have a NULL restart handle :-) .
> >
> > So for this the dt-board could simply use the wdt-reset, which then gets
> > replaced by the ccf-based reset if appropriate.
>
> OK. By the way, are there any benefits of using this software reset over
> watchdog reset? Maybe all S3C24xx could simply use watchdog reset and no
> special handling of those with swrst would be needed.
According to the manuals I looked at, all S3C24XX SoCs seem to support the
watchdog reset - I'm not sure why the swrst variant was choosen for the newer
ones when they were added initially. So yes in theory all of them seem to be
able to use the watchdog reset.
But in any case the s3c2412 will need its own handling, due to the apparent
clock problem during resets (mentioned in the code and the manuals of
s3c2412/s3c2413).
Heiko
^ permalink raw reply
* DT include files
From: Heiko Stübner @ 2014-01-24 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140113021912.GB23525@S2101-09.ap.freescale.net>
Hi Shawn,
did this topic get any final resolution - especially in terms of the pingrp.h
header?
As I'm currently preparing two board files (imx50 and imx6sl) this discussion
made me unsure if using the pin-group definitions is still the preferred style.
Thanks
Heiko
On Monday 13 January 2014 10:19:14 Shawn Guo wrote:
> On Sun, Jan 12, 2014 at 09:21:19PM +0100, Arnd Bergmann wrote:
> > I was under the impression that the generic pinctrl binding was designed
> > in a way to let you assign labels to each possible (reasonable)
> > configuration so you didn't have get to this level of detail at the
> > driver.
>
> The generic part of pinctrl binding only covers the procedure how a
> client device get its pinctrl state configuration from a pin controller
> node. That's what we defined in bindings/pinctrl/pinctrl-bindings.txt
> and implemented in pinctrl core. But the details of how a pinctrl state
> configuration should be interpreted for a particular pin controller is
> defined by individual pin controller binding like fsl,imx-pinctrl.txt,
> and implemented in the pin controller driver like
> drivers/pinctrl/pinctrl-imx.c.
>
> > I'm also surprised that you have to know multiple constants
> > (mux register, input register, config register offsets) to select a
> > particular pin. I would have expected that you could have one constant
> > from which the driver is able to compute the other ones.
>
> That's what we do before. We define a constant in the binding and have
> the driver to maintain these data and look up the data using the
> constant. See commit below for imx6q example.
>
> d8fe357 pinctrl: pinctrl-imx: add imx6q pinctrl driver
>
> The biggest problem with that approach is we have huge data to maintain
> in the driver because of the complexity and flexibility of IMX pin
> controller design. And these data can not be init data. Check that big
> array of struct imx_pin_reg in commit above for what I'm talking about.
> So when we build a v7 kernel image for IMX, we will have such big array
> for each of these SoCs, imx50, imx51, imx53, imx6sl, imx6dl, imx6q, and
> more to come.
>
> That's why we went through the pain of breaking DT compatibility to move
> all these data into device tree one year ago with the commit below.
>
> e164153 pinctrl: imx: move hard-coding data into device tree
>
> Now kernel gets released from the floating and we do not even need to
> touch kernel to add these data when new SoC support is added.
>
> Shawn
^ permalink raw reply
* [PATCH resend] pwm: Remove obsolete HAVE_PWM Kconfig symbol
From: Sascha Hauer @ 2014-01-24 7:54 UTC (permalink / raw)
To: linux-arm-kernel
Before we had the PWM framework we used to have a barebone PWM api. The
HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify
the PWM API is present in the kernel. Since the last legacy driver is gone
the HAVE_PWM symbol can go aswell.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-pwm at vger.kernel.orig
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
---
Thierry as PWM maintainer has agreed to take this patch. Would be nice
to get some Acks from affected architectures. Russell, Ralf?
arch/arm/Kconfig | 4 ----
arch/arm/mach-pxa/Kconfig | 15 ---------------
arch/mips/Kconfig | 1 -
drivers/input/misc/Kconfig | 4 ++--
include/linux/pwm.h | 2 +-
5 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c1f1a7e..1b6f499 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -109,9 +109,6 @@ config ARM_DMA_IOMMU_ALIGNMENT
endif
-config HAVE_PWM
- bool
-
config MIGHT_HAVE_PCI
bool
@@ -606,7 +603,6 @@ config ARCH_LPC32XX
select CPU_ARM926T
select GENERIC_CLOCKEVENTS
select HAVE_IDE
- select HAVE_PWM
select USB_ARCH_HAS_OHCI
select USE_OF
help
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index 96100db..b96244c 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -7,7 +7,6 @@ comment "Intel/Marvell Dev Platforms (sorted by hardware release time)"
config MACH_PXA3XX_DT
bool "Support PXA3xx platforms from device tree"
select CPU_PXA300
- select HAVE_PWM
select POWER_SUPPLY
select PXA3xx
select USE_OF
@@ -23,12 +22,10 @@ config ARCH_LUBBOCK
config MACH_MAINSTONE
bool "Intel HCDDBBVA0 Development Platform (aka Mainstone)"
- select HAVE_PWM
select PXA27x
config MACH_ZYLONITE
bool
- select HAVE_PWM
select PXA3xx
config MACH_ZYLONITE300
@@ -69,7 +66,6 @@ config ARCH_PXA_IDP
config ARCH_VIPER
bool "Arcom/Eurotech VIPER SBC"
select ARCOM_PCMCIA
- select HAVE_PWM
select I2C_GPIO
select ISA
select PXA25x
@@ -120,7 +116,6 @@ config MACH_CM_X300
bool "CompuLab CM-X300 modules"
select CPU_PXA300
select CPU_PXA310
- select HAVE_PWM
select PXA3xx
config MACH_CAPC7117
@@ -211,7 +206,6 @@ config TRIZEPS_PCMCIA
config MACH_LOGICPD_PXA270
bool "LogicPD PXA270 Card Engine Development Platform"
- select HAVE_PWM
select PXA27x
config MACH_PCM027
@@ -222,7 +216,6 @@ config MACH_PCM027
config MACH_PCM990_BASEBOARD
bool "PHYTEC PCM-990 development board"
depends on MACH_PCM027
- select HAVE_PWM
choice
prompt "display on pcm990"
@@ -246,7 +239,6 @@ config MACH_COLIBRI
config MACH_COLIBRI_PXA270_INCOME
bool "Income s.r.o. PXA270 SBC"
depends on MACH_COLIBRI
- select HAVE_PWM
select PXA27x
config MACH_COLIBRI300
@@ -275,7 +267,6 @@ comment "End-user Products (sorted by vendor name)"
config MACH_H4700
bool "HP iPAQ hx4700"
- select HAVE_PWM
select IWMMXT
select PXA27x
@@ -289,14 +280,12 @@ config MACH_HIMALAYA
config MACH_MAGICIAN
bool "Enable HTC Magician Support"
- select HAVE_PWM
select IWMMXT
select PXA27x
config MACH_MIOA701
bool "Mitac Mio A701 Support"
select GPIO_SYSFS
- select HAVE_PWM
select IWMMXT
select PXA27x
help
@@ -306,7 +295,6 @@ config MACH_MIOA701
config PXA_EZX
bool "Motorola EZX Platform"
- select HAVE_PWM
select IWMMXT
select PXA27x
@@ -346,7 +334,6 @@ config MACH_MP900C
config ARCH_PXA_PALM
bool "PXA based Palm PDAs"
- select HAVE_PWM
config MACH_PALM27X
bool
@@ -444,7 +431,6 @@ config MACH_TREO680
config MACH_RAUMFELD_RC
bool "Raumfeld Controller"
select CPU_PXA300
- select HAVE_PWM
select POWER_SUPPLY
select PXA3xx
@@ -608,7 +594,6 @@ config MACH_E800
config MACH_ZIPIT2
bool "Zipit Z2 Handheld"
- select HAVE_PWM
select PXA27x
endmenu
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 650de39..ce62af8 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -233,7 +233,6 @@ config MACH_JZ4740
select IRQ_CPU
select ARCH_REQUIRE_GPIOLIB
select SYS_HAS_EARLY_PRINTK
- select HAVE_PWM
select HAVE_CLK
select GENERIC_IRQ_CHIP
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 5f4967d..bc6ec8e 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -156,7 +156,7 @@ config INPUT_MAX8925_ONKEY
config INPUT_MAX8997_HAPTIC
tristate "MAXIM MAX8997 haptic controller support"
- depends on PWM && HAVE_PWM && MFD_MAX8997
+ depends on PWM && MFD_MAX8997
select INPUT_FF_MEMLESS
help
This option enables device driver support for the haptic controller
@@ -461,7 +461,7 @@ config INPUT_PCF8574
config INPUT_PWM_BEEPER
tristate "PWM beeper support"
- depends on PWM && HAVE_PWM
+ depends on PWM
help
Say Y here to get support for PWM based beeper devices.
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f0feafd..4717f54 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -7,7 +7,7 @@
struct pwm_device;
struct seq_file;
-#if IS_ENABLED(CONFIG_PWM) || IS_ENABLED(CONFIG_HAVE_PWM)
+#if IS_ENABLED(CONFIG_PWM)
/*
* pwm_request - request a PWM device
*/
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/2] PWM: let of_xlate handlers check args count
From: Sascha Hauer @ 2014-01-24 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124064254.0369084d@ipc1.ka-ro>
On Fri, Jan 24, 2014 at 06:42:54AM +0100, Lothar Wa?mann wrote:
> Hi,
>
> > Okay, this works, but there's a problem with pwm-leds.
> >
> > When the duty cycle is set to zero (when you set the brightness to zero)
> > pwm-leds decides to disable the PWM after configuring it. This causes
> > the PWM output to be driven low, causing the LED to go to maximum
> > brightness.
> >
> > So, using the inversion at PWM level doesn't work.
> >
> The problem is that the driver calls pwm_disable() when the duty cycle is 0.
> This sets the PWM output low independent from the output polarity setting.
>
> > To make this work correctly, we really need pwm-leds to do the inversion
> > rather than setting the inversion bit in hardware.
> >
> The same holds for the pwm-backlight driver.
>
> The easiest fix would be not to call pwm_disable() even for a zero duty
> cycle.
IMO that's the right thing to do anyway due to the different PWM
hardware controllers we have. I'm thinking about the following patch
for some time.
Sascha
--------------------8<--------------------------
>From 9ebbc3d72c71bd97d7fc4458f60ae3ecd5876984 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Fri, 24 Jan 2014 08:34:16 +0100
Subject: [PATCH] PWM: Document disabled PWM output as undefined
When disabled PWM hardware reacts differently. Some controllers
just stop with their current value, others produce a constant high
or low output, sometimes depending on the output inversion bit. Update
the documentation to reflect that and request from the PWM consumer
drivers to set a constant high/low value with duty cycles of 0/100%
instead of disabling the PWM.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Documentation/pwm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 93cb979..b7e8a31 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -44,6 +44,8 @@ After being requested, a PWM has to be configured using:
int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
+The output of a disabled PWM is undefined. Set the duty cycle to 100%
+for a constant high output and to 0 for constant low output.
Using PWMs with the sysfs interface
-----------------------------------
--
1.8.5.2
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply related
* [PATCH v3 1/2] i2c: qup: Add device tree bindings information
From: Andy Gross @ 2014-01-24 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121024007.GE13785@codeaurora.org>
On Mon, Jan 20, 2014 at 06:40:07PM -0800, Stephen Boyd wrote:
> On 01/20, Rob Herring wrote:
> > On Fri, Jan 17, 2014 at 5:03 PM, Bjorn Andersson
> > <bjorn.andersson@sonymobile.com> wrote:
> >
> > > .../devicetree/bindings/i2c/qcom,i2c-qup.txt | 41 ++++++++++++++++++++++
> > > 1 file changed, 41 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
> > > new file mode 100644
> > > index 0000000..a99711b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
> > > @@ -0,0 +1,41 @@
> > > +Qualcomm Universal Peripheral (QUP) I2C controller
> > > +
> > > +Required properties:
> > > + - compatible: Should be "qcom,i2c-qup".
> >
> > Seems a bit generic. All versions of the IP are exactly the same?
> > "qcom,<chip>-i2c-qup" would be better.
> >
>
> There are different versions of the IP in different SoCs. The
> versions for platforms supported upstream are:
>
> 1.1.1 (MSM8660, MSM8960)
> 2.2.1 (MSM8974v2)
>
> so how about one of "qcom,i2c-qup-v1.1.1" or
> "qcom,i2c-qup-v2.2.1" should be specified as more specific
> compatible strings in addition to "qcom,i2c-qup"?
>
This definitely needs two compatible tags. The v1.1.1 supports the FIFO, block,
and data mover modes. The v2.2.1 supports FIFO, block, and BAM DMA.
The BAM patches are currently in review and ideally BAM support can be added to
the I2C. We'll need a way to differentiate so BAM can be used.
Otherwise, the register interfaces are interchangeable except for BAM specific
fields in the registers.
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-addr> for phy probe
From: Mohit KUMAR DCG @ 2014-01-24 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64pSvoRBzrpzXT5yywqWSw8ryQiuVop2tMSRpU2=YMLiw@mail.gmail.com>
Hello Chen,
> -----Original Message-----
> From: wens213 at gmail.com [mailto:wens213 at gmail.com] On Behalf Of
> Chen-Yu Tsai
> Sent: Friday, January 24, 2014 11:33 AM
> To: Viresh Kumar
> Cc: Mohit KUMAR DCG; Pratyush ANAND; spear-devel; linux-arm-
> kernel at lists.infradead.org; devicetree
> Subject: Re: [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-
> addr> for phy probe
>
> Hi,
>
> On Fri, Jan 24, 2014 at 1:02 PM, Viresh Kumar <viresh.kumar@linaro.org>
> wrote:
> > On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com>
> wrote:
> >> DT field name for the phy address changed since kernel 3.10. Set the
> >> snps,phy-addr to 0xffffffff so that the driver probes for the phy.
>
> This will no longer be required. The default behavior for DT based setups has
> been changed to auto-detecting the phy.
>
> See http://patchwork.ozlabs.org/patch/312063/
>
- Thanks, we will test with your patch and remove this one from v3.
Regards
Mohit
>
> Cheers
> ChenYu
>
> >>
> >> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
> >> Cc: Pratyush Anand <pratyush.anand@st.com>
> >> Cc: Viresh Kumar <viresh.linux@gmail.com>
> >> Cc: spear-devel at list.st.com
> >> Cc: linux-arm-kernel at lists.infradead.org
> >> Cc: devicetree at vger.kernel.org
> >> ---
> >> arch/arm/boot/dts/spear13xx.dtsi | 1 +
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/spear13xx.dtsi
> >> b/arch/arm/boot/dts/spear13xx.dtsi
> >> index 4382547..3518803 100644
> >> --- a/arch/arm/boot/dts/spear13xx.dtsi
> >> +++ b/arch/arm/boot/dts/spear13xx.dtsi
> >> @@ -155,6 +155,7 @@
> >>
> >> gmac0: eth at e2000000 {
> >> compatible = "st,spear600-gmac";
> >> + snps,phy-addr = <0xffffffff>;
> >> reg = <0xe2000000 0x8000>;
> >> interrupts = <0 33 0x4
> >> 0 34 0x4>;
> >
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-addr> for phy probe
From: Chen-Yu Tsai @ 2014-01-24 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x=mQLyMV_0Swf3o2c9bW_DNCLT-fQFc3Qs6yt1+9prabmw@mail.gmail.com>
Hi,
On Fri, Jan 24, 2014 at 1:02 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
>> DT field name for the phy address changed since kernel 3.10. Set the
>> snps,phy-addr to 0xffffffff so that the driver probes for the phy.
This will no longer be required. The default behavior for
DT based setups has been changed to auto-detecting the phy.
See http://patchwork.ozlabs.org/patch/312063/
Cheers
ChenYu
>>
>> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
>> Cc: Pratyush Anand <pratyush.anand@st.com>
>> Cc: Viresh Kumar <viresh.linux@gmail.com>
>> Cc: spear-devel at list.st.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree at vger.kernel.org
>> ---
>> arch/arm/boot/dts/spear13xx.dtsi | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
>> index 4382547..3518803 100644
>> --- a/arch/arm/boot/dts/spear13xx.dtsi
>> +++ b/arch/arm/boot/dts/spear13xx.dtsi
>> @@ -155,6 +155,7 @@
>>
>> gmac0: eth at e2000000 {
>> compatible = "st,spear600-gmac";
>> + snps,phy-addr = <0xffffffff>;
>> reg = <0xe2000000 0x8000>;
>> interrupts = <0 33 0x4
>> 0 34 0x4>;
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox