Re: [PATCH] ARM: dts: igep00x0: Add pinmux configuration for MCBSP2.
Hi Benoit,
2013/9/18 Benoit Cousson bcous...@baylibre.com:
Hi Enric,
On 10/09/2013 17:38, Enric Balletbo Serra wrote:
2013/9/10 Enric Balletbo i Serra eballe...@gmail.com:
Add pinmux configuration for MCBSP2 connected to the TDM interface. With
this configuration the Headset modules works as expected.
Signed-off-by: Enric Balletbo i Serra eballe...@gmail.com
Acked-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/boot/dts/omap3-igep.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index bc48b11..2326d11 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -48,6 +48,15 @@
;
};
+ mcbsp2_pins: pinmux_mcbsp2_pins {
+ pinctrl-single,pins =
+ 0x10c (PIN_INPUT | MUX_MODE0) /*
mcbsp2_fsx.mcbsp2_fsx */
+ 0x10e (PIN_INPUT | MUX_MODE0) /*
mcbsp2_clkx.mcbsp2_clkx */
+ 0x110 (PIN_INPUT | MUX_MODE0) /*
mcbsp2_dr.mcbsp2.dr */
+ 0x112 (PIN_OUTPUT | MUX_MODE0) /*
mcbsp2_dx.mcbsp2_dx */
+ ;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins =
0x114 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_clk.sdmmc1_clk */
@@ -93,6 +102,11 @@
clock-frequency = 40;
};
+mcbsp2 {
+ pinctrl-names = default;
+ pinctrl-0 = mcbsp2_pins;
+};
+
mmc1 {
pinctrl-names = default;
pinctrl-0 = mmc1_pins;
--
1.8.1.2
Hi Benoit,
I sent this patch some time ago to be merged as a fix for 3.11, but
seems was not merged. Would be possible include this patch in these
series ?
I'm really sorry I missed that one :-(
I'm applying it right now, and will update my pull request.
Thanks,
Benoit
Many thanks.
Best regards,
Enric
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCF857x and 16-bit GPIO expanders
On 9/18/2013 11:06 PM, Felipe Balbi wrote: Hi, On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote: On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote: On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote: has anyone ever successfully using gpio-pcf857x.c driver with 16-bit gpio expanders ? We're having some issues here where toggling the last gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I can't come up with any explanation of why would it hang... Bouncing the question to George, Laurent and Kuninori... I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as far as I know. I can try toggling I/O 15, but that will need to wait until next week as I'm currently travelling without access to the hardware. alright, that'd help me a lot :-) Just want to make sure if we're having a board issue, or PCF8575 is a bit screwy ;-) Is it on dra7x-evm if so which pcf device (i2c address)? The pins i were interested were only 1 and 2 I never tried pin 15. Just tried toggling through sysfs and it works for me. Thanks -- -George -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that require
regulators. The output's connect op tries to get a regulator which may not exist
yet because it might get registered later in the kernel boot.
omapdrm currently ignores those panels which return a non zero value when
connected. A better approach would be for omapdrm to request for probe
deferral if a panel's connect op returns -EPROBE_DEFER.
The connecting of panels is moved very early in the the drm device's probe
before anything else is initialized. When we enter omap_modeset_init(), we have
a set of panels that have been connected. We now proceed with registering only
those panels which are already connected.
Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.
This fixes boot with omapdrm on an omap4 panda ES board. The regulators used by
HDMI aren't initialized because I2c isn't initialized, I2C isn't initialized
as it's pins are not configured because pinctrl is yet to probe.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +++
drivers/gpu/drm/omapdrm/omap_drv.c | 64 -
drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0fd2eb1..9c01311 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -623,6 +623,11 @@ void omap_crtc_pre_init(void)
dss_install_mgr_ops(mgr_ops);
}
+void omap_crtc_pre_uninit(void)
+{
+ dss_uninstall_mgr_ops();
+}
+
/* initialize crtc */
struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2603d90..45fbb1c 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -87,6 +87,37 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static int omap_connect_dssdevs(void)
+{
+ int r;
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ r = dssdev-driver-connect(dssdev);
+ if (r == -EPROBE_DEFER) {
+ omap_dss_put_device(dssdev);
+ goto cleanup;
+ } else if (r) {
+ dev_warn(dssdev-dev, could not connect display: %s\n,
+ dssdev-name);
+ }
+ }
+
+ return 0;
+
+cleanup:
+ /*
+* if we are deferring probe, we disconnect the devices we previously
+* connected
+*/
+ dssdev = NULL;
+
+ for_each_dss_dev(dssdev)
+ dssdev-driver-disconnect(dssdev);
+
+ return r;
+}
+
static int omap_modeset_init(struct drm_device *dev)
{
struct omap_drm_private *priv = dev-dev_private;
@@ -95,9 +126,6 @@ static int omap_modeset_init(struct drm_device *dev)
int num_mgrs = dss_feat_get_num_mgrs();
int num_crtcs;
int i, id = 0;
- int r;
-
- omap_crtc_pre_init();
drm_mode_config_init(dev);
@@ -119,26 +147,8 @@ static int omap_modeset_init(struct drm_device *dev)
enum omap_channel channel;
struct omap_overlay_manager *mgr;
- if (!dssdev-driver) {
- dev_warn(dev-dev, %s has no driver.. skipping it\n,
- dssdev-name);
- continue;
- }
-
- if (!(dssdev-driver-get_timings ||
- dssdev-driver-read_edid)) {
- dev_warn(dev-dev, %s driver does not support
- get_timings or read_edid.. skipping it!\n,
- dssdev-name);
+ if (!omapdss_device_is_connected(dssdev))
continue;
- }
-
- r = dssdev-driver-connect(dssdev);
- if (r) {
- dev_err(dev-dev, could not connect display: %s\n,
- dssdev-name);
- continue;
- }
encoder = omap_encoder_init(dev, dssdev);
@@ -656,9 +666,19 @@ static void pdev_shutdown(struct platform_device *device)
static int pdev_probe(struct platform_device *device)
{
+ int r;
+
if (omapdss_is_initialized() == false)
return -EPROBE_DEFER;
+ omap_crtc_pre_init();
+
+ r = omap_connect_dssdevs();
+ if (r) {
+ omap_crtc_pre_uninit();
+
[PATCH 2/2] drm: omap: disconnect devices when omapdrm module is removed
omapdrm established connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it can also
cause problems when omapdrm is re-inserted.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/gpu/drm/omapdrm/omap_drv.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 45fbb1c..44a1203 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static void omap_disconnect_dssdevs(void)
+{
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev)
+ dssdev-driver-disconnect(dssdev);
+}
static int omap_connect_dssdevs(void)
{
@@ -110,10 +117,7 @@ cleanup:
* if we are deferring probe, we disconnect the devices we previously
* connected
*/
- dssdev = NULL;
-
- for_each_dss_dev(dssdev)
- dssdev-driver-disconnect(dssdev);
+ omap_disconnect_dssdevs();
return r;
}
@@ -688,6 +692,8 @@ static int pdev_remove(struct platform_device *device)
DBG();
drm_platform_exit(omap_drm_driver, device);
+ omap_disconnect_dssdevs();
+
platform_driver_unregister(omap_dmm_driver);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
3.12-rc1: no longer compiles for Nokia n900 (omap based)
Hi! I get: CC arch/arm/kernel/machine_kexec.o /tmp/ccCFXeXG.s: Assembler messages: /tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb nshst' /tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh' make[1]: *** [arch/arm/kernel/suspend.o] Error 1 make[1]: *** Waiting for unfinished jobs pavel@amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5 Minimum required gcc is 3.2, so I'm safe. I suspect commit 62cbbc42e0019aff6310259f275ae812463f8836 Author: Will Deacon will.dea...@arm.com Date: Thu May 23 18:43:58 2013 +0100 Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On Tuesday 17 September 2013 07:59 PM, Joel Fernandes wrote: On 09/17/2013 01:05 AM, Sekhar Nori wrote: [..] mixed messages. In short, we aim for consistency with situation today, not tomorrow. What you're asking to do infact breaks consistency with the rest of the code. Well, ideally we support second CC even with DT to be consistent all around. Since that has not happened, I don't want the code to pretend that it it supports the second channel controller with DT that too only in parts of code. Ok, I agree that the bindings don't talk about encoding a controller number in the channel provided from DT so it shouldn't assume that without binding updates. Following this suggestion, I've update the patch to the below: ---8--- From: Joel Fernandes jo...@ti.com Subject: [PATCH v6] ARM: EDMA: Fix clearing of unused list for DT DMA resources HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. The above issue is fixed by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list if the dma controller used by any device is EDMA. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Also introduced is a minor clean up of a checkpatch error in old code. The patch looks good to me. I made some modifications to commit message - mostly for brevity. ARM: edma: dt: create unused channel list HWMOD removal for MMC is breaking edma_start() as the events are being manually triggered due to EDMA unused channel list not being ready. The above issue is fixed by reading the dmas property from the DT node if it exists and then clearing the bits in the unused channel list if the dma controller used by any device is EDMA. This is similar to approach taken in non-DT case. Also introduced is a minor clean up of a checkpatch error in old code. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.12-rc1: no longer compiles for Nokia n900 (omap based)
On Thu, Sep 19, 2013 at 10:30:02AM +0100, Pavel Machek wrote: Hi! I get: CC arch/arm/kernel/machine_kexec.o /tmp/ccCFXeXG.s: Assembler messages: /tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb nshst' /tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh' make[1]: *** [arch/arm/kernel/suspend.o] Error 1 make[1]: *** Waiting for unfinished jobs pavel@amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5 Minimum required gcc is 3.2, so I'm safe. Please check your binutils. = 2.22 has been reported to work. Will1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.12-rc1: no longer compiles for Nokia n900 (omap based), display no longer works
On Thu 2013-09-19 11:30:02, Pavel Machek wrote:
Hi!
I get:
CC arch/arm/kernel/machine_kexec.o
/tmp/ccCFXeXG.s: Assembler messages:
/tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb
nshst'
/tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh'
make[1]: *** [arch/arm/kernel/suspend.o] Error 1
make[1]: *** Waiting for unfinished jobs
pavel@amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5
Minimum required gcc is 3.2, so I'm safe.
I suspect
commit 62cbbc42e0019aff6310259f275ae812463f8836
Author: Will Deacon will.dea...@arm.com
Date: Thu May 23 18:43:58 2013 +0100
And
commit 6af396a6b6c698eb3834184518fc9a59bc22c817
Author: Will Deacon will.dea...@arm.com
Date: Wed Jun 12 10:03:30 2013 +0100
and
commit 73a6fdc48bf52e93c26874dc8c0f0f8d5585a809
Author: Will Deacon will.dea...@arm.com
Date: Mon May 13 11:39:50 2013 +0100
and
commit 6abdd491698a27f7df04a32ca12cc453810e4396
Author: Will Deacon will.dea...@arm.com
Date: Mon May 13 12:01:12 2013 +0100
Now I've reverted those, and it seems to build... and boot, but
something in 3.12-rc1 broke display :-(. (dmesg diff attached at the
end, maybe someone knows...)
Signed-off-by: Pavel Machek pa...@ucw.cz
Pavel
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index 15f2d5b..bfd37e5 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -351,7 +351,7 @@ static inline void flush_cache_vmap(unsigned long start,
unsigned long end)
* set_pte_at() called from vmap_pte_range() does not
* have a DSB after cleaning the cache line.
*/
- dsb(ishst);
+ dsb();
}
static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 4f2c280..b07c09e 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -46,7 +46,7 @@ static inline void dsb_sev(void)
{
#if __LINUX_ARM_ARCH__ = 7
__asm__ __volatile__ (
- dsb ishst\n
+ dsb\n
SEV
);
#else
diff --git a/arch/arm/include/asm/switch_to.h b/arch/arm/include/asm/switch_to.h
index c99e259..fa09e6b 100644
--- a/arch/arm/include/asm/switch_to.h
+++ b/arch/arm/include/asm/switch_to.h
@@ -4,16 +4,6 @@
#include linux/thread_info.h
/*
- * For v7 SMP cores running a preemptible kernel we may be pre-empted
- * during a TLB maintenance operation, so execute an inner-shareable dsb
- * to ensure that the maintenance completes in case we migrate to another
- * CPU.
- */
-#if defined(CONFIG_PREEMPT) defined(CONFIG_SMP) defined(CONFIG_CPU_V7)
-#define finish_arch_switch(prev) dsb(ish)
-#endif
-
-/*
* switch_to(prev, next) should switch from task `prev' to `next'
* `prev' will never be the same as `next'. schedule() itself
* contains the memory barrier to tell GCC not to cache `current'.
diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 3896026..8471824 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -335,13 +335,13 @@ static inline void local_flush_tlb_all(void)
const unsigned int __tlb_flag = __cpu_tlb_flags;
if (tlb_flag(TLB_WB))
- dsb(nshst);
+ dsb();
__local_flush_tlb_all();
tlb_op(TLB_V7_UIS_FULL, c8, c7, 0, zero);
if (tlb_flag(TLB_BARRIER)) {
- dsb(nsh);
+ dsb();
isb();
}
}
@@ -352,13 +352,13 @@ static inline void __flush_tlb_all(void)
const unsigned int __tlb_flag = __cpu_tlb_flags;
if (tlb_flag(TLB_WB))
- dsb(ishst);
+ dsb();
__local_flush_tlb_all();
tlb_op(TLB_V7_UIS_FULL, c8, c3, 0, zero);
if (tlb_flag(TLB_BARRIER)) {
- dsb(ish);
+ dsb();
isb();
}
}
@@ -388,13 +388,13 @@ static inline void local_flush_tlb_mm(struct mm_struct
*mm)
const unsigned int __tlb_flag = __cpu_tlb_flags;
if (tlb_flag(TLB_WB))
- dsb(nshst);
+ dsb();
__local_flush_tlb_mm(mm);
tlb_op(TLB_V7_UIS_ASID, c8, c7, 2, asid);
if (tlb_flag(TLB_BARRIER))
- dsb(nsh);
+ dsb();
}
static inline void __flush_tlb_mm(struct mm_struct *mm)
@@ -402,7 +402,7 @@ static inline void __flush_tlb_mm(struct mm_struct *mm)
const unsigned int __tlb_flag = __cpu_tlb_flags;
if (tlb_flag(TLB_WB))
- dsb(ishst);
+ dsb();
__local_flush_tlb_mm(mm);
#ifdef CONFIG_ARM_ERRATA_720789
@@ -412,7 +412,7 @@ static inline void __flush_tlb_mm(struct mm_struct *mm)
#endif
if
Re: 3.12-rc1: no longer compiles for Nokia n900 (omap based)
On Thu 2013-09-19 10:36:28, Will Deacon wrote: On Thu, Sep 19, 2013 at 10:30:02AM +0100, Pavel Machek wrote: Hi! I get: CC arch/arm/kernel/machine_kexec.o /tmp/ccCFXeXG.s: Assembler messages: /tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb nshst' /tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh' make[1]: *** [arch/arm/kernel/suspend.o] Error 1 make[1]: *** Waiting for unfinished jobs pavel@amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5 Minimum required gcc is 3.2, so I'm safe. Please check your binutils. = 2.22 has been reported to work. pavel@amd:/data/l/linux-good$ arm-linux-gnueabi-ld --version GNU ld (GNU Binutils for Debian) 2.20.1.20100303 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. but Documentation/Changes: o binutils 2.12# ld -v Can the code be fixed so that binutils 2.12 still work? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drm: omap: disconnect devices when omapdrm module is removed
On 19/09/13 11:49, Archit Taneja wrote:
omapdrm established connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it can also
cause problems when omapdrm is re-inserted.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/gpu/drm/omapdrm/omap_drv.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 45fbb1c..44a1203 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static void omap_disconnect_dssdevs(void)
+{
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev)
+ dssdev-driver-disconnect(dssdev);
+}
With a quick test, it looks like omapdrm leaves the displays enabled
when exiting. This can be fixed by adding to the above loop:
if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED)
dssdev-driver-disable(dssdev);
However... omapdrm still crashes when unloading, and it could be somehow
related to leaving something un-removed. Disabling a CRTC should disable
the display, and maybe omapdrm should disable (and clean-up) all CRTCs
on exit, and maybe that would remove the crash, and also fix the issue
of leaving displays enabled.
But I'm just guessing there, I have no idea how the process of unloading
a drm driver goes.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] drm: omap: disconnect devices when omapdrm module is removed
Hi,
On Thursday 19 September 2013 03:38 PM, Tomi Valkeinen wrote:
On 19/09/13 11:49, Archit Taneja wrote:
omapdrm established connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it can also
cause problems when omapdrm is re-inserted.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/gpu/drm/omapdrm/omap_drv.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 45fbb1c..44a1203 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static void omap_disconnect_dssdevs(void)
+{
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev)
+ dssdev-driver-disconnect(dssdev);
+}
With a quick test, it looks like omapdrm leaves the displays enabled
when exiting. This can be fixed by adding to the above loop:
if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED)
dssdev-driver-disable(dssdev);
However... omapdrm still crashes when unloading, and it could be somehow
related to leaving something un-removed. Disabling a CRTC should disable
the display, and maybe omapdrm should disable (and clean-up) all CRTCs
on exit, and maybe that would remove the crash, and also fix the issue
of leaving displays enabled.
But I'm just guessing there, I have no idea how the process of unloading
a drm driver goes.
It seems like dev_unload is the place where we should disconnect the
dssdevs.
omap_modeset_free() calls drm_mode_config_cleanup() which calls omapdrm
specific destroy funcs for connectors, encoders and crtcs.
I don't think crtcs should disable the device. I think it's the
encoder(and connector) which is mapped to a display. The omap_encoder's
destroy op should disable the dssdev device.
I'm not sure about this though. Rob, do you have any comment on this?
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 04/11] ASoC: davinci-mcasp: Extract DMA channels directly from DT
Extract DMA channels directly from DT as they can not be found from
platform resources anymore. This is a work-around until davinci audio
driver is updated to use dmaengine.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-mcasp-audio.txt |5 +++
include/linux/platform_data/davinci_asp.h |2 +
sound/soc/davinci/davinci-mcasp.c | 47 +---
3 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index 63b67ae..68e0f47 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -18,6 +18,11 @@ Required properties:
- serial-dir : A list of serializer pin mode. The list number should be equal
to num-serializer parameter. Each entry is a number indication
serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
+- dmas: two element list of DMA controller phandles and DMA request line
+ordered pairs.
+- dma-names: identifier string for each DMA request line in the dmas property.
+These strings correspond 1:1 with the ordered pairs in dmas. The
dma
+identifiers must be rx and tx.
Optional properties:
diff --git a/include/linux/platform_data/davinci_asp.h
b/include/linux/platform_data/davinci_asp.h
index 8db5ae0..689a856 100644
--- a/include/linux/platform_data/davinci_asp.h
+++ b/include/linux/platform_data/davinci_asp.h
@@ -84,6 +84,8 @@ struct snd_platform_data {
u8 version;
u8 txnumevt;
u8 rxnumevt;
+ int tx_dma_channel;
+ int rx_dma_channel;
};
enum {
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index a056fc5..acbf5f8 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1047,6 +1047,7 @@ static struct snd_platform_data
*davinci_mcasp_set_pdata_from_of(
struct snd_platform_data *pdata = NULL;
const struct of_device_id *match =
of_match_device(mcasp_dt_ids, pdev-dev);
+ struct of_phandle_args dma_spec;
const u32 *of_serial_dir32;
u8 *of_serial_dir;
@@ -1109,6 +1110,28 @@ static struct snd_platform_data
*davinci_mcasp_set_pdata_from_of(
pdata-serial_dir = of_serial_dir;
}
+ ret = of_property_match_string(np, dma-names, tx);
+ if (ret 0)
+ goto nodata;
+
+ ret = of_parse_phandle_with_args(np, dmas, #dma-cells, ret,
+dma_spec);
+ if (ret 0)
+ goto nodata;
+
+ pdata-tx_dma_channel = dma_spec.args[0];
+
+ ret = of_property_match_string(np, dma-names, rx);
+ if (ret 0)
+ goto nodata;
+
+ ret = of_parse_phandle_with_args(np, dmas, #dma-cells, ret,
+dma_spec);
+ if (ret 0)
+ goto nodata;
+
+ pdata-rx_dma_channel = dma_spec.args[0];
+
ret = of_property_read_u32(np, tx-num-evt, val);
if (ret = 0)
pdata-txnumevt = val;
@@ -1139,7 +1162,7 @@ nodata:
static int davinci_mcasp_probe(struct platform_device *pdev)
{
struct davinci_pcm_dma_params *dma_data;
- struct resource *mem, *ioarea, *res;
+ struct resource *mem, *ioarea, *res, *dma;
struct snd_platform_data *pdata;
struct davinci_audio_dev *dev;
int ret;
@@ -1213,15 +1236,11 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
dma_data-sram_size = pdata-sram_size_playback;
dma_data-dma_addr = dma-start + pdata-tx_dma_offset;
- /* first TX, then RX */
res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!res) {
- dev_err(pdev-dev, no DMA resource\n);
- ret = -ENODEV;
- goto err_release_clk;
- }
-
- dma_data-channel = res-start;
+ if (res)
+ dma_data-channel = res-start;
+ else
+ dma_data-channel = pdata-tx_dma_channel;
dma_data = dev-dma_params[SNDRV_PCM_STREAM_CAPTURE];
dma_data-asp_chan_q = pdata-asp_chan_q;
@@ -1231,13 +1250,11 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
dma_data-dma_addr = dma-start + pdata-rx_dma_offset;
res = platform_get_resource(pdev, IORESOURCE_DMA, 1);
- if (!res) {
- dev_err(pdev-dev, no DMA resource\n);
- ret = -ENODEV;
- goto err_release_clk;
- }
+ if (res)
+ dma_data-channel = res-start;
+ else
+ dma_data-channel = pdata-rx_dma_channel;
- dma_data-channel = res-start;
dev_set_drvdata(pdev-dev, dev);
ret = snd_soc_register_component(pdev-dev, davinci_mcasp_component,
[PATCH v3 02/11] ASoC: davinci-evm: Add device tree binding
From: Hebbar, Gururaja gururaja.heb...@ti.com
Device tree support for Davinci Machine driver
When the board boots with device tree, the driver will receive card,
codec, dai interface details (like the card name, DAPM routing map,
phandle for the audio components described in the dts file, codec mclk
speed). The card will be set up based on this information. Since the
routing is provided via DT we can mark the card fully routed so core
can take care of disconnecting the unused pins.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-evm-audio.txt | 58 ++
sound/soc/davinci/davinci-evm.c| 120 +++-
2 files changed, 176 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
new file mode 100644
index 000..e6b61ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -0,0 +1,58 @@
+* Texas Instruments SoC audio setups with TLV320AIC3X Codec
+
+Required properties:
+- compatible : ti,da830-evm-audio : forDM365/DA8xx/OMAPL1x/AM33xx
+- ti,model : The user-visible name of this sound complex.
+- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
+- ti,mcasp-controller : The phandle of the McASP controller
+- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
+- ti,audio-routing : A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source. Valid names for sources and
+ sinks are the codec's pins, and the jacks on the board:
+
+ TLV320AIC3X pins:
+
+ * LLOUT
+ * RLOUT
+ * MONO_LOUT
+ * HPLOUT
+ * HPROUT
+ * HPLCOM
+ * HPRCOM
+ * MIC3L
+ * MIC3R
+ * LINE1L
+ * LINE2L
+ * LINE1R
+ * LINE2R
+
+ Board connectors:
+
+ * Headphone Jack
+ * Line Out
+ * Mic Jack
+ * Line In
+
+
+Example:
+
+sound {
+ compatible = ti,da830-evm-audio;
+ ti,model = DA830 EVM;
+ ti,audio-codec = tlv320aic3x;
+ ti,mcasp-controller = mcasp1;
+ ti,codec-clock-rate = 1200;
+ ti,audio-routing =
+ Headphone Jack, HPLOUT,
+ Headphone Jack, HPROUT,
+ Line Out, LLOUT,
+ Line Out, RLOUT,
+ MIC3L,Mic Bias 2V,
+ MIC3R,Mic Bias 2V,
+ Mic Bias 2V, Mic Jack,
+ LINE1L, Line In,
+ LINE2L, Line In,
+ LINE1R, Line In,
+ LINE2R, Line In;
+};
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 2f8161c..340a68d 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -16,6 +16,7 @@
#include linux/platform_device.h
#include linux/platform_data/edma.h
#include linux/i2c.h
+#include linux/of_platform.h
#include sound/core.h
#include sound/pcm.h
#include sound/soc.h
@@ -23,6 +24,8 @@
#include asm/dma.h
#include asm/mach-types.h
+#include linux/edma.h
+
#include davinci-pcm.h
#include davinci-i2s.h
#include davinci-mcasp.h
@@ -121,13 +124,22 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
{
struct snd_soc_codec *codec = rtd-codec;
struct snd_soc_dapm_context *dapm = codec-dapm;
+ struct device_node *np = codec-card-dev-of_node;
+ int ret;
/* Add davinci-evm specific widgets */
snd_soc_dapm_new_controls(dapm, aic3x_dapm_widgets,
ARRAY_SIZE(aic3x_dapm_widgets));
- /* Set up davinci-evm specific audio path audio_map */
- snd_soc_dapm_add_routes(dapm, audio_map, ARRAY_SIZE(audio_map));
+ if (np) {
+ ret = snd_soc_of_parse_audio_routing(codec-card,
+ ti,audio-routing);
+ if (ret)
+ return ret;
+ } else {
+ /* Set up davinci-evm specific audio path audio_map */
+ snd_soc_dapm_add_routes(dapm, audio_map, ARRAY_SIZE(audio_map));
+ }
/* not connected */
snd_soc_dapm_disable_pin(dapm, MONO_LOUT);
@@ -312,6 +324,98 @@ static struct snd_soc_card da850_snd_soc_card = {
.drvdata = da850_snd_soc_card_drvdata,
};
+#if defined(CONFIG_OF)
+
+/*
+ * The struct is used as place holder. It will be completely
+ * filled with data from dt node.
+ */
+static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
+ .name = TLV320AIC3X,
+ .stream_name= AIC3X,
+ .codec_dai_name = tlv320aic3x-hifi,
+ .ops=
[PATCH v3 05/11] ASoC: davinci-mcasp: Interrupts property to optional and add interrupt-names
Makes interrupts property optional as the interrupts are not currently
used by the driver and adds interrupt-names property to name listed
interrupts. Currently know interrupt names are tx and rx.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-mcasp-audio.txt |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index 68e0f47..2fd0bf2 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -11,7 +11,6 @@ Required properties:
- reg-names : The mandatory reg-range must be named mpu and the optional DMA
reg-range must be named dma. For backward compatibility it is
good to keep mpu first in the list.
-- interrupts : Interrupt number for McASP
- op-mode : I2S/DIT ops mode.
- tdm-slots : Slots for TDM operation.
- num-serializer : Serializers used by McASP.
@@ -31,6 +30,8 @@ Optional properties:
- rx-num-evt : FIFO levels.
- sram-size-playback : size of sram to be allocated during playback
- sram-size-capture : size of sram to be allocated during capture
+- interrupts : Interrupt numbers for McASP, currently not used by the driver
+- interrupt-names : Known interrupt names are tx and rx
Example:
@@ -41,6 +42,7 @@ mcasp0: mcasp0@1d0 {
reg = 0x10 0x3000;
reg-names mpu;
interrupts = 82 83;
+ interrupts-names = tx, rx;
op-mode = 0; /* MCASP_IIS_MODE */
tdm-slots = 2;
num-serializer = 16;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/11] ASoC: davinci-evm: Move sysclk logic away from evm_hw_params
The sysclk rate does not change runtime so it should be initialized at
init time.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/davinci/davinci-evm.c | 64 +++
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index fd7c45b..2f8161c 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -27,6 +27,10 @@
#include davinci-i2s.h
#include davinci-mcasp.h
+struct snd_soc_card_drvdata_davinci {
+ unsigned sysclk;
+};
+
#define AUDIO_FORMAT (SND_SOC_DAIFMT_DSP_B | \
SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_IB_NF)
static int evm_hw_params(struct snd_pcm_substream *substream,
@@ -35,27 +39,11 @@ static int evm_hw_params(struct snd_pcm_substream
*substream,
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *codec_dai = rtd-codec_dai;
struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
+ struct snd_soc_codec *codec = rtd-codec;
+ struct snd_soc_card *soc_card = codec-card;
int ret = 0;
- unsigned sysclk;
-
- /* ASP1 on DM355 EVM is clocked by an external oscillator */
- if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm() ||
- machine_is_davinci_dm365_evm())
- sysclk = 2700;
-
- /* ASP0 in DM6446 EVM is clocked by U55, as configured by
-* board-dm644x-evm.c using GPIOs from U18. There are six
-* options; here we know we use a 48 KHz sample rate.
-*/
- else if (machine_is_davinci_evm())
- sysclk = 12288000;
-
- else if (machine_is_davinci_da830_evm() ||
- machine_is_davinci_da850_evm())
- sysclk = 24576000;
-
- else
- return -EINVAL;
+ unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))-sysclk;
/* set codec DAI configuration */
ret = snd_soc_dai_set_fmt(codec_dai, AUDIO_FORMAT);
@@ -243,35 +231,65 @@ static struct snd_soc_dai_link da850_evm_dai = {
};
/* davinci dm6446 evm audio machine driver */
+/*
+ * ASP0 in DM6446 EVM is clocked by U55, as configured by
+ * board-dm644x-evm.c using GPIOs from U18. There are six
+ * options; here we know we use a 48 KHz sample rate.
+ */
+static struct snd_soc_card_drvdata_davinci dm6446_snd_soc_card_drvdata = {
+ .sysclk = 12288000,
+};
+
static struct snd_soc_card dm6446_snd_soc_card_evm = {
.name = DaVinci DM6446 EVM,
.owner = THIS_MODULE,
.dai_link = dm6446_evm_dai,
.num_links = 1,
+ .drvdata = dm6446_snd_soc_card_drvdata,
};
/* davinci dm355 evm audio machine driver */
+/* ASP1 on DM355 EVM is clocked by an external oscillator */
+static struct snd_soc_card_drvdata_davinci dm355_snd_soc_card_drvdata = {
+ .sysclk = 2700,
+};
+
static struct snd_soc_card dm355_snd_soc_card_evm = {
.name = DaVinci DM355 EVM,
.owner = THIS_MODULE,
.dai_link = dm355_evm_dai,
.num_links = 1,
+ .drvdata = dm355_snd_soc_card_drvdata,
};
/* davinci dm365 evm audio machine driver */
+static struct snd_soc_card_drvdata_davinci dm365_snd_soc_card_drvdata = {
+ .sysclk = 2700,
+};
+
static struct snd_soc_card dm365_snd_soc_card_evm = {
.name = DaVinci DM365 EVM,
.owner = THIS_MODULE,
.dai_link = dm365_evm_dai,
.num_links = 1,
+ .drvdata = dm365_snd_soc_card_drvdata,
};
/* davinci dm6467 evm audio machine driver */
+static struct snd_soc_card_drvdata_davinci dm6467_snd_soc_card_drvdata = {
+ .sysclk = 2700,
+};
+
static struct snd_soc_card dm6467_snd_soc_card_evm = {
.name = DaVinci DM6467 EVM,
.owner = THIS_MODULE,
.dai_link = dm6467_evm_dai,
.num_links = ARRAY_SIZE(dm6467_evm_dai),
+ .drvdata = dm6467_snd_soc_card_drvdata,
+};
+
+static struct snd_soc_card_drvdata_davinci da830_snd_soc_card_drvdata = {
+ .sysclk = 24576000,
};
static struct snd_soc_card da830_snd_soc_card = {
@@ -279,6 +297,11 @@ static struct snd_soc_card da830_snd_soc_card = {
.owner = THIS_MODULE,
.dai_link = da830_evm_dai,
.num_links = 1,
+ .drvdata = da830_snd_soc_card_drvdata,
+};
+
+static struct snd_soc_card_drvdata_davinci da850_snd_soc_card_drvdata = {
+ .sysclk = 24576000,
};
static struct snd_soc_card da850_snd_soc_card = {
@@ -286,6 +309,7 @@ static struct snd_soc_card da850_snd_soc_card = {
.owner = THIS_MODULE,
.dai_link = da850_evm_dai,
.num_links = 1,
+ .drvdata = da850_snd_soc_card_drvdata,
};
static struct platform_device *evm_snd_device;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v3 00/11] Fix AM335x-evm analog audio support
The RFC version of patches can been found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066178.html The v2 version of patches can be found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066379.html Changes since v2 [PATCH v2 01/11] ASoC: davinci-evm: Move sysclk logic away from evm_hw_params - no change [PATCH v2 02/11] ASoC: davinci-evm: Add device tree binding - no change [PATCH v2 03/11] ASoC: davinci-mcasp: Add DMA register locations to DT - no change [PATCH v2 04/11] ASoC: davinci-mcasp: Extract DMA channels directly from DT - no change [PATCH v2 05/11] ASoC: davinci-mcasp: Remove interrupt property from DT bindin - restore binding but make it optional and add interrupt-names property [PATCH v2 06/11] ASoC: davinci: Add support for AM33xx SoC Audio - SND_DAVINCI_SOC help Machine driver for ... - Platform driver for ... - SND_AM33XX_SOC_EVM depends on SND_DAVINCI_SOC SOC_AM33XX - SND_AM33XX_SOC_EVM does not selcet SND_DAVINCI_SOC [PATCH v2 07/11] ASoC: tlv320aic3x: Add regulators to DT bindings document - no change [PATCH v2 08/11] ASoC: tlv320aic3x: Add codec pins to DT bindings document - no change [PATCH v2 09/11] ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries - restore interrupt property and add interrupt-names property [PATCH v2 10/11] ARM/dts: am33xx: mcasp: Add new dma register location to reg-property - no change [PATCH v2 11/11] ARM/dts: am335x-evm: Add audio support for am335x-evm.dts - no change Changes from RFC to v2 - Dropped out ASoC: davinci-mcasp: Add pinctrl support since driver core is taking care of this now. - Cleanup am33xx audio build - Add regulators to tlv320aic3x DT binding document - Remove dm365-voice-codec-audio DT support as it has never been tested an probably does not work - Add output pins and Line In connector to davinci-evm-audio DT binding doc - Remove asp_chan_q and ram_chan_q properties from mcasp DT node in DT mode mcasp is hardcoded to event queue 0 (highest priority) - Add pins to tlv320aic3x DT bindings document. If I misunderstood Marks comment and this patch is not needed, then just leave it out Changes based on TI internal discussions - Move system clock rate logic away from from evm_hw_params soc-op - Remove unnecesary #if defined(CONFIG_OF) from davinci-evm.c - Make dma property DT binding document more exact - Add only dma reg location instead of separate dma-tx and dma-rx - Primarily look for mpu reg property, but fall back to index 0 if not found - Remove interrupt property from mcasp DT node as it is not used - Remove #address-cells and #size-cells mcasp properties as they are not needed This set of patches fixes the basic audio support for am335x-evm. It should also be relatively simple to add the necessary nodes to relevant dts files to get BeagleBone + AudioCape and am335x-evmsk working too. The patch set depends on following patches: [PATCH v11 4/8] ARM: dts: add AM33XX EDMA support https://lkml.org/lkml/2013/6/18/49 [PATCH v11 5/8] ARM: dts: add AM33XX SPI DMA support https://lkml.org/lkml/2013/6/18/55 [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA resources https://lkml.org/lkml/2013/7/22/441 I have tried my best not to break the existing support for older davinci boards, but since I do not have those boards I can not be sure. Some commit comments refer to a dmaengine based davinci audio implementation which is planned for but nothing has been done yet. Best regards, Jyri Darren Etheridge (1): ARM/dts: am335x-evm: Add audio support for am335x-evm.dts Hebbar, Gururaja (2): ASoC: davinci-evm: Add device tree binding ASoC: davinci: Add support for AM33xx SoC Audio Jyri Sarha (7): ASoC: davinci-evm: Move sysclk logic away from evm_hw_params ASoC: davinci-mcasp: Add DMA register locations to DT ASoC: davinci-mcasp: Extract DMA channels directly from DT ASoC: davinci-mcasp: Interrupts property to optional and add interrupt-names ASoC: tlv320aic3x: Add regulators to DT bindings document ASoC: tlv320aic3x: Add codec pins to DT bindings document ARM/dts: am33xx: mcasp: Add new dma register location to reg-property Pantelis Antoniou (1): ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries .../bindings/sound/davinci-evm-audio.txt | 58 ++ .../bindings/sound/davinci-mcasp-audio.txt | 17 +- .../devicetree/bindings/sound/tlv320aic3x.txt | 26 +++ arch/arm/boot/dts/am335x-evm.dts | 56 ++ arch/arm/boot/dts/am33xx.dtsi | 29 +++ include/linux/platform_data/davinci_asp.h |2 + sound/soc/davinci/Kconfig | 18 +- sound/soc/davinci/Makefile |1 + sound/soc/davinci/davinci-evm.c| 184 +--- sound/soc/davinci/davinci-mcasp.c | 106
[PATCH v3 03/11] ASoC: davinci-mcasp: Add DMA register locations to DT
This patch adds DMA register location to mcasp DT bindings. On am33xx
SoCs the McASP registers are mapped trough L4 interconnect, which is
not accessible by the DMA controller, so McASP data port is mapped
trough L3 to a different location.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../bindings/sound/davinci-mcasp-audio.txt |8 ++-
sound/soc/davinci/davinci-mcasp.c | 59 +---
2 files changed, 46 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index 374e145..63b67ae 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -6,7 +6,11 @@ Required properties:
ti,da830-mcasp-audio : for both DA830 DA850 platforms
ti,omap2-mcasp-audio : for OMAP2 platforms (TI81xx, AM33xx)
-- reg : Should contain McASP registers offset and length
+- reg : Should contain McASP registers address and length for mpu and
+ optionally for dma controller access.
+- reg-names : The mandatory reg-range must be named mpu and the optional DMA
+ reg-range must be named dma. For backward compatibility it is
+ good to keep mpu first in the list.
- interrupts : Interrupt number for McASP
- op-mode : I2S/DIT ops mode.
- tdm-slots : Slots for TDM operation.
@@ -15,7 +19,6 @@ Required properties:
to num-serializer parameter. Each entry is a number indication
serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
-
Optional properties:
- ti,hwmods : Must be mcaspn, n is controller instance starting 0
@@ -31,6 +34,7 @@ mcasp0: mcasp0@1d0 {
#address-cells = 1;
#size-cells = 0;
reg = 0x10 0x3000;
+ reg-names mpu;
interrupts = 82 83;
op-mode = 0; /* MCASP_IIS_MODE */
tdm-slots = 2;
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 32ddb7f..a056fc5 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1001,18 +1001,40 @@ static const struct snd_soc_component_driver
davinci_mcasp_component = {
.name = davinci-mcasp,
};
+/* Some HW specific values and defaults. The rest is filled in from DT. */
+static struct snd_platform_data dm646x_mcasp_pdata = {
+ .tx_dma_offset = 0x400,
+ .rx_dma_offset = 0x400,
+ .asp_chan_q = EVENTQ_0,
+ .version = MCASP_VERSION_1,
+};
+
+static struct snd_platform_data da830_mcasp_pdata = {
+ .tx_dma_offset = 0x2000,
+ .rx_dma_offset = 0x2000,
+ .asp_chan_q = EVENTQ_0,
+ .version = MCASP_VERSION_2,
+};
+
+static struct snd_platform_data omap2_mcasp_pdata = {
+ .tx_dma_offset = 0,
+ .rx_dma_offset = 0,
+ .asp_chan_q = EVENTQ_0,
+ .version = MCASP_VERSION_3,
+};
+
static const struct of_device_id mcasp_dt_ids[] = {
{
.compatible = ti,dm646x-mcasp-audio,
- .data = (void *)MCASP_VERSION_1,
+ .data = dm646x_mcasp_pdata,
},
{
.compatible = ti,da830-mcasp-audio,
- .data = (void *)MCASP_VERSION_2,
+ .data = da830_mcasp_pdata,
},
{
.compatible = ti,omap2-mcasp-audio,
- .data = (void *)MCASP_VERSION_3,
+ .data = omap2_mcasp_pdata,
},
{ /* sentinel */ }
};
@@ -1035,20 +1057,13 @@ static struct snd_platform_data
*davinci_mcasp_set_pdata_from_of(
pdata = pdev-dev.platform_data;
return pdata;
} else if (match) {
- pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
- if (!pdata) {
- ret = -ENOMEM;
- goto nodata;
- }
+ pdata = (struct snd_platform_data *) match-data;
} else {
/* control shouldn't reach here. something is wrong */
ret = -EINVAL;
goto nodata;
}
- if (match-data)
- pdata-version = (u8)((int)match-data);
-
ret = of_property_read_u32(np, op-mode, val);
if (ret = 0)
pdata-op_mode = val;
@@ -1145,10 +1160,15 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
return -EINVAL;
}
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mem = platform_get_resource_byname(pdev, IORESOURCE_MEM, mpu);
if (!mem) {
- dev_err(pdev-dev, no mem resource?\n);
- return -ENODEV;
+ dev_warn(dev-dev,
+\mpu\ mem resource not found, using index 0\n);
+ mem =
[PATCH v3 09/11] ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries
From: Pantelis Antoniou pa...@antoniou-consulting.com
Add missing mcasp entries in the am33xx.dtsi include file.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0fdb949..fe53ce0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -552,5 +552,24 @@
#size-cells = 1;
status = disabled;
};
+
+ mcasp0: mcasp@48038000 {
+ compatible = ti,omap2-mcasp-audio;
+ ti,hwmods = mcasp0;
+ reg = 0x48038000 0x2000;
+ interrupts = 80 81;
+ interrupts-names = tx, rx;
+ status = disabled;
+ };
+
+ mcasp1: mcasp@4803C000 {
+ compatible = ti,omap2-mcasp-audio;
+ ti,hwmods = mcasp1;
+ reg = 0x4803C000 0x2000;
+ interrupts = 82 83;
+ interrupts-names = tx, rx;
+ status = disabled;
+ };
+
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/11] ASoC: tlv320aic3x: Add codec pins to DT bindings document
Add list of codec pins to tlv320aic3x DT bindings document.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/sound/tlv320aic3x.txt | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index 11e24b2..2b76c81 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -20,6 +20,25 @@ Optional properties:
- AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the
device as covered in
Documentation/devicetree/bindings/regulator/regulator.txt
+CODEC output pins:
+ * LLOUT
+ * RLOUT
+ * MONO_LOUT
+ * HPLOUT
+ * HPROUT
+ * HPLCOM
+ * HPRCOM
+
+CODEC input pins:
+ * MIC3L
+ * MIC3R
+ * LINE1L
+ * LINE2L
+ * LINE1R
+ * LINE2R
+
+The pins can be used in referring sound node's audio-routing property.
+
Example:
tlv320aic3x: tlv320aic3x@1b {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/11] ASoC: tlv320aic3x: Add regulators to DT bindings document
Add regulator properties to tlv320aic3x DT bindings document.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/sound/tlv320aic3x.txt |7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index f47c3f5..11e24b2 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -17,10 +17,17 @@ Optional properties:
3 - MICBIAS output is connected to AVDD,
If this node is not mentioned or if the value is incorrect, then MicBias
is powered down.
+- AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the
+ device as covered in
Documentation/devicetree/bindings/regulator/regulator.txt
Example:
tlv320aic3x: tlv320aic3x@1b {
compatible = ti,tlv320aic3x;
reg = 0x1b;
+
+ AVDD-supply = regulator;
+ IOVDD-supply = regulator;
+ DRVDD-supply = regulator;
+ DVDD-supply = regulator;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 06/11] ASoC: davinci: Add support for AM33xx SoC Audio
From: Hebbar, Gururaja gururaja.heb...@ti.com AM33xx uses same McASP IP as the Davinci Platform. This patch updates Kconfig and makefile to enable build for McASP, PCM Codec drivers. Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com Signed-off-by: Darren Etheridge detheri...@ti.com Signed-off-by: Jyri Sarha jsa...@ti.com --- sound/soc/davinci/Kconfig | 18 +++--- sound/soc/davinci/Makefile |1 + 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index c82f89c..95970f5 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -1,9 +1,10 @@ config SND_DAVINCI_SOC - tristate SoC Audio for the TI DAVINCI chip - depends on ARCH_DAVINCI + tristate SoC Audio for the TI DAVINCI or AM33XX chip + depends on ARCH_DAVINCI || SOC_AM33XX help + Platform driver for daVinci or AM33xx Say Y or M if you want to add support for codecs attached to - the DAVINCI AC97 or I2S interface. You will also need + the DAVINCI AC97, I2S, or McASP interface. You will also need to select the audio interfaces to support below. config SND_DAVINCI_SOC_I2S @@ -15,6 +16,17 @@ config SND_DAVINCI_SOC_MCASP config SND_DAVINCI_SOC_VCIF tristate +config SND_AM33XX_SOC_EVM + tristate SoC Audio for the AM33XX chip based boards + depends on SND_DAVINCI_SOC SOC_AM33XX + select SND_SOC_TLV320AIC3X + select SND_DAVINCI_SOC_MCASP + help + Say Y or M if you want to add support for SoC audio on AM33XX + boards using McASP and TLV320AIC3X codec. For example AM335X-EVM, + AM335X-EVMSK, and BeagelBone with AudioCape boards have this + setup. + config SND_DAVINCI_SOC_EVM tristate SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM depends on SND_DAVINCI_SOC diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile index a396ab6..bc81e79 100644 --- a/sound/soc/davinci/Makefile +++ b/sound/soc/davinci/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o snd-soc-evm-objs := davinci-evm.o obj-$(CONFIG_SND_DAVINCI_SOC_EVM) += snd-soc-evm.o +obj-$(CONFIG_SND_AM33XX_SOC_EVM) += snd-soc-evm.o obj-$(CONFIG_SND_DM6467_SOC_EVM) += snd-soc-evm.o obj-$(CONFIG_SND_DA830_SOC_EVM) += snd-soc-evm.o obj-$(CONFIG_SND_DA850_SOC_EVM) += snd-soc-evm.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/11] ARM/dts: am335x-evm: Add audio support for am335x-evm.dts
From: Darren Etheridge detheri...@ti.com
Adds sound, tlv320aic3x, mcasp1, and am335x_evm_audio_pin nodes.
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 56 ++
1 file changed, 56 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 3aee1a4..4a49229 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -149,6 +149,16 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+
+ am335x_evm_audio_pins: am335x_evm_audio_pins {
+ pinctrl-single,pins =
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_rx_dv.mcasp1_aclkx */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_txd3.mcasp1_fsx */
+ 0x108 (PIN_OUTPUT_PULLDOWN | MUX_MODE4) /*
mii1_col.mcasp1_axr2 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
rmii1_ref_clk.mcasp1_axr3 */
+ ;
+ };
+
};
ocp {
@@ -215,6 +225,19 @@
compatible = ti,tmp275;
reg = 0x48;
};
+
+ tlv320aic3x: tlv320aic3x@1b {
+ compatible = ti,tlv320aic3x;
+ reg = 0x1b;
+ status = okay;
+
+ /* Regulators */
+ AVDD-supply = vaux2_reg;
+ IOVDD-supply = vaux2_reg;
+ DRVDD-supply = vaux2_reg;
+ DVDD-supply = vbat;
+ };
+
};
elm: elm@4808 {
@@ -311,6 +334,20 @@
};
};
};
+
+ sound {
+ compatible = ti,da830-evm-audio;
+ ti,model = DA830 EVM;
+ ti,audio-codec = tlv320aic3x;
+ ti,mcasp-controller = mcasp1;
+ ti,codec-clock-rate = 1200;
+ ti,audio-routing =
+ Headphone Jack, HPLOUT,
+ Headphone Jack, HPROUT,
+ LINE1L, Line In,
+ LINE1R, Line In;
+ };
+
};
vbat: fixedregulator@0 {
@@ -378,6 +415,25 @@
#include tps65910.dtsi
+mcasp1 {
+ pinctrl-names = default;
+ pinctrl-0 = am335x_evm_audio_pins;
+
+ status = okay;
+
+ op-mode = 0; /* MCASP_IIS_MODE */
+ tdm-slots = 2;
+ num-serializer = 16;
+ serial-dir = /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ ;
+ tx-num-evt = 1;
+ rx-num-evt = 1;
+};
+
tps {
vcc1-supply = vbat;
vcc2-supply = vbat;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/11] ARM/dts: am33xx: mcasp: Add new dma register location to reg-property
This patch adds an optional address range to reg property. The range
describes the register location for DMA controller on am33xx. The both
address ranges are named accordingly in the reg-names property.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Darren Etheridge detheri...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index fe53ce0..4dc388a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -556,19 +556,29 @@
mcasp0: mcasp@48038000 {
compatible = ti,omap2-mcasp-audio;
ti,hwmods = mcasp0;
- reg = 0x48038000 0x2000;
+ reg = 0x48038000 0x2000,
+ 0x4640 0x40;
+ reg-names = mpu, dma;
interrupts = 80 81;
interrupts-names = tx, rx;
status = disabled;
+ dmas = edma 8
+ edma 9;
+ dma-names = tx, rx;
};
mcasp1: mcasp@4803C000 {
compatible = ti,omap2-mcasp-audio;
ti,hwmods = mcasp1;
- reg = 0x4803C000 0x2000;
+ reg = 0x4803C000 0x2000,
+ 0x4640 0x40;
+ reg-names = mpu, dma;
interrupts = 82 83;
interrupts-names = tx, rx;
status = disabled;
+ dmas = edma 10
+ edma 11;
+ dma-names = tx, rx;
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCF857x and 16-bit GPIO expanders
On 09/19/2013 03:13 AM, George Cherian wrote: On 9/18/2013 11:06 PM, Felipe Balbi wrote: Hi, On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote: On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote: On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote: has anyone ever successfully using gpio-pcf857x.c driver with 16-bit gpio expanders ? We're having some issues here where toggling the last gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I can't come up with any explanation of why would it hang... Bouncing the question to George, Laurent and Kuninori... I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as far as I know. I can try toggling I/O 15, but that will need to wait until next week as I'm currently travelling without access to the hardware. alright, that'd help me a lot :-) Just want to make sure if we're having a board issue, or PCF8575 is a bit screwy ;-) Is it on dra7x-evm if so which pcf device (i2c address)? The pins i were interested were only 1 and 2 I never tried pin 15. Just tried toggling through sysfs and it works for me. When I look at the data sheet for PCF8575[1] Page 7, Figure 4 Write mode (output) I see the data writes are of the order: I2c 1's byte: address I2c 2'nd byte:P[7-0] I2c 3rd byte:P[17-10] Note: bits 8,9 are missing not supported. Now [2] claims that it does support PCF8575, however when I look at line 143[3] unsignedbit = 1 offset; [snip] if (value) gpio-out |= bit; else gpio-out = ~bit; There is no handling for the skip needed for bits 8 and 9.. Seems to me like a driver bug. [1] http://www.ti.com/lit/ds/symlink/pcf8575.pdf [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-pcf857x.c [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-pcf857x.c#n143 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCF857x and 16-bit GPIO expanders
On 9/19/2013 5:37 PM, Nishanth Menon wrote: On 09/19/2013 03:13 AM, George Cherian wrote: On 9/18/2013 11:06 PM, Felipe Balbi wrote: Hi, On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote: On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote: On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote: has anyone ever successfully using gpio-pcf857x.c driver with 16-bit gpio expanders ? We're having some issues here where toggling the last gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I can't come up with any explanation of why would it hang... Bouncing the question to George, Laurent and Kuninori... I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as far as I know. I can try toggling I/O 15, but that will need to wait until next week as I'm currently travelling without access to the hardware. alright, that'd help me a lot :-) Just want to make sure if we're having a board issue, or PCF8575 is a bit screwy ;-) Is it on dra7x-evm if so which pcf device (i2c address)? The pins i were interested were only 1 and 2 I never tried pin 15. Just tried toggling through sysfs and it works for me. When I look at the data sheet for PCF8575[1] Page 7, Figure 4 Write mode (output) I see the data writes are of the order: I2c 1's byte: address I2c 2'nd byte:P[7-0] I2c 3rd byte:P[17-10] I read it as an octal numbering. Note: bits 8,9 are missing not supported. In octal there is no 8 and 9 Now [2] claims that it does support PCF8575, however when I look at line 143[3] unsignedbit = 1 offset; [snip] if (value) gpio-out |= bit; else gpio-out = ~bit; There is no handling for the skip needed for bits 8 and 9.. Seems to me like a driver bug. In which case there is no driver bug [1] http://www.ti.com/lit/ds/symlink/pcf8575.pdf [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-pcf857x.c [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-pcf857x.c#n143 -- -George -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCF857x and 16-bit GPIO expanders
On 09/19/2013 07:20 AM, George Cherian wrote: On 9/19/2013 5:37 PM, Nishanth Menon wrote: On 09/19/2013 03:13 AM, George Cherian wrote: On 9/18/2013 11:06 PM, Felipe Balbi wrote: Hi, On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote: On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote: On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote: has anyone ever successfully using gpio-pcf857x.c driver with 16-bit gpio expanders ? We're having some issues here where toggling the last gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I can't come up with any explanation of why would it hang... Bouncing the question to George, Laurent and Kuninori... I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as far as I know. I can try toggling I/O 15, but that will need to wait until next week as I'm currently travelling without access to the hardware. alright, that'd help me a lot :-) Just want to make sure if we're having a board issue, or PCF8575 is a bit screwy ;-) Is it on dra7x-evm if so which pcf device (i2c address)? The pins i were interested were only 1 and 2 I never tried pin 15. Just tried toggling through sysfs and it works for me. When I look at the data sheet for PCF8575[1] Page 7, Figure 4 Write mode (output) I see the data writes are of the order: I2c 1's byte: address I2c 2'nd byte:P[7-0] I2c 3rd byte:P[17-10] I read it as an octal numbering. Note: bits 8,9 are missing not supported. In octal there is no 8 and 9 Where is octal coming into play here? P8 and 9 does not exist as per the data sheet - look at the pinout on page 1[1] -P00-P17 this is exactly what is described on page 2[1]: The number of data bytes that can be sent successively is not limited After every two bytes, the previous data is overwritten. When the PCF8575 receives the pairs of data bytes, the first byte is referred to as P07 – P00 and the second byte as P17 – P10. The third byte is referred to as P07 – P00, the fourth byte as P17 – P10, and so on For someone reading schematics and setting up the P15, if the person uses gpios = PCF8575 15 OF_GPIO_HIGH; this will result in offset = 15, and as a result 0x80 will be send in byte 3, which from h/w point of view is P13 which could be controlling something weird! Now [2] claims that it does support PCF8575, however when I look at line 143[3] unsignedbit = 1 offset; [snip] if (value) gpio-out |= bit; else gpio-out = ~bit; There is no handling for the skip needed for bits 8 and 9.. Seems to me like a driver bug. In which case there is no driver bug It probably needs clarification: Depends on how the definition is done - to hit exact P15 in definition and to set P15, should I provide 17 as gpio number? That does not match what the h/w description is in the data sheet! [1] http://www.ti.com/lit/ds/symlink/pcf8575.pdf [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-pcf857x.c [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/gpio-pcf857x.c#n143 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCF857x and 16-bit GPIO expanders
On 19/09/13 13:20, George Cherian wrote: On 9/19/2013 5:37 PM, Nishanth Menon wrote: On 09/19/2013 03:13 AM, George Cherian wrote: On 9/18/2013 11:06 PM, Felipe Balbi wrote: Hi, On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote: On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote: On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote: has anyone ever successfully using gpio-pcf857x.c driver with 16-bit gpio expanders ? We're having some issues here where toggling the last gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I can't come up with any explanation of why would it hang... Bouncing the question to George, Laurent and Kuninori... I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as far as I know. I can try toggling I/O 15, but that will need to wait until next week as I'm currently travelling without access to the hardware. alright, that'd help me a lot :-) Just want to make sure if we're having a board issue, or PCF8575 is a bit screwy ;-) Is it on dra7x-evm if so which pcf device (i2c address)? The pins i were interested were only 1 and 2 I never tried pin 15. Just tried toggling through sysfs and it works for me. When I look at the data sheet for PCF8575[1] Page 7, Figure 4 Write mode (output) I see the data writes are of the order: I2c 1's byte: address I2c 2'nd byte:P[7-0] I2c 3rd byte:P[17-10] I read it as an octal numbering. Kind of ... looking at the pinout, you have pins:- P00...P07 P10...P17 So that's Port 0, bits 0..7, and Port 1, bits 0..7. Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCF857x and 16-bit GPIO expanders
Hi, On Thu, Sep 19, 2013 at 01:43:41PM +0530, George Cherian wrote: On 9/18/2013 11:06 PM, Felipe Balbi wrote: Hi, On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote: On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote: On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote: has anyone ever successfully using gpio-pcf857x.c driver with 16-bit gpio expanders ? We're having some issues here where toggling the last gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I can't come up with any explanation of why would it hang... Bouncing the question to George, Laurent and Kuninori... I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as far as I know. I can try toggling I/O 15, but that will need to wait until next week as I'm currently travelling without access to the hardware. alright, that'd help me a lot :-) Just want to make sure if we're having a board issue, or PCF8575 is a bit screwy ;-) Is it on dra7x-evm if so which pcf device (i2c address)? 0x21 IIRC, it's pin 15 on that goes to a discrete mux. I want to toggle the mux ;-) -- balbi signature.asc Description: Digital signature
Re: PCF857x and 16-bit GPIO expanders
Hi, On Thu, Sep 19, 2013 at 07:36:33AM -0500, Nishanth Menon wrote: On 09/19/2013 07:20 AM, George Cherian wrote: On 9/19/2013 5:37 PM, Nishanth Menon wrote: On 09/19/2013 03:13 AM, George Cherian wrote: On 9/18/2013 11:06 PM, Felipe Balbi wrote: Hi, On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote: On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote: On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote: has anyone ever successfully using gpio-pcf857x.c driver with 16-bit gpio expanders ? We're having some issues here where toggling the last gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I can't come up with any explanation of why would it hang... Bouncing the question to George, Laurent and Kuninori... I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as far as I know. I can try toggling I/O 15, but that will need to wait until next week as I'm currently travelling without access to the hardware. alright, that'd help me a lot :-) Just want to make sure if we're having a board issue, or PCF8575 is a bit screwy ;-) Is it on dra7x-evm if so which pcf device (i2c address)? The pins i were interested were only 1 and 2 I never tried pin 15. Just tried toggling through sysfs and it works for me. When I look at the data sheet for PCF8575[1] Page 7, Figure 4 Write mode (output) I see the data writes are of the order: I2c 1's byte: address I2c 2'nd byte:P[7-0] I2c 3rd byte:P[17-10] I read it as an octal numbering. Note: bits 8,9 are missing not supported. In octal there is no 8 and 9 Where is octal coming into play here? P8 and 9 does not exist as per the data sheet - look at the pinout on page 1[1] -P00-P17 this is exactly what is described on page 2[1]: The number of data bytes that can be sent successively is not limited After every two bytes, the previous data is overwritten. When the PCF8575 receives the pairs of data bytes, the first byte is referred to as P07 – P00 and the second byte as P17 – P10. The third byte is referred to as P07 – P00, the fourth byte as P17 – P10, and so on For someone reading schematics and setting up the P15, if the person uses gpios = PCF8575 15 OF_GPIO_HIGH; this will result in offset = 15, and as a result 0x80 will be send in byte 3, which from h/w point of view is P13 which could be controlling something weird! you missed one detail only. I said GPIO15, not P15 :-) GPIO15 on that device is P17 ;-) -- balbi signature.asc Description: Digital signature
[RFC PATCH 06/15] phy: omap-pipe3: update compatibility string and DT binding
Improve compatibility string format to ti,phy-pipe3-type
where type can be usb3 or sata. Remove pcie type
as it is not yet supported due to missing DPLL data.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/phy/omap-phy.txt |3 +--
drivers/phy/phy-omap-pipe3.c |8 ++--
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/omap-phy.txt
b/Documentation/devicetree/bindings/phy/omap-phy.txt
index cf45b01..8e09ad3 100644
--- a/Documentation/devicetree/bindings/phy/omap-phy.txt
+++ b/Documentation/devicetree/bindings/phy/omap-phy.txt
@@ -47,8 +47,7 @@ usb2phy@4a0ad080 {
OMAP PIPE3 PHY
Required properties:
- - compatible: Should be ti,omap-usb3, ti,omap-pipe3, ti,omap-sata
- or ti,omap-pcie
+ - compatible: Should be ti,phy-pipe3-usb3 or ti,phy-pipe3-sata
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
diff --git a/drivers/phy/phy-omap-pipe3.c b/drivers/phy/phy-omap-pipe3.c
index 19d1664..67eeaeb 100644
--- a/drivers/phy/phy-omap-pipe3.c
+++ b/drivers/phy/phy-omap-pipe3.c
@@ -219,17 +219,13 @@ static struct phy_ops ops = {
#ifdef CONFIG_OF
static const struct of_device_id omap_pipe3_id_table[] = {
{
- .compatible = ti,omap-pipe3,
+ .compatible = ti,phy-pipe3-usb3,
.data = dpll_map_usb,
},
{
- .compatible = ti,omap-sata,
+ .compatible = ti,phy-pipe3-sata,
.data = dpll_map_sata,
},
- {
- .compatible = ti,omap-usb3,
- .data = dpll_map_usb,
- },
{},
};
MODULE_DEVICE_TABLE(of, omap_pipe3_id_table);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 09/15] ata: ti_sata: Add Texas Instruments SATA Wrapper driver
Texas Instruments SoCs like OMAP5 and DRA7 contain a SATA wrapper
around the AHCI SATA core. This driver will manage that.
CC: Tejun Heo t...@kernel.org
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/ata/ti-sata.txt | 31
drivers/ata/Kconfig |7 +
drivers/ata/Makefile |1 +
drivers/ata/sata_ti.c | 160 +
4 files changed, 199 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/ti-sata.txt
create mode 100644 drivers/ata/sata_ti.c
diff --git a/Documentation/devicetree/bindings/ata/ti-sata.txt
b/Documentation/devicetree/bindings/ata/ti-sata.txt
new file mode 100644
index 000..bf0ea3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ti-sata.txt
@@ -0,0 +1,31 @@
+* Texas Instruments SATA Controller Wrapper
+
+Required properties:
+- compatible : ti,sata
+- ti,hwmods: sata
+- reg : Register mapping
+- #address-cells: 1
+- #size-cells : 1
+- ranges : allows valid translation between child's address space and
parent's
+ address space.
+- Must contain at least one child node for the SATA controller core
+
+Example:
+
+ sata: sata@4a141100 {
+ compatible = ti,sata;
+ ti,hwmods = sata;
+ reg = 0x4a141100 0x7;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ dwc-ahci@4a14 {
+ compatible = snps,dwc-ahci;
+ reg = 0x4a14 0x1100;
+ interrupts = GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH;
+ phys = sata_phy;
+ phy-names = sata-phy;
+ clocks = sata_ref_clk;
+ clock-names = optclk;
+ };
+ };
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index a53ef27..a3de4d2 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -138,6 +138,13 @@ config SATA_SIL24
If unsure, say N.
+config SATA_TI
+ tristate Texas Instruments SATA Wrapper driver
+ depends on ARCH_OMAP
+ help
+ This options enables SATA Wrapper driver for Texas Instruments SoCs.
+ It is found on OMAP5 and DRA7.
+
config ATA_SFF
bool ATA SFF support (for legacy IDE and PATA)
default y
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 46518c6..673ba5e 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SATA_SIL24) += sata_sil24.o
obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
obj-$(CONFIG_SATA_HIGHBANK)+= sata_highbank.o libahci.o
obj-$(CONFIG_AHCI_IMX) += ahci_imx.o
+obj-$(CONFIG_SATA_TI) += sata_ti.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/sata_ti.c b/drivers/ata/sata_ti.c
new file mode 100644
index 000..0b9093d
--- /dev/null
+++ b/drivers/ata/sata_ti.c
@@ -0,0 +1,160 @@
+/**
+ * sata-ti.c - Texas Instruments Specific SATA Glue layer
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Authors: Roger Quadros rog...@ti.com
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include linux/ioport.h
+#include linux/io.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
+
+/*
+ * All these registers belong to OMAP's Wrapper around the
+ * DesignWare SATA Core.
+ */
+
+#define SATA_SYSCONFIG 0x
+#define SATA_CDRLOCK 0x0004
+
+struct ti_sata {
+ struct device *dev;
+ void __iomem *base;
+};
+
+static int ti_sata_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev = pdev-dev;
+ struct ti_sata *sata;
+ struct resource *res;
+ void __iomem *base;
+ int ret;
+
+ if (!np) {
+ dev_err(dev, device node not found\n);
+ return -EINVAL;
+ }
+
+ sata = devm_kzalloc(dev, sizeof(*sata), GFP_KERNEL);
+ if (!sata)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, sata);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev, missing memory base resource\n);
+ return -EINVAL;
+ }
+
+
[RFC PATCH 08/15] ata: ahci_platform: Manage SATA PHY
From: Balaji T K balaj...@ti.com
Some platforms have a PHY hooked up to the
SATA controller. The PHY needs to be initialized
and powered up for SATA to work. We do that
using the PHY framework.
[Roger Q] Cleaned up.
CC: Tejun Heo t...@kernel.org
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/ata/ahci-platform.txt |2 +-
drivers/ata/Kconfig|1 +
drivers/ata/ahci.h |2 +
drivers/ata/ahci_platform.c| 31 +++-
4 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt
b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index 89de156..c6c549a 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -4,7 +4,7 @@ SATA nodes are defined to describe on-chip Serial ATA
controllers.
Each SATA controller should have its own node.
Required properties:
-- compatible: compatible list, contains snps,spear-ahci
+- compatible: compatible list, contains snps,spear-ahci or
snps,dwc-ahci
- interrupts: interrupt mapping for SATA IRQ
- reg : registers mapping
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 4e73772..a53ef27 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -91,6 +91,7 @@ config SATA_AHCI
config SATA_AHCI_PLATFORM
tristate Platform AHCI SATA support
+ select GENERIC_PHY
help
This option enables support for Platform AHCI Serial ATA
controllers.
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 1145637..94484cb 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -37,6 +37,7 @@
#include linux/clk.h
#include linux/libata.h
+#include linux/phy/phy.h
/* Enclosure Management Control */
#define EM_CTRL_MSG_TYPE 0x000f
@@ -322,6 +323,7 @@ struct ahci_host_priv {
u32 em_buf_sz; /* EM buffer size in byte */
u32 em_msg_type;/* EM message type */
struct clk *clk; /* Only for platforms
supporting clk */
+ struct phy *phy; /* If platforms use phy */
void*plat_data; /* Other platform data */
};
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 2daaee0..f812ffa 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -23,6 +23,7 @@
#include linux/platform_device.h
#include linux/libata.h
#include linux/ahci_platform.h
+#include linux/phy/phy.h
#include ahci.h
static void ahci_host_stop(struct ata_host *host);
@@ -141,16 +142,32 @@ static int ahci_probe(struct platform_device *pdev)
}
}
+ hpriv-phy = devm_phy_get(dev, sata-phy);
+ if (IS_ERR(hpriv-phy)) {
+ dev_err(dev, can't get phy\n);
+ /* return only if -EPROBE_DEFER */
+ if (PTR_ERR(hpriv-phy) == -EPROBE_DEFER) {
+ rc = -EPROBE_DEFER;
+ goto disable_unprepare_clk;
+ }
+ }
+
/*
* Some platforms might need to prepare for mmio region access,
* which could be done in the following init call. So, the mmio
* region shouldn't be accessed before init (if provided) has
* returned successfully.
*/
+
+ if (!(IS_ERR(hpriv-phy))) {
+ phy_init(hpriv-phy);
+ phy_power_on(hpriv-phy);
+ }
+
if (pdata pdata-init) {
rc = pdata-init(dev, hpriv-mmio);
if (rc)
- goto disable_unprepare_clk;
+ goto disable_phy;
}
ahci_save_initial_config(dev, hpriv,
@@ -220,6 +237,12 @@ static int ahci_probe(struct platform_device *pdev)
pdata_exit:
if (pdata pdata-exit)
pdata-exit(dev);
+disable_phy:
+ if (!IS_ERR(hpriv-phy)) {
+ phy_power_off(hpriv-phy);
+ phy_exit(hpriv-phy);
+ }
+
disable_unprepare_clk:
if (!IS_ERR(hpriv-clk))
clk_disable_unprepare(hpriv-clk);
@@ -238,6 +261,11 @@ static void ahci_host_stop(struct ata_host *host)
if (pdata pdata-exit)
pdata-exit(dev);
+ if (!IS_ERR(hpriv-phy)) {
+ phy_power_off(hpriv-phy);
+ phy_exit(hpriv-phy);
+ }
+
if (!IS_ERR(hpriv-clk)) {
clk_disable_unprepare(hpriv-clk);
clk_put(hpriv-clk);
@@ -328,6 +356,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend,
ahci_resume);
static const struct of_device_id ahci_of_match[] = {
{ .compatible = snps,spear-ahci, },
{ .compatible = snps,exynos5440-ahci, },
+ { .compatible =
[RFC PATCH 05/15] phy: omap-pipe3: Add SATA DPLL support
USB and SATA DPLLs need different settings. Provide
the SATA DPLL settings and use the proper DPLL settings
based on device tree compatible_id.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-pipe3.c | 82 ++--
include/linux/phy/omap_pipe3.h |6 +++
2 files changed, 60 insertions(+), 28 deletions(-)
diff --git a/drivers/phy/phy-omap-pipe3.c b/drivers/phy/phy-omap-pipe3.c
index 807ab8a..19d1664 100644
--- a/drivers/phy/phy-omap-pipe3.c
+++ b/drivers/phy/phy-omap-pipe3.c
@@ -58,29 +58,41 @@
*/
# define PLL_IDLE_TIME 100;
-struct pipe3_dpll_map {
- unsigned long rate;
- struct pipe3_dpll_params params;
-};
-
-static struct pipe3_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map_usb[] = {
{1200, {1250, 5, 4, 20, 0} }, /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} }, /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} }, /* 19.2 MHz */
{2000, {1000, 7, 4, 10, 0} }, /* 20 MHz */
{2600, {1250, 12, 4, 20, 0} }, /* 26 MHz */
{3840, {3125, 47, 4, 20, 92843} }, /* 38.4 MHz */
+ { },/* Terminator */
+};
+
+static struct pipe3_dpll_map dpll_map_sata[] = {
+ {1200, {1000, 7, 4, 6, 0} },/* 12 MHz */
+ {1680, {714, 7, 4, 6, 0} }, /* 16.8 MHz */
+ {1920, {625, 7, 4, 6, 0} }, /* 19.2 MHz */
+ {2000, {600, 7, 4, 6, 0} }, /* 20 MHz */
+ {2600, {461, 7, 4, 6, 0} }, /* 26 MHz */
+ {3840, {312, 7, 4, 6, 0} }, /* 38.4 MHz */
+ { },/* Terminator */
};
-static struct pipe3_dpll_params *omap_pipe3_get_dpll_params(unsigned long rate)
+static struct pipe3_dpll_params *omap_pipe3_get_dpll_params(struct omap_pipe3
+ *pipe3)
{
- int i;
+ unsigned long rate;
+ struct pipe3_dpll_map *dpll_map = pipe3-dpll_map;
- for (i = 0; i ARRAY_SIZE(dpll_map); i++) {
- if (rate == dpll_map[i].rate)
- return dpll_map[i].params;
+ rate = clk_get_rate(pipe3-sys_clk);
+
+ for (; dpll_map-rate; dpll_map++) {
+ if (rate == dpll_map-rate)
+ return dpll_map-params;
}
+ dev_err(pipe3-dev,
+ No DPLL configuration for %lu Hz SYS CLK\n, rate);
return 0;
}
@@ -148,10 +160,8 @@ static int omap_pipe3_dpll_lock(struct omap_pipe3 *phy)
struct pipe3_dpll_params *dpll_params;
rate = clk_get_rate(phy-sys_clk);
- dpll_params = omap_pipe3_get_dpll_params(rate);
+ dpll_params = omap_pipe3_get_dpll_params(phy);
if (!dpll_params) {
- dev_err(phy-dev,
- No DPLL configuration for %lu Hz SYS CLK\n, rate);
return -EINVAL;
}
@@ -206,6 +216,25 @@ static struct phy_ops ops = {
.owner = THIS_MODULE,
};
+#ifdef CONFIG_OF
+static const struct of_device_id omap_pipe3_id_table[] = {
+ {
+ .compatible = ti,omap-pipe3,
+ .data = dpll_map_usb,
+ },
+ {
+ .compatible = ti,omap-sata,
+ .data = dpll_map_sata,
+ },
+ {
+ .compatible = ti,omap-usb3,
+ .data = dpll_map_usb,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_pipe3_id_table);
+#endif
+
static int omap_pipe3_probe(struct platform_device *pdev)
{
struct omap_pipe3 *phy;
@@ -215,9 +244,7 @@ static int omap_pipe3_probe(struct platform_device *pdev)
struct device_node *node = pdev-dev.of_node;
struct device_node *control_node;
struct platform_device *control_pdev;
-
- if (!node)
- return -EINVAL;
+ const struct of_device_id *match;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -225,6 +252,16 @@ static int omap_pipe3_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ match = of_match_device(of_match_ptr(omap_pipe3_id_table), pdev-dev);
+ if (!match)
+ return -EINVAL;
+
+ phy-dpll_map = (struct pipe3_dpll_map *)match-data;
+ if (!phy-dpll_map) {
+ dev_err(pdev-dev, no dpll data\n);
+ return -EINVAL;
+ }
+
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pll_ctrl);
phy-pll_ctrl_base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(phy-pll_ctrl_base))
@@ -354,17 +391,6 @@ static const struct dev_pm_ops omap_pipe3_pm_ops = {
#define DEV_PM_OPS NULL
#endif
-#ifdef CONFIG_OF
-static const struct of_device_id omap_pipe3_id_table[] = {
- { .compatible = ti,omap-pipe3 },
- { .compatible = ti,omap-sata },
- { .compatible = ti,omap-pcie },
- {
[RFC PATCH 00/15] Add SATA support for TI OMAP5 and DRA7 SoCs
Hi, This series adds SATA controller support for the Texas Instruments OMAP5 and DRA7 platforms. As the SATA controller is compatible with AHCI, we use the ahci_platform driver and just provide the glue logic. The AHCI controller is enclosed within a TI specific Wrapper that controls the controller power mode. Patch 9 adds a driver for this wrapper. The controller is linked to a SATA (PIPE3) PHY, which needs to be clocked and powered up before it can be used. We do that with the help of the generic PHY framework [2] in Patch 8. Patches 1 to 7 adapt the the PHY driver to the Generic PHY framework. Patches 9 to 15 provide platform adaptation code for OMAP5 and DRA7. Patches are based on v3.12-rc1 with the following patches on top [1] - omap control usb multiple instance support http://article.gmane.org/gmane.linux.ports.arm.kernel/267587 git://github.com/rogerq/linux.git usb-control-module [2] - Generic PHY framework git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing [3] - Clock DT support git://gitorious.org/~kristo/omap-pm/omap-pm-work.git mainline-3.11-rc3-omap-dt-clks-v5 [4] - PHY framework mis cleanup https://lkml.org/lkml/2013/9/2/313 NOTE: [2], [3] and [4] will cause merge conflicts and need to be resolved manually. A merged tree is available for reference/testing at git://github.com/rogerq/linux.git ti-3.12-sata Tested on omap5-uevm and dra7-evm with Gen2 SATA hard drive. Known issues: - Gen3 SATA SSD does not work due to some issue with PHY speed negotiation. cheers, -roger --- Balaji T K (3): ata: ahci_platform: Manage SATA PHY arm: dts: omap5: add sata node arm: dts: dra7: add sata node Benoit Cousson (1): arm: omap5: hwmod: add missing ocp2scp hwmod data Keshava Munegowda (1): ARM: omap5: hwmod: Add ocp2scp3 and sata hwmods Kishon Vijay Abraham I (2): phy: rename struct omap_control_usb to struct omap_control_phy phy: omap-pipe3: use generic clock names Nikhil Devshatwar (1): ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods Roger Quadros (7): phy: omap-control: Update DT binding information ARM: dts: omap5: Add clocks to usb3_phy node phy: omap-pipe3: Add SATA DPLL support phy: omap-pipe3: update compatibility string and DT binding ARM: dts: omap5: Update usb3phy node ata: ti_sata: Add Texas Instruments SATA Wrapper driver ARM: dts: omap5: add ocp2scp1 address resource .../devicetree/bindings/ata/ahci-platform.txt |2 +- Documentation/devicetree/bindings/ata/ti-sata.txt | 31 ++ Documentation/devicetree/bindings/phy/omap-phy.txt | 26 ++- Documentation/devicetree/bindings/usb/omap-usb.txt | 23 -- arch/arm/boot/dts/dra7.dtsi| 49 arch/arm/boot/dts/omap5.dtsi | 56 - arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 117 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 40 +++- drivers/ata/Kconfig|8 + drivers/ata/Makefile |1 + drivers/ata/ahci.h |2 + drivers/ata/ahci_platform.c| 31 ++- drivers/ata/sata_ti.c | 160 +++ drivers/phy/Kconfig| 14 +- drivers/phy/Makefile |1 + drivers/phy/phy-omap-control.c | 300 drivers/phy/phy-omap-pipe3.c | 157 ++- drivers/phy/phy-omap-usb2.c|9 +- drivers/usb/musb/omap2430.c|2 +- drivers/usb/phy/Kconfig| 10 - drivers/usb/phy/Makefile |1 - drivers/usb/phy/phy-omap-control.c | 300 include/linux/phy/omap_control_phy.h | 83 ++ include/linux/phy/omap_pipe3.h |6 + include/linux/usb/omap_control_usb.h | 83 -- 25 files changed, 1013 insertions(+), 499 deletions(-) create mode 100644 Documentation/devicetree/bindings/ata/ti-sata.txt create mode 100644 drivers/ata/sata_ti.c create mode 100644 drivers/phy/phy-omap-control.c delete mode 100644 drivers/usb/phy/phy-omap-control.c create mode 100644 include/linux/phy/omap_control_phy.h delete mode 100644 include/linux/usb/omap_control_usb.h -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 03/15] ARM: dts: omap5: Add clocks to usb3_phy node
The pipe3-phy driver expects certain named clocks. Provide the necessary clocks. CC: Benoit Cousson bcous...@baylibre.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap5.dtsi |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 576b06a..97f361a 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -677,6 +677,8 @@ 0x4a084c00 0x40; reg-names = phy_rx, phy_tx, pll_ctrl; ctrl-module = omap_control_usb3phy; + clocks = usb_phy_cm_clk32k, sys_clkin; + clock-names = wkupclk, sysclk; #phy-cells = 0; }; }; -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 04/15] phy: omap-pipe3: use generic clock names
From: Kishon Vijay Abraham I kis...@ti.com
As this driver is no longer USB specific use generic clock names.
[Roger Q]
- Fix PLL_SD_SHIFT from 9 to 10
- As optclk and wkupclk may not be always required, don't bail out
if they aren't available.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-pipe3.c | 71 +++---
1 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/drivers/phy/phy-omap-pipe3.c b/drivers/phy/phy-omap-pipe3.c
index 63de0f8..807ab8a 100644
--- a/drivers/phy/phy-omap-pipe3.c
+++ b/drivers/phy/phy-omap-pipe3.c
@@ -37,15 +37,15 @@
#definePLL_CONFIGURATION4 0x0020
#definePLL_REGM_MASK 0x001FFE00
-#definePLL_REGM_SHIFT 0x9
+#definePLL_REGM_SHIFT 9
#definePLL_REGM_F_MASK 0x0003
-#definePLL_REGM_F_SHIFT0x0
+#definePLL_REGM_F_SHIFT0
#definePLL_REGN_MASK 0x01FE
-#definePLL_REGN_SHIFT 0x1
+#definePLL_REGN_SHIFT 1
#definePLL_SELFREQDCO_MASK 0x000E
-#definePLL_SELFREQDCO_SHIFT0x1
+#definePLL_SELFREQDCO_SHIFT1
#definePLL_SD_MASK 0x0003FC00
-#definePLL_SD_SHIFT0x9
+#definePLL_SD_SHIFT10
#defineSET_PLL_GO 0x1
#definePLL_TICOPWDN0x1
#definePLL_LOCK0x2
@@ -232,23 +232,21 @@ static int omap_pipe3_probe(struct platform_device *pdev)
phy-dev= pdev-dev;
- phy-wkupclk = devm_clk_get(phy-dev, usb_phy_cm_clk32k);
- if (IS_ERR(phy-wkupclk)) {
- dev_err(pdev-dev, unable to get usb_phy_cm_clk32k\n);
- return PTR_ERR(phy-wkupclk);
- }
- clk_prepare(phy-wkupclk);
+ phy-wkupclk = devm_clk_get(phy-dev, wkupclk);
+ if (IS_ERR(phy-wkupclk))
+ dev_dbg(pdev-dev, unable to get wkupclk\n);
+ else
+ clk_prepare(phy-wkupclk);
- phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
- if (IS_ERR(phy-optclk)) {
- dev_err(pdev-dev, unable to get usb_otg_ss_refclk960m\n);
- return PTR_ERR(phy-optclk);
- }
- clk_prepare(phy-optclk);
+ phy-optclk = devm_clk_get(phy-dev, optclk);
+ if (IS_ERR(phy-optclk))
+ dev_dbg(pdev-dev, unable to get optclk\n);
+ else
+ clk_prepare(phy-optclk);
- phy-sys_clk = devm_clk_get(phy-dev, sys_clkin);
+ phy-sys_clk = devm_clk_get(phy-dev, sysclk);
if (IS_ERR(phy-sys_clk)) {
- pr_err(%s: unable to get sys_clkin\n, __func__);
+ dev_err(pdev-dev, unable to get sysclk\n);
return -EINVAL;
}
@@ -290,8 +288,10 @@ static int omap_pipe3_remove(struct platform_device *pdev)
{
struct omap_pipe3 *phy = platform_get_drvdata(pdev);
- clk_unprepare(phy-wkupclk);
- clk_unprepare(phy-optclk);
+ if (!IS_ERR(phy-wkupclk))
+ clk_unprepare(phy-wkupclk);
+ if (!IS_ERR(phy-optclk))
+ clk_unprepare(phy-optclk);
if (!pm_runtime_suspended(pdev-dev))
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
@@ -305,8 +305,10 @@ static int omap_pipe3_runtime_suspend(struct device *dev)
{
struct omap_pipe3 *phy = dev_get_drvdata(dev);
- clk_disable(phy-wkupclk);
- clk_disable(phy-optclk);
+ if (!IS_ERR(phy-wkupclk))
+ clk_disable(phy-wkupclk);
+ if (!IS_ERR(phy-optclk))
+ clk_disable(phy-optclk);
return 0;
}
@@ -316,22 +318,27 @@ static int omap_pipe3_runtime_resume(struct device *dev)
u32 ret = 0;
struct omap_pipe3 *phy = dev_get_drvdata(dev);
- ret = clk_enable(phy-optclk);
- if (ret) {
- dev_err(phy-dev, Failed to enable optclk %d\n, ret);
- goto err1;
+ if (!IS_ERR(phy-optclk)) {
+ ret = clk_enable(phy-optclk);
+ if (ret) {
+ dev_err(phy-dev, Failed to enable optclk %d\n, ret);
+ goto err1;
+ }
}
- ret = clk_enable(phy-wkupclk);
- if (ret) {
- dev_err(phy-dev, Failed to enable wkupclk %d\n, ret);
- goto err2;
+ if (!IS_ERR(phy-wkupclk)) {
+ ret = clk_enable(phy-wkupclk);
+ if (ret) {
+ dev_err(phy-dev, Failed to enable wkupclk %d\n, ret);
+ goto err2;
+ }
}
return 0;
err2:
- clk_disable(phy-optclk);
+ if (!IS_ERR(phy-optclk))
+ clk_disable(phy-optclk);
err1:
return ret;
--
1.7.4.1
--
To unsubscribe from this list: send the line
[RFC PATCH 02/15] phy: omap-control: Update DT binding information
Update compatibility string and DT binding document.
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/phy/omap-phy.txt | 23
Documentation/devicetree/bindings/usb/omap-usb.txt | 23
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/omap-phy.txt
b/Documentation/devicetree/bindings/phy/omap-phy.txt
index 2c485ee..cf45b01 100644
--- a/Documentation/devicetree/bindings/phy/omap-phy.txt
+++ b/Documentation/devicetree/bindings/phy/omap-phy.txt
@@ -1,5 +1,28 @@
OMAP PHY: DT DOCUMENTATION FOR PHYs in OMAP PLATFORM
+OMAP CONTROL PHY
+
+Required properties:
+ - compatible: Should be one of
+ ti,control-phy-otghs - if it has otghs_control mailbox register as on OMAP4.
+ ti,control-phy-usb2 - if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ ti,control-phy-pipe3 - if it has DPLL and individual Rx Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ ti,control-phy-dra7usb2 - if it has power down register like USB2 PHY on
+ DRA7 platform.
+ - reg : Address and length of the register set for the device. It contains
+ the address of otghs_control for control-phy-otghs or power register
+ for other types.
+ - reg-names: should be otghs_control control-phy-otghs and power for
+ other types.
+
+omap_control_otghs: omap-control-phy@4a002300 {
+ compatible = ti,control-phy-otghs;
+ reg = 0x4a00233c 0x4;
+ reg-names = otghs_control;
+};
+
OMAP USB2 PHY
Required properties:
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index b2bf7b3..4aa8eab 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -79,26 +79,3 @@ omap_dwc3 {
clock-names = usb_otg_ss_refclk960m;
ranges;
};
-
-OMAP CONTROL USB
-
-Required properties:
- - compatible: Should be one of
- ti,control-phy-otghs - if it has otghs_control mailbox register as on OMAP4.
- ti,control-phy-usb2 - if it has Power down bit in control_dev_conf register
- e.g. USB2_PHY on OMAP5.
- ti,control-phy-pipe3 - if it has DPLL and individual Rx Tx power control
- e.g. USB3 PHY and SATA PHY on OMAP5.
- ti,control-phy-dra7usb2 - if it has power down register like USB2 PHY on
- DRA7 platform.
- - reg : Address and length of the register set for the device. It contains
- the address of otghs_control for control-phy-otghs or power register
- for other types.
- - reg-names: should be otghs_control control-phy-otghs and power for
- other types.
-
-omap_control_usb: omap-control-usb@4a002300 {
- compatible = ti,control-phy-otghs;
- reg = 0x4a00233c 0x4;
- reg-names = otghs_control;
-};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 01/15] phy: rename struct omap_control_usb to struct omap_control_phy
From: Kishon Vijay Abraham I kis...@ti.com
Rename struct omap_control_usb to struct omap_control_phy since it can
be used to control PHY of USB, SATA and PCIE. Also move the driver and
include files under *phy* and made the corresponding changes in the users
of phy-omap-control.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/Kconfig | 14 ++-
drivers/phy/Makefile |1 +
drivers/phy/phy-omap-control.c | 300 ++
drivers/phy/phy-omap-pipe3.c |8 +-
drivers/phy/phy-omap-usb2.c |9 +-
drivers/usb/musb/omap2430.c |2 +-
drivers/usb/phy/Kconfig | 10 -
drivers/usb/phy/Makefile |1 -
drivers/usb/phy/phy-omap-control.c | 300 --
include/linux/phy/omap_control_phy.h | 83 ++
include/linux/usb/omap_control_usb.h | 83 --
11 files changed, 406 insertions(+), 405 deletions(-)
create mode 100644 drivers/phy/phy-omap-control.c
delete mode 100644 drivers/usb/phy/phy-omap-control.c
create mode 100644 include/linux/phy/omap_control_phy.h
delete mode 100644 include/linux/usb/omap_control_usb.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5c2e7a0..7155f56 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,12 +15,22 @@ config GENERIC_PHY
phy users can obtain reference to the PHY. All the users of this
framework should select this config.
+config OMAP_CONTROL_PHY
+ tristate OMAP CONTROL PHY Driver
+ help
+ Enable this to add support for the PHY part present in the control
+ module. This driver has API to power on the USB2 PHY and to write to
+ the mailbox. The mailbox is present only in omap4 and the register to
+ power on the USB2 PHY is present in OMAP4 and OMAP5. OMAP5 has an
+ additional register to power on USB3 PHY/SATA PHY/PCIE PHY
+ (PIPE3 PHY).
+
config OMAP_USB2
tristate OMAP USB2 PHY Driver
depends on ARCH_OMAP2PLUS
select GENERIC_PHY
select USB_PHY
- select OMAP_CONTROL_USB
+ select OMAP_CONTROL_PHY
help
Enable this to support the transceiver that is part of SOC. This
driver takes care of all the PHY functionality apart from comparator.
@@ -30,7 +40,7 @@ config OMAP_USB2
config OMAP_PIPE3
tristate OMAP PIPE3 PHY Driver
select GENERIC_PHY
- select OMAP_CONTROL_USB
+ select OMAP_CONTROL_PHY
help
Enable this to support the PIPE3 PHY that is part of SOC. This
driver takes care of all the PHY functionality apart from comparator.
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 48bf9f2..f0127f6 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_OMAP_PIPE3) += phy-omap-pipe3.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
new file mode 100644
index 000..5b85478
--- /dev/null
+++ b/drivers/phy/phy-omap-control.c
@@ -0,0 +1,300 @@
+/*
+ * omap-control-phy.c - The PHY part of control module.
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/phy/omap_control_phy.h
+
+/**
+ * omap_control_phy_power - power on/off the phy using control module reg
+ * @dev: the control module device
+ * @on: 0 or 1, based on powering on or off the PHY
+ */
+void omap_control_phy_power(struct device *dev, int on)
+{
+ u32 val;
+ unsigned long rate;
+ struct omap_control_phy *control_phy;
+
+ if (IS_ERR(dev) || !dev) {
+ pr_err(%s: invalid device\n, __func__);
+ return;
+ }
+
+ control_phy = dev_get_drvdata(dev);
+ if (!control_phy) {
+ dev_err(dev, %s: invalid control phy device\n, __func__);
+ return;
+ }
+
+ if
[RFC PATCH 07/15] ARM: dts: omap5: Update usb3phy node
Update compatible property for usb3phy node.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 97f361a..06aa665 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -671,7 +671,7 @@
};
usb3_phy: usb3phy@4a084400 {
- compatible = ti,omap-usb3;
+ compatible = ti,phy-pipe3-usb3;
reg = 0x4a084400 0x80,
0x4a084800 0x64,
0x4a084c00 0x40;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCF857x and 16-bit GPIO expanders
Hi, On Thu, Sep 19, 2013 at 06:38:13PM +0530, George Cherian wrote: On 9/19/2013 6:14 PM, Felipe Balbi wrote: Hi, On Thu, Sep 19, 2013 at 01:43:41PM +0530, George Cherian wrote: On 9/18/2013 11:06 PM, Felipe Balbi wrote: Hi, On Wed, Sep 18, 2013 at 07:18:04PM +0200, Laurent Pinchart wrote: On Wednesday 18 September 2013 13:16:27 Linus Walleij wrote: On Tue, Sep 17, 2013 at 9:07 PM, Felipe Balbi ba...@ti.com wrote: has anyone ever successfully using gpio-pcf857x.c driver with 16-bit gpio expanders ? We're having some issues here where toggling the last gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I can't come up with any explanation of why would it hang... Bouncing the question to George, Laurent and Kuninori... I've got a board with a PCF8575 chip, but it uses I/Os 8 to 14 only as far as I know. I can try toggling I/O 15, but that will need to wait until next week as I'm currently travelling without access to the hardware. alright, that'd help me a lot :-) Just want to make sure if we're having a board issue, or PCF8575 is a bit screwy ;-) Is it on dra7x-evm if so which pcf device (i2c address)? 0x21 IIRC, it's pin 15 on that goes to a discrete mux. I want to toggle the mux ;-) I am able to toggle the same via sysfs(pcf8575 @ 0x21gpio15(p17)) and it does not hang the board. I am using Rev D1 board. Log :- # cat /sys/kernel/debug/gpio . ... GPIOs 480-495, i2c/0-0021, pcf8575, can sleep: gpio-481 (id_gpio ) in hi gpio-482 (id_gpio ) in hi gpio-495 (sysfs ) out hi # echo 0 /sys/class/gpio/gpio495/value # cat /sys/kernel/debug/gpio . ... GPIOs 480-495, i2c/0-0021, pcf8575, can sleep: gpio-481 (id_gpio ) in hi gpio-482 (id_gpio ) in hi gpio-495 (sysfs ) out lo weird... I'll debug here and see if I can still reproduce with v3.12-rc1. Thanks anyway :-) cheers -- balbi signature.asc Description: Digital signature
[RFC PATCH 10/15] ARM: omap5: hwmod: Add ocp2scp3 and sata hwmods
From: Keshava Munegowda keshava_mgo...@ti.com
Create hwmods for ocp2scp3 and sata modules.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 72
1 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 3dae6b9..2b698b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1545,6 +1545,76 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
},
};
+/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+/* ocp2scp3 */
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
+ * 'sata' class
+ * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
+ .sysc_offs = 0x,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
+ .name = sata,
+ .sysc = omap54xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod omap54xx_sata_hwmod = {
+ .name = sata,
+ .class = omap54xx_sata_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .main_clk = func_48m_fclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* l4_cfg - sata */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_sata_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
/*
* Interfaces
@@ -2192,6 +2262,8 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
omap54xx_l4_per__uart6,
omap54xx_l4_cfg__usb_otg_ss,
omap54xx_l4_wkup__wd_timer2,
+ omap54xx_l4_cfg__ocp2scp3,
+ omap54xx_l4_cfg__sata,
NULL,
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] ASoC: davinci-evm: Move sysclk logic away from evm_hw_params
On Thu, Sep 19, 2013 at 02:29:34PM +0300, Jyri Sarha wrote: The sysclk rate does not change runtime so it should be initialized at init time. Are there any updates from the version already applied (I only dropped the patch to allow the extra builds, not this one). signature.asc Description: Digital signature
[RFC PATCH 15/15] arm: dts: dra7: add sata node
From: Balaji T K balaj...@ti.com
Add support for sata controller.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 49 +++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..545545d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -426,6 +426,55 @@
dma-names = tx, rx;
};
+ omap_control_sata: control-phy@4a002374 {
+ compatible = ti,control-phy-pipe3;
+ reg = 0x4a002374 0x4;
+ reg-names = power;
+ clocks = sys_clkin1;
+ clock-names = sysclk;
+ };
+
+ ocp2scp3: ocp2scp3@4a09 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp3;
+ reg = 0x4a09 0x1f; /* ocp2scp3 */
+ reg-names = ocp2scp3;
+ sata_phy: sataphy@4A096000 {
+ compatible = ti,phy-pipe3-sata;
+ reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_sata;
+ clocks = sata_ref_clk,
+sys_clkin1;
+ clock-names = optclk, sysclk;
+ #phy-cells = 0;
+ };
+ };
+
+ sata: sata@4a141100 {
+ compatible = ti,sata;
+ ti,hwmods = sata;
+ reg = 0x4a141100 0x7;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ dwc-ahci@4a14 {
+ compatible = snps,dwc-ahci;
+ reg = 0x4a14 0x1100;
+ interrupts = 0 54 0x4;
+ phys = sata_phy;
+ phy-names = sata-phy;
+ clocks = sata_ref_clk;
+ clock-names = optclk;
+ };
+ };
+
+
mcspi1: spi@48098000 {
compatible = ti,omap4-mcspi;
reg = 0x48098000 0x200;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 13/15] arm: dts: omap5: add sata node
From: Balaji T K balaj...@ti.com
Add support for sata.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 51 +-
1 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 8a88a94..a79ccb7 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -434,6 +434,53 @@
dma-names = tx, rx;
};
+ omap_control_sata: control-phy@4a002374 {
+ compatible = ti,control-phy-pipe3;
+ reg = 0x4a002374 0x4;
+ reg-names = power;
+ clocks = sys_clkin;
+ clock-names = sysclk;
+ };
+
+ ocp2scp3: ocp2scp3@4a09 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp3;
+ reg = 0x4a09 0x1f; /* ocp2scp3 */
+ reg-names = ocp2scp3;
+ sata_phy: sataphy@4A096000 {
+ compatible = ti,phy-pipe3-sata;
+ reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_sata;
+ clocks = sys_clkin;
+ clock-names = sysclk;
+ #phy-cells = 0;
+ };
+ };
+
+ sata: sata@4a141100 {
+ compatible = ti,sata;
+ ti,hwmods = sata;
+ reg = 0x4a141100 0x7;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ dwc-ahci@4a14 {
+ compatible = snps,dwc-ahci;
+ reg = 0x4a14 0x1100;
+ interrupts = GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH;
+ phys = sata_phy;
+ phy-names = sata-phy;
+ clocks = sata_ref_clk;
+ clock-names = optclk;
+ };
+ };
+
keypad: keypad@4ae1c000 {
compatible = ti,omap4-keypad;
reg = 0x4ae1c000 0x400;
@@ -636,6 +683,8 @@
compatible = ti,control-phy-pipe3;
reg = 0x4a002370 0x4;
reg-names = power;
+ clocks = sys_clkin;
+ clock-names = sysclk;
};
omap_dwc3@4a02 {
@@ -657,7 +706,7 @@
};
};
- ocp2scp {
+ ocp2scp1: ocp2scp1@4a08 {
compatible = ti,omap-ocp2scp;
#address-cells = 1;
#size-cells = 1;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 12/15] ARM: dts: omap5: add ocp2scp1 address resource
Add OCP2SCP1 module address space.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 06aa665..8a88a94 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -663,6 +663,7 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp1;
+ reg = 0x4a08 0x1f;
usb2_phy: usb2phy@4a084000 {
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 14/15] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
From: Nikhil Devshatwar nikhil...@ti.com
Add hwmods for ocp2scp3 and sata modules.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 40 +---
1 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index f647998b..4d7d70f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1215,6 +1215,40 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
},
};
+/* ocp2scp3 */
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
+static struct omap_hwmod_addr_space dra7xx_ocp2scp3_addrs[] = {
+ {
+ .name = ocp2scp3,
+ .pa_start = 0x4a09,
+ .pa_end = 0x4a09001f,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .addr = dra7xx_ocp2scp3_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = dra7xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'qspi' class
*
@@ -1268,9 +1302,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class = {
};
/* sata */
-static struct omap_hwmod_opt_clk sata_opt_clks[] = {
- { .role = ref_clk, .clk = sata_ref_clk },
-};
static struct omap_hwmod dra7xx_sata_hwmod = {
.name = sata,
@@ -1285,8 +1316,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
- .opt_clks = sata_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
};
/*
@@ -2683,6 +2712,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_per1__mmc4,
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
+ dra7xx_l4_cfg__ocp2scp3,
dra7xx_l3_main_1__qspi,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 11/15] arm: omap5: hwmod: add missing ocp2scp hwmod data
From: Benoit Cousson bcous...@baylibre.com
without that hwmod data, USB3 will not in OMAP5 boards.
Signed-off-by: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 2b698b8..e7d4fcb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1146,6 +1146,42 @@ static struct omap_hwmod omap54xx_mpu_hwmod = {
};
/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_ocp2scp_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_ocp2scp_hwmod_class = {
+ .name = ocp2scp,
+ .sysc = omap54xx_ocp2scp_sysc,
+};
+
+/* ocp2scp1 */
+static struct omap_hwmod omap54xx_ocp2scp1_hwmod = {
+ .name = ocp2scp1,
+ .class = omap54xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_OCP2SCP1_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_OCP2SCP1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
* 'timer' class
* general purpose timer module with accurate 1ms tick
* This class contains several variants: ['timer_1ms', 'timer']
@@ -2040,6 +2076,14 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mpu = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - ocp2scp1 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp1 = {
+ .master = omap54xx_l4_cfg_hwmod,
+ .slave = omap54xx_ocp2scp1_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_wkup - timer1 */
static struct omap_hwmod_ocp_if omap54xx_l4_wkup__timer1 = {
.master = omap54xx_l4_wkup_hwmod,
@@ -2243,6 +2287,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
omap54xx_l4_per__mmc4,
omap54xx_l4_per__mmc5,
omap54xx_l4_cfg__mpu,
+ omap54xx_l4_cfg__ocp2scp1,
omap54xx_l4_wkup__timer1,
omap54xx_l4_per__timer2,
omap54xx_l4_per__timer3,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 07/11] ASoC: tlv320aic3x: Add regulators to DT bindings document
On Thu, Sep 19, 2013 at 02:29:40PM +0300, Jyri Sarha wrote: Add regulator properties to tlv320aic3x DT bindings document. Similarly for this and the other CODEC patch, are these changed? signature.asc Description: Digital signature
Re: [PATCH v3 00/11] Fix AM335x-evm analog audio support
On Thu, Sep 19, 2013 at 02:29:33PM +0300, Jyri Sarha wrote: The RFC version of patches can been found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066178.html This all looks fine to me, I'd like some review from the DT guys though. signature.asc Description: Digital signature
RE: [PATCH v3 01/11] ASoC: davinci-evm: Move sysclk logic away from evm_hw_params
As I described in cover letter on these patches did change: [PATCH v2 05/11] ASoC: davinci-mcasp: Remove interrupt property from DT bindin - restore binding but make it optional and add interrupt-names property [PATCH v2 06/11] ASoC: davinci: Add support for AM33xx SoC Audio - SND_DAVINCI_SOC help Machine driver for ... - Platform driver for ... - SND_AM33XX_SOC_EVM depends on SND_DAVINCI_SOC SOC_AM33XX - SND_AM33XX_SOC_EVM does not selcet SND_DAVINCI_SOC [PATCH v2 09/11] ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries - restore interrupt property and add interrupt-names property Best regards, Jyri Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From: Mark Brown [broo...@kernel.org] Sent: Thursday, September 19, 2013 4:23 PM To: Sarha, Jyri Cc: alsa-de...@alsa-project.org; devicet...@vger.kernel.org; linux-omap@vger.kernel.org; Ujfalusi, Peter; liam.r.girdw...@linux.intel.com; grant.lik...@linaro.org; rob.herr...@calxeda.com; Fernandes, Joel Subject: Re: [PATCH v3 01/11] ASoC: davinci-evm: Move sysclk logic away from evm_hw_params On Thu, Sep 19, 2013 at 02:29:34PM +0300, Jyri Sarha wrote: The sysclk rate does not change runtime so it should be initialized at init time. Are there any updates from the version already applied (I only dropped the patch to allow the extra builds, not this one). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 07/11] ASoC: tlv320aic3x: Add regulators to DT bindings document
No change here either. Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From: devicetree-ow...@vger.kernel.org [devicetree-ow...@vger.kernel.org] on behalf of Mark Brown [broo...@kernel.org] Sent: Thursday, September 19, 2013 4:29 PM To: Sarha, Jyri Cc: alsa-de...@alsa-project.org; devicet...@vger.kernel.org; linux-omap@vger.kernel.org; Ujfalusi, Peter; liam.r.girdw...@linux.intel.com; grant.lik...@linaro.org; rob.herr...@calxeda.com; Fernandes, Joel Subject: Re: [PATCH v3 07/11] ASoC: tlv320aic3x: Add regulators to DT bindings document On Thu, Sep 19, 2013 at 02:29:40PM +0300, Jyri Sarha wrote: Add regulator properties to tlv320aic3x DT bindings document. Similarly for this and the other CODEC patch, are these changed? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 15/15] arm: dts: dra7: add sata node
Hello.
On 09/19/2013 05:24 PM, Roger Quadros wrote:
From: Balaji T K balaj...@ti.com
Add support for sata controller.
[Roger Q] Clean up.
CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 49 +++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..545545d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -426,6 +426,55 @@
dma-names = tx, rx;
};
+ omap_control_sata: control-phy@4a002374 {
+ compatible = ti,control-phy-pipe3;
+ reg = 0x4a002374 0x4;
+ reg-names = power;
+ clocks = sys_clkin1;
+ clock-names = sysclk;
+ };
+
+ ocp2scp3: ocp2scp3@4a09 {
+ compatible = ti,omap-ocp2scp;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ocp2scp3;
+ reg = 0x4a09 0x1f; /* ocp2scp3 */
+ reg-names = ocp2scp3;
+ sata_phy: sataphy@4A096000 {
It's better to name the PHY nodes uniformly after already standard
ethernet-phy and your control-phy.
+ compatible = ti,phy-pipe3-sata;
+ reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+ reg-names = phy_rx, phy_tx, pll_ctrl;
+ ctrl-module = omap_control_sata;
+ clocks = sata_ref_clk,
+sys_clkin1;
+ clock-names = optclk, sysclk;
+ #phy-cells = 0;
+ };
+ };
+
+ sata: sata@4a141100 {
+ compatible = ti,sata;
+ ti,hwmods = sata;
+ reg = 0x4a141100 0x7;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ dwc-ahci@4a14 {
Hm, ePAPR spec. [1] says that the name of a node should be somewhat
generic, reflecting the function of the device and not its precise programming
model, so it looks like the name should be sata as well. I'm a bit at a
loss here, not sure why you had to use the nested device nodes.
+ compatible = snps,dwc-ahci;
+ reg = 0x4a14 0x1100;
+ interrupts = 0 54 0x4;
+ phys = sata_phy;
Hm, it's the third PHY related generic property I'm encountering. First,
there was phy-handle, then phy, now phys... Seems like a bit too much. :-)
+ phy-names = sata-phy;
+ clocks = sata_ref_clk;
+ clock-names = optclk;
+ };
+ };
[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 01/15] phy: rename struct omap_control_usb to struct omap_control_phy
On 19.09.2013 15:05, Roger Quadros wrote: From: Kishon Vijay Abraham I kis...@ti.com Rename struct omap_control_usb to struct omap_control_phy since it can be used to control PHY of USB, SATA and PCIE. Also move the driver and include files under *phy* and made the corresponding changes in the users of phy-omap-control. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- drivers/phy/Kconfig | 14 ++- drivers/phy/Makefile |1 + drivers/phy/phy-omap-control.c | 300 ++ drivers/phy/phy-omap-pipe3.c |8 +- drivers/phy/phy-omap-usb2.c |9 +- drivers/usb/musb/omap2430.c |2 +- drivers/usb/phy/Kconfig | 10 - drivers/usb/phy/Makefile |1 - drivers/usb/phy/phy-omap-control.c | 300 -- include/linux/phy/omap_control_phy.h | 83 ++ include/linux/usb/omap_control_usb.h | 83 -- 11 files changed, 406 insertions(+), 405 deletions(-) create mode 100644 drivers/phy/phy-omap-control.c delete mode 100644 drivers/usb/phy/phy-omap-control.c create mode 100644 include/linux/phy/omap_control_phy.h delete mode 100644 include/linux/usb/omap_control_usb.h In case you do another version of this set, please use git format-patch -M, which will detect renames and hence make the review much easier. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 12/15] ARM: dts: omap5: add ocp2scp1 address resource
On 09/19/2013 05:23 PM, Roger Quadros wrote: Add OCP2SCP1 module address space. CC: Benoit Cousson bcous...@baylibre.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap5.dtsi |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 06aa665..8a88a94 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -663,6 +663,7 @@ #size-cells = 1; ranges; ti,hwmods = ocp2scp1; + reg = 0x4a08 0x1f; Are you sure length is not 0x20? WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP35x MMC Host Controller compatibility with SDXC?
On Wednesday 18 September 2013 02:32 AM, Kevyn-Alexandre Paré wrote: Hi, My question is related to the drivers/mmc/host/omap_hsmmc.c host controller compatibility with SDXC for the OMAP35x? Reading the TRM for OMAP35x: http://www.ti.com/lit/ug/spruf98x/spruf98x.pdf It's said that: - Full compliance with SD command/response sets as defined in the SD Memory Card Specifications, v2.0 including high-capacity SDHC cards up to 32GB. - Full compliance with sets as defined in the SD Card Specification, Part A2, SD Host Controller Standard Specification, v2.00 It doesn't mention the SDXC? I'm trying to found my way through all the spec of sdcard.org. I'm still wondering why using SDXC of 64GB is working and doesn't pop a WARNING message and if it's safe?? My test shows that I'm having some timeout in some cases (v3.4.60): omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO mmc0: req done (CMD52): -110: mmc0: starting CMD52 arg 8c08 flags 0195 omap_hsmmc omap_hsmmc.0: mmc0: CMD5, argument 0x omap_hsmmc omap_hsmmc.0: IRQ Status is 18000 omap_hsmmc omap_hsmmc.0: MMC IRQ 0x18000 : ERRI CTO mmc0: req failed (CMD5): -110, retrying... mmc1: starting CMD8 arg 01aa flags 02f5 omap_hsmmc omap_hsmmc.1: mmc1: CMD8, argument 0x01aa mmc0: starting CMD18 arg 0002 flags 00b5 omap_hsmmc omap_hsmmc.1: IRQ Status is 18000 omap_hsmmc omap_hsmmc.1: MMC IRQ 0x18000 : ERRI CTO mmc1: req done (CMD8): -110: So CMD 52,5 and 8 gives me timeout... For SD cards, these cmd's are expected to timeout during card initialization. Looking at the 3.11.1 there is 2 more validation for UHS that are not in 3.4.60: omap_hsmmc_set_clock // Enable High-Speed Support omap_set_bus_width Those changes are not for SD3.0 speed modes Is it safe to use SDXC with OMAP35x or not? Should this pop a error message? SDXC cards should work albeit at High Speed mode (as in SD2.0). Refer to [1] for card size Vs speed mode/SD spec version. Can you check if the filesystem type on SDXC card is supported by the system software running on OMAP35x. [1] https://www.sdcard.org/consumers/speed/bus_speed/ Best Regards, -KA -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: dts: dra7-evm: add support for sd, eMMC
On 08/26/2013 08:53 AM, Balaji T K wrote: Add mmc1, mmc2 dt node to dra7-evm Balaji T K (2): ARM: dts: dra7-evm: Add mmc1 node for micro-sd support ARM: dts: dra7-evm: Add mmc2 node for eMMC support arch/arm/boot/dts/dra7-evm.dts | 20 1 files changed, 20 insertions(+), 0 deletions(-) Series: Acked-by: Nishanth Menon n...@ti.com Thanks. this is needed for MMC boot on DRA7 evm. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
* Luca Coelho l...@coelho.fi [130918 22:50]: On Wed, 2013-09-18 at 16:47 -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130918 11:00]: * Benoit Cousson bcous...@baylibre.com [130918 02:12]: Hi Tony, On 18/09/2013 02:02, Tony Lindgren wrote: * Luca Coelho l...@coelho.fi [130916 23:35]: On Tue, 2013-09-17 at 09:26 +0300, Luca Coelho wrote: Both patches look good to me, though I didn't have the time to retest them. Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :( OK no problem, I've tested it on panda es. Do we have someone out-there that still own a Blaze? Anyway, I'm about to send a DTS fix branch for -rc2, so I'll include these two patches. OK yes good please do pick them up, I'll drop them from my not-yet-pushed-out omap-for-v3.12/fixes. Hmm looks like there's also some new regression in the wl12xx driver: # iwconfig wlan0 wlan0 no wireless extensions. My test script was just doing: # iw dev wlan0 scan And that works fine. Luca, any ideas? Have you compiled WEXT support in your kernel? iwconfig uses the (deprecated) Wireless Extensions API. iw uses the current nl80211 API. If you want to use iwconfig and friends you need to enable CONFIG_CFG80211_WEXT. OK thanks, I don't need to use iwconfig. Looks like the default changed in commit 10bab00af (cfg80211: deprecate CFG80211_WEXT). Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am335x-boneblack: move fixed regulator to board level
3.3V fixed regulator does not belong to TPS node - as a result
the fixed regulator is never probed and MMC is continually deferred due
to lack of regulator.
Move the fixed regulator to be at root of platform.
Signed-off-by: Nishanth Menon n...@ti.com
---
Based on: (benoit's for_3.13/dts branch)
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
+
https://patchwork.kernel.org/patch/2902711/
Test Log:
before: http://pastebin.com/UuCsBg2d
After: http://pastebin.com/149FWujf
notice how vmmcsd_fixed: 3300 mV does not appear in the log before the patch.
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 56361ce..fe2742e 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -215,6 +215,13 @@
default-state = off;
};
};
+
+ vmmcsd_fixed: fixedregulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
};
/include/ tps65217.dtsi
@@ -259,13 +266,6 @@
regulator-always-on;
};
};
-
- vmmcsd_fixed: fixedregulator@0 {
- compatible = regulator-fixed;
- regulator-name = vmmcsd_fixed;
- regulator-min-microvolt = 330;
- regulator-max-microvolt = 330;
- };
};
cpsw_emac0 {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
On Thu, 2013-09-19 at 07:53 -0700, Tony Lindgren wrote: * Luca Coelho l...@coelho.fi [130918 22:50]: On Wed, 2013-09-18 at 16:47 -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130918 11:00]: * Benoit Cousson bcous...@baylibre.com [130918 02:12]: Hi Tony, On 18/09/2013 02:02, Tony Lindgren wrote: * Luca Coelho l...@coelho.fi [130916 23:35]: On Tue, 2013-09-17 at 09:26 +0300, Luca Coelho wrote: Both patches look good to me, though I didn't have the time to retest them. Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :( OK no problem, I've tested it on panda es. Do we have someone out-there that still own a Blaze? Anyway, I'm about to send a DTS fix branch for -rc2, so I'll include these two patches. OK yes good please do pick them up, I'll drop them from my not-yet-pushed-out omap-for-v3.12/fixes. Hmm looks like there's also some new regression in the wl12xx driver: # iwconfig wlan0 wlan0 no wireless extensions. My test script was just doing: # iw dev wlan0 scan And that works fine. Luca, any ideas? Have you compiled WEXT support in your kernel? iwconfig uses the (deprecated) Wireless Extensions API. iw uses the current nl80211 API. If you want to use iwconfig and friends you need to enable CONFIG_CFG80211_WEXT. OK thanks, I don't need to use iwconfig. Looks like the default changed in commit 10bab00af (cfg80211: deprecate CFG80211_WEXT). Yeah, it's not enabled by default anymore. And it was more than about time! ;) -- Luca. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello My Dear.
Hello My Dear, How are you today? I hope fine, I came across your contact today while browsing looking for reliable friend and i became interested, My name is miss Famatta Sando. I wish to have you as a friend, if you care. I have important reasons to request your interest for a serious friendship, i will be happy if you write me back, so that i can easily explain to you more about me and give you my picture for you to know whom i am, I have something very Important to tell you. Thanks for your understanding. Your New Friend. Miss Famatta. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.12-rc1: no longer compiles for Nokia n900 (omap based), display no longer works
Hi, On Thu, Sep 19, 2013 at 11:44:02AM +0200, Pavel Machek wrote: something in 3.12-rc1 broke display :-(. (dmesg diff attached at the end, maybe someone knows...) 3.12-rc1 for N900 compiles and works (also display) here with binutils 2.23.2. + omapfb omapfb: no displays [...] - acx565akm spi1.2: omapfb: acx565akm rev 12 LCD detected I think this is because the panel driver has changed, and the old one was deleted. You need to change your kernel configuration with something like below: -CONFIG_PANEL_ACX565AKM=y +CONFIG_DISPLAY_PANEL_SONY_ACX565AKM=y A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap5-uevm: mark TWL6037 as system-power-controller
This allows the palmas pm_power_off to kick in on power off command
and switch off the board.
Signed-off-by: Nishanth Menon n...@ti.com
---
Based on: (benoit's for_3.13/dts branch)
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
This uses the support introduced by:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b81eec09a484c588ead035003ce7555ca8a9963a
arch/arm/boot/dts/omap5-uevm.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index da25a14..8227386 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -271,6 +271,7 @@
reg = 0x48;
interrupt-controller;
#interrupt-cells = 2;
+ ti,system-power-controller;
extcon_usb3: palmas_usb {
compatible = ti,palmas-usb-vid;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RX-51: Add missing max_current to rx51_lp5523_led_config
On Thursday 19 September 2013 00:26:43 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130918 15:02]:
Without max_current data in board file lp5523 driver does
not change current.
Hmm is this a regression or are there other reasons to merge
this during the -rc cycle?
I think this is regression, drivers/leds/leds-lp55xx-common.c
code refuse to change led_current sysfs attribute if value is
higher than max_current specified in board file. And because in
board file max_current is not specified it is by default zero as
global variable. So changing led_current is not possible because
any positive value is more than zero. First I saw this behaviour
in 3.10, but I forgot to send this patch.
Regards,
Tony
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |9
+ 1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c index
9326890..d0f857c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -180,38 +180,47 @@ static struct lp55xx_led_config
rx51_lp5523_led_config[] = {
.name = lp5523:kb1,
.chan_nr= 0,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb2,
.chan_nr= 1,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb3,
.chan_nr= 2,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb4,
.chan_nr= 3,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:b,
.chan_nr= 4,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:g,
.chan_nr= 5,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:r,
.chan_nr= 6,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb5,
.chan_nr= 7,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb6,
.chan_nr= 8,
.led_current= 50,
+ .max_current= 255,
}
};
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 0/3] PM / OPP: rename to dev_pm_opp * equivalents
On 16:03-20130919, Nishanth Menon wrote: Hi, Based on [1], Randy rightly pointed out that OPP functions and data structures could be a bit specific to Power management. So, the following series is based on v3.12-rc1 tag. If folks like it broken in a different way, I am open to suggestions. Nishanth Menon (3): PM / OPP: rename functions to dev_pm_opp* PM / OPP: rename data structures to dev_pm equivalents PM / OPP: rename header to linux/pm_opp.h Documentation/power/opp.txt | 108 arch/arm/mach-imx/mach-imx6q.c |4 +- arch/arm/mach-omap2/board-omap3beagle.c | 10 +-- arch/arm/mach-omap2/omap-pm.h |2 +- arch/arm/mach-omap2/opp.c |6 +- arch/arm/mach-omap2/pm.c|8 +- drivers/base/power/opp.c| 115 - drivers/cpufreq/arm_big_little.c|8 +- drivers/cpufreq/arm_big_little_dt.c |2 +- drivers/cpufreq/cpufreq-cpu0.c | 24 +++--- drivers/cpufreq/exynos5440-cpufreq.c| 17 ++-- drivers/cpufreq/imx6q-cpufreq.c | 26 +++--- drivers/cpufreq/omap-cpufreq.c | 12 +-- drivers/devfreq/devfreq.c | 25 +++--- drivers/devfreq/exynos/exynos4_bus.c| 29 +++ drivers/devfreq/exynos/exynos5_bus.c| 28 +++ include/linux/devfreq.h |6 +- include/linux/opp.h | 134 - include/linux/pm_opp.h | 139 +++ 19 files changed, 357 insertions(+), 346 deletions(-) delete mode 100644 include/linux/opp.h create mode 100644 include/linux/pm_opp.h -- 1.7.9.5 Oops.. seems I deleted the link of the discussion - my bad... [1] http://marc.info/?t=13757946747r=1w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] PM / OPP: rename to dev_pm_opp * equivalents
Hi, Based on [1], Randy rightly pointed out that OPP functions and data structures could be a bit specific to Power management. So, the following series is based on v3.12-rc1 tag. If folks like it broken in a different way, I am open to suggestions. Nishanth Menon (3): PM / OPP: rename functions to dev_pm_opp* PM / OPP: rename data structures to dev_pm equivalents PM / OPP: rename header to linux/pm_opp.h Documentation/power/opp.txt | 108 arch/arm/mach-imx/mach-imx6q.c |4 +- arch/arm/mach-omap2/board-omap3beagle.c | 10 +-- arch/arm/mach-omap2/omap-pm.h |2 +- arch/arm/mach-omap2/opp.c |6 +- arch/arm/mach-omap2/pm.c|8 +- drivers/base/power/opp.c| 115 - drivers/cpufreq/arm_big_little.c|8 +- drivers/cpufreq/arm_big_little_dt.c |2 +- drivers/cpufreq/cpufreq-cpu0.c | 24 +++--- drivers/cpufreq/exynos5440-cpufreq.c| 17 ++-- drivers/cpufreq/imx6q-cpufreq.c | 26 +++--- drivers/cpufreq/omap-cpufreq.c | 12 +-- drivers/devfreq/devfreq.c | 25 +++--- drivers/devfreq/exynos/exynos4_bus.c| 29 +++ drivers/devfreq/exynos/exynos5_bus.c| 28 +++ include/linux/devfreq.h |6 +- include/linux/opp.h | 134 - include/linux/pm_opp.h | 139 +++ 19 files changed, 357 insertions(+), 346 deletions(-) delete mode 100644 include/linux/opp.h create mode 100644 include/linux/pm_opp.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] PM / OPP: rename header to linux/pm_opp.h
Since Operating Performance Points(OPP) functions are specific to
device specific power management, be specific and rename opp.h
to pm_opp.h
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/power/opp.txt |2 +-
arch/arm/mach-imx/mach-imx6q.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/omap-pm.h |2 +-
arch/arm/mach-omap2/opp.c |2 +-
arch/arm/mach-omap2/pm.c|2 +-
drivers/base/power/opp.c|2 +-
drivers/cpufreq/arm_big_little.c|2 +-
drivers/cpufreq/arm_big_little_dt.c |2 +-
drivers/cpufreq/cpufreq-cpu0.c |2 +-
drivers/cpufreq/exynos5440-cpufreq.c|2 +-
drivers/cpufreq/imx6q-cpufreq.c |2 +-
drivers/cpufreq/omap-cpufreq.c |2 +-
drivers/devfreq/devfreq.c |2 +-
drivers/devfreq/exynos/exynos4_bus.c|2 +-
drivers/devfreq/exynos/exynos5_bus.c|4 ++--
include/linux/devfreq.h |2 +-
include/linux/{opp.h = pm_opp.h} |0
18 files changed, 18 insertions(+), 18 deletions(-)
rename include/linux/{opp.h = pm_opp.h} (100%)
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 7f67e3d..b8a907d 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -42,7 +42,7 @@ We can represent these as three OPPs as the following {Hz,
uV} tuples:
OPP library provides a set of helper functions to organize and query the OPP
information. The library is located in drivers/base/power/opp.c and the header
-is located in include/linux/opp.h. OPP library can be enabled by enabling
+is located in include/linux/pm_opp.h. OPP library can be enabled by enabling
CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on
CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to
optionally boot at a certain OPP without needing cpufreq.
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index dfbf6f2..86dea10 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -25,7 +25,7 @@
#include linux/of_address.h
#include linux/of_irq.h
#include linux/of_platform.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/phy.h
#include linux/reboot.h
#include linux/regmap.h
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 33969e5..6432ab8 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -25,7 +25,7 @@
#include linux/gpio.h
#include linux/input.h
#include linux/gpio_keys.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/cpu.h
#include linux/mtd/mtd.h
diff --git a/arch/arm/mach-omap2/omap-pm.h b/arch/arm/mach-omap2/omap-pm.h
index 67faa7b..1d777e6 100644
--- a/arch/arm/mach-omap2/omap-pm.h
+++ b/arch/arm/mach-omap2/omap-pm.h
@@ -17,7 +17,7 @@
#include linux/device.h
#include linux/cpufreq.h
#include linux/clk.h
-#include linux/opp.h
+#include linux/pm_opp.h
/*
* agent_id values for use with omap_pm_set_min_bus_tput():
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 7b04637..ec21e6e 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -17,7 +17,7 @@
* GNU General Public License for more details.
*/
#include linux/module.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/cpu.h
#include omap_device.h
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 92901bd..2f569b3 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -13,7 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/err.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/export.h
#include linux/suspend.h
#include linux/cpu.h
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 693e14a..fa41874 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -21,7 +21,7 @@
#include linux/list.h
#include linux/rculist.h
#include linux/rcupdate.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/of.h
#include linux/export.h
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 9e82a9d..e010fb7 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -25,7 +25,7 @@
#include linux/cpumask.h
#include linux/export.h
#include linux/of_platform.h
-#include linux/opp.h
+#include linux/pm_opp.h
#include linux/slab.h
#include linux/topology.h
#include linux/types.h
diff --git a/drivers/cpufreq/arm_big_little_dt.c
b/drivers/cpufreq/arm_big_little_dt.c
index 480c0bd..8d9d591 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -24,7 +24,7 @@
#include linux/export.h
#include linux/module.h
#include
[PATCH 1/3] PM / OPP: rename functions to dev_pm_opp*
Since Operating Performance Points(OPP) functions are specific to
device specific power management, be specific and rename opp_*
accessors in OPP library with dev_pm_opp_* equivalent.
Impacted functions are:
opp_get_voltage
opp_get_freq
opp_get_opp_count
opp_find_freq_exact
opp_find_freq_floor
opp_find_freq_ceil
opp_add
opp_enable
opp_disable
opp_get_notifier
opp_init_cpufreq_table
opp_free_cpufreq_table
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/power/opp.txt | 102 +++
arch/arm/mach-imx/mach-imx6q.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |8 +--
arch/arm/mach-omap2/opp.c |4 +-
arch/arm/mach-omap2/pm.c|4 +-
drivers/base/power/opp.c| 82 -
drivers/cpufreq/arm_big_little.c|6 +-
drivers/cpufreq/cpufreq-cpu0.c | 18 +++---
drivers/cpufreq/exynos5440-cpufreq.c| 13 ++--
drivers/cpufreq/imx6q-cpufreq.c | 20 +++---
drivers/cpufreq/omap-cpufreq.c |8 +--
drivers/devfreq/devfreq.c | 14 ++---
drivers/devfreq/exynos/exynos4_bus.c| 21 ---
drivers/devfreq/exynos/exynos5_bus.c| 18 +++---
include/linux/opp.h | 50 +++
15 files changed, 187 insertions(+), 183 deletions(-)
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 425c51d..185367b 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -71,14 +71,14 @@ operations until that OPP could be re-enabled if possible.
OPP library facilitates this concept in it's implementation. The following
operational functions operate only on available opps:
-opp_find_freq_{ceil, floor}, opp_get_voltage, opp_get_freq, opp_get_opp_count
-and opp_init_cpufreq_table
+opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq,
dev_pm_opp_get_opp_count
+and dev_pm_opp_init_cpufreq_table
-opp_find_freq_exact is meant to be used to find the opp pointer which can then
-be used for opp_enable/disable functions to make an opp available as required.
+dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which
can then
+be used for dev_pm_opp_enable/disable functions to make an opp available as
required.
WARNING: Users of OPP library should refresh their availability count using
-get_opp_count if opp_enable/disable functions are invoked for a device, the
+get_opp_count if dev_pm_opp_enable/disable functions are invoked for a device,
the
exact mechanism to trigger these or the notification mechanism to other
dependent subsystems such as cpufreq are left to the discretion of the SoC
specific framework which uses the OPP library. Similar care needs to be taken
@@ -96,24 +96,24 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor},
opp_get_{voltage, freq, opp_count} fall into this category.
opp_{add,enable,disable} are updaters which use mutex and implement it's own
-RCU locking mechanisms. opp_init_cpufreq_table acts as an updater and uses
+RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and
uses
mutex to implment RCU updater strategy. These functions should *NOT* be called
under RCU locks and other contexts that prevent blocking functions in RCU or
mutex operations from working.
2. Initial OPP List Registration
-The SoC implementation calls opp_add function iteratively to add OPPs per
+The SoC implementation calls dev_pm_opp_add function iteratively to add OPPs
per
device. It is expected that the SoC framework will register the OPP entries
optimally- typical numbers range to be less than 5. The list generated by
registering the OPPs is maintained by OPP library throughout the device
operation. The SoC framework can subsequently control the availability of the
-OPPs dynamically using the opp_enable / disable functions.
+OPPs dynamically using the dev_pm_opp_enable / disable functions.
-opp_add - Add a new OPP for a specific domain represented by the device
pointer.
+dev_pm_opp_add - Add a new OPP for a specific domain represented by the device
pointer.
The OPP is defined using the frequency and voltage. Once added, the OPP
is assumed to be available and control of it's availability can be done
- with the opp_enable/disable functions. OPP library internally stores
+ with the dev_pm_opp_enable/disable functions. OPP library internally
stores
and manages this information in the opp struct. This function may be
used by SoC framework to define a optimal list as per the demands of
SoC usage environment.
@@ -124,7 +124,7 @@ opp_add - Add a new OPP for a specific domain represented
by the device pointer.
soc_pm_init()
{
/* Do things */
- r = opp_add(mpu_dev, 100, 90);
+ r
[PATCH 2/3] PM / OPP: rename data structures to dev_pm equivalents
Since Operating Performance Points(OPP) data structures are specific
to device specific power management, be specific and rename opp_* data
structures in OPP library with dev_pm_opp_* equivalent.
Impacted structures are:
struct opp
enum opp_event
Minor checkpatch warning fixes as a result of this change was fixed as
well.
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Nishanth Menon n...@ti.com
---
Documentation/power/opp.txt |4 ++--
arch/arm/mach-omap2/pm.c |2 +-
drivers/base/power/opp.c | 41 ++
drivers/cpufreq/cpufreq-cpu0.c |4 ++--
drivers/cpufreq/exynos5440-cpufreq.c |2 +-
drivers/cpufreq/imx6q-cpufreq.c |4 ++--
drivers/cpufreq/omap-cpufreq.c |2 +-
drivers/devfreq/devfreq.c|9
drivers/devfreq/exynos/exynos4_bus.c |6 ++---
drivers/devfreq/exynos/exynos5_bus.c |6 ++---
include/linux/devfreq.h |4 ++--
include/linux/opp.h | 29 +---
12 files changed, 60 insertions(+), 53 deletions(-)
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 185367b..7f67e3d 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -358,14 +358,14 @@ accessed by various functions as described above.
However, the structures
representing the actual OPPs and domains are internal to the OPP library itself
to allow for suitable abstraction reusable across systems.
-struct opp - The internal data structure of OPP library which is used to
+struct dev_pm_opp - The internal data structure of OPP library which is used to
represent an OPP. In addition to the freq, voltage, availability
information, it also contains internal book keeping information required
for the OPP library to operate on. Pointer to this structure is
provided back to the users such as SoC framework to be used as a
identifier for OPP in the interactions with OPP layer.
- WARNING: The struct opp pointer should not be parsed or modified by the
+ WARNING: The struct dev_pm_opp pointer should not be parsed or modified
by the
users. The defaults of for an instance is populated by dev_pm_opp_add,
but the
availability of the OPP can be modified by dev_pm_opp_enable/disable
functions.
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 937744c..92901bd 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -131,7 +131,7 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
{
struct voltagedomain *voltdm;
struct clk *clk;
- struct opp *opp;
+ struct dev_pm_opp *opp;
unsigned long freq, bootup_volt;
struct device *dev;
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 00c6a44..693e14a 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -42,7 +42,7 @@
*/
/**
- * struct opp - Generic OPP description structure
+ * struct dev_pm_opp - Generic OPP description structure
* @node: opp list node. The nodes are maintained throughout the lifetime
* of boot. It is expected only an optimal set of OPPs are
* added to the library by the SoC framework.
@@ -59,7 +59,7 @@
*
* This structure stores the OPP information for a given device.
*/
-struct opp {
+struct dev_pm_opp {
struct list_head node;
bool available;
@@ -150,9 +150,9 @@ static struct device_opp *find_device_opp(struct device
*dev)
* prior to unlocking with rcu_read_unlock() to maintain the integrity of the
* pointer.
*/
-unsigned long dev_pm_opp_get_voltage(struct opp *opp)
+unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
{
- struct opp *tmp_opp;
+ struct dev_pm_opp *tmp_opp;
unsigned long v = 0;
tmp_opp = rcu_dereference(opp);
@@ -180,9 +180,9 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage);
* prior to unlocking with rcu_read_unlock() to maintain the integrity of the
* pointer.
*/
-unsigned long dev_pm_opp_get_freq(struct opp *opp)
+unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
{
- struct opp *tmp_opp;
+ struct dev_pm_opp *tmp_opp;
unsigned long f = 0;
tmp_opp = rcu_dereference(opp);
@@ -209,7 +209,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq);
int dev_pm_opp_get_opp_count(struct device *dev)
{
struct device_opp *dev_opp;
- struct opp *temp_opp;
+ struct dev_pm_opp *temp_opp;
int count = 0;
dev_opp = find_device_opp(dev);
@@ -254,11 +254,12 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_get_opp_count);
* under the locked area. The pointer returned must be used prior to unlocking
* with rcu_read_unlock() to maintain the integrity of the pointer.
*/
-struct opp *dev_pm_opp_find_freq_exact(struct device *dev, unsigned long freq,
-
Re: [PATCH] RX-51: Add missing max_current to rx51_lp5523_led_config
* Pali Rohár pali.ro...@gmail.com [130919 14:10]: On Thursday 19 September 2013 00:26:43 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [130918 15:02]: Without max_current data in board file lp5523 driver does not change current. Hmm is this a regression or are there other reasons to merge this during the -rc cycle? I think this is regression, drivers/leds/leds-lp55xx-common.c code refuse to change led_current sysfs attribute if value is higher than max_current specified in board file. And because in board file max_current is not specified it is by default zero as global variable. So changing led_current is not possible because any positive value is more than zero. First I saw this behaviour in 3.10, but I forgot to send this patch. OK thanks, can you please update the patch description with that so I can merge it for the -rc cycle? Ideally of course with the breaking commit too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/51] DMA mask changes
This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM - notably how the DMA mask should be setup. However, I started off reviewing how the dma_mask and coherent_dma_mask was being used, and what I found was rather messy, and in some cases rather buggy. I tried to get some of the bug fixes in before the last merge window, but it seems that the maintainers preferred to have the full solution rather than a simple -rc suitable bug fix. So, this is an attempt to clean things up. The first point here is that drivers performing DMA should be calling dma_set_mask()/dma_set_coherent_mask() in their probe function to verify that DMA can be performed. Lots of ARM drivers omit this step; please refer to the DMA API documentation on this subject. What this means is that the DMA mask provided by bus code is a default value - nothing more. It doesn't have to accurately reflect what the device is actually capable of. Apart from the storage for dev-dma_mask being initialised for any device which is DMA capable, there is no other initialisation which is strictly necessary at device creation time. Now, these cleanups address two major areas: 1. The setting of DMA masks, particularly when both the coherent and streaming DMA masks are set together. 2. The initialisation of DMA masks by drivers - this seems to be becoming a popular habbit, one which may not be entirely the right solution. Rather than having this scattered throughout the tree, I've pulled that into a central location (and called it coercing the DMA mask - because it really is about forcing the DMA mask to be that value.) 3. Finally, addressing the long held misbelief that DMA masks somehow correspond with physical addresses. We already have established long ago that dma_addr_t values returned from the DMA API are the values which you program into the DMA controller, and so are the bus addresses. It is _only_ sane that DMA masks are also bus related too, and not related to physical address spaces. (3) is a very important point for LPAE systems, which may still have less than 4GB of memory, but this memory is all located above the 4GB physical boundary. This means with the current model, any device using a 32-bit DMA mask fails - even though the DMA controller is still only a 32-bit DMA controller but the 32-bit bus addresses map to system memory. To put it another way, the bus addresses have a 4GB physical offset on them. This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Patches based on v3.12-rc1. Documentation/DMA-API-HOWTO.txt | 37 +-- Documentation/DMA-API.txt |8 +++ arch/arm/include/asm/dma-mapping.h|8 +++ arch/arm/mm/dma-mapping.c | 49 ++-- arch/arm/mm/init.c| 12 +++--- arch/arm/mm/mm.h |2 + arch/powerpc/kernel/vio.c |3 +- block/blk-settings.c |8 ++-- drivers/amba/bus.c|6 +-- drivers/ata/pata_ixp4xx_cf.c |5 ++- drivers/ata/pata_octeon_cf.c |5 +- drivers/block/nvme-core.c | 10 ++--- drivers/crypto/ixp4xx_crypto.c| 48 ++-- drivers/dma/amba-pl08x.c |5 ++ drivers/dma/dw/platform.c |8 +-- drivers/dma/edma.c|6 +-- drivers/dma/pl330.c |4 ++ drivers/firmware/dcdbas.c | 23 +- drivers/firmware/google/gsmi.c| 13 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +- drivers/media/platform/omap3isp/isp.c |6 +- drivers/media/platform/omap3isp/isp.h |3 - drivers/mmc/card/queue.c |3 +- drivers/mmc/host/sdhci-acpi.c |5 +- drivers/net/ethernet/broadcom/b44.c |3 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 +--- drivers/net/ethernet/brocade/bna/bnad.c | 13 ++ drivers/net/ethernet/emulex/benet/be_main.c | 12 + drivers/net/ethernet/intel/e1000/e1000_main.c |9 +--- drivers/net/ethernet/intel/e1000e/netdev.c| 18 +++- drivers/net/ethernet/intel/igb/igb_main.c | 18 +++- drivers/net/ethernet/intel/igbvf/netdev.c | 18 +++- drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 ++- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
Re: [PATCH v2] ADP1653 board code for Nokia RX-51
On Wednesday 18 September 2013 19:42:12 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [130918 09:08]: On Wednesday 18 September 2013 15:16:44 Pavel Machek wrote: On Sun 2013-09-08 02:02:52, Aaro Koskinen wrote: Hi, On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote: --- /dev/null +++ b/arch/arm/mach-omap2/board-rx51-camera.c [...] Ping, can you review this patch v2? I don't think Tony will accept any new board stuff for RX-51/N900. See for example: http://marc.info/?l=linux-kernelm=137629626213187w=2 There should be initial Nokia N900 DTS file in 3.12-rc1, and we should continue converting this board fully to DT. That's not reasonable. N900 is pretty far away from working with device tree. Yes, I was able to get some bits merged, but that should not be excuse to halt other N900 development. Pavel Right. So Tony, will you accept future patches for board files? Only fixes to board-*.c files please unless there's a _really_ good reason to make things more complex with the platform data. Let's not make the DT conversion any more complex than it already is. Getting things working with DT for the devices is pretty trivial in most cases. And we can also still initialize the legacy devices using platform data the same way as earlier. Regards, Tony So, what to this with this patch v2 (it was sent 06.03.2013)? It adding board support for ADP1653 flash torch which is part of rx51 camera code. Driver itself is already in kernel tree. Can you comment/review this patch? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] RX-51: Add missing max_current to rx51_lp5523_led_config
On Thursday 19 September 2013 23:29:22 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130919 14:10]:
On Thursday 19 September 2013 00:26:43 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [130918 15:02]:
Without max_current data in board file lp5523 driver
does not change current.
Hmm is this a regression or are there other reasons to
merge this during the -rc cycle?
I think this is regression,
drivers/leds/leds-lp55xx-common.c code refuse to change
led_current sysfs attribute if value is higher than
max_current specified in board file. And because in board
file max_current is not specified it is by default zero as
global variable. So changing led_current is not possible
because any positive value is more than zero. First I saw
this behaviour in 3.10, but I forgot to send this patch.
OK thanks, can you please update the patch description with
that so I can merge it for the -rc cycle? Ideally of course
with the breaking commit too.
Regards,
Tony
I do not know which commit broke it. There was some change in lp driver which
caused that driver not worked with testing applications. Now it should be fixed.
So I resending my patch with updated description.
RX-51: Add missing max_current to rx51_lp5523_led_config
File drivers/leds/leds-lp55xx-common.c refuse to change led_current sysfs
attribute if value is higher than max_current specified in board file. By
default
global C variables are zero, so changing always failed. This patch adding
missing
max_current and setting it to max value 255.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9326890..d0f857c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -180,38 +180,47 @@ static struct lp55xx_led_config rx51_lp5523_led_config[]
= {
.name = lp5523:kb1,
.chan_nr= 0,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb2,
.chan_nr= 1,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb3,
.chan_nr= 2,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb4,
.chan_nr= 3,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:b,
.chan_nr= 4,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:g,
.chan_nr= 5,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:r,
.chan_nr= 6,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb5,
.chan_nr= 7,
.led_current= 50,
+ .max_current= 255,
}, {
.name = lp5523:kb6,
.chan_nr= 8,
.led_current= 50,
+ .max_current= 255,
}
};
--
1.7.10.4
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[PATCH 02/51] DMA-API: net: brocade/bna/bnad.c: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err)
goto release_regions;
}
This means we only try and set the coherent DMA mask if we failed to
set a 32-bit DMA mask, and only if both fail do we fail the driver.
Adjust this so that if either setting fails, we fail the driver - and
thereby end up properly setting both the DMA mask and the coherent
DMA mask in the fallback case.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/brocade/bna/bnad.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c
b/drivers/net/ethernet/brocade/bna/bnad.c
index b78e69e..45ce6e2 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3300,17 +3300,12 @@ bnad_pci_init(struct bnad *bnad,
err = pci_request_regions(pdev, BNAD_NAME);
if (err)
goto disable_device;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
- if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err)
- goto release_regions;
- }
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (err)
+ goto release_regions;
*using_dac = false;
}
pci_set_master(pdev);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/51] DMA-API: net: intel/igb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/igb/igb_main.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 8cf44f2..7579383 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2034,21 +2034,15 @@ static int igb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
Documentation/DMA-API-HOWTO.txt | 37 ++---
Documentation/DMA-API.txt |8
include/linux/dma-mapping.h | 14 ++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 14129f1..5e98303 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -101,14 +101,23 @@ style to do this even if your device holds the default
setting,
because this shows that you did think about these issues wrt. your
device.
-The query is performed via a call to dma_set_mask():
+The query is performed via a call to dma_set_mask_and_coherent():
- int dma_set_mask(struct device *dev, u64 mask);
+ int dma_set_mask_and_coherent(struct device *dev, u64 mask);
-The query for consistent allocations is performed via a call to
-dma_set_coherent_mask():
+which will query the mask for both streaming and coherent APIs together.
+If you have some special requirements, then the following two separate
+queries can be used instead:
- int dma_set_coherent_mask(struct device *dev, u64 mask);
+ The query for streaming mappings is performed via a call to
+ dma_set_mask():
+
+ int dma_set_mask(struct device *dev, u64 mask);
+
+ The query for consistent allocations is performed via a call
+ to dma_set_coherent_mask():
+
+ int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
@@ -137,7 +146,7 @@ exactly why.
The standard 32-bit addressing device would do something like this:
- if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
mydev: No suitable DMA available.\n);
goto ignore_this_device;
@@ -171,22 +180,20 @@ If a card is capable of using 64-bit consistent
allocations as well,
int using_dac, consistent_using_dac;
- if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
- } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
mydev: No suitable DMA available.\n);
goto ignore_this_device;
}
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will always be able to set the same or a
+smaller mask as the streaming mask. However for the rare case that a
device driver only uses consistent allocations, one would have to
check the return value from dma_set_coherent_mask().
@@ -199,9 +206,9 @@ Finally, if your device can only drive the low 24-bits of
goto ignore_this_device;
}
-When dma_set_mask() is successful, and returns zero, the kernel saves
-away this mask you have provided. The kernel will use this
-information later when you make DMA mappings.
+When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
+returns zero, the kernel saves away this mask you have provided. The
+kernel will use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 78a6c56..e865279 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -142,6 +142,14 @@ internal API for use by the platform than an external API
for use by
driver writers.
int
+dma_set_mask_and_coherent(struct device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+streaming and coherent DMA mask parameters if it is.
+
+Returns: 0 if successful and a negative error if not.
+
+int
dma_set_mask(struct device *dev, u64 mask)
Checks to see if the mask is possible and updates the device
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 3a8d0a2..ec951f9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -97,6 +97,20 @@ static
[PATCH 03/51] DMA-API: net: intel/e1000e: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/e1000e/netdev.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index e87e9b0..519e293 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6553,21 +6553,15 @@ static int e1000_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/51] DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev, No usable DMA
configuration, aborting\n);
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/igbvf/netdev.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c
b/drivers/net/ethernet/intel/igbvf/netdev.c
index 93eb7ee..4e6b02f 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2638,21 +2638,15 @@ static int igbvf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev, No usable DMA
- configuration, aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev, No usable DMA
+ configuration, aborting\n);
+ goto err_dma;
}
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
pr_err(No usable DMA configuration,
aborting\n);
goto err_dma_mask;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index 9f6b236..57e390c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -408,20 +408,14 @@ ixgb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- pr_err(No usable DMA configuration,
aborting\n);
- goto err_dma_mask;
- }
+ pr_err(No usable DMA configuration, aborting\n);
+ goto err_dma_mask;
}
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/51] DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev,
No usable DMA configuration,
aborting\n);
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7aba452..b1dc844 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7475,19 +7475,14 @@ static int ixgbe_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev,
- No usable DMA configuration,
aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev,
+ No usable DMA configuration, aborting\n);
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/51] DMA-API: net: intel/ixgbevf: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
!dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(pdev-dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(pdev-dev, No usable DMA
configuration, aborting\n);
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 59a62bb..e34c2da 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -3326,19 +3326,14 @@ static int ixgbevf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(pdev-dev, DMA_BIT_MASK(64))
- !dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(pdev-dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(pdev-dev, No usable DMA
- configuration, aborting\n);
- goto err_dma;
- }
+ dev_err(pdev-dev, No usable DMA
+ configuration, aborting\n);
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: Provide a helper to set both the DMA and coherent DMA masks to the same value - this avoids duplicated code in a number of drivers, sometimes with buggy error handling, and also allows us identify which drivers do things differently. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Documentation/DMA-API-HOWTO.txt | 37 ++--- Documentation/DMA-API.txt |8 include/linux/dma-mapping.h | 14 ++ 3 files changed, 44 insertions(+), 15 deletions(-) diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 14129f1..5e98303 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt [...] -dma_set_coherent_mask() will always be able to set the same or a -smaller mask as dma_set_mask(). However for the rare case that a +The coherent coherent mask will always be able to set the same or a +smaller mask as the streaming mask. However for the rare case that a [...] The new wording doesn't make sense; a mask doesn't set itself. I would suggest: The coherent mask can always be set to the same or a smaller mask than the streaming mask. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 35/51] DMA-API: parport: parport_pc.c: use dma_coerce_mask_and_coherent()
The code sequence:
dev-coherent_dma_mask = DMA_BIT_MASK(24);
dev-dma_mask = dev-coherent_dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/parport/parport_pc.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 903e128..9637615 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2004,6 +2004,7 @@ struct parport *parport_pc_probe_port(unsigned long int
base,
struct resource *ECR_res = NULL;
struct resource *EPP_res = NULL;
struct platform_device *pdev = NULL;
+ int ret;
if (!dev) {
/* We need a physical device to attach to, but none was
@@ -2014,8 +2015,11 @@ struct parport *parport_pc_probe_port(unsigned long int
base,
return NULL;
dev = pdev-dev;
- dev-coherent_dma_mask = DMA_BIT_MASK(24);
- dev-dma_mask = dev-coherent_dma_mask;
+ ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(24));
+ if (ret) {
+ dev_err(dev, Unable to set coherent dma mask:
disabling DMA\n);
+ dma = PARPORT_DMA_NONE;
+ }
}
ops = kmalloc(sizeof(struct parport_operations), GFP_KERNEL);
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This avoids a direct reference to the DMA
masks by this driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/edma.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..7f9fe30 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
static const struct platform_device_info edma_dev_info0 = {
.name = edma-dma-engine,
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
};
static const struct platform_device_info edma_dev_info1 = {
.name = edma-dma-engine,
.id = 1,
+ .dma_mask = DMA_BIT_MASK(32),
};
static int edma_init(void)
@@ -720,8 +722,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
- pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
- pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
if (EDMA_CTLRS == 2) {
@@ -731,8 +731,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
- pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
- pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
out:
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 44/51] DMA-API: dcdbas: update DMA mask handing
dcdbas was explicitly initializing DMA masks thusly:
dcdbas_pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
dcdbas_pdev-dev.dma_mask = dcdbas_pdev-dev.coherent_dma_mask;
which bypasses the architecture check. Moreover, it is creating the
dcdbas_pdev device itself, and using the platform_device_register_full()
avoids some of this explicit initialization.
Convert the driver to use platform_device_register_full(), and as it
makes use of coherent DMA, also call dma_set_coherent_mask() to ensure
that the architecture gets to check the mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/firmware/dcdbas.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index ff080ee..a85fda2 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -549,8 +549,9 @@ static int dcdbas_probe(struct platform_device *dev)
* BIOS SMI calls require buffer addresses be in 32-bit address space.
* This is done by setting the DMA mask below.
*/
- dcdbas_pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
- dcdbas_pdev-dev.dma_mask = dcdbas_pdev-dev.coherent_dma_mask;
+ error = dma_set_coherent_mask(dcdbas_pdev-dev, DMA_BIT_MASK(32));
+ if (error)
+ return error;
error = sysfs_create_group(dev-dev.kobj, dcdbas_attr_group);
if (error)
@@ -581,6 +582,12 @@ static struct platform_driver dcdbas_driver = {
.remove = dcdbas_remove,
};
+static const struct platform_device_info dcdbas_dev_info __initdata = {
+ .name = DRIVER_NAME,
+ .id = -1,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
/**
* dcdbas_init: initialize driver
*/
@@ -592,20 +599,14 @@ static int __init dcdbas_init(void)
if (error)
return error;
- dcdbas_pdev = platform_device_alloc(DRIVER_NAME, -1);
- if (!dcdbas_pdev) {
- error = -ENOMEM;
+ dcdbas_pdev = platform_device_register_full(dcdbas_dev_info);
+ if (IS_ERR(dcdbas_pdev)) {
+ error = PTR_ERR(dcdbas_pdev);
goto err_unregister_driver;
}
- error = platform_device_add(dcdbas_pdev);
- if (error)
- goto err_free_device;
-
return 0;
- err_free_device:
- platform_device_put(dcdbas_pdev);
err_unregister_driver:
platform_driver_unregister(dcdbas_driver);
return error;
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 41/51] DMA-API: crypto: remove last references to 'static struct device *dev'
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/crypto/ixp4xx_crypto.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 8306185..214357e 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -221,7 +221,6 @@ static int support_aes = 1;
#define DRIVER_NAME ixp4xx_crypto
static struct platform_device *pdev;
-static struct device *dev;
static inline dma_addr_t crypt_virt2phys(struct crypt_ctl *virt)
{
@@ -250,6 +249,7 @@ static inline const struct ix_hash_algo *ix_hash(struct
crypto_tfm *tfm)
static int setup_crypt_desc(void)
{
+ struct device *dev = pdev-dev;
BUILD_BUG_ON(sizeof(struct crypt_ctl) != 64);
crypt_virt = dma_alloc_coherent(dev,
NPE_QLEN * sizeof(struct crypt_ctl),
@@ -350,6 +350,7 @@ static void finish_scattered_hmac(struct crypt_ctl *crypt)
static void one_packet(dma_addr_t phys)
{
+ struct device *dev = pdev-dev;
struct crypt_ctl *crypt;
struct ixp_ctx *ctx;
int failed;
@@ -419,7 +420,7 @@ static void crypto_done_action(unsigned long arg)
tasklet_schedule(crypto_done_tasklet);
}
-static int init_ixp_crypto(void)
+static int init_ixp_crypto(struct device *dev)
{
int ret = -ENODEV;
u32 msg[2] = { 0, 0 };
@@ -506,7 +507,7 @@ static int init_ixp_crypto(void)
return ret;
}
-static void release_ixp_crypto(void)
+static void release_ixp_crypto(struct device *dev)
{
qmgr_disable_irq(RECV_QID);
tasklet_kill(crypto_done_tasklet);
@@ -873,6 +874,7 @@ static int ablk_perform(struct ablkcipher_request *req, int
encrypt)
enum dma_data_direction src_direction = DMA_BIDIRECTIONAL;
struct ablk_ctx *req_ctx = ablkcipher_request_ctx(req);
struct buffer_desc src_hook;
+ struct device *dev = pdev-dev;
gfp_t flags = req-base.flags CRYPTO_TFM_REQ_MAY_SLEEP ?
GFP_KERNEL : GFP_ATOMIC;
@@ -997,6 +999,7 @@ static int aead_perform(struct aead_request *req, int
encrypt,
unsigned int cryptlen;
struct buffer_desc *buf, src_hook;
struct aead_ctx *req_ctx = aead_request_ctx(req);
+ struct device *dev = pdev-dev;
gfp_t flags = req-base.flags CRYPTO_TFM_REQ_MAY_SLEEP ?
GFP_KERNEL : GFP_ATOMIC;
@@ -1426,7 +1429,7 @@ static int __init ixp_module_init(void)
spin_lock_init(desc_lock);
spin_lock_init(emerg_lock);
- err = init_ixp_crypto();
+ err = init_ixp_crypto(pdev-dev);
if (err) {
platform_device_unregister(pdev);
return err;
@@ -1492,7 +1495,7 @@ static void __exit ixp_module_exit(void)
if (ixp4xx_algos[i].registered)
crypto_unregister_alg(ixp4xx_algos[i].crypto);
}
- release_ixp_crypto();
+ release_ixp_crypto(pdev-dev);
platform_device_unregister(pdev);
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 0/8] PHY framework
Hi Greg, On Tuesday 17 September 2013 09:11 PM, Felipe Balbi wrote: On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: Hi Greg, On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: Hi, On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing Looks like there are not further comments on this series. Can you take this in your misc tree? Do you want me to queue these for you ? There are quite a few users for this framework already and I know of at least 2 others which will show up for v3.13. Can you queue this patch series? There are quite a few users already for this framework. It will have to wait for 3.13 as the merge window for new features has been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 is out. Alright, thanks. Just a gentle ping on this one... Let me know if you want me to rebase this patch series on the latest mainline HEAD. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
