* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Mitch Bradley @ 2012-10-24 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50882EED.9020200@wwwdotorg.org>
On 10/24/2012 8:09 AM, Stephen Warren wrote:
> On 10/24/2012 11:46 AM, Alan Stern wrote:
>> On Wed, 24 Oct 2012, Stephen Warren wrote:
>>
>>>> How do we determine which existing drivers claim to support usb-ehci?
>>>> A quick search under arch/ and drivers/ turns up nothing but
>>>> drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specific
>>>> match should be easy enough, and then "usb-ehci" would be safe to use
>>>> in ehci-platform.c.
>>>
>>> It's not drivers that claim to support usb-ehci, but device tree files
>>> that contain nodes that include "usb-ehci" in their compatible value,
>>> yet need to be handled by a driver that isn't the generic USB EHCI
>>> driver, and that driver binds to the other more specific compatible value:
>>>
>>>> $ grep -HrnI usb-ehci arch/*/boot/dts
> ...
>>> and then search for all those other compatible values in drivers. The
>>> ARM instances certainly all have this issue (although perhaps it's worth
>>> investigating if a generic could work for them instead). The PPC
>>> instances need more investigation; the values don't show up in of match
>>> tables but rather in code.
>>
>> Ah, now I'm starting to get the picture.
>>
>> So by listing "usb-ehci" in its device ID table, a driver would
>> essentially be saying that it can handle _all_ USB EHCI controllers.
Actually, it means that the driver can handle at least USB EHCI
controllers that are 100% compatible with the EHCI spec (requiring
nothing extra). The driver might be able to handle almost-compatible
controllers, possibly with the help of additional properties.
If a DT node lists "usb-ehci" as a "fallback", it's not guaranteed that
a given version of that driver will work, but it's worth a try in the
event that no more-specific driver is matched.
>
> Yes, exactly.
>
>> (Which means that the entry in ehci-ppc-of.c is questionable; perhaps
>> the intention is that this driver really does handle all EHCI
>> controllers on any PPC-based OpenFirmware platform bus.)
>
> Yes, that seems questionable, although perhaps within the context of
> only enabling the driver on PPC specifically, it may be reasonable.
>
>>> This doesn't continue forever though; you typically only list the
>>> specific HW model, the base specific model it's compatible with, and any
>>> generic value needed. So, a hypothetical Tegra40 EHCI controller would be:
>>>
>>> compatible = "nvidia,tegra40-ehci", "nvidia,tegra20-ehci", "usb-ehci".
>>
>> What's the reason for listing the generic value if drivers can't key
>> off it? Does it contain any information that's not already present in
>> the specific values?
>
> This may or may not be a mistake.
>
> The idea is that usb-ehci is included in the device node's compatible
> list iff the HW is 100% compatible with a "usb-ehci" HW device, and
> hence a pure usb-ehci driver can handle the hardware without any
> additional knowledge. (That's true in general for any compatible value).
>
> It's quite possible that this often gets translated to the subtly
> different "the HW is an EHCI controller, so it gets
> compatible="usb-ehci"" when writing .dts files.
>
> So yes we probably should remove compatible="usb-ehci" from any device
> node for HW which really isn't a pure EHCI device. That would presumably
> require looking at the existing custom drivers and/or HW specs to
> determine what, if anything, is different about the HW.
>
> Related, at least on Tegra, the PHY handling is IIRC pretty tightly
> coupled into the EHCI driver. We probably should have separate nodes
> for, and drivers for, the PHYs instead. I don't know if that would
> remove all the non-standard attributes of the Tegra EHCI HW and hence
> allow Tegra's EHCI to be handled by the generic driver. From memory,
> there are certainly some HW workarounds in the Tegra EHCI driver that
> would need to be ported though.
>
>> It sounds like the ehci-platform driver should simply list all the
>> specific HW device types (or base HW device types) that it handles, and
>> it shouldn't include "usb-ehci" in the list. As more DT board files
>> are created or as ehci-platform becomes capable to taking over from
>> other drivers, its device list would grow.
>
> That's certainly a reasonable way to go too. I think the only downside
> with that approach is that every new device needs a kernel update to add
> it to the table, whereas using a generic compatible="usb-ehci" wouldn't,
> assuming no quirks were required for the new device.
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply
* [PATCH] Revert "serial: omap: fix software flow control"
From: Felipe Balbi @ 2012-10-24 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024185742.GA26995@kroah.com>
On Wed, Oct 24, 2012 at 11:57:42AM -0700, Greg KH wrote:
> On Wed, Oct 24, 2012 at 01:02:55PM +0300, Felipe Balbi wrote:
> > Hi Greg,
> >
> > On Tue, Oct 16, 2012 at 08:13:59AM -0700, Tony Lindgren wrote:
> > > * Felipe Balbi <balbi@ti.com> [121016 07:16]:
> > > > This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
> > > > (serial: omap: fix software flow control).
> > > >
> > > > As Russell has pointed out, that commit isn't fixing
> > > > Software Flow Control at all, and it actually makes
> > > > it even more broken.
> > > >
> > > > It was agreed to revert this commit and use Russell's
> > > > latest UART patches instead.
> > > >
> > > > Cc: Russell King <linux@arm.linux.org.uk>
> > > > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > >
> > > This seems like the best way to go for the -rc series:
> > >
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> >
> > Any chance you can pick this one up for v3.7-rc3 ?
>
> Now queued up, sorry for the delay.
no problems, thanks a lot.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/ef6464e0/attachment.sig>
^ permalink raw reply
* [GIT PULL] omap fixes for v3.7-rc2
From: Tony Lindgren @ 2012-10-24 18:50 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc2/fixes-signed
for you to fetch changes up to 12ac7f9e117facfe128d6e569953fa73d2d676b3:
ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driverDate:Wed, 17 Oct 2012 13:55:55 -0500 (2012-10-23 18:58:21 -0700)
----------------------------------------------------------------
Timer fix for am33xx, runtime PM fix for UART, audio McBSP fixes,
mux and pinctrl fixes, and Beagle OPP fix.
----------------------------------------------------------------
Kevin Hilman (2):
ARM: OMAP2: UART: fix console UART mismatched runtime PM status
ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
Paul Walmsley (1):
ARM: OMAP3: PM: apply part of the erratum i582 workaround
Peter Ujfalusi (1):
ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio
Tony Lindgren (3):
ARM: OMAP2+: Fix location of select PINCTRL
ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals.
Merge tag 'for_3.7-rc3-fixes-pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.7-rc2/fixes
Vaibhav Hiremath (1):
ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driverDate:Wed, 17 Oct 2012 13:55:55 -0500
arch/arm/boot/dts/omap3.dtsi | 4 ++--
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mach-omap2/board-omap3beagle.c | 22 +++++++++++++---------
arch/arm/mach-omap2/clock33xx_data.c | 2 ++
arch/arm/mach-omap2/mux34xx.c | 8 ++++----
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm34xx.c | 30 ++++++++++++++++++++++++++++--
arch/arm/mach-omap2/serial.c | 5 +++++
arch/arm/plat-omap/Kconfig | 1 +
9 files changed, 56 insertions(+), 18 deletions(-)
^ permalink raw reply
* [PATCH] ARM: boot: Fix usage of kecho
From: Nicolas Pitre @ 2012-10-24 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351103848-30900-1-git-send-email-festevam@gmail.com>
On Wed, 24 Oct 2012, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Since commit edc88ceb0 (ARM: be really quiet when building with 'make -s') the
> following output is generated when building a kernel for ARM:
>
> echo ' Kernel: arch/arm/boot/Image is ready'
> Kernel: arch/arm/boot/Image is ready
> Building modules, stage 2.
> echo ' Kernel: arch/arm/boot/zImage is ready'
> Kernel: arch/arm/boot/zImage is ready
>
> As per Documentation/kbuild/makefiles.txt the correct way of using kecho is
> '@$(kecho)'.
>
> Make this change so no more unwanted 'echo' messages are displayed.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/boot/Makefile | 10 +++++-----
> arch/arm/tools/Makefile | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index f2aa09e..9137df5 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -33,7 +33,7 @@ ifeq ($(CONFIG_XIP_KERNEL),y)
>
> $(obj)/xipImage: vmlinux FORCE
> $(call if_changed,objcopy)
> - $(kecho) ' Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
> + @$(kecho) ' Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
>
> $(obj)/Image $(obj)/zImage: FORCE
> @echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
> @@ -48,14 +48,14 @@ $(obj)/xipImage: FORCE
>
> $(obj)/Image: vmlinux FORCE
> $(call if_changed,objcopy)
> - $(kecho) ' Kernel: $@ is ready'
> + @$(kecho) ' Kernel: $@ is ready'
>
> $(obj)/compressed/vmlinux: $(obj)/Image FORCE
> $(Q)$(MAKE) $(build)=$(obj)/compressed $@
>
> $(obj)/zImage: $(obj)/compressed/vmlinux FORCE
> $(call if_changed,objcopy)
> - $(kecho) ' Kernel: $@ is ready'
> + @$(kecho) ' Kernel: $@ is ready'
>
> endif
>
> @@ -90,7 +90,7 @@ fi
> $(obj)/uImage: $(obj)/zImage FORCE
> @$(check_for_multiple_loadaddr)
> $(call if_changed,uimage)
> - $(kecho) ' Image $@ is ready'
> + @$(kecho) ' Image $@ is ready'
>
> $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
> $(Q)$(MAKE) $(build)=$(obj)/bootp $@
> @@ -98,7 +98,7 @@ $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
>
> $(obj)/bootpImage: $(obj)/bootp/bootp FORCE
> $(call if_changed,objcopy)
> - $(kecho) ' Kernel: $@ is ready'
> + @$(kecho) ' Kernel: $@ is ready'
>
> PHONY += initrd FORCE
> initrd:
> diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
> index cd60a81..32d05c8 100644
> --- a/arch/arm/tools/Makefile
> +++ b/arch/arm/tools/Makefile
> @@ -5,6 +5,6 @@
> #
>
> include/generated/mach-types.h: $(src)/gen-mach-types $(src)/mach-types
> - $(kecho) ' Generating $@'
> + @$(kecho) ' Generating $@'
> @mkdir -p $(dir $@)
> $(Q)$(AWK) -f $^ > $@ || { rm -f $@; /bin/false; }
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] ARM: boot: Fix usage of kecho
From: Fabio Estevam @ 2012-10-24 18:37 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Since commit edc88ceb0 (ARM: be really quiet when building with 'make -s') the
following output is generated when building a kernel for ARM:
echo ' Kernel: arch/arm/boot/Image is ready'
Kernel: arch/arm/boot/Image is ready
Building modules, stage 2.
echo ' Kernel: arch/arm/boot/zImage is ready'
Kernel: arch/arm/boot/zImage is ready
As per Documentation/kbuild/makefiles.txt the correct way of using kecho is
'@$(kecho)'.
Make this change so no more unwanted 'echo' messages are displayed.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/boot/Makefile | 10 +++++-----
arch/arm/tools/Makefile | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index f2aa09e..9137df5 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -33,7 +33,7 @@ ifeq ($(CONFIG_XIP_KERNEL),y)
$(obj)/xipImage: vmlinux FORCE
$(call if_changed,objcopy)
- $(kecho) ' Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
+ @$(kecho) ' Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
$(obj)/Image $(obj)/zImage: FORCE
@echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
@@ -48,14 +48,14 @@ $(obj)/xipImage: FORCE
$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
- $(kecho) ' Kernel: $@ is ready'
+ @$(kecho) ' Kernel: $@ is ready'
$(obj)/compressed/vmlinux: $(obj)/Image FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed $@
$(obj)/zImage: $(obj)/compressed/vmlinux FORCE
$(call if_changed,objcopy)
- $(kecho) ' Kernel: $@ is ready'
+ @$(kecho) ' Kernel: $@ is ready'
endif
@@ -90,7 +90,7 @@ fi
$(obj)/uImage: $(obj)/zImage FORCE
@$(check_for_multiple_loadaddr)
$(call if_changed,uimage)
- $(kecho) ' Image $@ is ready'
+ @$(kecho) ' Image $@ is ready'
$(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
$(Q)$(MAKE) $(build)=$(obj)/bootp $@
@@ -98,7 +98,7 @@ $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
$(obj)/bootpImage: $(obj)/bootp/bootp FORCE
$(call if_changed,objcopy)
- $(kecho) ' Kernel: $@ is ready'
+ @$(kecho) ' Kernel: $@ is ready'
PHONY += initrd FORCE
initrd:
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index cd60a81..32d05c8 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -5,6 +5,6 @@
#
include/generated/mach-types.h: $(src)/gen-mach-types $(src)/mach-types
- $(kecho) ' Generating $@'
+ @$(kecho) ' Generating $@'
@mkdir -p $(dir $@)
$(Q)$(AWK) -f $^ > $@ || { rm -f $@; /bin/false; }
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Florian Fainelli @ 2012-10-24 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210241358090.1282-100000@iolanthe.rowland.org>
On Wednesday 24 October 2012 14:04:12 Alan Stern wrote:
> On Wed, 24 Oct 2012, Florian Fainelli wrote:
>
> > As long as no one enables both ehci-platform and ehci-ppc-of at the same time
> > there is no problem. ehci-ppc-of should be removed in favor of ehci-platform
> > and make sure that the specific quirk in ehci-ppc-of also gets ported, other
> > that I see no issue using "usb-ehci" as the least detailed compatible property
> > name.
>
> Suppose a DT board file is created for a oontroller which ehci-platform
> can't handle. Then by your proposal, the board file shouldn't have
> "usb-ehci" in its compatible property.
>
> Now later on, suppose ehci-platform is enhanced so that it can manage
> that controller. It's too late to update the board file because the
> information has already been written to various firmwares. The
> enhanced ehci-platform would have to include a special entry to match
> the controller.
In any case you are supposed to use a compatible property which describes
as much as possible your hardware, and this one should have the precedence
if a special treatment is required, so I see no problem with this approach.
>
> Since this reasoning applies every time ehci-platform is updated, it
> seems reasonable to use the same approach right from the beginning.
>
> Alan Stern
>
--
Florian
^ permalink raw reply
* [PATCH V3 1/5] ARM: dts: OMAP: Add timer nodes
From: Hiremath, Vaibhav @ 2012-10-24 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350496873-21337-2-git-send-email-jon-hunter@ti.com>
On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote:
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Please note that for OMAP2/3 devices, there is only one interrupt controller
> for the ARM CPU (which has the label "intc") and so globally define this as the
> interrupt parent to save duplicating the interrupt parent for all device nodes.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
> .../devicetree/bindings/arm/omap/timer.txt | 29 ++++++
> arch/arm/boot/dts/am33xx.dtsi | 61 +++++++++++++
> arch/arm/boot/dts/omap2.dtsi | 86 ++++++++++++++++++
> arch/arm/boot/dts/omap2420.dtsi | 8 ++
> arch/arm/boot/dts/omap2430.dtsi | 8 ++
> arch/arm/boot/dts/omap3.dtsi | 96 ++++++++++++++++++++
> arch/arm/boot/dts/omap4.dtsi | 86 ++++++++++++++++++
> 7 files changed, 374 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
>
Although I have not tested this version of patch series at my end, but
whole patch-series Looks ok to me.
Acked-By: Vaibhav Hiremath <hvaibhav@ti.com>
Thanks,
Vaibhav
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
> new file mode 100644
> index 0000000..d9449d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -0,0 +1,29 @@
> +OMAP Timer bindings
> +
> +Required properties:
> +- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers
> +- reg: Contains timer register address range (base address and length)
> +- interrupts: Contains the interrupt information for the timer. The format is
> + being dependent on which interrupt controller the OMAP device
> + uses.
> +- ti,hwmods: Name of the hwmod associated to the timer, "timer<X>", where
> + <X> is the instance number of the timer from the HW spec.
> +
> +Optional properties:
> +- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
> +- ti,timer-dsp: Indicates the timer can interrupt the on-chip DSP in
> + addition to the ARM CPU.
> +- ti,timer-pwm: Indicates the timer can generate a PWM output.
> +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> + and therefore cannot be used by the kernel.
> +
> +Example:
> +
> +timer12: timer at 48304000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48304000 0xfff>;
> + interrupts = <95>;
> + ti,hwmods = "timer12"
> + ti,timer-alwon;
> + ti,timer-secure;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index bb31bff..fd5074c 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -210,5 +210,66 @@
> interrupt-parent = <&intc>;
> interrupts = <91>;
> };
> +
> + timer1: timer at 44e31000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x44e31000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <67>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer at 48040000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48040000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <68>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 48042000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48042000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <69>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 48044000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48044000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <92>;
> + ti,hwmods = "timer4";
> + ti,timer-pwm;
> + };
> +
> + timer5: timer at 48046000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48046000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <93>;
> + ti,hwmods = "timer5";
> + ti,timer-pwm;
> + };
> +
> + timer6: timer at 48048000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48048000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <94>;
> + ti,hwmods = "timer6";
> + ti,timer-pwm;
> + };
> +
> + timer7: timer at 4804a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4804a000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <95>;
> + ti,hwmods = "timer7";
> + ti,timer-pwm;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
> index 581cb08..731de55 100644
> --- a/arch/arm/boot/dts/omap2.dtsi
> +++ b/arch/arm/boot/dts/omap2.dtsi
> @@ -12,6 +12,7 @@
>
> / {
> compatible = "ti,omap2430", "ti,omap2420", "ti,omap2";
> + interrupt-parent = <&intc>;
>
> aliases {
> serial0 = &uart1;
> @@ -65,5 +66,90 @@
> ti,hwmods = "uart3";
> clock-frequency = <48000000>;
> };
> +
> + timer2: timer at 4802a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4802a000 0xfff>;
> + interrupts = <38>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 48078000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48078000 0xfff>;
> + interrupts = <39>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 4807a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4807a000 0xfff>;
> + interrupts = <40>;
> + ti,hwmods = "timer4";
> + };
> +
> + timer5: timer at 4807c000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4807c000 0xfff>;
> + interrupts = <41>;
> + ti,hwmods = "timer5";
> + ti,timer-dsp;
> + };
> +
> + timer6: timer at 4807e000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4807e000 0xfff>;
> + interrupts = <42>;
> + ti,hwmods = "timer6";
> + ti,timer-dsp;
> + };
> +
> + timer7: timer at 48080000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48080000 0xfff>;
> + interrupts = <43>;
> + ti,hwmods = "timer7";
> + ti,timer-dsp;
> + };
> +
> + timer8: timer at 48082000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48082000 0xfff>;
> + interrupts = <44>;
> + ti,hwmods = "timer8";
> + ti,timer-dsp;
> + };
> +
> + timer9: timer at 48084000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48084000 0xfff>;
> + interrupts = <45>;
> + ti,hwmods = "timer9";
> + ti,timer-pwm;
> + };
> +
> + timer10: timer at 48086000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48086000 0xfff>;
> + interrupts = <46>;
> + ti,hwmods = "timer10";
> + ti,timer-pwm;
> + };
> +
> + timer11: timer at 48088000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48088000 0xfff>;
> + interrupts = <47>;
> + ti,hwmods = "timer11";
> + ti,timer-pwm;
> + };
> +
> + timer12: timer at 4808a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4808a000 0xfff>;
> + interrupts = <48>;
> + ti,hwmods = "timer12";
> + ti,timer-pwm;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
> index bfd76b4..5f68a70 100644
> --- a/arch/arm/boot/dts/omap2420.dtsi
> +++ b/arch/arm/boot/dts/omap2420.dtsi
> @@ -44,5 +44,13 @@
> interrupt-parent = <&intc>;
> ti,hwmods = "mcbsp2";
> };
> +
> + timer1: timer at 48028000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48028000 0xfff>;
> + interrupts = <37>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
> index 4565d97..7439987 100644
> --- a/arch/arm/boot/dts/omap2430.dtsi
> +++ b/arch/arm/boot/dts/omap2430.dtsi
> @@ -88,5 +88,13 @@
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp5";
> };
> +
> + timer1: timer at 49018000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49018000 0xfff>;
> + interrupts = <37>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index f38ea87..3fb910f 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -12,6 +12,7 @@
>
> / {
> compatible = "ti,omap3430", "ti,omap3";
> + interrupt-parent = <&intc>;
>
> aliases {
> serial0 = &uart1;
> @@ -300,5 +301,100 @@
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp5";
> };
> +
> + timer1: timer at 48318000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48318000 0xfff>;
> + interrupts = <37>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer at 49032000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49032000 0xfff>;
> + interrupts = <38>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 49034000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49034000 0xfff>;
> + interrupts = <39>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 49036000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49036000 0xfff>;
> + interrupts = <40>;
> + ti,hwmods = "timer4";
> + };
> +
> + timer5: timer at 49038000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49038000 0xfff>;
> + interrupts = <41>;
> + ti,hwmods = "timer5";
> + ti,timer-dsp;
> + };
> +
> + timer6: timer at 4903a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903a000 0xfff>;
> + interrupts = <42>;
> + ti,hwmods = "timer6";
> + ti,timer-dsp;
> + };
> +
> + timer7: timer at 4903c000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903c000 0xfff>;
> + interrupts = <43>;
> + ti,hwmods = "timer7";
> + ti,timer-dsp;
> + };
> +
> + timer8: timer at 4903e000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903e000 0xfff>;
> + interrupts = <44>;
> + ti,hwmods = "timer8";
> + ti,timer-pwm;
> + ti,timer-dsp;
> + };
> +
> + timer9: timer at 49040000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49040000 0xfff>;
> + interrupts = <45>;
> + ti,hwmods = "timer9";
> + ti,timer-pwm;
> + };
> +
> + timer10: timer at 48086000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48086000 0xfff>;
> + interrupts = <46>;
> + ti,hwmods = "timer10";
> + ti,timer-pwm;
> + };
> +
> + timer11: timer at 48088000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48088000 0xfff>;
> + interrupts = <47>;
> + ti,hwmods = "timer11";
> + ti,timer-pwm;
> + };
> +
> + timer12: timer at 48304000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48304000 0xfff>;
> + interrupts = <95>;
> + ti,hwmods = "timer12";
> + ti,timer-alwon;
> + ti,timer-secure;
> + };
> };
> };
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 3883f94..f6ac2b7 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -438,5 +438,91 @@
> ranges;
> ti,hwmods = "ocp2scp_usb_phy";
> };
> +
> + timer1: timer at 4a318000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4a318000 0x7f>;
> + interrupts = <0 37 0x4>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer at 48032000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48032000 0x7f>;
> + interrupts = <0 38 0x4>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer at 48034000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48034000 0x7f>;
> + interrupts = <0 39 0x4>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer at 48036000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48036000 0x7f>;
> + interrupts = <0 40 0x4>;
> + ti,hwmods = "timer4";
> + };
> +
> + timer5: timer at 49038000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x49038000 0x7f>;
> + interrupts = <0 41 0x4>;
> + ti,hwmods = "timer5";
> + ti,timer-dsp;
> + };
> +
> + timer6: timer at 4903a000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903a000 0x7f>;
> + interrupts = <0 42 0x4>;
> + ti,hwmods = "timer6";
> + ti,timer-dsp;
> + };
> +
> + timer7: timer at 4903c000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903c000 0x7f>;
> + interrupts = <0 43 0x4>;
> + ti,hwmods = "timer7";
> + ti,timer-dsp;
> + };
> +
> + timer8: timer at 4903e000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4903e000 0x7f>;
> + interrupts = <0 44 0x4>;
> + ti,hwmods = "timer8";
> + ti,timer-pwm;
> + ti,timer-dsp;
> + };
> +
> + timer9: timer at 4803e000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4803e000 0x7f>;
> + interrupts = <0 45 0x4>;
> + ti,hwmods = "timer9";
> + ti,timer-pwm;
> + };
> +
> + timer10: timer at 48086000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48086000 0x7f>;
> + interrupts = <0 46 0x4>;
> + ti,hwmods = "timer10";
> + ti,timer-pwm;
> + };
> +
> + timer11: timer at 48088000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48088000 0x7f>;
> + interrupts = <0 47 0x4>;
> + ti,hwmods = "timer11";
> + ti,timer-pwm;
> + };
> };
> };
> --
> 1.7.9.5
>
>
^ permalink raw reply
* [PATCH v3 3/5] zynq: remove use of CLKDEV_LOOKUP
From: Josh Cartwright @ 2012-10-24 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024133231.GA28661@elliptictech.com>
On Wed, Oct 24, 2012 at 09:32:32AM -0400, Nick Bowler wrote:
> On 2012-10-23 19:34 -0500, Josh Cartwright wrote:
> > The Zynq support in mainline does not (yet) make use of any of the
> > generic clk or clk lookup functionality. Remove what is upstream for
> > now, until the out-of-tree implementation is in suitable form for
> > merging.
> >
> > An important side effect of this patch is that it allows the building of
> > a Zynq kernel without running into unresolved symbol problems:
> >
> > drivers/built-in.o: In function `amba_get_enable_pclk':
> > clkdev.c:(.text+0x444): undefined reference to `clk_enable'
>
> For the record, I think this was introduced by commit 56a34b03ff427
> ("ARM: versatile: Make plat-versatile clock optional") which forgot to
> select PLAT_VERSATILE_CLOCK on Zynq. This is not all that surprising,
> because the fact that Zynq "uses" PLAT_VERSATILE is secretly hidden in
> the Makefile.
Yes, indeed. I did try to fix my problems by having ARCH_ZYNQ select
PLAT_VERSATILE_CLOCK, but I recall running into additional build
problems...
But now that I just tried it again, it all seems to work, barring
Kconfig complaining I've selected PLAT_VERSATILE_CLOCK, but not
PLAT_VERSATILE. (Having ARCH_ZYNQ select PLAT_VERSATILE, however, leads
to additional build problems).
> Nevertheless, the only feature from versatile that Zynq needed was the
> clock support, so this patch should *also* delete the secret use of
> plat-versatile by removing this line from arch/arm/Makefile:
>
> plat-$(CONFIG_ARCH_ZYNQ) += versatile
Yes, indeed it should.
Thanks,
Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121024/07b24168/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Stephen Warren @ 2012-10-24 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210241329230.1282-100000@iolanthe.rowland.org>
On 10/24/2012 11:46 AM, Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
>>> How do we determine which existing drivers claim to support usb-ehci?
>>> A quick search under arch/ and drivers/ turns up nothing but
>>> drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specific
>>> match should be easy enough, and then "usb-ehci" would be safe to use
>>> in ehci-platform.c.
>>
>> It's not drivers that claim to support usb-ehci, but device tree files
>> that contain nodes that include "usb-ehci" in their compatible value,
>> yet need to be handled by a driver that isn't the generic USB EHCI
>> driver, and that driver binds to the other more specific compatible value:
>>
>>> $ grep -HrnI usb-ehci arch/*/boot/dts
...
>> and then search for all those other compatible values in drivers. The
>> ARM instances certainly all have this issue (although perhaps it's worth
>> investigating if a generic could work for them instead). The PPC
>> instances need more investigation; the values don't show up in of match
>> tables but rather in code.
>
> Ah, now I'm starting to get the picture.
>
> So by listing "usb-ehci" in its device ID table, a driver would
> essentially be saying that it can handle _all_ USB EHCI controllers.
Yes, exactly.
> (Which means that the entry in ehci-ppc-of.c is questionable; perhaps
> the intention is that this driver really does handle all EHCI
> controllers on any PPC-based OpenFirmware platform bus.)
Yes, that seems questionable, although perhaps within the context of
only enabling the driver on PPC specifically, it may be reasonable.
>> This doesn't continue forever though; you typically only list the
>> specific HW model, the base specific model it's compatible with, and any
>> generic value needed. So, a hypothetical Tegra40 EHCI controller would be:
>>
>> compatible = "nvidia,tegra40-ehci", "nvidia,tegra20-ehci", "usb-ehci".
>
> What's the reason for listing the generic value if drivers can't key
> off it? Does it contain any information that's not already present in
> the specific values?
This may or may not be a mistake.
The idea is that usb-ehci is included in the device node's compatible
list iff the HW is 100% compatible with a "usb-ehci" HW device, and
hence a pure usb-ehci driver can handle the hardware without any
additional knowledge. (That's true in general for any compatible value).
It's quite possible that this often gets translated to the subtly
different "the HW is an EHCI controller, so it gets
compatible="usb-ehci"" when writing .dts files.
So yes we probably should remove compatible="usb-ehci" from any device
node for HW which really isn't a pure EHCI device. That would presumably
require looking at the existing custom drivers and/or HW specs to
determine what, if anything, is different about the HW.
Related, at least on Tegra, the PHY handling is IIRC pretty tightly
coupled into the EHCI driver. We probably should have separate nodes
for, and drivers for, the PHYs instead. I don't know if that would
remove all the non-standard attributes of the Tegra EHCI HW and hence
allow Tegra's EHCI to be handled by the generic driver. From memory,
there are certainly some HW workarounds in the Tegra EHCI driver that
would need to be ported though.
> It sounds like the ehci-platform driver should simply list all the
> specific HW device types (or base HW device types) that it handles, and
> it shouldn't include "usb-ehci" in the list. As more DT board files
> are created or as ehci-platform becomes capable to taking over from
> other drivers, its device list would grow.
That's certainly a reasonable way to go too. I think the only downside
with that approach is that every new device needs a kernel update to add
it to the table, whereas using a generic compatible="usb-ehci" wouldn't,
assuming no quirks were required for the new device.
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Michael Walle @ 2012-10-24 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351090434-30499-1-git-send-email-andrew@lunn.ch>
Hi Andrew,
Am Mittwoch 24 Oktober 2012, 16:53:45 schrieb Andrew Lunn:
> This patchset converts all DT kirkwood boards to using pinctrl.
>
> This patchset depends on an earlier patchset to allow the mvebu
> pinctrl driver and gpio driver to be built for kirkwood.
>
> Only the TS219 conversion has been tested on hardware. The remaining
> are compile tested. Before merging upstream, it would be good if the
> others could be tested on hardware.
>
> This series along with the dependents can be found in:
Unfortunately, this doesn't work for me. git bisect tells me its commit
e01139ec82162f21875d09e820686aede4219695.
I guess it has something to do with the lsxl_init calling gpio_set_value().
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Linux version 3.7.0-rc2-00015-g2773c33 (mw at thanatos) (gcc version 4.4.5
(Debian 4.4.5-8) ) #8 PREEMPT Wed Oct 24 20:05:32 CEST 2012
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell Kirkwood (Flattened Device Tree), model: Buffalo Linkstation
LS-CHLv2
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: console=ttyS0,115200 root=/dev/sda2 earlyprintk
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 55828k/55828k available, 9708k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xc4800000 - 0xff000000 ( 936 MB)
lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc04e2660 (4970 kB)
.init : 0xc04e3000 - 0xc0506cc0 ( 144 kB)
.data : 0xc0508000 - 0xc0540280 ( 225 kB)
.bss : 0xc05402a4 - 0xc05d7a3c ( 606 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:114
sched_clock: 32 bits at 166MHz, resolution 5ns, wraps every 25769ms
Console: colour dummy device 80x30
Calibrating delay loop... 597.60 BogoMIPS (lpj=2988032)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x3baaa8 - 0x3baae4
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 1024 KiB pool for atomic coherent allocations
Kirkwood: MV88F6281-A1, TCLK=166666667.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
Unable to handle kernel NULL pointer dereference at virtual address 0000003c
pgd = c0004000
[0000003c] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 Not tainted (3.7.0-rc2-00015-g2773c33 #8)
PC is at __gpio_set_value+0x20/0xb4
LR is at lsxl_init+0x14/0x58
pc : [<c01ab75c>] lr : [<c04e99d0>] psr: 20000053
sp : c342ff20 ip : 00000000 fp : 00000000
r10: 00000089 r9 : c0506878 r8 : c04e4498
r7 : 00000000 r6 : c05cea18 r5 : 00000000 r4 : 0000000b
r3 : 00000084 r2 : 00000001 r1 : 00000001 r0 : 0000000b
Flags: nzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 0005397f Table: 00004000 DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc342e1b8)
Stack: (0xc342ff20 to 0xc3430000)
ff20: 00000037 c3b5508c c0516230 00000004 c05402c0 c04e99d0 c05005f8 c04e9640
ff40: c05005f8 c04e44b4 c05005f8 c0008614 00000003 00000003 00000000 c05005f8
ff60: c05005f8 00000004 c05402c0 c0500610 c04e31b0 00000089 00000000 c03ab064
ff80: 00000003 00000003 c04e31b0 c03aaf74 00000000 c03aaf74 00000000 00000000
ffa0: 00000000 00000000 00000000 c0008dd0 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c01ab75c>] (__gpio_set_value+0x20/0xb4) from [<c04e99d0>]
(lsxl_init+0x14/0x58)
[<c04e99d0>] (lsxl_init+0x14/0x58) from [<c04e9640>]
(kirkwood_dt_init+0xe4/0x158)
[<c04e9640>] (kirkwood_dt_init+0xe4/0x158) from [<c04e44b4>]
(customize_machine+0x1c/0x28)
[<c04e44b4>] (customize_machine+0x1c/0x28) from [<c0008614>]
(do_one_initcall+0x30/0x174)
[<c0008614>] (do_one_initcall+0x30/0x174) from [<c03ab064>]
(kernel_init+0xf0/0x2a0)
[<c03ab064>] (kernel_init+0xf0/0x2a0) from [<c0008dd0>]
(ret_from_fork+0x14/0x24)
Code: e24dd008 e1a04000 e7965003 e1a02001 (e5d5303c)
---[ end trace 1b75b31a2719ed1c ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
--
Michael
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-24 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2721213.h9kKFkpVW0@flexo>
On Wed, 24 Oct 2012, Florian Fainelli wrote:
> As long as no one enables both ehci-platform and ehci-ppc-of at the same time
> there is no problem. ehci-ppc-of should be removed in favor of ehci-platform
> and make sure that the specific quirk in ehci-ppc-of also gets ported, other
> that I see no issue using "usb-ehci" as the least detailed compatible property
> name.
Suppose a DT board file is created for a oontroller which ehci-platform
can't handle. Then by your proposal, the board file shouldn't have
"usb-ehci" in its compatible property.
Now later on, suppose ehci-platform is enhanced so that it can manage
that controller. It's too late to update the board file because the
information has already been written to various firmwares. The
enhanced ehci-platform would have to include a special entry to match
the controller.
Since this reasoning applies every time ehci-platform is updated, it
seems reasonable to use the same approach right from the beginning.
Alan Stern
^ permalink raw reply
* [PATCH] MAINTAINERS: Add arm-soc tree entry
From: Stephen Boyd @ 2012-10-24 18:00 UTC (permalink / raw)
To: linux-arm-kernel
Document the arm-soc tree in the maintainers file so that
developers know how arm SoC development is structured.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 014272b..f70afea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -637,6 +637,13 @@ W: http://www.arm.linux.org.uk/
S: Maintained
F: arch/arm/
+ARM SUB-ARCHITECTURES
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: MAINTAINED
+F: arch/arm/mach-*/
+F: arch/arm/plat-*/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
+
ARM PRIMECELL AACI PL041 DRIVER
M: Russell King <linux@arm.linux.org.uk>
S: Maintained
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Dmitry Torokhov @ 2012-10-24 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024165749.GB32220@arwen.pp.htv.fi>
On Wednesday, October 24, 2012 07:57:49 PM Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote:
> > > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov
> > >
> > > <dmitry.torokhov@gmail.com> wrote:
> > > > I have seen just in a few days 3 or 4 drivers having exactly the same
> > > > change - call to devm_pinctrl_get_select_default(), and I guess I will
> > > > receive the same patches for the rest of input drivers shortly.
> > > > This suggests that the operation is done at the wrong level. Do the
> > > > pin configuration as you parse DT data, the same way you set up i2c
> > > > devices registers in of_i2c.c, and leave the individual drivers that
> > > > do
> > > > not care about specifics alone.
> > >
> > > Exactly this can be done with pinctrl hogs.
> > >
> > > The problem with that is that it removes the cross-reference
> > > between the device and it's pinctrl handle (also from the device
> > > tree). Instead the pinctrl handle gets referenced to the pin controller
> > > itself. So from a modelling perpective this looks a bit ugly.
> > >
> > > So we have two kinds of ugly:
> > >
> > > - Sprinke devm_pinctrl_get_select_default() over all drivers
> > >
> > > which makes pinctrl handles properly reference their devices
> > >
> > > - Use hogs and loose coupling between pinctrl handles and their
> > >
> > > devices
> > >
> > > A third alternative as outlined is to use notifiers and some
> > > resource core in drivers/base/*
> >
> > OK, so with drivers/base/, have you considered doing default pinctrl
> > selection in bus's probe() methods? Yo would select the default
> > configuration before starting probing the device and maybe select idle
> > when probe fails or device is unbound? That would still keep the link
> > between device object and pinctrl and there less busses than device
> > drivers out there.
>
> it starts to become confusing after a while. I mean, there's a reason
> why all drivers explictly call pm_runtim_enable(), right ?
Right. Because not all of them support runtime PM and quite usually their
PM methods are not ready to go until initialization is complete. And again,
the driver here controls its own behavior.
>
> From a first thought, one could think of just yanking that into bus'
> probe() as you may suggest, but sometimes the device is already enabled,
> so we need extra tricks:
>
> pm_runtime_set_active();
> pm_runtime_enable();
> pm_runtime_get();
>
> the same could happen with pinctrl eventually. What if a device needs to
> do something else (an errata fix as an example) before requesting
> pinctrl's default state ?
That is a valid concern and we'll need to find a compromise here. As I said,
I am not saying that no driver should ever touch pinctrl. I can see, for
example, input drivers actually disabling pins until they are ->open()ed,
in addition of doing that at [runtime] suspend/resume. But it would be nice
if we could have "dumb" drivers not care about pins.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-24 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50882882.1090806@gmail.com>
On Wed, 24 Oct 2012, Rob Herring wrote:
> On 10/24/2012 11:44 AM, Alan Stern wrote:
> > On Wed, 24 Oct 2012, Stephen Warren wrote:
> >
> >> We should absolutely avoid Linux-specific properties where possible.
> >>
> >> That said, what Linux-specific properties are you talking about? The
> >> properties discussed here (has-synopsys-hc-bug, no-io-watchdog, has-tt)
> >> are all purely a description of HW, aren't they.
> >
> > "has-tt" is definitely a description of the HW.
>
> Can you spell out tt.
It stands for Transaction Translator. The acronym is a standard one,
used in the USB specs.
> > "has-synopsys-hc-bug" is too, although determining whether or not it
> > should apply to a particular controller might be difficult. I'm
> > inclined not to include it among the properties.
>
> What happens when there are 2 synopsys hc bugs? Something more specific
> about what the bug is would be better.
We will leave it out.
> > "no-io-watchdog" is not the greatest name. It describes to controllers
> > that always do generate IRQs for I/O events when they are supposed to
> > (and hence the driver doesn't need to set up a watchdog timer to detect
> > I/O completions that didn't generate an IRQ). So while the concept is
> > HW-specific, the name refers to a driver implementation issue. A
> > better name might be something like "reliable-IRQs". Again, it's not
> > such an easy thing to test for. Almost all the existing drivers leave
> > it unset.
>
> Shouldn't the default be reliable irqs? What about "unreliable-irqs"?
I don't know why the default was set the way it was. That was before
my time as EHCI maintainer. Right now only a few EHCI drivers claim to
have reliable IRQs.
Avoiding the watchdog timer is a fairly minor optimization in any case.
It fires only once every 100 ms, and only while I/O is in progress.
Alan Stern
^ permalink raw reply
* [PATCHv2] ARM: Push selects for TWD/SCU into machine entries
From: Stephen Warren @ 2012-10-24 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351099475-29349-1-git-send-email-sboyd@codeaurora.org>
On 10/24/2012 11:24 AM, Stephen Boyd wrote:
> The TWD and SCU configs are selected by default as long as
> MSM_SCORPIONMP is false and/or MCT is false. Implementing the
> logic this way certainly saves lines in the Kconfig but it
> precludes those machines which select MSM_SCORPIONMP or MCT from
> participating in the single zImage effort because when those
> machines are combined with other SMP capable machines the TWD and
> SCU are no longer selected by default.
>
> Push the select out to the machine entries so that we can compile
> these machines together and still select the appropriate configs.
Acked-by: Stephen Warren <swarren@nvidia.com>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> @@ -633,6 +633,8 @@ config ARCH_TEGRA
> select GENERIC_GPIO
> select HAVE_CLK
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> select SPARSE_IRQ
> select USE_OF
Where will this patch be merged?
It probably won't happen for 3.8, but that config fragment will move to
arch/arm/mach-tegra/Kconfig when Tegra enables single zImage support, I
believe. So, it'd be good to make sure this patch gets merged somewhere
that could be used as a baseline for other arm-soc branches if needed,
to avoid merge conflicts.
^ permalink raw reply
* [PATCH 6/6] ARM: ux500: Convert DT_MACHINE_START to use SMP operations
From: Linus Walleij @ 2012-10-24 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089926-32161-7-git-send-email-lee.jones@linaro.org>
On Wed, Oct 24, 2012 at 4:45 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The Device Tree machine description for the ux5x0 was moved
> recently and as a consequence missed the addition of SMP
> operations. Without this patch SMP doesn't work and only one
> CPU is present after booting.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/6] ARM: ux500: Correct SDI5 address and add some format changes
From: Linus Walleij @ 2012-10-24 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089926-32161-6-git-send-email-lee.jones@linaro.org>
On Wed, Oct 24, 2012 at 4:45 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Here we fix a simple copy and paste error and bring some node
> spaces back into line with the remainder of the tree.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/6] ARM: ux500: Specify AMBA Primecell IDs for Nomadik I2C in DT
From: Linus Walleij @ 2012-10-24 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089926-32161-5-git-send-email-lee.jones@linaro.org>
On Wed, Oct 24, 2012 at 4:45 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Now the Nomadik I2C driver has been converted to an AMBA one, we
> are required to provide the Primecell IDs via platform code. When
> booting with DT enabled these have to be specified in the device
> nodes. We do that here.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
I suspect this should go to stable as well.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-24 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50881B19.3080609@wwwdotorg.org>
On Wed, 24 Oct 2012, Stephen Warren wrote:
> > How do we determine which existing drivers claim to support usb-ehci?
> > A quick search under arch/ and drivers/ turns up nothing but
> > drivers/usb/host/ehci-ppc-of.c. Changing it to a more HW-specific
> > match should be easy enough, and then "usb-ehci" would be safe to use
> > in ehci-platform.c.
>
> It's not drivers that claim to support usb-ehci, but device tree files
> that contain nodes that include "usb-ehci" in their compatible value,
> yet need to be handled by a driver that isn't the generic USB EHCI
> driver, and that driver binds to the other more specific compatible value:
>
> > $ grep -HrnI usb-ehci arch/*/boot/dts
> > arch/arm/boot/dts/spear3xx.dtsi:76: compatible = "st,spear600-ehci", "usb-ehci";
> > arch/arm/boot/dts/at91sam9x5.dtsi:399: compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
> > arch/arm/boot/dts/spear13xx.dtsi:145: compatible = "st,spear600-ehci", "usb-ehci";
> > arch/arm/boot/dts/spear13xx.dtsi:152: compatible = "st,spear600-ehci", "usb-ehci";
> > arch/arm/boot/dts/tegra20.dtsip:215: compatible = "nvidia,tegra20-ehci", "usb-ehci";
> > arch/arm/boot/dts/tegra20.dtsip:224: compatible = "nvidia,tegra20-ehci", "usb-ehci";
> > arch/arm/boot/dts/tegra20.dtsip:232: compatible = "nvidia,tegra20-ehci", "usb-ehci";
> > arch/arm/boot/dts/spear600.dtsi:88: compatible = "st,spear600-ehci", "usb-ehci";
> > arch/arm/boot/dts/spear600.dtsi:96: compatible = "st,spear600-ehci", "usb-ehci";
> > arch/arm/boot/dts/at91sam9g45.dtsi:392: compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
> > arch/powerpc/boot/dts/sequoia.dts:156: compatible = "ibm,usb-ehci-440epx", "usb-ehci";
> > arch/powerpc/boot/dts/wii.dts:120: compatible = "nintendo,hollywood-usb-ehci",
> > arch/powerpc/boot/dts/wii.dts:121: "usb-ehci";
> > arch/powerpc/boot/dts/canyonlands.dts:167: compatible = "ibm,usb-ehci-460ex", "usb-ehci";
>
> and then search for all those other compatible values in drivers. The
> ARM instances certainly all have this issue (although perhaps it's worth
> investigating if a generic could work for them instead). The PPC
> instances need more investigation; the values don't show up in of match
> tables but rather in code.
Ah, now I'm starting to get the picture.
So by listing "usb-ehci" in its device ID table, a driver would
essentially be saying that it can handle _all_ USB EHCI controllers.
(Which means that the entry in ehci-ppc-of.c is questionable; perhaps
the intention is that this driver really does handle all EHCI
controllers on any PPC-based OpenFirmware platform bus.)
> This doesn't continue forever though; you typically only list the
> specific HW model, the base specific model it's compatible with, and any
> generic value needed. So, a hypothetical Tegra40 EHCI controller would be:
>
> compatible = "nvidia,tegra40-ehci", "nvidia,tegra20-ehci", "usb-ehci".
What's the reason for listing the generic value if drivers can't key
off it? Does it contain any information that's not already present in
the specific values?
It sounds like the ehci-platform driver should simply list all the
specific HW device types (or base HW device types) that it handles, and
it shouldn't include "usb-ehci" in the list. As more DT board files
are created or as ehci-platform becomes capable to taking over from
other drivers, its device list would grow.
And it sounds like the only property we really need to add to the
usb-ehci binding at the moment is "has-tt".
Alan Stern
^ permalink raw reply
* [PATCH 0/6] ux500 fixes bound for the -rcs
From: Linus Walleij @ 2012-10-24 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089926-32161-1-git-send-email-lee.jones@linaro.org>
On Wed, Oct 24, 2012 at 4:45 PM, Lee Jones <lee.jones@linaro.org> wrote:
> This patch-set contains a bunch of fixes which are bound for the
> v3.6 Release Candidates. Each of them provides a fix for something
> which went wrong during the merge window. Without them we either
> can't build the kernel, have no GPIOs, only have one running CPU
> core, see unnecessary WARN()s, or individual devices fail at to be
> functional.
>
> arch/arm/boot/dts/dbx5x0.dtsi | 17 ++++++-
> arch/arm/mach-ux500/cpu-db8500.c | 1 +
> arch/arm/mach-ux500/cpu.c | 1 +
I provide my Acked-by for patches: 3,4,5,6 of this series.
I tried to apply them to my ux500 fixes branch but it appears
there are dependencies in the .dtsi file and it does not apply
so I guess it's better if you send these to the ARM SoC tree
yourself.
Patches 1,2 need to go through respective subtrees and
I need review comments on the pinctrl patch.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Benoit Cousson @ 2012-10-24 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024161429.GA16350@core.coreip.homeip.net>
Hi Dmitry,
On 10/24/2012 06:14 PM, Dmitry Torokhov wrote:
> On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote:
>> Hi,
>>
>> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote:
>>> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
>>>> Hi Dimitry,
>>>>
>>>> On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
>>>>> Hi Sourav,
>>>>>
>>>>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>>>>>> Adapt keypad to use pinctrl framework.
>>>>>>
>>>>>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>>>>>
>>>>> I do not see anything in the driver that would directly use pinctrl. Is
>>>>> there a better place to select default pin configuration; maybe when
>>>>> instantiating platform device?
>>>>
>>>> Why?
>>>> The devm_pinctrl_get_select_default is using the pinctrl.
>>>
>>> No, I guess we ihave different understanding of what "directly use" means.
>>> This particular driver does directly use interrupts: it requests it and
>>> performs some actions when interrupt arrives. Same goes for IO memory -
>>> it gets requested, then we access it. With pinctrl we do not do anything
>>> - we just ask another layer to configure it and that is it.
>>
>> this is true for almost anything we do:
>>
>> - we ask another layer to allocate memory for us
>> - we ask another layer to call our ISR once the IRQ line is asserted
>> - we ask another layer to handle the input events we just received
>> - we ask another layer to transfer data through DMA for us
>> - we ask another layer to turn regulators on and off.
>
> But we are _directly_ _using_ all of these. You allocate memory and you
> (the driver) stuff data into that memory. You ask for DMA and you take
> the DMAed data and work with it. Not so with pinctrl in omap keypad and
> other drivers I have seen so far.
That's not really true. You select a pin mode and thanks to that you get
the signal from an external pin that goes to your IP.
And thanks to that the IP is doing what your are expecting it to do.
Without that your IP will not get any input signal, which will make it a
little bit useless, isn't it?
>> and so on. This is just how abstractions work, we group common parts in
>> a framework so that users don't need to know the details, but still need
>> to tell the framework when to fiddle with those resources.
>>
>>> I have seen just in a few days 3 or 4 drivers having exactly the same
>>> change - call to devm_pinctrl_get_select_default(), and I guess I will
>>> receive the same patches for the rest of input drivers shortly.
>>> This suggests that the operation is done at the wrong level. Do the
>>> pin configuration as you parse DT data, the same way you set up i2c
>>> devices registers in of_i2c.c, and leave the individual drivers that do
>>> not care about specifics alone.
>>
>> Makes no sense to hide that from drivers. The idea here is that driver
>> should know when it needs its pins to muxed correctly.
>
> The driver also needs memory controller to be initialized, gpio chip be
> ready and registered, DMA subsystem ready, input core reade, etc, etc,
> etc. You however do not have every driver explicitly initialize any of
> that; you expect certain working environment to be already operable. The
> driver does manage resources it controls, it has ultimate knowledge
> about, pin configuration is normally is not it. We just need to know
> that we wired/muxed properly, otherwise we won't work. So please let
> parent layers deal with it.
>
>> 95% of the time
>> it will be done during probe() but then again, so what ?
>>
>> doing that when parsing DT, or on bus notifiers is just plain wrong.
>> Drivers should be required to handle all of their resources.
>
> All of _their_ resources, exactly. They do not own nor control pins so
> they should not be bothered with them either. Look, when you see that
> potentially _every_ driver in the system needs to set up the same object
> that it doe snot use otherwise you should realize that individual driver
> is not the proper place to do that.
What your are missing as well in that case is the explicit dependency
that this API is creating with the pinctrl driver that we are going to
miss otherwise.
Hence the following code.
+ if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
If the pinctrl is not already there you defer the probe until it is there.
Moreover, as already said, we are probably at some point going to handle
as well the low power mode and thus change the pin mode upon idle/suspend.
And again, selecting a pin mode during probe is doing something with the
pins when and only when it is useful. It is not different than getting
an IRQ or DMA request at probe time.
You get it, use it for registration and that all you are doing with it.
It is no different here.
Doing that during device creation does not make sense, since that device
might never be used.
Is it like allocating the memory by default for every devices at boot
time just in case a driver will probe it at some time or registering
every IRQs at boot time just in case a driver will use it...
That's just pointless. We are wasting resources for nothing and thus
potentially power and that will not help the Earth getting any better.
Regards,
Benoit
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Rob Herring @ 2012-10-24 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210241238570.1282-100000@iolanthe.rowland.org>
On 10/24/2012 11:44 AM, Alan Stern wrote:
> On Wed, 24 Oct 2012, Stephen Warren wrote:
>
>> We should absolutely avoid Linux-specific properties where possible.
>>
>> That said, what Linux-specific properties are you talking about? The
>> properties discussed here (has-synopsys-hc-bug, no-io-watchdog, has-tt)
>> are all purely a description of HW, aren't they.
>
> "has-tt" is definitely a description of the HW.
Can you spell out tt.
> "has-synopsys-hc-bug" is too, although determining whether or not it
> should apply to a particular controller might be difficult. I'm
> inclined not to include it among the properties.
What happens when there are 2 synopsys hc bugs? Something more specific
about what the bug is would be better.
> "no-io-watchdog" is not the greatest name. It describes to controllers
> that always do generate IRQs for I/O events when they are supposed to
> (and hence the driver doesn't need to set up a watchdog timer to detect
> I/O completions that didn't generate an IRQ). So while the concept is
> HW-specific, the name refers to a driver implementation issue. A
> better name might be something like "reliable-IRQs". Again, it's not
> such an easy thing to test for. Almost all the existing drivers leave
> it unset.
Shouldn't the default be reliable irqs? What about "unreliable-irqs"?
Rob
^ permalink raw reply
* [PATCH] ARM: PMU: fix runtime PM enable
From: Jon Hunter @ 2012-10-24 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024172325.GK7339@mudshark.cambridge.arm.com>
On 10/24/2012 12:23 PM, Will Deacon wrote:
> On Wed, Oct 24, 2012 at 04:06:07PM +0100, Jon Hunter wrote:
>> On 10/24/2012 09:32 AM, Will Deacon wrote:
>>> Hmmm, now I start to wonder whether your original idea of having separate
>>> callbacks for enable/disable irq and resume/suspend doesn't make more sense.
>>> Then the CTI magic can go in the irq management code and be totally separate
>>> to the PM stuff.
>>>
>>> What do you reckon?
>>
>> The resume/suspend calls really replaced the enable/disable irq
>> callbacks. That still seems like a good approach given that we need
>> runtime PM for OMAP and PMU.
>
> Ok, perhaps splitting it up isn't worth it then. I'm still not convinced
> either way.
Given that we needed to employ runtime PM for OMAP, adding the handlers
is a natural progression and fits more with the PM framework model.
>>> Nah, we should be able to fix this in the platdata, I'd just rather have
>>> function pointers instead of state variables in there.
>>
>> Well, we could pass a pointer to pm_runtime_enable() function in the
>> platdata.
>
> What do other drivers do? Grepping around, I see calls to pm_runtime_enable
> made in various drivers and, given that you pass the device in there, what's
> the problem with us just calling that unconditionally from perf? I know you
> said that will work for OMAP, but I'm trying to understand the effect that
> has on PM-aware platforms that don't require this for the PMU (since this
> seems to be per-device).
I had done this initially when testing on OMAP platforms that do and
don't require runtime PM for PMU. I don't see any side affect of this,
however, may be Kevin could comment on if that is ok. It would be the
best approach.
Cheers
Jon
^ permalink raw reply
* [PATCH v4] pwm: vt8500: Update vt8500 PWM driver support
From: Tony Prisk @ 2012-10-24 17:38 UTC (permalink / raw)
To: linux-arm-kernel
This patch updates pwm-vt8500.c to support devicetree probing and
make use of the common clock subsystem.
A binding document describing the PWM controller found on
arch-vt8500 is also included.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
v4:
return err from clk_enable rather than -EBUSY
.../devicetree/bindings/pwm/vt8500-pwm.txt | 17 ++++
drivers/pwm/pwm-vt8500.c | 86 ++++++++++++++------
2 files changed, 80 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
new file mode 100644
index 0000000..bcc6367
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -0,0 +1,17 @@
+VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
+
+Required properties:
+- compatible: should be "via,vt8500-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2. The first cell specifies the per-chip index
+ of the PWM to use and the second cell is the period in nanoseconds.
+- clocks: phandle to the PWM source clock
+
+Example:
+
+pwm1: pwm at d8220000 {
+ #pwm-cells = <2>;
+ compatible = "via,vt8500-pwm";
+ reg = <0xd8220000 0x1000>;
+ clocks = <&clkpwm>;
+};
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index ad14389..5264962 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -1,7 +1,8 @@
/*
* drivers/pwm/pwm-vt8500.c
*
- * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -21,14 +22,24 @@
#include <linux/io.h>
#include <linux/pwm.h>
#include <linux/delay.h>
+#include <linux/clk.h>
#include <asm/div64.h>
-#define VT8500_NR_PWMS 4
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+
+/*
+ * SoC architecture allocates register space for 4 PWMs but only
+ * 2 are currently implemented.
+ */
+#define VT8500_NR_PWMS 2
struct vt8500_chip {
struct pwm_chip chip;
void __iomem *base;
+ struct clk *clk;
};
#define to_vt8500_chip(chip) container_of(chip, struct vt8500_chip, chip)
@@ -52,7 +63,7 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, prescale, pv, dc;
- c = 25000000/2; /* wild guess --- need to implement clocks */
+ c = clk_get_rate(vt8500->clk);
c = c * period_ns;
do_div(c, 1000000000);
period_cycles = c;
@@ -85,8 +96,15 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ int err;
struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+ err = clk_enable(vt8500->clk);
+ if (err < 0)
+ dev_err(chip->dev, "failed to enable clock\n");
+ return err;
+ };
+
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(5, vt8500->base + (pwm->hwpwm << 4));
return 0;
@@ -98,6 +116,8 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(0, vt8500->base + (pwm->hwpwm << 4));
+
+ clk_disable(vt8500->clk);
}
static struct pwm_ops vt8500_pwm_ops = {
@@ -107,12 +127,24 @@ static struct pwm_ops vt8500_pwm_ops = {
.owner = THIS_MODULE,
};
-static int __devinit pwm_probe(struct platform_device *pdev)
+static const struct of_device_id vt8500_pwm_dt_ids[] = {
+ { .compatible = "via,vt8500-pwm", },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vt8500_pwm_dt_ids);
+
+static int vt8500_pwm_probe(struct platform_device *pdev)
{
struct vt8500_chip *chip;
struct resource *r;
+ struct device_node *np = pdev->dev.of_node;
int ret;
+ if (!np) {
+ dev_err(&pdev->dev, "invalid devicetree node\n");
+ return -EINVAL;
+ }
+
chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
if (chip == NULL) {
dev_err(&pdev->dev, "failed to allocate memory\n");
@@ -124,6 +156,12 @@ static int __devinit pwm_probe(struct platform_device *pdev)
chip->chip.base = -1;
chip->chip.npwm = VT8500_NR_PWMS;
+ chip->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR_OR_NULL(chip->clk)) {
+ dev_err(&pdev->dev, "clock source not specified\n");
+ return PTR_ERR(chip->clk);
+ }
+
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
dev_err(&pdev->dev, "no memory resource defined\n");
@@ -131,18 +169,26 @@ static int __devinit pwm_probe(struct platform_device *pdev)
}
chip->base = devm_request_and_ioremap(&pdev->dev, r);
- if (chip->base == NULL)
+ if (!chip->base)
return -EADDRNOTAVAIL;
+ ret = clk_prepare(chip->clk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to prepare clock\n");
+ return ret;
+ }
+
ret = pwmchip_add(&chip->chip);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to add PWM chip\n");
return ret;
+ }
platform_set_drvdata(pdev, chip);
return ret;
}
-static int __devexit pwm_remove(struct platform_device *pdev)
+static int vt8500_pwm_remove(struct platform_device *pdev)
{
struct vt8500_chip *chip;
@@ -150,28 +196,22 @@ static int __devexit pwm_remove(struct platform_device *pdev)
if (chip == NULL)
return -ENODEV;
+ clk_unprepare(chip->clk);
+
return pwmchip_remove(&chip->chip);
}
-static struct platform_driver pwm_driver = {
+static struct platform_driver vt8500_pwm_driver = {
+ .probe = vt8500_pwm_probe,
+ .remove = vt8500_pwm_remove,
.driver = {
.name = "vt8500-pwm",
.owner = THIS_MODULE,
+ .of_match_table = vt8500_pwm_dt_ids,
},
- .probe = pwm_probe,
- .remove = __devexit_p(pwm_remove),
};
+module_platform_driver(vt8500_pwm_driver);
-static int __init pwm_init(void)
-{
- return platform_driver_register(&pwm_driver);
-}
-arch_initcall(pwm_init);
-
-static void __exit pwm_exit(void)
-{
- platform_driver_unregister(&pwm_driver);
-}
-module_exit(pwm_exit);
-
-MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("VT8500 PWM Driver");
+MODULE_AUTHOR("Tony Prisk <linux@prisktech.co.nz>");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/6] mfd: ab8500-core: Remove unused ab8500-gpio IRQ ranges
From: Linus Walleij @ 2012-10-24 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351089926-32161-2-git-send-email-lee.jones@linaro.org>
On Wed, Oct 24, 2012 at 4:45 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The IRQ ranges provided in ab8500-core to be passed on to the
> ab8500-gpio driver are not only redundant, but they are also
> causing a warning in the boot log. These IRQ ranges, like any
> other MFD related IRQ resource are passed though MFD core for
> automatic conversion to virtual IRQs; however, MFD core does
> not support IRQ mapping of IRQ ranges. Let's just remove them.
>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Hey! That riddes the pesky boot warning.
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Sam, please pick this into the MFD tree for the -rc series!
Yours,
Linus Walleij
^ 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